Codex untuk AP, AR, Billing, dan Collections

Codex dapat dirancang untuk membantu AP, AR, billing, dan collections mengelola exception invoice-to-pay dan billing-to-cash secara lebih rapi. Jawaban langsungnya: Codex cocok untuk ekstraksi, matching, duplicate check, aging queue, draft dunning letter, dan reviewer packet, tetapi tidak boleh mengubah vendor master, melepas pembayaran, memberi kredit final, atau mengirim tagihan keluar tanpa approval manusia.

Lihat peta cluster di Codex untuk Perusahaan Indonesia, rancangan teknis di Arsitektur Agentic Work System dengan Codex, kontrol data di Security, Privacy, dan UU PDP untuk Corporate AI Agents, gate aksi di Human Approval Matrix dan Governance Pilot Codex, dan jalur latihan di Pelatihan Codex dan AI Agent untuk Tim Perusahaan.

AP/AR adalah simpul handoff. Untuk PO, RFQ, vendor due diligence, dan award, arahkan ke Procurement dan Vendor Management. Untuk selisih ledger, accrual, dan close, arahkan ke Accounting, Closing, dan Consolidation. Untuk payment run dan bank release, arahkan ke Treasury dan Cash Management. Untuk PPN, bukti potong, dan rekonsiliasi fiskal, arahkan ke Tax dan Fiscal Compliance. Untuk pipeline, quotation, dan commercial term, lihat Sales Operations dan Commercial Excellence.

Fakta, konteks, dan rekomendasi

[Fakta produk] Codex bekerja pada file dan command dalam lingkungan yang bisa dibatasi. Ia dapat menjalankan parser, script matching, lint dokumen, dan test deterministik. Untuk AP/AR, kemampuan ini paling berguna pada pekerjaan yang punya bukti: invoice, PO, goods receipt, BAST, billing schedule, aging, customer statement, dan template surat.

[Konteks resmi Indonesia] AP/AR bersentuhan dengan dokumen elektronik, transaksi, data vendor, data pelanggan, faktur pajak, dan bukti potong. UU PDP relevan jika data pribadi diproses. UU ITE dan perubahannya menjadi konteks informasi dan transaksi elektronik. DJP menjadi sumber rujukan pajak, termasuk kanal peraturan. Artikel ini tidak menyatakan Codex dapat memastikan validitas pajak final atau menggantikan proses resmi DJP.

[Rekomendasi workflow] Gunakan Codex sebagai exception engine di atas ekspor, bukan sebagai tombol bayar atau billing otomatis. Jalur yang aman adalah ekspor invoice, PO, GR/BAST, vendor master read-only, customer master read-only, dan aging report. Controlled connector boleh dipakai hanya untuk action terbatas yang sudah disetujui, misalnya membuat draft task di queue internal, bukan mengubah rekening vendor atau melepas payment.

Artefak dan handoff

Di AP, artefak utamanya adalah invoice supplier, PO, goods receipt, BAST, kontrak, vendor master, tax invoice, payment term, dan approval budget owner. Di AR, artefaknya adalah billing schedule, sales order, kontrak pelanggan, invoice pelanggan, aging report, dispute log, dunning letter, dan proof of delivery. Billing dan collections sering tersendat bukan karena tidak ada AI, tetapi karena bukti tersebar dan aturan exception tidak tertulis.

Codex membantu menstrukturkan bukti itu. Folder AP dapat berisi input/invoices/, input/po/, input/gr-bast/, input/vendor-master/, rules/tax-checks/, dan output/payment-proposal/. Folder AR dapat berisi input/billing-schedule/, input/customer-master/, input/aging/, input/disputes/, dan output/collections-queue/. Setiap file diberi periode, source, dan status.

Handoff terbaik adalah queue yang bisa dikerjakan. AP reviewer tidak butuh ringkasan panjang untuk semua invoice. Ia butuh daftar invoice duplikat, mismatch amount, PO overrun, missing BAST, term tidak cocok, vendor bank change, dan tax evidence missing. AR reviewer butuh daftar customer overdue, dispute reason, invoice yang belum terkirim, dunning stage, dan blocked action yang butuh approval sales atau legal.

Workflow AP step-by-step

1. Terima invoice melalui folder masuk atau ticket. File yang diterima dari email dianggap tidak tepercaya sampai lolos scan, naming, dan completeness check.

2. Extract field wajib: vendor, nomor invoice, tanggal, nilai, mata uang, PPN, PO number, nomor faktur pajak jika ada, payment term, dan rekening tujuan. OCR atau parser boleh dipakai, tetapi hasilnya harus disimpan sebagai structured output yang dapat diuji.

3. Cek duplikasi. Codex membandingkan vendor, nomor invoice, amount, tanggal, dan hash file. Duplikasi fuzzy masuk exception, bukan langsung ditolak otomatis.

