Otomasi Pemrosesan Invoice: Dari Email ke Akuntansi
Oleh Apex Horizon Digital
Otomasi pemrosesan invoice harus lebih dari membaca PDF dan menyalin angka ke akuntansi. Sistem harus mempertahankan dokumen sumber, mengenali supplier, memvalidasi field wajib, mendeteksi duplikat, mencocokkan bukti pembelian, merutekan exception, memperoleh approval yang tepat, memposting melalui interface terkontrol, dan merekonsiliasi hasil. Desain tingkat field membuat setiap keputusan terlihat dan mencegah data yang tidak pasti diam-diam menjadi entry akuntansi.
Ringkasan utama
- Pisahkan confidence ekstraksi dari validasi bisnis dan approval.
- Arahkan mismatch ke antrean spesifik dengan owner serta bukti.
- Konfirmasi record akuntansi dan rekonsiliasi setiap invoice sumber setelah posting.
Tangkap email dan pertahankan sumber
Mailbox atau kanal intake khusus menerima pesan, attachment, sender, timestamp, dan message identifier. Proses membuat kasus invoice sebelum mencoba ekstraksi, menyimpan file asli di lokasi terkontrol, dan menautkan file hash atau sinyal duplikat setara. Attachment dengan password, format tidak didukung, kosong, atau berisi banyak invoice masuk ke antrean exception capture. Sumber tetap tersedia selama review agar orang dapat membandingkan nilai ekstraksi dengan dokumen. Aturan retensi, akses, dan penghapusan harus mengikuti kebutuhan akuntansi serta privasi organisasi, bukan default tool otomasi.
- Field capture: message ID, sender, waktu diterima, nama file, jenis file, dan lokasi sumber.
- Field kasus: workflow ID, kanal intake, owner saat ini, status, dan alasan exception.
- Sinyal duplikat: supplier, nomor invoice, tanggal, jumlah, mata uang, dan identitas file.
Ekstrak field, lalu validasi secara independen
Ekstraksi mengusulkan nilai seperti nama supplier, nomor pajak, nomor invoice, tanggal invoice, jatuh tempo, mata uang, subtotal, pajak, total, purchase order, referensi bank, dan line item. Confidence dapat membantu memilih field yang perlu review, tetapi bukan validasi bisnis. Validasi memeriksa format, aritmetika, nilai wajib, aturan tanggal, master data supplier, dan riwayat duplikat. Total yang salah tidak boleh lolos hanya karena dokumen mudah dibaca. Simpan nilai ekstraksi, confidence, nilai normalisasi, hasil validasi, dan koreksi reviewer sebagai fakta terpisah.
- Validasi identitas: record supplier, data pajak, status approved, dan kontrol perubahan bank.
- Validasi dokumen: nomor invoice, tanggal, mata uang, total line, pajak, dan grand total.
- Validasi history: pencarian duplikat di kasus terbuka, posted, rejected, dan archived.
Cocokkan bukti pembelian dan penerimaan
Ketika invoice merujuk purchase order, proses mengambil item, kuantitas, harga, perlakuan pajak, dan supplier yang dipesan. Jika data penerimaan tersedia, proses juga mengambil kuantitas serta tanggal yang diterima. Aturan matching membandingkan line invoice dengan catatan tersebut memakai tolerance terdokumentasi. Mismatch tidak boleh disatukan menjadi satu status gagal. Pisahkan order hilang, item tidak dikenal, kuantitas berlebih, selisih harga, selisih pajak, dan receipt hilang karena owner-nya berbeda. Invoice jasa dapat memakai kontrak, milestone, atau konfirmasi pemohon sebagai pengganti goods receipt.
- Order match: supplier, item, unit, kuantitas, harga, mata uang, pajak, dan referensi.
- Receipt match: kuantitas diterima, lokasi, tanggal, dan bukti penerima.
- Hasil tolerance: aturan lolos, threshold terlewati, bukti tidak tersedia, atau review manual.
Arahkan exception dan approval dengan konteks
Setiap antrean exception membutuhkan owner, usia, tindakan yang diperlukan, dan titik resume aman. Purchasing menangani pertanyaan order, receiving menangani penerimaan, administrasi supplier menangani master data, dan finance menangani perlakuan akuntansi sesuai tanggung jawab organisasi. Reviewer perlu melihat dokumen sumber, field ekstraksi, record pasangan, perbedaan, dan aturan yang membuat exception. Setelah validasi, approval diarahkan berdasarkan jumlah, entitas, departemen, dan status exception. Penolakan mewajibkan alasan, sedangkan koreksi membuat versi baru. Approval harus merujuk data invoice yang persis sama dengan data yang diposting.
- Antrean ekstraksi: field wajib tidak terbaca atau confidence rendah.
- Antrean matching: bukti hilang atau selisih melewati tolerance yang disetujui.
- Antrean kontrol: sinyal duplikat, perubahan supplier, account tidak biasa, atau policy exception.
Posting, konfirmasi, dan rekonsiliasi entry akuntansi
Request posting memakai nilai tervalidasi dan transaction key stabil agar retry tidak membuat entry kedua. Response akuntansi diperiksa untuk status sukses, record identifier, nomor dokumen, dan field yang ditolak. Hasil tidak diketahui memicu rekonsiliasi sebelum percobaan lain. Setelah konfirmasi, workflow menautkan record akuntansi, dokumen sumber, approval, dan bukti matching, lalu memperbarui status kasus. Rekonsiliasi harian membandingkan semua kasus sumber yang diterima dengan record posted dan semua response posting dengan kasus sumber. Monitoring menampilkan kegagalan, usia exception, percobaan duplikat, dan kasus approved yang belum posted.
- Payload posting: entitas, supplier, tanggal, mata uang, account, pajak, dimensi, line, dan referensi.
- Konfirmasi: accounting ID, status posting, nomor dokumen, timestamp, dan validasi yang dikembalikan.
- Rekonsiliasi: kelengkapan sumber ke ledger, pencegahan duplikat, dan review hasil belum selesai.