Alur Persetujuan Permintaan Pembelian Berdasarkan Nominal

Senin pagi, tim operasional mengirim permintaan pembelian mesin senilai Rp18 juta lewat grup WhatsApp. Manajer membalas “cek dulu”, staf mengirim foto penawaran, lalu percakapan tertutup oleh pesan lain. Dua hari kemudian, pemasok menanyakan PO dan tim belum tahu siapa yang memegang keputusan terakhir.

Alur persetujuan permintaan pembelian perlu menjawab hal praktis: siapa mengajukan, informasi apa yang wajib ada, siapa memeriksa kebutuhan, batas nominal mana yang menentukan peninjau, dan bukti keputusan tersimpan di mana. Jika langkah itu ditulis jelas, manajer bisa memeriksa permintaan tanpa mencari konteks dari beberapa percakapan.

Artikel ini membahas proses internal perusahaan. Aturan pengadaan pemerintah berbeda menurut instansi dan regulasinya. JDIH Kementerian Keuangan, misalnya, mencatat Peraturan Menteri Keuangan 223/PMK.01/2021 tentang pengadaan barang/jasa di lingkungan Kementerian Keuangan; halaman itu menyebut aturan tersebut berlaku sejak 1 Januari 2022 sampai dicabut. Prosedur internal perusahaan swasta tidak otomatis mengikuti aturan khusus instansi tersebut. Gunakan kebijakan perusahaan dan nasihat yang sesuai untuk menetapkan kewenangan.

Mulai dari keputusan yang harus bisa dilacak

Pisahkan permintaan pembelian dari PO dan pembayaran. Permintaan menjelaskan kebutuhan dan meminta otorisasi. PO atau dokumen pemesanan menyatakan pembelian yang disetujui sesuai prosedur perusahaan. Pembayaran terjadi pada tahap berbeda, setelah tim memeriksa tagihan dan syaratnya. Menggabungkan semuanya dalam satu status “disetujui” membuat manajer sulit mengetahui apakah kebutuhan baru diajukan, barang sudah dipesan, atau uang sudah keluar.

Tentukan satu catatan induk untuk setiap permintaan. Beri nomor seperti PB-2026-0018, lalu hubungkan penawaran pemasok, persetujuan, PO, bukti penerimaan, dan invoice memakai nomor tersebut. Nomor yang sama mengurangi risiko dokumen tercecer saat nama barang atau pemasok ditulis dengan variasi.

Catatan awal dapat memuat tanggal pengajuan, pemohon, divisi, lokasi atau cabang, barang/jasa, alasan, jumlah, perkiraan nilai, tanggal dibutuhkan, pemasok yang diusulkan, penawaran, sumber anggaran internal bila relevan, status, peninjau aktif, dan keputusan. Tambahkan kolom khusus bila tim benar-benar memerlukannya. Formulir yang meminta data yang tidak dipakai hanya menambah waktu pengisian.

Nomor	Pemohon/divisi	Kebutuhan	Nilai perkiraan	Dibutuhkan	Lampiran	Status
PB-2026-018	Operasional	Servis unit pengemas	Rp18.000.000	12 Nov	Dua penawaran	Menunggu manajer
PB-2026-019	SDM	Kursi ruang pelatihan	Rp3.200.000	20 Nov	Spesifikasi	Perlu dilengkapi
PB-2026-020	Proyek A	Sensor pengukur	Rp27.500.000	8 Nov	Penawaran dan alasan	Menunggu direktur

Baris di atas adalah contoh kerja sintetis. Nilai, unit, tanggal, dan nomor bukan catatan pelanggan. Dalam pemakaian nyata, sesuaikan bidang dan aturan dengan organisasi kamu.

Tetapkan batas persetujuan sebelum permintaan datang

Buat matriks yang menerangkan siapa meninjau setiap nilai dan kondisi. Contoh kebijakan internal bisa menetapkan bahwa permintaan sampai Rp5 juta diperiksa manajer divisi, di atas Rp5 juta sampai Rp25 juta juga diperiksa manajer keuangan, dan nominal lebih besar memerlukan direktur. Angka ini hanya contoh untuk menunjukkan bentuk aturan, bukan rekomendasi ambang untuk perusahaan kamu.

