Cara AI belajar dari koreksi tim Anda, dan apa yang mencegahnya mempelajari hal yang salah

Setiap bulan, sebuah perusahaan freight forwarder di Surabaya mengirimkan invoice dua halaman yang sama kepada Anda. Setiap bulan, AI capture di sistem AP Anda membaca nomor di pojok kanan atas, yang sebenarnya nomor surat jalan vendor, sebagai nomor invoice. Dan setiap bulan, seorang staf AP menghapusnya lalu mengetik nomor yang benar dari bagian bawah halaman pertama. Sampai Desember, koreksi yang sama sudah dilakukan dua belas kali, dan sistemnya tidak lebih pintar daripada di bulan Januari.

Sebagian besar tool AI capture menjanjikan solusinya: koreksi satu field sekali, dan berikutnya AI akan membacanya dengan benar. Janji itu nyata, tetapi cara AI belajar sama pentingnya dengan apakah AI belajar atau tidak. Sistem yang belajar dari setiap suntingan juga akan mempelajari salah ketik dan pengecualian sekali jalan, dan di bidang keuangan, salah satunya bisa berupa nomor rekening bank.

Panduan ini menjelaskan bagaimana AI belajar dari koreksi, apa yang seharusnya dan tidak seharusnya dipelajari, contoh sebuah aturan yang dipelajari lalu dilepas, dan cara menilai apakah AI yang membaca invoice dan struk Anda belajar dengan baik.

Apa artinya AI belajar dari koreksi?

Ketika software keuangan mengatakan AI-nya “belajar”, biasanya yang dimaksud adalah salah satu dari tiga hal ini:

1. Melatih ulang model bersama. Koreksi dari banyak pelanggan dikumpulkan dan dipakai untuk melatih ulang model milik vendor. Perbaikannya datang lambat, per rilis, dan dokumen Anda ikut memperbaiki model yang dipakai perusahaan lain.
2. Template dan aturan yang disiapkan manual. Seseorang memberi tahu sistem di mana letak setiap field pada invoice setiap vendor, atau vendor mana masuk ke kategori mana. Hasilnya presisi, tetapi harus ada yang menyusun dan merawatnya, dan template akan rusak begitu vendor mengubah tata letak invoice-nya.
3. Aturan yang dipelajari per perusahaan. Sistem mengubah koreksi tim Anda menjadi aturan singkat dalam bahasa sehari-hari, misalnya “pada invoice vendor ini, nomor invoice adalah nomor di bagian bawah halaman pertama, bukan nomor surat jalan”. AI menerima aturan perusahaan Anda setiap kali membaca dokumen Anda. Tidak ada model yang dilatih ulang, dan aturannya hanya dipakai untuk perusahaan Anda.

Cara ketiga beradaptasi secepat tim Anda mengoreksi, tanpa perlu ada yang menulis template. Namun cara ini juga paling berisiko jika dibangun sembarangan, karena apa pun yang dilakukan tim Anda menjadi perilaku AI. Bagian selanjutnya dari panduan ini membahas cara melakukannya dengan benar. Pertanyaan yang sama berlaku untuk AI agent, yang belajar dari run yang ditinjau tim Anda, tetapi fokus panduan ini adalah AI yang membaca dokumen.

Apa yang dipelajari sistem yang hati-hati, dan apa yang diabaikannya

• Keputusan, bukan ketikan. Belajar dari nilai yang diajukan atau disetujui seseorang, bukan dari setiap suntingan di draf. Salah ketik yang dibuat lalu diperbaiki sebelum pengajuan seharusnya tidak mengajarkan apa pun.
• Satu field dalam satu waktu. Sebuah koreksi adalah satu field tertentu: nomor invoice, total, kategori. Dengan begitu setiap aturan cukup kecil untuk diperiksa.
• Cakupan yang tepat. Sebagian besar aturan berlaku untuk satu vendor atau merchant. Hanya sedikit yang berlaku untuk semua dokumen, misalnya membaca tanggal dengan urutan hari, bulan, tahun.
• Bukti, bukan satu contoh. Satu koreksi bisa saja kejadian sekali. Sebuah aturan baru boleh diterapkan setelah koreksi yang sama dilakukan lebih dari sekali.
• Bukti lebih banyak untuk field uang. Deskripsi yang salah dipelajari hanya merepotkan; nomor rekening yang salah dipelajari berarti pembayaran ke pihak yang salah. Nominal, pajak, mata uang dan detail bank seharusnya memerlukan bukti lebih banyak, termasuk koreksi yang dibuat oleh approver.
• Ada cara untuk melepas aturan. Ketika orang terus mengubah nilai yang diisi oleh sebuah aturan, aturan itu seharusnya berhenti dipakai.
• Dihitung, bukan ditebak. Jika Anda bertanya kepada model bahasa seberapa yakin ia, Anda akan mendapat angka yang terdengar presisi tetapi tidak terkalibrasi dengan baik. Menghitung koreksi yang mendukung sebuah aturan dan yang bertentangan dengannya memberi ambang batas yang bisa diandalkan.
• Hanya untuk perusahaan Anda. Koreksi Anda seharusnya memperbaiki hasil Anda, bukan hasil perusahaan lain.

