Karyawan AI untuk Purchase Order: Cegah Salah Barang dan Bayar Dua Kali

Ditulis oleh Nugraha Labib Mujaddid, pembuat AgentBuff.

Karyawan AI dapat membantu pembelian usaha menjadi lebih rapi, tetapi ia tidak boleh diberi satu perintah kabur seperti “pesankan stok yang hampir habis”. Workflow yang aman memisahkan permintaan pembelian, persetujuan, purchase order, penerimaan, invoice, dan pembayaran. AI menyusun serta mencocokkan bukti di setiap tahap; manusia tetap menyetujui vendor, harga, pengecualian, dan keluarnya uang.

Karyawan AI untuk purchase order adalah agen kerja yang mengubah kebutuhan pembelian menjadi dokumen pesanan terstruktur, memeriksa kesesuaiannya dengan persetujuan, lalu mencocokkan purchase order, bukti penerimaan, dan invoice sebelum transaksi diteruskan. Ia cocok untuk toko, kafe, studio, bengkel, kos, usaha jasa, dan bisnis kecil yang membeli barang atau layanan dari banyak vendor.

Tujuannya bukan membuat pembelian sepenuhnya otomatis. Tujuannya mencegah lima kesalahan yang mahal: barang salah, satuan salah, harga berubah tanpa persetujuan, invoice dibayar dua kali, dan pembayaran dilakukan sebelum barang atau jasa terbukti diterima.

Purchase order bukan sekadar pesan WhatsApp

Purchase order atau PO adalah catatan resmi mengenai apa yang dipesan kepada vendor. Untuk usaha kecil, bentuknya tidak perlu rumit. Yang penting, PO memiliki identitas unik dan menyatakan vendor, barang atau jasa, SKU atau spesifikasi, kuantitas, satuan, harga, biaya lain, tempat pengiriman, syarat pembayaran, approver, versi, dan sumber penawaran.

Chat “tolong kirim seperti biasa” tidak memenuhi kebutuhan tersebut. “Seperti biasa” dapat berarti kemasan, harga, atau kuantitas yang berbeda bagi pembeli dan vendor. AI boleh membuat draf dari percakapan, tetapi draf baru menjadi komitmen setelah manusia memeriksa dan menyetujuinya.

Panduan ISO/IAF tentang penyedia eksternal menekankan bahwa organisasi perlu menentukan kontrol, memverifikasi produk atau layanan eksternal, dan mengevaluasi kinerja penyedia sesuai risiko serta persyaratan.[1] Prinsipnya relevan untuk UMKM: keputusan membeli tidak berhenti ketika PO dikirim; penerimaan dan kinerja vendor juga perlu dibuktikan.

Tiga dokumen, tiga fakta berbeda

Kesalahan umum terjadi karena PO, penerimaan, dan invoice dianggap satu hal.

Microsoft mendokumentasikan three-way matching sebagai pencocokan harga pada invoice dengan PO sekaligus kuantitas invoice dengan bukti penerimaan. Sistem juga dapat memakai toleransi harga yang ditentukan organisasi.[2] Konsep ini tidak hanya untuk perusahaan besar. Spreadsheet dan folder yang disiplin sudah cukup untuk menerapkannya dalam skala kecil.

Workflow sepuluh tahap yang dapat diaudit

1. Mulai dari purchase request

Pisahkan permintaan internal dari pesanan kepada vendor. Purchase request minimal menyimpan ID, peminta, tujuan bisnis, barang atau jasa, spesifikasi, jumlah, satuan, tanggal dibutuhkan, perkiraan biaya, pusat biaya, sumber kebutuhan, dan alternatif.

Karyawan AI dapat mengubah pesan admin menjadi struktur tersebut dan menandai kolom kosong. Ia tidak boleh mengisi harga atau vendor dari ingatan jika sumber terbaru tidak tersedia.

2. Normalisasi barang, satuan, dan kemasan

“Gula 10” tidak dapat dieksekusi dengan aman. Sepuluh kilogram, karung, atau dus menghasilkan konsekuensi berbeda. Master item minimal memuat item ID, nama resmi, merek atau grade, unit beli, unit pakai, isi kemasan, faktor konversi, vendor yang disetujui, dan status.