Jangan berhenti pada angka. Tuliskan apakah nilai dihitung per item, per permintaan, atau seluruh kebutuhan yang saling terkait. Tanpa batas agregasi, orang dapat memecah satu kebutuhan menjadi beberapa formulir untuk melewati ambang. Tentukan juga perlakuan pajak, ongkos kirim, biaya instalasi, pembelian berulang, keadaan darurat, dan permintaan yang melampaui anggaran yang disetujui.

Kondisi contoh	Pemeriksa	Tindakan yang dicatat
Sampai Rp5 juta	Manajer pemohon	Setujui, tolak, atau minta perbaikan
Di atas Rp5 juta sampai Rp25 juta	Manajer pemohon lalu keuangan	Periksa kebutuhan dan ketersediaan anggaran internal
Di atas Rp25 juta	Manajer pemohon, keuangan, lalu direktur	Catat keputusan tiap tahap
Informasi inti belum lengkap	Pemohon melengkapi	Status kembali ke “perlu dilengkapi”

Siapa yang berwenang menentukan angka tersebut? Owner dan pimpinan yang ditunjuk sesuai tata kelola perusahaan. Manajer keuangan dapat membantu memperkirakan dampak dan kebutuhan pemeriksaan. Batas itu tidak boleh ditebak oleh pembuat formulir atau disalin dari contoh perusahaan lain tanpa keputusan internal.

Tuliskan apakah keputusan harus berurutan atau boleh berlangsung bersamaan. Jika kebutuhan teknis perlu dicek oleh operasional sebelum keuangan memeriksa, alurnya berurutan. Jika dua pemeriksa memberi masukan terpisah, tetapkan apakah keduanya wajib menyetujui. Beri pengganti yang berwenang untuk keadaan cuti, dan catat siapa yang mengambil alih.

Rancang formulir agar pemohon tidak menebak

Pemohon sebaiknya dapat menjelaskan kebutuhan dengan kalimat kerja: apa yang dibeli, masalah apa yang diselesaikan, siapa yang memakai, kapan dibutuhkan, dan apa akibatnya jika tertunda. Untuk barang, minta jumlah, satuan, spesifikasi dan lokasi. Untuk jasa, minta ruang lingkup, periode, hasil yang diharapkan, serta dasar pemilihan penyedia bila kebijakan meminta.

Lampiran perlu sesuai jenis permintaan. Penawaran pemasok membantu membandingkan nilai dan ruang lingkup. Dokumen teknis membantu pemeriksa memastikan spesifikasi. Bukti ketersediaan atau persetujuan anggaran internal membantu peninjau memahami sumber daya yang dipakai. Jangan meminta berkas tanpa menjelaskan siapa yang memeriksanya dan apa yang harus diperiksa.

Buat pilihan status yang berbeda: draf, diajukan, perlu dilengkapi, menunggu persetujuan, disetujui, ditolak, dipesan, diterima, dan ditutup. Tidak semua organisasi memerlukan seluruh status, tetapi jangan memakai “selesai” untuk beberapa kejadian. Keputusan persetujuan tidak membuktikan barang sudah diterima; penerimaan juga tidak membuktikan invoice sudah dibayar.

Catat keputusan, alasan, dan perubahan

Setiap peninjau perlu melihat permintaan, dokumen, keputusan sebelumnya, dan tindakan yang diminta. Pilihan keputusan bisa berupa setujui, tolak, atau minta perbaikan. Minta catatan singkat saat menolak atau mengubah lingkup, agar pemohon tahu bagian mana yang perlu diperbaiki. Simpan waktu keputusan dan identitas jabatan yang bertindak sesuai kebutuhan audit internal.

Jika nominal berubah setelah pengajuan, tentukan apakah alur harus dimulai kembali. Misalnya penawaran awal Rp24 juta berubah menjadi Rp29 juta setelah ongkos instalasi dihitung. Jika perubahan melewati batas otorisasi, kirim ke peninjau tambahan sebelum pemesanan. Jangan mengedit angka lama tanpa riwayat; simpan nilai sebelumnya dan alasan revisi.

Tetapkan cara mengelola permintaan darurat. Definisikan siapa yang dapat mengaktifkan jalur cepat, kondisi apa yang dianggap mendesak, informasi minimum yang tetap harus ada, serta kapan pemeriksaan susulan berlangsung. Jalur cepat tanpa batas dan catatan akan menyulitkan peninjauan sesudahnya.

Untuk menjaga proses tetap bergerak, tampilkan antrean yang bisa disaring menurut peninjau, usia permintaan, nilai, divisi, dan tanggal kebutuhan. Notifikasi sebaiknya mengarahkan penerima ke catatan yang benar, bukan menjadi satu-satunya tempat keputusan. Saat orang cuti atau berganti jabatan, pemilik proses memperbarui penugasan agar permintaan tidak tertahan pada akun yang tidak aktif.

Uji alur dengan permintaan yang pernah terjadi

Sebelum digunakan luas, jalankan beberapa contoh dari proses yang benar-benar pernah muncul, setelah data sensitif disamarkan. Uji permintaan di bawah ambang, tepat pada ambang, di atas ambang, nilai yang berubah, dokumen kurang, penolakan, dan peninjau yang tidak tersedia. Pastikan sistem memilih orang yang tepat dan menyimpan keputusan yang dapat ditemukan kembali.

Periksa titik gagal bersama pemohon dan peninjau. Apakah pemohon memahami dokumen yang perlu dilampirkan? Apakah manajer dapat melihat alasan serta sisa tugasnya? Apakah perubahan nilai memicu pemeriksaan ulang? Apakah status “dipesan” hanya muncul setelah tindakan pemesanan benar-benar terjadi? Perbaiki istilah yang membuat dua orang menafsirkan status secara berbeda.

Kesalahan yang sering membuat alur tersendat adalah meminta persetujuan lewat percakapan tanpa menautkan nomor permintaan, menentukan batas setelah transaksi masuk, membiarkan satu orang menyetujui permintaannya sendiri, atau menganggap keputusan sama dengan pembayaran. Manajer juga perlu menghindari satu ambang yang terlalu umum bagi kebutuhan berbeda, seperti pembelian berulang dan pekerjaan darurat. Tulis pengecualian yang disetujui, bukan mengandalkan kebiasaan lisan.

Saat spreadsheet mulai sulit dipelihara

Kalau daftar permintaan, peninjau, dan status sudah tersebar di beberapa spreadsheet, kamu dapat menilai apakah satu aplikasi kerja akan membantu. Halaman aplikasi Sora menjelaskan bahwa owner dapat menceritakan alur atau mengunggah spreadsheet untuk membuat aplikasi tim, dengan jabatan, persetujuan, cabang, dan laporan. Beranda Sora menampilkan contoh alur persetujuan berdasarkan nominal, tetapi contoh itu adalah ilustrasi, bukan hasil pelanggan. Periksa usulan perubahan sebelum menerapkannya.

Untuk memastikan cara kerja produk, baca penjelasan Sora dan halaman aplikasi bisnis sesuai bidang usaha. Fitur yang dipublikasikan mencakup persetujuan bertahap bersyarat, akses per jabatan, catatan per cabang, nomor otomatis, laporan, dan riwayat versi. Pilih hanya bagian yang cocok dengan proses perusahaan kamu; tim tetap perlu menetapkan kewenangan dan kebijakan pembeliannya sendiri. Untuk contoh kontrol kas yang lebih rinci, lihat panduan pencatatan arus kas tim.

Mulai dari satu kategori pembelian

Hari ini, pilih satu kategori yang sering diajukan dan tulis formulir ringkasnya: pemohon, kebutuhan, nilai, tanggal diperlukan, penawaran, dan keputusan. Minta owner atau pemegang kewenangan menetapkan batas persetujuan serta pengganti peninjau. Jalankan satu permintaan uji dari awal hingga penutupan, lalu perbaiki kolom atau status yang membuat orang menebak langkah berikutnya.