Contoh kasus: satu aturan, dipelajari lalu dilepas

Berikut perjalanan nomor invoice dari freight forwarder tadi selama enam bulan. Sebagai contoh, misalkan sebuah aturan mulai diterapkan setelah didukung dua koreksi, dan dipensiunkan ketika bukti yang menentangnya menyamai bukti yang mendukungnya. Ketika aturan mengisi sebuah field dan tim mempertahankan nilainya, itu dihitung sebagai dukungan; ketika tim mengubahnya, itu dihitung sebagai bantahan.

Invoice	Yang terjadi	Dukung	Bantah
Januari	AP mengganti nomor surat jalan dengan nomor invoice	1	0
Februari	Koreksi yang sama lagi, sehingga aturan mulai diterapkan	2	0
Maret	Aturan memilih nomor yang benar, dan tidak ada yang mengubahnya	3	0
April	Vendor mengubah tata letak, dan AP mengoreksi nomor yang dipilih aturan	3	1
Mei	Koreksi yang sama	3	2
Juni	Koreksi yang sama lagi, sehingga aturan dipensiunkan	3	3

Ada tiga hal yang perlu diperhatikan:

• Bulan Maret adalah intinya. Tidak ada yang menyentuh nomor invoice. Ulangi hal itu untuk setiap vendor yang punya kebiasaan uniknya sendiri, dan waktu mengetik yang dihemat menjadi signifikan.
• Satu invoice yang janggal tidak membatalkan aturan yang sudah terbukti. Koreksi di bulan April dihitung sebagai bantahan tetapi tidak langsung memensiunkan aturannya, karena aturan itu punya riwayat dukungan yang lebih banyak. Aturan dengan rekam jejak seharusnya tidak runtuh hanya karena satu pengecualian.
• Perubahan dari vendor bisa diserap. Di bulan Juni bukti yang menentang sudah menyamai bukti yang mendukung, aturan berhenti dipakai dan AI membaca tata letak baru dari awal. Jika tim terus mengoreksinya dengan cara yang sama, aturan baru akan mulai dihitung dari nol.

Mengapa proses belajar AI sering keliru dalam praktik

• Belajar dari draf. Setiap suntingan dianggap pelajaran, sehingga salah ketik yang diperbaiki dua detik kemudian menjadi aturan.
• Belajar dari satu contoh. Satu invoice yang tidak biasa, seperti nota kredit atau jasa sekali jalan, menjadi aturan untuk semua invoice dari vendor itu.
• Cakupan yang salah. Aturan yang dipelajari dari invoice satu vendor diterapkan ke semua vendor, atau koreksi satu perusahaan mengubah hasil perusahaan lain.
• Field uang diperlakukan seperti deskripsi. Total atau rekening bank hasil belajar tampak sama meyakinkannya dengan deskripsi hasil belajar.
• Tidak ada cara untuk melepas aturan. Vendor mengubah tata letak invoice, aturan lama terus dipakai dan tim harus mengoreksi AI selamanya.
• Koreksi dilakukan di luar sistem. Staf memperbaiki nomor invoice di sistem akuntansi atau spreadsheet, bukan di catatan AP, sehingga AI tidak pernah melihatnya.

AI capture di Indonesia

Beberapa kebiasaan setempat membuat belajar per vendor sangat berguna, sekaligus menunjukkan di mana perlu kehati-hatian:

• Dua bahasa dalam satu dokumen. Invoice sering mencampur label bahasa Indonesia dan Inggris, seperti “Jumlah” di samping “Total” atau “Jatuh Tempo” di samping “Due date”, dan struk dari pedagang kecil bisa saja ditulis tangan. Belajar per vendor mampu mengikuti kebiasaan setiap vendor tanpa perlu template untuk setiap bahasa.
• Vendor yang sama, ditulis tiga cara. “PT Sinar Logistik”, “PT. Sinar Logistik Indonesia” dan “SINAR LOGISTIK” adalah satu perusahaan. Mengaitkan aturan dengan nomor pajak vendor (NPWP), jika tercantum di dokumen, membuat setiap aturan tetap melekat pada vendor yang benar, bagaimanapun namanya ditulis.
• Tanggal. 03/04/2026 berarti 3 April di Indonesia. Jika AI membacanya sebagai 4 Maret, itu koreksi yang layak dipelajari sekali untuk seluruh perusahaan, bukan per vendor.
• DPP, PPN dan total. Banyak invoice mencantumkan dasar pengenaan pajak (DPP), PPN dan total secara terpisah, dan sebagian juga mencantumkan pajak yang dipotong. Angka mana yang dimaksud sebagai “total” bergantung pada tata letak invoice vendor. Aturan per vendor membantu, tetapi ini adalah field uang: semuanya seharusnya memerlukan bukti lebih banyak, dan approver tetap harus memeriksanya.
• Data pribadi. Struk dan invoice bisa memuat data pribadi, seperti nama atau nomor telepon karyawan, yang dilindungi UU PDP. Tanyakan apakah dokumen dan koreksi Anda dipakai untuk memperbaiki hasil bagi perusahaan lain.