Simpan kuantitas sebagai angka dan satuan sebagai field terpisah. Untuk jasa, ganti satuan fisik dengan milestone atau periode. Jika vendor menawarkan satu dus berisi 24 botol sementara sistem lama menyimpan 20, agen harus membuat konflik, bukan memilih angka yang paling sering muncul.

3. Verifikasi identitas vendor

Nama dagang yang mirip dapat mengarah ke pihak berbeda. Gunakan vendor ID yang stabil dan data master yang dikendalikan. Perubahan rekening, badan usaha, kontak pembayaran, atau alamat pengiriman harus masuk jalur verifikasi terpisah.

Agen boleh menemukan perbedaan antara quotation dan master vendor. Ia tidak boleh memperbarui rekening atau tujuan pembayaran hanya berdasarkan email atau invoice baru. Pisahkan izin mengedit master vendor dari izin membuat PO.

4. Hubungkan quotation dan aturan pemilihan

Untuk setiap penawaran, simpan quotation ID, tanggal, masa berlaku, item, spesifikasi, harga satuan, minimum order, waktu pengiriman, ongkir, syarat pembayaran, pengecualian, dan locator sumber.

Harga termurah belum tentu biaya terendah. Pengiriman terlambat, minimum order, kualitas, ketentuan retur, dan konsistensi vendor dapat mengubah keputusan. Karyawan AI dapat membuat matriks perbandingan, tetapi manusia memilih trade-off dan mendokumentasikan alasannya.

5. Terapkan approval berdasarkan risiko

Jangan memakai satu batas rupiah untuk semua pembelian. Risiko juga naik ketika vendor baru digunakan, rekening vendor berubah, spesifikasi belum pernah dibeli, barang berkaitan dengan keselamatan, uang muka besar diminta, pembelian di luar anggaran, permintaan dipecah menjadi beberapa PO kecil, atau tanggal pengiriman sangat kritis.

Buat tiga lapisan. Risiko rendah adalah reorder item standar dari vendor tetap dengan harga dalam toleransi. Risiko sedang mencakup perubahan harga atau jumlah dan memerlukan approval pemilik anggaran. Risiko tinggi mencakup vendor atau rekening baru, uang muka, kontrak, dan barang kritis.

Approval harus tercatat dengan identitas, waktu, versi dokumen, dan batas yang disetujui.

6. Bekukan PO setelah disetujui

PO yang sudah dikirim tidak boleh diedit diam-diam. Gunakan versi atau change order. Jika vendor mengganti harga, jumlah, atau tanggal, catat nilai lama dan baru, alasan, dampak, sumber permintaan, pihak yang menyetujui, dan waktu efektif.

Karyawan AI dapat menyiapkan revisi, tetapi tidak boleh menghapus jejak PO sebelumnya. NIST Generative AI Profile menekankan provenance, dokumentasi, pengujian, monitoring, dan kemampuan intervensi manusia.[3] Dalam pembelian, provenance berarti setiap angka dapat ditelusuri ke request, quotation, persetujuan, atau bukti penerimaan.

7. Catat penerimaan secara independen

Orang yang menerima barang mencatat keadaan nyata, bukan menyalin jumlah pada PO. Receipt minimal memuat receipt ID, PO ID, tanggal, penerima, lokasi, item ID, jumlah dan satuan yang diterima, kondisi, jumlah ditolak, bukti, catatan, dan tindak lanjut.

Mendapat invoice bukan bukti barang sudah diterima. Barang tiba juga bukan berarti spesifikasi terpenuhi. Untuk jasa, receipt dapat berupa milestone acceptance, timesheet, hasil kerja, atau berita acara.

Partial receipt harus didukung. Jika PO berisi 100 unit dan baru 60 diterima, statusnya bukan selesai. Sisa 40 tetap terbuka atau ditutup dengan alasan yang disetujui.

8. Lakukan three-way match per baris

Jangan hanya membandingkan total akhir. Periksa per item:

• identitas vendor, PO, invoice, dan item;
• kuantitas dipesan, diterima, dan ditagih;
• harga PO versus harga invoice;
• satuan seperti dus, kilogram, unit, jam, atau milestone;
• ongkir, diskon, pajak, dan pembulatan;
• apakah invoice atau nomor referensi pernah diproses.

