# Procurement di ERP: PR ke PO ke Penerimaan ke 3-Way Match

> Mendesain workflow procurement ERP ujung ke ujung: purchase requisition, komitmen PO, goods receipt, dan mesin 3-way match yang memblokir invoice bermasalah.

URL: https://www.matthewswong.com/id/blog/erp-procurement-purchase-order-workflow/

- Author: Matthews Wong (https://www.matthewswong.com/id/about/)
- Published: 2026-05-14
- Updated: 2026-05-14
- Category: ERP

Procurement adalah tempat ERP membayar dirinya sendiri dalam uang tunai. Modul lain kebanyakan merapikan informasi; rantai procure-to-pay adalah yang memutuskan apakah uang keluar perusahaan untuk barang yang benar-benar tiba dengan harga yang benar-benar disepakati. Saat saya mendesain alur pembelian berdampingan dengan modul AP yang saya bangun untuk ANCoraPRO di NestJS dan PostgreSQL, proses klien sebelumnya adalah pesan WhatsApp ke supplier dan satu baris Excel — dan kira-kira dua kali setahun, ada invoice terbayar untuk barang yang tidak ditemukan siapa pun di gudang.

Solusinya adalah rantai dokumen dengan empat mata rantai — purchase requisition, purchase order, goods receipt, invoice vendor — dan mesin pencocokan yang menolak melepas pembayaran sampai cerita keempatnya konsisten. Artikel ini menyusuri rantai itu satu per satu, dengan keputusan skema dan edge case yang membedakan modul procurement yang bekerja dari yang diakali.

## Rantai Dokumen: Empat Dokumen, Empat Kebenaran Berbeda

Insight desain intinya: tiap dokumen di rantai menjawab pertanyaan berbeda, dan harus tetap menjadi record terpisah bahkan saat satu orang menangani semuanya. Requisition mencatat niat, purchase order mencatat komitmen, goods receipt mencatat realita fisik, dan invoice mencatat klaim vendor. Gabungkan dua di antaranya menjadi satu record dan Anda kehilangan kemampuan mendeteksi ketidaksesuaiannya — padahal itu seluruh intinya:

Setiap baris di setiap dokumen hilir membawa foreign key ke baris hulunya: baris PO mereferensi baris PR, baris GR mereferensi baris PO, baris invoice mereferensi baris PO. Keterkaitan level baris itulah, bukan level dokumen, yang membuat pengiriman parsial dan invoice terpecah bisa ditangani nanti.

## Purchase Requisition: Murah Diajukan, Dirutekan oleh Matrix

PR ada supaya meminta sesuatu itu mudah dan mengikat uang itu terkontrol. Karyawan mana pun bisa mengajukan: deskripsi bebas boleh, item katalog lebih disukai, estimasi harga terisi otomatis dari pembelian terakhir. Friksi di sini mendorong orang kembali ke WhatsApp — form PR harus selesai di bawah dua menit, termasuk di mobile, karena orang yang sadar forklift butuh sparepart sedang berdiri di sebelah forkliftnya.

Approval adalah tempat kebijakan pengeluaran hidup, dirutekan berdasarkan band nominal dan departemen lewat approval matrix yang configurable, bukan rantai hardcoded. Satu keputusan yang layak dieksplisitkan: approval PR mengotorisasi kebutuhannya, bukan supplier atau harga finalnya. Purchasing yang mengonversi PR yang disetujui menjadi PO, memilih atau menegosiasikan vendor — memisahkan siapa boleh meminta dari siapa boleh mengikat adalah kontrol fraud dasar.

Pro tip: agregasikan baris PR yang disetujui per item lintas departemen sebelum dikonversi ke PO. Tiga departemen yang masing-masing memesan sepuluh dus kertas adalah satu PO untuk tiga puluh dengan harga lebih baik — dan layar konsolidasi ini konsisten menjadi tempat pertama modul procurement menunjukkan penghematan terukur.

## Purchase Order: Record Komitmen

PO biasanya komitmen yang bermakna hukum ke vendor, jadi lifecycle-nya perlu ketat dengan cara yang tidak dibutuhkan PR. Aturan yang saya implementasikan:

Immutable setelah dikirim — begitu tersampaikan ke vendor, perubahan harga dan kuantitas lewat amendemen berversi yang butuh approval ulang kalau totalnya melintasi band approval, tidak pernah lewat edit diam-diam.

Status dari fakta, bukan klik — OPEN, PARTIALLY_RECEIVED, RECEIVED, CLOSED diturunkan dari kuantitas GR yang tertaut, bukan diatur tangan. PO yang bisa ditutup manual menjadi tempat barang belum terkirim bersembunyi.

Visibilitas komitmen — total PO terbuka per baris anggaran langsung muncul di dashboard. Tim finance menyebutnya committed spend, dan melihatnya sebelum invoice datang adalah separuh nilai modul ini.

Disiplin kedaluwarsa — PO yang tak tersentuh selama periode yang bisa dikonfigurasi (90 hari cukup) memunculkan tugas review. PO terbuka yang basi mendistorsi committed spend dan akhirnya menjadi kiriman kejutan.

## Goods Receipt: Tempat Realita Fisik Masuk ke Sistem

GR adalah gudang mengonfirmasi apa yang fisik tiba: kuantitas dihitung, kondisi dicatat, diposting terhadap baris PO spesifik. Ia mengerjakan dua tugas sekaligus — menambahkan stock movement ke inventory, dan menciptakan bukti kuantitas-diterima yang akan dibandingkan mesin match dengan invoice. Pengiriman parsial itu normal, jadi banyak GR per baris PO harus jadi warga kelas satu, dengan total diterima berjalan dipelihara per baris.

Desain layar GR untuk dok penerimaan, bukan untuk accounting: field kuantitas besar, baris PO sudah terdaftar sehingga penerima mengonfirmasi alih-alih mengetik, field kuantitas-rusak yang otomatis membuat draft retur vendor. Kualitas seluruh match hilir Anda bergantung pada pekerja gudang yang menemukan layar ini lebih cepat daripada formulir kertas.

Jangan pernah izinkan penerimaan tanpa PO sebagai jalur rutin. Keadaan darurat memang terjadi — kiriman mendesak sungguhan dengan dokumen menyusul — jadi sediakan penerimaan eksepsi yang butuh approver bernama dan membuat PO retroaktif dalam tenggat. Kalau penerimaan tanpa referensi bebas friksi, seluruh rantai terurai dalam hitungan bulan, karena setiap penerimaan menjadi eksepsi.

## 3-Way Match: Mesin Penjaga Pembayaran

Three-way matching membandingkan PO, akumulasi goods receipt, dan invoice vendor sebelum pembayaran disetujui — kontrol standar untuk menangkap penagihan berlebih, pengiriman kurang, dan fraud. Tiga pemeriksaannya, apa yang ditangkap masing-masing, dan di mana toleransi berada:

Pemeriksaan

Membandingkan

Menangkap

Toleransi

Kuantitas

Qty ditagih vs qty diterima, per baris PO

Penagihan barang yang belum terkirim; tagihan ganda lintas invoice terpecah

Nol — kuantitas bisa dihitung; jangan pernah bayar lebih dari yang tiba

Harga

Harga satuan invoice vs harga satuan PO

Harga merayap naik, price list salah, selip mata uang

Band persentase kecil (0,5 sampai 2 persen) menyerap rounding; di atasnya antre untuk review

Eksistensi

Baris invoice vs baris PO terbuka yang disetujui

Invoice untuk barang yang tidak pernah dipesan — vektor fraud klasik

Tidak ada — tanpa referensi PO, tidak ada jalur otomatis ke pembayaran

Jalankan match per baris invoice saat posting dan simpan hasilnya sebagai status di baris itu. Baris yang cocok mengalir ke penjadwalan pembayaran tanpa disentuh tangan manusia; eksepsi mendarat di antrean yang menampilkan ketiga dokumen berdampingan dengan selisihnya disorot. Metrik yang diawasi adalah touchless rate — porsi baris invoice yang cocok otomatis. Setup yang matang mencapai jauh di atas separuh, dan setiap jenis eksepsi yang berulang menunjuk perbaikan hulu: penerima melewatkan GR, price list kedaluwarsa, vendor berimprovisasi unit of measure.

## Edge Case yang Harus Dilewati Mesin Match Anda

Happy path-nya kerjaan satu sore. Empat skenario ini proyek sebenarnya:

Parsial di mana-mana — PO 100 unit yang tiba dalam tiga kiriman dan ditagih lewat dua invoice berarti pencocokan harus bekerja terhadap kumulatif diterima dan yang sudah ditagih sebelumnya per baris, bukan total dokumen.

Harga berubah antara PO dan invoice — biaya angkut tambahan dan diskon hasil negosiasi itu nyata. Perubahan sah lewat amendemen PO sebelum invoice diposting; mesin match tidak boleh punya mode melunakkan-aturan.

Retur setelah penerimaan — barang rusak yang diretur pasca-GR mengurangi kuantitas yang bisa dicocokkan. Dokumen retur vendor harus mengurangi kumulatif diterima, atau invoice berikutnya over-match.

PO jasa tanpa penerimaan fisik — jasa melompati GR, jadi butuh konfirmasi penerimaan jasa sebagai dokumen kedua, atau kebijakan 2-way match eksplisit (PO vs invoice) per kategori dengan approval lebih ketat.

## Checklist Implementasi

Sebelum menyebut modul procurement siap production, saya memverifikasi lima hal ini berurutan:

Foreign key level baris di sepanjang rantai — PR ke PO ke GR ke invoice — dengan kuantitas kumulatif bisa di-query per baris PO dalam satu query ber-index.

Integrasi approval matrix di PR (kebutuhan) dan amendemen PO (komitmen), dengan semantik snapshot-saat-submission.

Layar GR diuji dengan staf gudang sungguhan pada kiriman sungguhan — termasuk kasus parsial dan rusak — sebelum go-live, bukan sesudahnya.

Toleransi match dikonfigurasi per kategori dan disetujui finance, dengan setiap auto-release dicatat beserta inputnya untuk auditor.

Antrean eksepsi dengan tampilan dokumen berdampingan, indikator umur, dan ritual review mingguan — antrean eksepsi yang tidak pernah dikosongkan hanyalah cara lebih lambat membayar semuanya.

## Intinya

Modul procurement adalah empat dokumen dan satu wasit. Jaga dokumen tetap terpisah supaya bisa saling tidak setuju, tautkan di level baris supaya realita parsial muat, dan biarkan mesin match — bukan kebiasaan atau hierarki — memutuskan invoice mana yang menyentuh uang tanpa manusia. Bangun seperti ini dan sistem membayar persis untuk yang tiba; bangun lebih longgar dan Anda baru saja mendigitalkan proses WhatsApp dengan langkah ekstra.

## Sumber dan bacaan lanjutan

- Tipalti — Apa Itu 3-Way Match di Proses AP
- Dokumentasi Odoo 18 — Bill Control Policies dan 3-Way Matching

> **Key takeaway:** Procurement adalah tempat ERP membayar dirinya sendiri dalam bentuk uang, karena rantai procure-to-pay menentukan apakah uang keluar untuk barang yang benar-benar datang. Pencocokan tiga arah antara purchase order, bukti penerimaan barang dan invoice adalah kontrol yang membuat hal itu bisa diverifikasi, bukan sekadar dipercaya.

## Source links

- https://tipalti.com/resources/learn/3-way-match/
- https://www.odoo.com/documentation/18.0/applications/inventory_and_mrp/purchase/manage_deals/control_bills.html

## FAQ

### Mengapa alur procurement memerlukan empat dokumen terpisah, bukan digabung menjadi satu?

Setiap dokumen menjawab pertanyaan berbeda: requisition mencatat niat, PO mencatat komitmen, goods receipt mencatat realita fisik, dan invoice mencatat klaim vendor. Menggabungkan dua di antaranya menjadi satu record menghilangkan kemampuan mendeteksi ketidaksesuaiannya — dan itu adalah seluruh tujuan rantai ini. Foreign key level baris yang menghubungkan setiap dokumen ke dokumen hulunya adalah yang membuat pengiriman parsial dan invoice terpecah bisa ditangani.

### Apa saja yang diperiksa mesin 3-way match, dan di mana toleransinya berada?

Mesin match menjalankan tiga pemeriksaan per baris invoice: kuantitas (qty ditagih vs qty diterima, toleransi nol), harga (harga satuan invoice vs harga satuan PO, dengan band kecil 0,5–2% untuk rounding), dan eksistensi (baris invoice vs baris PO terbuka yang disetujui, tanpa toleransi). Kuantitas bertoleransi nol karena bisa dihitung — Anda tidak pernah membayar lebih dari yang fisik tiba. Toleransi harga menyerap rounding; apa pun yang melewati band tersebut masuk antrean review manusia, bukan lolos diam-diam.

### Bagaimana status PO sebaiknya dikelola agar barang yang belum terkirim tidak tersembunyi?

Status PO — OPEN, PARTIALLY_RECEIVED, RECEIVED, CLOSED — harus diturunkan otomatis dari kuantitas goods receipt yang tertaut, bukan diatur manual. PO yang bisa ditutup tangan memberi celah bagi barang belum terkirim untuk bersembunyi, mendistorsi dashboard committed spend. PO yang tak tersentuh melewati periode yang dikonfigurasi (direkomendasikan 90 hari) harus memunculkan tugas review agar komitmen terbuka yang basi tidak menjadi kiriman kejutan di kemudian hari.

### Bagaimana PO jasa ditangani ketika tidak ada penerimaan barang fisik?

Jasa melewatkan tahap goods receipt karena tidak ada barang fisik yang tiba di gudang. Mereka memerlukan konfirmasi penerimaan jasa sebagai dokumen kedua dalam rantai, atau kebijakan 2-way match eksplisit (PO vs invoice) per kategori jasa dengan ambang approval yang lebih ketat. Prinsip utamanya: setiap jalur pembayaran tetap harus memiliki dokumen kedua yang terverifikasi — mesin match tidak boleh punya mode yang melunakkan aturan ini.

### Apa pendekatan yang direkomendasikan untuk mengonsolidasikan purchase requisition sebelum diubah menjadi PO?

Baris PR yang sudah disetujui sebaiknya diagregasikan per item lintas departemen sebelum dikonversi menjadi purchase order. Beberapa departemen yang masing-masing memesan item yang sama bisa digabungkan menjadi satu PO untuk total kuantitasnya, yang biasanya menghasilkan harga lebih baik. Layar konsolidasi ini konsisten menjadi tempat pertama modul procurement menunjukkan penghematan yang nyata dan terukur.

---

- HTML version: https://www.matthewswong.com/id/blog/erp-procurement-purchase-order-workflow/
- English: https://www.matthewswong.com/en/blog/erp-procurement-purchase-order-workflow/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json