Apa itu procure-to-pay? Proses P2P langkah demi langkah
Manajer pabrik mengirim pesan WhatsApp ke tim procurement: lini pengemasan butuh empat conveyor belt baru sebelum hari Jumat. Procurement menelepon pemasok yang pernah dipakai tahun lalu, menyepakati harga lewat telepon, dan belt-nya tiba hari Kamis. Tiga minggu kemudian, invoice senilai Rp86.500.000 masuk ke tim AP.
Tidak ada purchase order untuk mencocokkannya. Tidak ada yang mencatat apa yang tiba. Pemilik anggaran tidak pernah menyetujui pengeluarannya, dan rekening bank di invoice tidak sama dengan yang ada di master data vendor. Sebelum tim AP bisa membayar, seseorang harus menyusun ulang seluruh pembelian itu dari riwayat chat.
Setiap langkah yang seharusnya terjadi dilewati, padahal masing-masing hanya butuh beberapa menit saat itu. Rangkaian langkah itulah yang disebut procure-to-pay. Panduan ini menjelaskan setiap langkahnya dan siapa penanggung jawabnya, perbedaan pengajuan pembelian dan purchase order, contoh pemeriksaan anggaran, titik-titik di mana prosesnya gagal dan cara memperketatnya.
Apa itu procure-to-pay?
Procure-to-pay (P2P) adalah proses menyeluruh yang dipakai perusahaan untuk membeli barang dan jasa: mulai dari mengidentifikasi kebutuhan, melalui persetujuan, pemesanan, penerimaan dan penagihan, sampai membayar vendor dan mencatatnya di pembukuan.
Proses ini melintasi dua tim yang sering bekerja terpisah. Procurement memegang paruh depannya: memilih vendor, menyepakati harga dan melakukan pemesanan. Utang usaha (AP) memegang paruh belakangnya: memeriksa invoice, membayarnya dan mencatat pembayarannya. P2P adalah satu proses yang menghubungkan keduanya, sehingga setiap langkah menyerahkan catatan yang lengkap ke langkah berikutnya.
Anda mungkin juga menemukan istilah source-to-pay, yang menambahkan pekerjaan sourcing strategis sebelum pembelian apa pun: tender, kontrak dan pemilihan pemasok. Di sisi penjualan, kebalikan dari P2P adalah order-to-cash.
Proses procure-to-pay, langkah demi langkah
- Pilih vendornya. Pembeli memilih dari vendor yang disetujui, item katalog atau harga kontrak, atau mengumpulkan penawaran lalu membandingkannya. Vendor baru di-onboard dan diverifikasi sebelum siapa pun bisa memesan darinya.
- Ajukan permintaan pembelian. Orang yang membutuhkan sesuatu memintanya secara resmi: apa, berapa banyak, untuk apa dan cost centre atau proyek mana yang menanggungnya.
- Setujui. Pengajuan melewati matriks persetujuan Anda, berdasarkan nominal, cost centre, proyek atau entitas, dengan anggaran terlihat di layar.
- Terbitkan purchase order. Pengajuan yang disetujui menjadi PO yang dikirim ke vendor, lengkap dengan nomor, baris barang, harga, tanggal pengiriman dan syarat pembayaran.
- Terima barang atau jasanya. Siapa pun yang menerimanya mencatat apa yang tiba terhadap baris PO, termasuk pengiriman sebagian dan barang yang ditolak.
- Capture invoice-nya. Invoice dari vendor diinput dan ditautkan ke PO-nya.
- Cocokkan. Invoice diperiksa terhadap PO dan bukti penerimaan, biasanya dengan 3-way matching, dalam batas toleransi yang disepakati. Yang tidak cocok masuk ke antrean pengecualian.
- Bayar. Invoice yang sudah cocok dan disetujui masuk ke batch pembayaran yang dijadwalkan berdasarkan jatuh tempo, ke rekening bank yang terverifikasi, dengan pemeriksaan yang mencegah pembayaran ganda.
- Catat. Invoice dan pembayarannya diposting ke buku besar, dan laporan umur utang (AP ageing) menunjukkan apa yang masih terutang.
Siapa penanggung jawab setiap langkah
| Langkah | Penanggung jawab | Dokumen |
|---|---|---|
| Pemilihan vendor | Procurement | Daftar vendor yang disetujui, penawaran |
| Pengajuan | Pengaju | Purchase requisition (PR) |
| Persetujuan | Pemilik anggaran, approver | Catatan persetujuan |
| Pemesanan | Procurement | Purchase order (PO) |
| Penerimaan | Gudang atau pengaju | Bukti penerimaan barang, atau BAST untuk jasa |
| Invoice dan pencocokan | AP | Invoice dan faktur pajak |
| Pembayaran | Keuangan | Batch pembayaran dan file bank |
Setiap dokumen berasal dari orang yang berbeda. Pemisahan inilah kontrolnya: tidak ada satu orang pun yang bisa membuat komitmen, mengonfirmasi penerimaannya dan menyetujui pembayarannya sendirian.
Perbedaan PR dan PO
Keduanya mudah tertukar, dan banyak perusahaan memakai satu formulir untuk keduanya.
- Purchase requisition (PR), atau pengajuan pembelian, bersifat internal. PR meminta izin untuk mengeluarkan uang. PR tidak mengikat perusahaan pada apa pun, dan mungkin belum menyebutkan vendor atau harga akhirnya.
- Purchase order (PO) bersifat eksternal. PO dikirim ke vendor dan mengikat perusahaan untuk membeli barang tertentu dengan harga dan syarat yang disebutkan. PO adalah dokumen yang nantinya menjadi acuan untuk memeriksa bukti penerimaan dan invoice.
Singkatnya, PR adalah pertanyaannya (“bolehkah kita membeli ini?”) dan PO adalah jawaban kepada vendor (“kami membeli ini, dengan syarat-syarat ini”).
Contoh perhitungan: memeriksa anggaran sebelum komitmen dibuat
Kembali ke conveyor belt tadi. Jika pengajuannya dibuat dengan benar, approver akan melihat anggaran pemeliharaan untuk triwulan tersebut:
| Anggaran pemeliharaan, Q4 | Nominal |
|---|---|
| Anggaran | Rp250.000.000 |
| Terpakai (invoice sudah diposting) | Rp148.000.000 |
| Terkomitmen (PO yang masih terbuka) | Rp31.500.000 |
| Tersedia | Rp70.500.000 |
| Pengajuan ini | Rp86.500.000 |
| Melebihi anggaran | Rp16.000.000 |
Jika hanya melihat buku besar, sisa anggaran tampak Rp102.000.000, sehingga pengajuan ini terlihat masih muat. Hitung juga purchase order yang sudah diterbitkan tetapi belum ditagih, dan ternyata pengajuan ini melebihi anggaran Rp16.000.000. Itulah keputusan yang perlu diambil approver sebelum pesanan dibuat: memindahkan anggaran, mengurangi pesanan atau menunda sebagiannya.
Inilah keunggulan yang jarang disadari dari proses P2P yang benar. Purchase order menunjukkan kepada tim keuangan apa yang sudah dikomitmenkan perusahaan sebelum invoice-nya datang, sehingga anggaran diperiksa terhadap posisi yang sebenarnya, bukan posisi bulan lalu.
Di mana procure-to-pay sering gagal
- Pembelian di luar proses. Pesanan lewat telepon atau chat membuat invoice menjadi dokumen pertama yang dilihat tim keuangan.
- PO dibuat setelah invoice datang. Purchase order yang dibuat hanya agar invoice lolos di sistem tidak mengontrol apa pun.
- Penerimaan yang tidak pernah dicatat. Tanpa bukti penerimaan, tim AP terpaksa menunggu atau membayar atas dasar kepercayaan.
- Persetujuan yang macet. Jika persetujuan memakan waktu seminggu, orang akan mencari jalan pintas.
- Master data vendor yang berantakan. Vendor yang sama terdaftar dua kali, rekening bank diubah lewat email dan tidak ada yang memeriksa keduanya.
- Invoice dari segala saluran, diketik manual. Email, kertas dan WhatsApp, masing-masing harus diinput dulu sebelum bisa dicocokkan.
- Pembayaran berdasarkan ingatan. Invoice dibayar ketika vendor menelepon, artinya sebagian terlalu cepat, sebagian terlambat dan diskon terlewat.
Procure-to-pay di Indonesia
- Catat status pajak saat onboarding vendor. Simpan NPWP-nya dan apakah vendor tersebut PKP, karena hanya PKP yang bisa menerbitkan faktur pajak.
- BAST untuk jasa. Untuk jasa, bukti penerimaannya biasanya berupa berita acara serah terima (BAST) yang menyatakan pekerjaan sudah diserahkan. Perlakukan BAST seperti bukti penerimaan barang dalam proses pencocokan.
- Periksa faktur pajak bersama invoice. PPN masukan hanya bisa dikreditkan atas faktur pajak yang lengkap dan benar, jadi periksa faktur pajak terhadap PO dan invoice di tahap pencocokan, bukan di akhir bulan.
- Perhitungkan pemotongan pajak. Untuk banyak jenis jasa, PPh 23 dipotong dari pembayaran, sehingga nominal yang ditransfer lebih kecil dari total invoice. Masukkan hal ini ke tahap pembayaran, termasuk bukti potong yang nantinya akan diminta vendor.
- PT yang tepat menerbitkan PO. Dalam grup dengan beberapa perusahaan, PO sebaiknya diterbitkan oleh entitas yang akan ditagih, agar invoice dan faktur pajaknya memuat nama dan NPWP yang benar.
Tanda proses P2P Anda perlu dibenahi
Anda mungkin perlu meninjau prosesnya jika salah satu hal ini terdengar familier:
- Tim keuangan baru tahu ada pembelian ketika invoice-nya datang.
- Purchase order dibuat setelah invoice datang, agar invoice lolos di sistem.
- Tidak ada yang bisa menyebutkan berapa yang sudah dikomitmenkan terhadap anggaran bulan ini.
- Tim AP membayar invoice tanpa bukti penerimaan yang tercatat.
- Rekening bank vendor diubah hanya berdasarkan email.
- Invoice dibayar terlambat, atau terlalu cepat, karena tidak ada yang memantau jatuh tempo.
- Pengaju menanyakan status pembeliannya ke tim keuangan setiap minggu.
Jika invoice adalah dokumen pertama yang dilihat tim keuangan, Anda tidak punya proses procure-to-pay. Anda hanya punya proses bayar.
Cara memperketat procure-to-pay triwulan ini
- Telusuri lima pembelian terakhir. Ikuti masing-masing dari pengajuan pertama sampai pembayaran, dan catat setiap langkah yang terjadi di chat, email atau hanya di kepala seseorang.
- Sepakati aturan “tanpa PO, tidak dibayar”. Tentukan kategori mana yang selalu memerlukan PO dan daftarkan pengecualiannya, seperti utilitas, sewa dan langganan. Arahkan invoice tanpa PO ke rantai persetujuan yang lebih ketat.
- Hitung komitmen dalam anggaran. Periksa setiap pengajuan terhadap yang sudah terpakai ditambah yang sudah dipesan.
- Permudah pencatatan penerimaan. Orang yang menerima barang seharusnya bisa mengonfirmasinya dalam satu menit, dari mana pun mereka berada.
- Bersihkan master data vendor. Gabungkan data yang ganda, verifikasi rekening bank dan wajibkan orang kedua menyetujui setiap perubahan rekening bank.
- Kumpulkan invoice di satu tempat. Satu inbox atau portal, dengan setiap invoice tertaut ke PO-nya.
- Bayar berdasarkan kalender. Susun batch pembayaran dari jatuh tempo dan diskon pembayaran awal, bukan dari siapa yang terakhir menelepon.
- Ukur hasilnya. Pantau porsi pengeluaran yang punya PO sebelum invoice datang, tingkat kecocokan pada pencocokan pertama dan porsi invoice yang dibayar tepat waktu.
Bagaimana Procapy membantu
Proca to Pay menjalankan seluruh siklus procure-to-pay di dalam Procapy. Pengeluaran dimulai dari vendor yang disetujui, item katalog dan harga kontrak, dan vendor baru di-onboard dengan verifikasi rekening bank dan dokumen sebelum bisa digunakan. Pengajuan pembelian dibuat di Procapy, bukan lewat pesan chat, dan ProcAI memeriksa setiap pengajuan terhadap kebijakan, anggaran dan daftar vendor sebelum bisa diajukan. ProcApprove kemudian mengarahkannya melalui matriks delegasi wewenang Anda, dan approver bertindak dari ponsel dengan anggaran terlihat di layar yang sama.
Pengajuan yang disetujui menjadi purchase order tanpa input ulang, penerimaan dicatat per baris PO dan komitmen yang masih terbuka terlihat oleh tim keuangan sebelum invoice datang. Invoice diteruskan, diunggah atau dikirim langsung oleh vendor, lalu ProcAI membacanya dan menautkan setiap invoice ke PO-nya. Procapy membandingkan invoice, PO dan bukti penerimaan baris demi baris dalam batas toleransi yang Anda tetapkan, serta menandai invoice duplikat, rekening bank yang berubah dan vendor tak dikenal sebelum disetujui. Invoice yang lolos masuk ke batch pembayaran yang disusun berdasarkan jatuh tempo, entitas dan bank, lalu diposting ke Dynamics, SAP, Xero, QuickBooks atau ABSS beserta jejak audit lengkapnya. Invoice tanpa PO tetap melewati capture, persetujuan, pemeriksaan fraud dan pembayaran, dan Anda yang menentukan kategori atau nominal mana yang wajib memiliki PO.
Sebagian besar tim sudah berjalan dalam waktu kurang dari dua minggu. Jadwalkan sesi demo dan bawa dokumen delegasi wewenang Anda, dan kami akan mengonfigurasi rantai persetujuan pertama Anda secara langsung.