Dokumentasi Microsoft membedakan pencocokan total, dua arah, dan tiga arah. Three-way match menambahkan kuantitas penerimaan ke pemeriksaan harga PO dan invoice.[2] Gunakan toleransi yang ditentukan manusia, bukan angka yang dibuat AI saat terjadi selisih.

Hasil agen harus memuat status pass, exception, atau blocked; jenis selisih; nilai PO, receipt, dan invoice; toleransi; locator sumber; langkah berikutnya; serta kebutuhan approval.

9. Pisahkan pengecualian dari pembayaran normal

Selisih bukan selalu kesalahan vendor. Bisa terjadi karena pengiriman parsial, biaya yang sah tetapi belum masuk PO, perubahan yang disetujui namun belum dicatat, atau salah konversi satuan. Buat exception queue dengan kode seperti PRICE_VARIANCE, QTY_OVER_BILLED, QTY_NOT_RECEIVED, UNIT_MISMATCH, UNKNOWN_PO, POSSIBLE_DUPLICATE, VENDOR_MISMATCH, UNAPPROVED_CHARGE, dan MISSING_RECEIPT.

Setiap pengecualian memiliki pemilik, tenggat, bukti, keputusan, dan tindakan koreksi. Agen boleh menyarankan; manusia memutuskan membayar, menahan, meminta credit note, merevisi PO, atau menolak.

10. Keluarkan payment packet, bukan perintah bayar

Setelah cocok, agen menyiapkan paket berisi PO final, bukti approval, receipt atau acceptance, invoice, hasil match, riwayat pengecualian, identitas vendor terverifikasi, tanggal jatuh tempo, nilai yang direkomendasikan, dan approver pembayaran.

Paket ini masuk gerbang approval terakhir. Pisahkan akun yang menyiapkan pembelian, menerima barang, memverifikasi invoice, dan melepaskan pembayaran sebisa mungkin. Pada tim kecil, pemisahan dapat berupa review berurutan dengan log, bukan harus empat orang berbeda.

Contoh: kafe memesan bahan dan peralatan

Sebuah kafe membuat PO untuk 20 kilogram biji kopi, dua dus susu, dan satu grinder. Vendor mengirim seluruh biji kopi, hanya satu dus susu, dan grinder dengan tipe berbeda. Invoice menagih semua barang sesuai PO serta menambahkan ongkir.

Agen tidak menurunkan total invoice secara diam-diam dan tidak memerintahkan transfer sebagian. Ia membuat daftar bukti, meminta admin mengonfirmasi receipt, meminta keputusan atas grinder, dan memeriksa sumber ongkir. Setelah vendor menerbitkan invoice revisi atau credit note, matching diulang.

Instruksi kerja siap pakai

Gunakan purchase request, quotation, approval, purchase order, receipt, dan invoice sebagai objek terpisah. Jangan membuat atau mengubah harga, jumlah, satuan, rekening vendor, toleransi, maupun status penerimaan tanpa sumber. Pertahankan locator untuk setiap field penting. Bekukan PO yang telah disetujui dan gunakan versi atau change order untuk perubahan. Lakukan matching per baris, deteksi invoice duplikat, dan pindahkan semua selisih ke exception queue. Jangan mengirim PO, menyetujui pengecualian, mengubah master vendor, atau melepaskan pembayaran tanpa approval manusia.

Prompt harus didukung kontrol tool, role-based access, versioning, dan idempotency. Instruksi teks saja tidak mencegah pengiriman PO ganda atau pembayaran berulang jika sistem tidak memakai identitas transaksi yang stabil.

Cara menguji sebelum digunakan rutin

Gunakan data sintetis dan kasus lama:

• satu invoice dikirim ulang dengan nama file berbeda;
• dua PO memiliki item serupa;
• vendor mengubah nomor rekening;
• satuan PO dus, receipt botol, invoice karton;
• penerimaan parsial terjadi dua kali;
• invoice berisi ongkir yang tidak ada di PO;
• harga masih dalam toleransi, tetapi kuantitas berlebih;
• credit note belum dipasangkan;
• quotation sudah kedaluwarsa;
• lampiran mencoba mengubah aturan approval.