Tanda AI capture Anda belum belajar dengan baik

Anda mungkin perlu memeriksanya lebih teliti jika salah satu hal ini terdengar familier:

• Tim Anda mengoreksi field yang sama untuk vendor yang sama setiap bulan.
• Tidak ada yang bisa menjelaskan dari apa sistem belajar, atau kapan sebuah koreksi menjadi aturan.
• Koreksi untuk satu vendor ternyata mengubah hasil untuk vendor lain.
• Sistem menampilkan persentase keyakinan, dan tidak ada yang tahu apa arti 90%.
• Nominal dan detail bank diisi sama mudahnya dengan deskripsi.
• Koreksi dilakukan di sistem akuntansi atau spreadsheet, di tempat yang tidak bisa dilihat AI.
• Kontrak Anda tidak menyebutkan apakah dokumen Anda dipakai untuk memperbaiki hasil bagi pelanggan lain.

AI yang belajar dari setiap suntingan akan mempelajari salah ketik Anda. AI yang belajar dari keputusan Anda akan mempelajari cara bisnis Anda berjalan.

Cara mendapatkan hasil terbaik dari AI yang belajar

1. Koreksi di catatannya, sebelum diproses lebih lanjut. Perbaiki field di invoice atau klaim itu sendiri sebelum diajukan atau disetujui, bukan lewat komentar, email atau sistem akuntansi setelahnya.
2. Biarkan approver mengoreksi, bukan hanya menyetujui. Koreksi yang dibuat saat persetujuan punya bobot, terutama untuk nominal dan detail bank, jadi approver yang melihat field yang salah sebaiknya memperbaikinya, bukan meloloskannya begitu saja.
3. Siapkan masa belajar untuk setiap vendor. Invoice pertama dari setiap vendor memerlukan perhatian paling banyak. Pantau vendor terbesar Anda dengan saksama di bulan-bulan pertama.
4. Tetap libatkan manusia untuk urusan uang. Proses belajar mengurangi pengetikan, bukan tanggung jawab. Approver tetap memeriksa nominal, pajak dan detail bank, dan perubahan rekening bank vendor tetap harus melalui persetujuannya sendiri.
5. Telusuri field yang terus berubah. Jika sebuah field dikoreksi berulang kali untuk vendor yang sama, cari tahu penyebabnya: perubahan tata letak, kesalahan vendor atau aturan yang diterapkan tim Anda secara tidak konsisten.

---

Bagaimana Procapy membantu

ProcAI membaca invoice dan struk, dalam bahasa Indonesia maupun Inggris, untuk Proca to Pay dan Capy Expense, tanpa template yang perlu disiapkan. Ketika invoice atau klaim pengeluaran diajukan atau disetujui, setiap field yang di-capture ProcAI dibandingkan dengan nilai akhirnya, dan field yang diubah tim Anda menjadi bukti untuk sebuah aturan: aturan singkat dalam bahasa sehari-hari, baik untuk vendor atau merchant tersebut, yang dikenali dari nomor pajaknya jika tercantum di dokumen, maupun untuk seluruh organisasi Anda. Suntingan yang dibuat lalu dibatalkan di draf tidak mengajarkan apa pun.

Sebuah aturan baru dipakai setelah didukung lebih dari satu koreksi, dan nominal, pajak, mata uang serta detail bank memerlukan bukti lebih banyak, termasuk koreksi yang dibuat saat persetujuan. Ketika aturan mengisi sebuah field dan tim Anda mempertahankan nilainya, itu dihitung sebagai dukungan; ketika tim mengubahnya, itu dihitung sebagai bantahan, dan begitu bantahannya menyamai dukungannya, aturan itu dipensiunkan. Aturan-aturan ini milik organisasi Anda dan tidak pernah dibagikan ke organisasi lain. Di setiap invoice dan klaim, setiap field yang di-capture menunjukkan apakah nilainya masih sama dengan yang dibaca ProcAI atau sudah diubah seseorang.

Proca Agents juga belajar dari run yang ditinjau tim Anda, dengan setiap koreksi diterapkan ke run berikutnya dari agent tersebut, dan hanya agent tersebut. Jadwalkan sesi demo dan bawa beberapa invoice dari vendor Anda yang paling merepotkan.