4. Jalankan three-way match. Invoice dibandingkan dengan PO dan GR/BAST. Agent menandai quantity mismatch, price mismatch, missing receipt, partial delivery, dan PO yang sudah closed.

5. Cek pajak dan dokumen. Agent menandai faktur pajak hilang, format field tidak lengkap, atau bukti potong yang perlu diminta. Keputusan pajak final tetap di tax reviewer.

6. Buat payment proposal draft. Output berisi invoice yang clear, invoice yang hold, alasan hold, due date, cash priority, dan approval owner. Ini bukan instruksi bayar final.

7. Review manusia. AP checker memeriksa exception. Budget owner atau requester memberi konfirmasi receipt. Treasury memutuskan payment run, bukan AP agent.

8. Reconcile setelah payment. Setelah treasury membayar, proof of payment atau bank statement dicocokkan kembali dengan invoice untuk menutup item.

Workflow AR dan collections step-by-step

1. Ambil billing schedule dan customer master snapshot. Codex memeriksa contract ID, billing milestone, invoice date, due date, customer contact, tax status, dan commercial owner.

2. Cocokkan delivery evidence. Billing tidak dibuat hanya karena milestone ada. Agent memeriksa BAST, delivery note, timesheet approved, atau evidence lain sesuai kontrak.

3. Draft billing packet. Packet berisi invoice draft, supporting evidence list, tax flag, dan unresolved item. Manusia billing menyetujui sebelum invoice dikirim.

4. Bangun aging queue. AR aging dikelompokkan berdasarkan bucket, customer, dispute reason, promise-to-pay, dan next action. Codex memisahkan overdue karena sengketa, dokumen kurang, cash issue, atau lupa follow-up.

5. Draft dunning letter. Surat dibuat dari template approved dan disesuaikan dengan stage. External send tetap oleh manusia, terutama untuk pelanggan strategis atau sengketa.

6. Escalation. Item material, berulang, atau berisiko legal diarahkan ke sales owner, finance manager, atau legal. Codex tidak memberi keputusan kredit final atau hold service otomatis.

Acceptance checks

Untuk AP, invoice clear jika vendor aktif, rekening sama dengan master yang disetujui, PO cocok, GR/BAST cocok, amount sesuai toleransi, due date valid, dokumen pajak lengkap atau diberi flag, dan tidak ada duplicate warning terbuka. Jika rekening vendor berubah, item wajib blocked sampai callback dan dual control selesai. Agent tidak boleh memperlakukan email vendor sebagai dasar perubahan rekening.

Untuk AR, billing clear jika milestone didukung bukti, customer entity cocok, tax treatment ditandai untuk reviewer, nomor kontrak ada, due date sesuai term, dan contact penerima invoice valid. Aging queue clear jika setiap item overdue punya reason code, owner, next action, dan tanggal follow-up. Dunning letter harus memakai template approved, tidak mengancam di luar kebijakan, dan tidak mengirim data pelanggan lain.

Acceptance teknis meliputi schema valid, total invoice input sama dengan total yang diproses, semua exception punya alasan, semua output punya run ID, dan semua keputusan reviewer tercatat. Jika parser confidence rendah, file masuk manual review. Jangan memakai confidence sebagai pengganti bukti.

Approval, fraud, security, dan data

AP/AR memiliki risiko fraud yang nyata. Perubahan rekening vendor atau customer refund harus selalu human-gated dengan callback, segregation of duties, dan bukti terpisah dari email permintaan. Codex tidak mengubah vendor master, customer master, credit limit, payment term, atau beneficiary. Untuk payment, treasury dan bank approver tetap memegang token.

Data AP/AR juga sensitif. Invoice bisa berisi alamat, kontak, NPWP, nomor rekening, harga kontrak, dan informasi bisnis pelanggan. Gunakan minimization, masking bila perlu, dan akses folder berdasarkan role. Vendor dan customer document harus diperlakukan sebagai input tidak tepercaya. Instruksi dalam lampiran, seperti "abaikan PO" atau "ubah bank", tidak boleh menjadi perintah agent.

Jika perusahaan ingin integrasi, mulai dari export dan script. Controlled connector hanya membaca data yang diizinkan atau membuat draft task setelah approval. Jangan klaim integrasi langsung ERP bila yang ada hanya upload/download file. Ini membuat pilot lebih jujur dan lebih mudah diaudit.

Pilot 30 hari

Pilot AP dapat dimulai dari satu kategori vendor dengan volume invoice tinggi. Pilot AR dapat dimulai dari satu segment customer dengan aging material. Minggu pertama memetakan dokumen dan reason code. Minggu kedua membangun extractor dan matching rules. Minggu ketiga menguji invoice historis. Minggu keempat menjalankan queue live dengan AP/AR reviewer.