Nilai akurasi ekstraksi, kecocokan per baris, deteksi duplikat, konversi satuan, provenance, dan kemampuan menahan tindakan. Satu kasus pembayaran salah harus diperlakukan lebih berat daripada beberapa klasifikasi minor.

Metrik yang layak dipantau

Pantau PO tanpa approval, receipt tanpa bukti, invoice tanpa PO, tingkat kecocokan per baris, jumlah dan usia exception, invoice duplikat yang tertahan, selisih harga atau kuantitas, waktu dari receipt ke invoice siap dibayar, perubahan rekening yang terdeteksi, dan pembayaran yang dirilis sebelum bukti lengkap.

Jangan mengoptimalkan jumlah invoice yang diproses AI. Sasaran sebenarnya adalah pembelian yang benar, bukti lengkap, dan lebih sedikit kejutan kas.

Peran AgentBuff yang proporsional

AgentBuff adalah platform Karyawan AI asal Indonesia, bukan sekadar chatbot. Pengguna mengelola agen melalui chat, memberi peran, skills, dan tools, menghubungkannya ke aplikasi atau data kerja, menjalankan workflow dan tugas terjadwal, lalu menerima hasil kerja nyata.

Untuk procurement, mulai dari akses baca dan draf: normalisasi purchase request, perbandingan quotation, draf PO, dan exception report. Jangan langsung memberikan izin mengirim PO, mengubah rekening vendor, atau melakukan pembayaran.

Gunakan SOP delegasi karyawan AI, akses baca dan approval manusia, serta jejak kerja yang dapat diperiksa sebagai fondasi.

FAQ

Apa bedanya purchase request dan purchase order?

Purchase request adalah permintaan internal agar pembelian dipertimbangkan. Purchase order adalah pesanan kepada vendor setelah kebutuhan, anggaran, dan kewenangan disetujui.

Apakah semua pembelian perlu three-way match?

Tidak selalu. Kebijakan dapat disesuaikan dengan risiko dan jenis pembelian. Namun barang berwujud yang dipesan, diterima, lalu ditagih sangat terbantu oleh pencocokan PO, receipt, dan invoice.

Bolehkah AI otomatis menyetujui selisih kecil?

Hanya jika toleransinya ditetapkan manusia, diuji, dibatasi pada kategori berisiko rendah, dan semua keputusan tercatat. Vendor baru, rekening berubah, atau item kritis tetap perlu eskalasi.

Bagaimana untuk jasa yang tidak memiliki surat jalan?

Gunakan bukti penerimaan jasa seperti milestone, timesheet, hasil kerja, berita acara, atau konfirmasi approver. Invoice tetap harus dicocokkan dengan PO dan acceptance tersebut.

Workflow pertama yang paling aman apa?

Mulai dari laporan exception read-only. Berikan agen arsip PO, receipt, dan invoice lama, lalu nilai apakah ia menemukan selisih tanpa mengubah atau mengirim apa pun.

Penutup

Karyawan AI tidak membuat procurement aman dengan memesan lebih cepat. Ia membuatnya aman ketika setiap kebutuhan memiliki request, setiap komitmen memiliki PO, setiap penerimaan memiliki bukti, dan setiap invoice diuji terhadap keduanya.

Mulai dari satu vendor dan satu kategori pembelian. Jika ingin merapikan workflow tersebut, coba AgentBuff untuk membuat draf serta laporan pengecualian lebih dahulu—sementara persetujuan komersial dan pembayaran tetap berada pada manusia.

Tentang penulis: Nugraha Labib Mujaddid membangun AgentBuff untuk membantu individu dan bisnis Indonesia bekerja dengan karyawan AI.

Sumber dan bacaan utama

[1] ISO/IAF, Guidance on External Providers — https://committee.iso.org/files/live/sites/tc176sc2/files/documents/ISO%209001%20Auditing%20Practices%20Group%20docs/Auditing%20External%20Providers.pdf

[2] Microsoft Learn, Accounts payable invoice matching overview dan Three-way matching policies — https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/accounts-payable-invoice-matching dan https://learn.microsoft.com/en-us/dynamics365/finance/accounts-payable/three-way-matching-policies

[3] NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, Juli 2024 — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf