Permintaan perubahan rekening vendor sering datang ketika pembayaran sudah mendekati tenggat. Dokumen terlihat lengkap, email memakai nama pemasok yang dikenal, dan tim accounts payable diminta segera memprosesnya. Situasi seperti ini membutuhkan kontrol yang tidak bergantung pada isi pesan semata. Agentic AI perubahan rekening vendor dapat membantu mengoordinasikan pemeriksaan lintas sistem, tetapi tidak boleh menjadi pengganti verifikasi independen dan otorisasi manusia.
Artikel ini membahas rancangan proses perubahan master rekening, bukan instruksi melakukan pembayaran atau jaminan pencegahan fraud. Penggunaan AI perlu mengikuti kebijakan keuangan, keamanan, dan otorisasi perusahaan. Sistem yang hanya membaca pesan lalu mengirimnya ke antrean approval lebih tepat disebut workflow, meskipun memakai model bahasa.
Masalah yang Perlu Diselesaikan: Bukti Terpisah, Waktu Mendesak
Procurement menyimpan data kontak vendor, AP menerima dokumen, treasury mengelola kelayakan rekening pembayaran, dan ERP menyimpan master yang akhirnya dipakai transaksi. Jika setiap tim bekerja dari email berbeda, keputusan dapat dibuat dari versi bukti yang tidak sama. Kecepatan mengisi form tidak menyelesaikan masalah tersebut.
Tetapkan satu ID permintaan perubahan. Seluruh dokumen, hasil verifikasi, keputusan, dan versi master terhubung ke ID itu. Status yang disarankan mencakup diterima, bukti belum lengkap, menunggu verifikasi independen, menunggu approval, disetujui untuk pembaruan, telah diterapkan, serta ditolak atau dibatalkan. Arti setiap status perlu dibakukan sebelum otomasi dibangun.
Pisahkan Pengaju, Pemeriksa, dan Penerap Perubahan
PIC vendor dapat mengajukan permintaan melalui saluran resmi. Petugas internal memeriksa kelengkapan; pihak lain melakukan verifikasi independen; pejabat berwenang memutuskan; petugas atau layanan aplikasi yang berbeda menerapkan perubahan. Orang yang mengajukan atau mengumpulkan bukti tidak otomatis berhak mengesahkannya.
Prinsip ini sejalan dengan kebutuhan pemisahan tugas dan konflik kewenangan dalam ERP. Pemisahan harus ditegakkan oleh aplikasi serta hak akses, bukan hanya ditulis pada prompt agent.
Bedakan Workflow Tetap dari Orkestrasi Agentic
Workflow tetap dapat memeriksa kolom wajib dan mengarahkan kasus sesuai aturan. AI agent dapat memilih alat baca berikutnya berdasarkan bukti yang belum ditemukan. Orkestrasi agentic menjadi relevan ketika sistem perlu menyusun rencana terbatas, meminta data tambahan dari beberapa sumber, mengevaluasi kecukupan bukti, lalu berhenti pada gerbang manusia.
Anthropic membedakan workflow dari agent berdasarkan siapa yang menentukan jalur pelaksanaan. Penambahan beberapa chatbot atau beberapa panggilan model tidak cukup untuk menyebut proses agentic. Untuk permintaan sederhana dengan urutan pemeriksaan tetap, pertahankan workflow yang lebih mudah diaudit.
Contoh rencana terbatas: baca master vendor aktif, cocokkan ID badan usaha, temukan kontak dari sumber internal yang telah disahkan, periksa apakah ada permintaan perubahan lain yang masih terbuka, kemudian susun paket review. Agent berhenti bila sumber tidak cocok atau bukti belum cukup. Ia tidak boleh mencari kontak alternatif di internet dan menganggapnya sebagai identitas vendor resmi.
Verifikasi Harus Menggunakan Saluran yang Independen
Verifikasi rekening tidak boleh hanya menghubungi nomor yang baru tercantum pada pesan perubahan. Gunakan informasi kontak yang telah diketahui dan disahkan menurut prosedur perusahaan. Petugas yang berwenang mencatat jalur, waktu, pihak yang dihubungi, serta hasil pemeriksaan tanpa memasukkan rahasia yang tidak diperlukan ke model.
Panduan FBI mengenai business email compromise menekankan kehati-hatian dan verifikasi perubahan informasi pembayaran. Dokumen yang tampak meyakinkan maupun desakan urgensi tidak menggantikan kontrol tersebut. Implementasi perusahaan perlu menyesuaikan prosedur internal, tingkat risiko, dan layanan verifikasi yang memang tersedia.
Agent tidak boleh mengaku bahwa panggilan telah dilakukan hanya karena tugas callback sudah dibuat. Status “verifikasi selesai” memerlukan bukti pelaksanaan oleh petugas. Jika verifikasi tidak dapat diselesaikan, kasus tetap tertahan dan ditangani melalui jalur eskalasi yang disepakati.
Contoh Ilustratif: Dua Permintaan untuk Vendor yang Sama
Ini skenario ilustratif, bukan kejadian atau portofolio Layana. AP menerima dua permintaan perubahan dengan rekening berbeda untuk satu vendor. Agent menemukan permintaan kedua ketika memeriksa register kasus. Sistem menandai konflik dan menghentikan persiapan pembaruan, tanpa menyimpulkan salah satu rekening benar atau terjadi penipuan.
Procurement dan treasury kemudian memeriksa sumber secara independen. Bila satu permintaan dibatalkan, keputusan pembatalan dan alasan dicatat pada ID yang sama. Riwayat tidak dihapus agar reviewer dapat memahami mengapa perubahan terakhir disetujui.
Integrasi ERP: Approval Harus Terikat pada Nilai yang Diperiksa
Paket approval perlu memuat vendor, nilai rekening yang diajukan, versi master awal, ringkasan verifikasi, bukti, dan identitas pemberi keputusan. Jika rekening, nama pemilik, atau vendor berubah setelah approval, persetujuan lama tidak boleh langsung digunakan. Sistem harus meminta pemeriksaan ulang sesuai kebijakan.
Ketika pembaruan diizinkan, layanan aplikasi membandingkan versi master terkini dengan versi yang telah diperiksa. Perubahan bersamaan, kegagalan koneksi, atau respons tidak jelas harus menghasilkan status yang dapat direkonsiliasi. Baca ulang master sebelum mengulang pembaruan; jangan menebak bahwa timeout berarti perubahan gagal.
Mulai pilot dengan akses baca dan draf paket review saja. Otoritas melakukan pembaruan merupakan keputusan implementasi tersendiri. Pembayaran tetap berada pada kontrol pembayaran perusahaan, terpisah dari perubahan master. Kebutuhan ini dapat dipetakan melalui layanan integrasi sistem tanpa membuka akses yang lebih luas dari kebutuhan proses.
Uji Skenario Gagal Sebelum Menilai Kecepatan
Buat lingkungan uji dengan data sintetis atau data yang telah disamarkan dan disetujui. Sertakan vendor tidak aktif, kontak berbeda, dokumen kedaluwarsa, permintaan ganda, perubahan setelah approval, reviewer tidak berwenang, serta layanan ERP yang memberi respons ambigu. Jangan melakukan transfer dana nyata untuk membuktikan pilot.
KPI utama adalah jumlah perubahan tanpa approval yang lolos, konflik yang terlewat, ketepatan keterkaitan bukti, dan keberhasilan menahan kasus yang wajib dihentikan. Ukur juga waktu review, beban verifikasi manual, serta kasus tertahan yang ternyata sah. Waktu proses yang lebih singkat tidak bernilai jika pemeriksaan penting terlewati.
Sepakati kriteria stop, pemilik insiden, dan cara kembali ke proses manual sebelum pengujian. Kegagalan kontrol kritis harus menghentikan perluasan pilot. Jangan menurunkan persyaratan verifikasi agar angka penyelesaian agent meningkat atau menganggap klasifikasi model sebagai bukti autentisitas.
Diskusikan Proses, Bukti, dan Batas Kewenangan
Siapkan diagram proses saat ini, matriks approval, sumber kontak vendor yang sah, struktur master ERP, dan contoh kasus yang sudah disamarkan. Tunjukkan kapan proses harus berhenti serta siapa yang berhak melanjutkan. Bahan ini lebih berguna daripada langsung meminta agent mengubah rekening secara otomatis.
Layanan AI dan machine learning Layana dapat menjadi jalur diskusi rancangan orkestrasi yang sesuai kebutuhan. Diskusikan pemetaan pilot perubahan master vendor dengan PIC procurement, AP, treasury, dan IT. Sasaran awalnya adalah paket bukti serta kontrol yang dapat diuji, bukan otonomi pembayaran.
Gambar utama merupakan ilustrasi konseptual pemeriksaan independen dan approval manusia, bukan bukti proyek atau transaksi nyata.