Procure-to-pay adalah rangkaian proses pembelian yang menghubungkan permintaan kebutuhan, pemesanan, penerimaan, pemeriksaan tagihan, dan pembayaran pemasok. Bagi perusahaan dengan banyak unit kerja, tantangannya bukan sekadar membuat purchase order lebih cepat. Setiap perpindahan tahap harus menjawab apa yang disetujui, barang atau jasa apa yang diterima, dan siapa yang berhak melanjutkan transaksi.
Direktur operasional, finance, dan procurement dapat memakai alur ini untuk memetakan titik putus sebelum memilih sistem. Artikel ini membahas pengadaan operasional perusahaan swasta secara umum. Contoh dan rancangan kontrol merupakan analisis penerapan, bukan studi kasus atau jaminan hasil proyek Layana.ID.
Apa Yang Termasuk Dalam Procure-To-Pay?
Secara ringkas, kebutuhan berubah menjadi permintaan internal, lalu menjadi pesanan kepada pemasok. Setelah barang atau jasa diterima, perusahaan memeriksa tagihan terhadap acuan yang sesuai. Pembayaran dilakukan melalui persetujuan dan prosedur keuangan perusahaan. Dokumen pendukung serta status transaksi perlu tetap dapat ditelusuri setelah proses selesai.
SAP menjelaskan P2P sebagai hubungan proses purchasing dengan accounts payable, mencakup pemilihan, pengendalian pemesanan, penerimaan dan rekonsiliasi, serta invoice dan pembayaran. Kerangka ini membantu membaca ruang lingkup; urutan rinci dan kewenangan tetap harus disesuaikan dengan SOP perusahaan.
Procurement memiliki cakupan lebih luas, termasuk strategi kategori dan hubungan pemasok. Source-to-pay dapat memasukkan sourcing dan pengelolaan kontrak. Karena istilah vendor bisa berbeda, sepakati titik awal serta titik akhir yang akan dibangun, alih-alih hanya menulis “modul procurement lengkap”.
Alur Dokumen Dari Kebutuhan Hingga Pembayaran
1. Catat Kebutuhan Yang Bisa Diperiksa
Pemohon mencatat barang atau jasa, jumlah, satuan, tujuan penggunaan, lokasi, dan waktu dibutuhkan. Lampirkan spesifikasi jika identitas barang belum cukup jelas. Gudang atau pemilik anggaran memeriksa apakah kebutuhan dapat dipenuhi dari persediaan atau kontrak yang sudah tersedia sebelum permintaan diteruskan.
Permintaan yang sudah disetujui belum otomatis berarti pesanan dikirim. Status ini perlu dipisahkan agar pemohon tidak menganggap barang sedang dalam perjalanan ketika procurement masih menunggu keputusan pemasok.
2. Terbitkan Pesanan Dengan Acuan Yang Jelas
Procurement menyusun pesanan berdasarkan kebutuhan yang disahkan, penawaran yang relevan, dan ketentuan pembelian yang disepakati. Simpan hubungan baris permintaan dengan baris PO. Satu permintaan dapat dipecah ke beberapa pemasok; satu pesanan juga dapat menggabungkan kebutuhan yang diizinkan SOP.
Perubahan jumlah, jadwal, atau spesifikasi setelah persetujuan memerlukan catatan revisi dan pemeriksaan kewenangan. Mengganti file tanpa histori membuat receiving serta finance kehilangan dasar pembanding.
3. Buktikan Penerimaan Barang Atau Jasa
Gudang mencatat apa yang benar-benar datang, bukan menyalin seluruh jumlah pesanan. Pisahkan jumlah diterima, ditolak, dan menunggu pemeriksaan bila proses mutu membutuhkannya. Untuk jasa, pemilik pekerjaan memeriksa milestone atau hasil yang disepakati; bukti serah terima tidak selalu berbentuk jumlah unit fisik.
Pelajari alur ASN dan penerimaan barang; pada implementasi, pemberitahuan kiriman tetap harus dibedakan dari bukti barang tiba.
4. Periksa Tagihan Dan Selesaikan Pembayaran
Accounts payable memeriksa identitas pemasok, referensi pesanan, penerimaan, nilai tagihan, dan potensi dokumen ganda. Selisih masuk antrean penyelesaian dengan pemilik yang jelas. Tagihan yang cocok belum membuktikan pembayaran terlaksana; simpan persetujuan pembayaran dan bukti penyelesaiannya sebagai status tersendiri.
Contoh Penerapan Pada Pembelian Komponen
Berikut skenario ilustratif: maintenance meminta 100 komponen, procurement memesan jumlah yang sama, tetapi pemasok mengirim 60 terlebih dahulu. Gudang menerima 58 dan menahan dua untuk pemeriksaan. Invoice menagih 60. Jika sistem hanya melihat PO 100, perbedaan tersebut mudah terlewat.
Pemilik proses perlu memutuskan apakah 58 yang diterima boleh diproses terpisah, bagaimana status dua unit tertahan memengaruhi invoice, dan siapa menindaklanjuti sisa 40 yang belum dikirim. Rancangan ini tidak menetapkan hak pembayaran secara otomatis; keputusan mengikuti kontrak, hasil penerimaan, dan kebijakan finance.
Manajemen sebaiknya dapat menelusuri satu kebutuhan sampai seluruh pesanan, penerimaan, tagihan, serta sisa kewajibannya. Total nilai di dashboard saja tidak cukup menjelaskan mengapa sebuah transaksi masih terbuka.
Untuk merapikan dokumen awal, bedakan PR dan PO beserta persetujuannya. Pada tahap tagihan, gunakan three-way matching untuk memeriksa acuan pesanan dan penerimaan. Lengkapi keputusan biaya dengan alokasi landed cost per barang, lalu gunakan bukti transaksi untuk scorecard evaluasi supplier.
Data Dan Pembagian Peran Yang Perlu Disiapkan
- Pemohon: menjelaskan kebutuhan dan mengonfirmasi hasil sesuai tanggung jawabnya.
- Procurement: menjaga acuan pemasok, ketentuan pesanan, dan perubahan komitmen.
- Gudang atau penerima jasa: mencatat penerimaan dengan tanggal dan bukti.
- Finance: menetapkan pemeriksaan invoice, pengecualian, serta jalur pembayaran.
- Pemilik sistem: menjaga identitas transaksi, akses, integrasi, dan histori keputusan.
Untuk perusahaan multi-entitas, cantumkan badan usaha yang membeli dan membayar. Kesamaan nama grup tidak berarti PO satu entitas boleh dicocokkan dengan invoice entitas lain. Master vendor, mata uang, satuan, pusat biaya, dan nomor referensi perlu konsisten tanpa menghapus perbedaan yang sah.
Kapan Memakai ERP Dan Kapan Memerlukan Integrasi?
Mulai dari sistem yang sudah menjadi sumber transaksi. Bila ERP menyimpan PO dan invoice tetapi penerimaan berada di WMS, integrasi perlu membawa referensi per baris beserta koreksinya. Bila kebutuhan masih diajukan melalui spreadsheet, form terkontrol dapat menjadi tahap awal selama hubungan ke transaksi berikutnya tetap tercatat.
Evaluasi cakupan ERP perusahaan berdasarkan proses nyata. Untuk sistem berbeda, bahas integrasi sistem setelah pemilik data dan aturan koreksinya disepakati. Hindari membeli modul baru sebelum diketahui di tahap mana pekerjaan terhenti.
Ukur Hasil Proses, Bukan Jumlah Dokumen Digital
Gunakan waktu dari permintaan lengkap ke PO disahkan, umur invoice bermasalah, penerimaan yang belum dipasangkan, dan pesanan terbuka yang melewati jadwal. Tetapkan definisi awal-akhir, periode, serta populasi yang dihitung. Rata-rata yang baik dapat menyembunyikan beberapa transaksi penting yang terus tertahan.
Bandingkan kondisi sebelum dan sesudah pada kategori yang setara. Penghematan belum terbukti hanya karena formulir berpindah ke aplikasi. Hitung juga pekerjaan koreksi, tindak lanjut pemasok, dan pemeliharaan master data.
Pertanyaan Tentang Digitalisasi P2P
Apakah Semua Pembelian Harus Mengikuti Jalur Yang Sama?
Tidak selalu. Barang stok, jasa berbasis milestone, pembelian darurat, dan tagihan berkala dapat membutuhkan bukti serta persetujuan berbeda. Buat pengecualian yang tercatat, dengan pemilik dan batas penggunaan yang jelas.
Apakah Pembayaran Bisa Langsung Otomatis?
Kemampuan teknis tidak menggantikan kewenangan finance. Tentukan dahulu pemeriksaan, persetujuan, kontrol rekening, serta bukti transaksi yang harus tersedia sebelum membahas otomatisasi.
Mulai Dengan Satu Rangkaian Transaksi
Bawa satu contoh kebutuhan, PO, penerimaan parsial, invoice berselisih, dan bukti pembayaran yang boleh digunakan. Diskusikan pemetaan alur pengadaan bersama Layana.ID untuk menentukan cakupan ERP, integrasi, peran, serta kriteria penerimaan yang sesuai proses perusahaan.
Referensi konsep: SAP — What Is Procure-To-Pay. Peta peran, contoh komponen, serta usulan pengukuran merupakan analisis editorial. Gambar utama merupakan ilustrasi AI, bukan dokumentasi pelanggan.