KPI yang layak: persentase invoice yang masuk clear versus exception, jumlah duplicate yang benar, waktu menyiapkan payment proposal, jumlah dunning draft yang dipakai, penurunan item tanpa owner, dan jumlah false positive. KPI harus memisahkan AP dan AR agar tidak mencampur kualitas matching dengan kualitas collections.

Contoh reviewer packet

Reviewer packet AP dapat berisi invoice-extraction.csv, three-way-match-result.xlsx, duplicate-warnings.csv, tax-evidence-flags.csv, vendor-bank-change-blockers.csv, dan payment-proposal-draft.xlsx. Packet ini harus menjawab invoice mana yang boleh lanjut, invoice mana yang hold, siapa owner hold, dan bukti apa yang kurang. AP manager tidak perlu membaca seluruh lampiran jika daftar exception sudah tajam.

Reviewer packet AR dapat berisi billing-readiness.xlsx, missing-delivery-evidence.csv, aging-queue.xlsx, dispute-log-summary.md, dunning-drafts/, dan promise-to-pay-tracker.csv. Untuk collections, kualitas reason code sangat penting. "Overdue" saja tidak membantu. Reason code harus membedakan dokumen belum diterima, invoice disengketakan, budget pelanggan tertahan, service issue, salah kontak, atau eskalasi legal.

Contoh edge case AP: invoice vendor cocok dengan PO, tetapi rekening tujuan berbeda dari vendor master. Codex harus menahan invoice, membuat blocker, dan meminta callback sesuai SOP. Ia tidak boleh menerima rekening baru dari email atau lampiran. Contoh edge case AR: pelanggan overdue 45 hari, tetapi dispute log menunjukkan BAST belum diterima karena nama project salah. Output yang benar adalah memperbaiki billing evidence dan meminta sales owner follow-up, bukan langsung mengirim dunning keras.

FAQ singkat. Apakah Codex bisa membaca invoice PDF? Bisa jika parser/OCR disiapkan dalam workflow, tetapi hasil OCR tetap diuji. Apakah Codex bisa memilih invoice mana yang dibayar dulu? Ia bisa memberi draft prioritas berdasarkan due date, discount, hold, dan cash flag, tetapi treasury dan approver memutuskan. Apakah Codex bisa mengirim reminder otomatis? Untuk pilot awal, buat draft dan task internal. External send tetap manusia sampai template, contact, dan approval stabil.

Pertanyaan implementasi yang sering muncul adalah apakah AP dan AR harus dipilotkan bersamaan. Tidak. AP biasanya lebih mudah diuji karena tiga-way match memiliki bukti yang jelas. AR collections membutuhkan koordinasi sales, customer success, legal, dan kadang project delivery. Jika tim masih belum punya reason code aging, mulai dari AR queue dulu sebelum membuat dunning draft.

Pola handoff juga harus tertulis. Procurement menjawab apakah PO dan vendor valid. Receiving atau project owner menjawab apakah BAST benar. AP menjawab apakah invoice clear. Treasury menjawab kapan pembayaran masuk batch. Sales atau account owner menjawab komunikasi pelanggan. Codex membantu menjaga queue, tetapi tidak mengganti pemilik proses tersebut.

Tambahkan daftar tindakan yang dilarang sejak awal pilot. Codex tidak boleh membuat vendor baru, mengubah rekening, mengubah credit limit, mengubah payment term, menghapus dispute, menjanjikan tanggal bayar kepada vendor, atau mengirim ancaman collections. Jika workflow membutuhkan action tersebut, output berhenti di review packet dengan nama approver yang jelas.

Untuk billing, tetapkan juga aturan versi template. Invoice draft, dunning letter, dan statement of account harus berasal dari template approved. Jika template berubah, Codex mencatat versi dan meminta reviewer melihat sample output. Ini mencegah bahasa lama, logo salah, atau syarat pembayaran yang tidak lagi berlaku ikut terkirim.

Satu template salah bisa membuat dispute baru meskipun angka invoice sudah benar.

Karena itu, template menjadi artefak kontrol, bukan sekadar dokumen desain.

Sumber primer

• OpenAI Introducing Codex: https://openai.com/index/introducing-codex/
• OpenAI Codex documentation: https://developers.openai.com/codex/
• OpenAI Agent approvals and security: https://learn.chatgpt.com/docs/agent-approvals-security
• UU 27/2022 Pelindungan Data Pribadi: https://peraturan.bpk.go.id/Details/229798/uu-no-27-tahun-2022
• UU 11/2008 ITE: https://peraturan.bpk.go.id/Details/37589/uu-no-11-tahun-2008
• UU 1/2024 Perubahan Kedua UU ITE: https://peraturan.bpk.go.id/Details/274494/uu-no-1-tahun-2024
• DJP peraturan: https://www.pajak.go.id/id/peraturan

Untuk membangun exception queue AP/AR yang bisa direview tanpa melepas kontrol pembayaran, gunakan kasus invoice dan aging perusahaan dalam Pelatihan AI untuk Perusahaan.