Masalah pengeluaran bisnis tidak selalu berasal dari fraud. Kadang penyebabnya lebih sederhana: siapa pun bisa membeli, approval hanya melalui chat, tidak ada batas nominal, dan finance baru mengetahui transaksi ketika invoice jatuh tempo.
Ketika bisnis makin besar, pola informal seperti ini semakin berisiko. Mengembangkan Approval Matrix membantu perusahaan menciptakan jalur otorisasi yang jelas tanpa membuat semua keputusan harus naik ke direktur.
Jika dirancang berdasarkan risiko, matrix bisa mempercepat transaksi rutin sekaligus memberikan pengawasan lebih ketat pada pengeluaran yang benar-benar material.
Approval Matrix Harus Menjawab Empat Pertanyaan
Approval matrix yang efektif setidaknya menjawab empat hal.
Siapa yang boleh membuat request? Siapa yang boleh menyetujui? Berapa batas nominalnya? Dan transaksi apa yang membutuhkan approval khusus?
Misalnya Procurement Staff dapat membuat purchase request, Procurement Manager menyetujui sampai Rp15 juta, Finance Manager sampai Rp50 juta, lalu transaksi di atas Rp50 juta memerlukan Director.
Oracle NetSuite menggunakan mekanisme serupa melalui approval hierarchy dan purchase approval limit. Ketika nilai sebuah permintaan melewati batas approver pertama, workflow dapat meneruskannya kepada pejabat dengan limit lebih tinggi.
Struktur seperti ini menghilangkan area abu-abu.
Tim tidak lagi bertanya setiap kali transaksi muncul, “Ini harus minta izin ke siapa?”
Jangan Hanya Menggunakan Nominal
Kesalahan pertama adalah menganggap risiko transaksi selalu mengikuti nilainya.
Tidak selalu.
Pembelian rutin Rp20 juta kepada supplier lama mungkin lebih rendah risikonya dibanding transfer Rp10 juta ke vendor yang baru dibuat satu jam sebelumnya.
Karena itu, gunakan beberapa dimensi.
Nominal tetap penting, tetapi pertimbangkan juga jenis pengeluaran, status vendor, apakah transaksi berada di dalam budget, durasi kontrak, dan sifat transaksinya.
Oracle mendokumentasikan bahwa workflow approval dapat dibuat melalui hierarchical maupun custom routing serta conditional rules. Artinya, jalur approval memang dapat dirancang berdasarkan kondisi tertentu, bukan hanya satu batas angka.
Untuk UMKM, prinsip tersebut bisa diterapkan menggunakan matrix sederhana di spreadsheet.
Buat Kategori Risiko Rendah, Menengah, dan Tinggi
Supaya matrix mudah dipahami, kelompokkan transaksi berdasarkan risk level.
1. Risiko Rendah
Pembelian rutin, vendor terverifikasi, berada dalam budget, dan nominal kecil.
Approval cukup oleh supervisor atau budget owner.
2. Risiko Menengah
Nominal lebih besar, kontrak baru, pembelian aset, atau transaksi yang mulai mendekati batas anggaran.
Approval dapat melibatkan department head dan finance.
3. Risiko Tinggi
Vendor baru, perubahan rekening supplier, pembayaran di luar budget, transaksi material, related-party transaction, atau commitment jangka panjang.
Gunakan dual approval atau approval direktur.
Pendekatan berbasis risiko sesuai dengan prinsip internal control bahwa control activities perlu dirancang untuk merespons risiko yang relevan.
COSO menekankan bahwa kontrol efektif membantu organisasi mencapai tujuan serta meningkatkan kepercayaan terhadap informasi yang digunakan.
Matrix akhirnya tidak hanya menjadi alat administrasi, tetapi alat manajemen risiko.
Terapkan Segregation of Duties
Approval akan kehilangan fungsi jika satu orang mengendalikan semuanya.
Bayangkan seorang staf dapat membuat vendor, membuat purchase request, menyetujui invoice, dan melakukan transfer.
Secara sistem mungkin terlihat efisien. Dari perspektif kontrol, kondisinya sangat lemah.
ICAEW menjelaskan bahwa segregation of duties merupakan salah satu bentuk control activity bersama authorization, performance review, information processing, dan physical controls.
Idealnya proses pengeluaran dipisah menjadi beberapa fungsi:
request, approval, verification, dan payment execution.
Pada UMKM kecil, empat orang berbeda mungkin tidak tersedia.
AICPA & CIMA mencatat bahwa keterbatasan segregation of duties pada tim kecil dapat dikurangi menggunakan alternative controls seperti checklist, automated alerts, independent review, atau rotasi tanggung jawab.
Jadi, jangan menunggu bisnis besar untuk mulai mengendalikan proses.
Larang Self-Approval
Satu aturan sederhana dapat mencegah banyak masalah:
requester tidak boleh menjadi final approver untuk permintaannya sendiri.
Misalnya seorang manager ingin membeli laptop Rp18 juta. Meskipun approval limit manager adalah Rp20 juta, transaksi pribadinya tetap harus naik ke atasan atau pejabat lain.
Aturan yang sama berlaku untuk reimbursement.
Seseorang tidak seharusnya mengajukan biaya perjalanan Rp5 juta kemudian meng-approve klaimnya sendiri hanya karena masih berada dalam limit jabatannya.
Segregation of duties dirancang agar individu yang memiliki akses terhadap aset atau transaksi tidak sekaligus memiliki kemampuan penuh untuk menutupi kesalahan atau penyalahgunaan melalui catatan terkait.
ICAEW menjelaskan konsep ini sebagai mekanisme kontrol sederhana yang banyak digunakan perusahaan.
Self-approval harus menjadi exception yang sangat terbatas, bukan kebiasaan.
Tambahkan Finance Review pada Transaksi Tertentu
Department head memahami apakah sebuah pengeluaran dibutuhkan.
Namun finance memiliki perspektif lain: budget, cash flow, klasifikasi biaya, dan dampak kontrak.
Karena itu, matrix dapat menentukan finance review tanpa berarti finance harus meng-approve semua pembelian.
Misalnya transaksi dalam budget di bawah Rp10 juta cukup oleh manager.
Rp10–50 juta memerlukan manager plus finance.
Transaksi lebih besar membutuhkan director.
Untuk pembelian tertentu seperti prepaid contract satu tahun, lease, atau komitmen berulang, finance review dapat diwajibkan meskipun nilainya lebih kecil.
Cara ini mencegah situasi ketika sebuah biaya terlihat murah per bulan tetapi sebenarnya menciptakan commitment besar.
Misalnya software Rp8 juta per bulan dengan kontrak tiga tahun berarti perusahaan sedang membuat komitmen senilai Rp288 juta, bukan sekadar membeli sesuatu seharga Rp8 juta.
Buat Aturan Emergency Approval
Bisnis kadang menghadapi keadaan yang tidak bisa menunggu workflow normal.
Mesin rusak, sistem down, kendaraan distribusi bermasalah, atau fasilitas mengalami kerusakan mendadak.
Jika tidak ada emergency rule, tim biasanya melewati semua kontrol lalu berkata, “nanti dokumennya menyusul.”
Solusinya adalah membuat jalur khusus.
Emergency spending dapat dilakukan sampai nominal tertentu dengan approval satu pejabat senior, tetapi wajib direkonsiliasi dan didokumentasikan maksimal 24 atau 48 jam setelah transaksi.
Jangan menjadikan label “urgent” sebagai pintu belakang untuk menghindari approval.
Buat laporan bulanan berisi seluruh transaksi emergency. Jika departemen tertentu selalu memiliki pengeluaran “mendadak”, mungkin masalahnya bukan emergency tetapi perencanan yang buruk.
Lindungi Perubahan Data Vendor
Salah satu transaksi yang pantas mendapat special approval adalah perubahan detail vendor.
Contohnya supplier mengirim email bahwa rekening pembayarannya berubah.
Jangan otomatis mengganti data hanya karena invoice dan logo terlihat meyakinkan.
ICAEW pada pembahasan risiko deepfake dan voice-cloning menekankan pentingnya pemisahan initiation, approval, dan execution dalam pembayaran untuk mengurangi single point of failure.
Approval matrix dapat mengharuskan perubahan rekening vendor diverifikasi oleh finance melalui kontak yang sudah tersimpan sebelumnya.
Setelah verifikasi selesai, orang kedua menyetujui perubahan tersebut.
Kontrol kecil ini dapat menjadi sangat penting karena begitu uang terkirim ke rekening yang salah, proses pemulihannya bisa jauh lebih sulit.
Pastikan Transaksi Pending Tidak Bisa Diubah Diam-Diam
Ada satu kelemahan approval yang sering terlupakan.
Misalnya manager menyetujui purchase request sebesar Rp20 juta. Setelah approval, requester dapat mengedit nilainya menjadi Rp30 juta tanpa meminta approval lagi.
Kontrolnya jelas gagal.
Workflow sebaiknya mengunci transaksi ketika pending atau setelah disetujui. Jika jumlah, vendor, atau informasi material diubah, dokumen harus kembali melalui proses approval.
Oracle NetSuite secara eksplisit menyediakan opsi untuk mencegah records yang pending approval diedit serta memperbarui approval status dan next approver sebagai bagian workflow.
Jika masih memakai spreadsheet atau email, gunakan aturan serupa secara manual.
Setiap perubahan material setelah approval harus membatalkan persetujuan sebelumnya.
Bangun Audit Trail yang Bisa Ditelusuri
Approval melalui pesan singkat memang cepat, tetapi beberapa bulan kemudian sulit dibuktikan.
Siapa menyetujui? Kapan? Berdasarkan dokumen apa? Apakah nominalnya berubah?
Sistem idealnya menyimpan audit trail.
Catat requester, tanggal request, amount, vendor, budget code, approver, waktu approval, komentar, dan status akhir.
Approval workflow Oracle dapat mengirim notification, menentukan current atau next approver, serta menyediakan status approve dan reject dalam proses procurement.
Untuk perusahaan kecil, dokumentas tidak harus menggunakan ERP mahal.
Form online, accounting software, atau spreadsheet terkontrol dapat bekerja selama histori perubahan dan bukti persetujuan tersimpan dengan baik.
Cari Approval Bottleneck dan Rubber-Stamping
Terlalu sedikit approval meningkatkan risiko.
Terlalu banyak approval juga menciptakan masalah.
Jika setiap transaksi membutuhkan lima persetujuan, approver bisa berhenti membaca dan hanya menekan tombol “approve”. Ini disebut rubber-stamping.
ACFE mengingatkan bahwa keberadaan approval matrices dan prosedur tertulis saja belum menjamin fraud risk terkendali. Kontrol di atas kertas tetap membutuhkan oversight dan lingkungan organisasi yang mendukungnya.
Pantau beberapa metrik sederhana.
Berapa lama rata-rata request menunggu approval? Berapa banyak approval seorang director per bulan? Apakah hampir 100% request disetujui tanpa komentar?
Jika satu eksekutif menerima ratusan request kecil, delegasikan limit.
Approval harus menjadi titik pengambilan keputusan, bukan sekadar klik tambahan.
Review Matrix Ketika Bisnis Bertumbuh
Saat jumlah karyawan dan transaksi meningkat, struktur kewenangan harus ikut berkembang.
Supervisor baru mungkin membutuhkan limit tertentu. Cabang baru memerlukan approval lokal. Finance mungkin harus terlibat pada contract commitment yang sebelumnya tidak ada.
Review matrix setidaknya setahun sekali dan setiap kali terjadi reorganisasi besar.
Periksa siapa yang sudah keluar, siapa yang berpindah jabatan, serta siapa yang masih memiliki otorisai yang seharusnya dicabut.
Approval matrix yang tidak diperbarui dapat lebih berbahaya daripada tidak memiliki matrix sama sekali karena perusahaan merasa sudah memiliki kontrol, padahal kewenangannya tidak lagi sesuai struktur organisasi.
Mengembangkan Approval Matrix yang efektif berarti mengatur kewenangan berdasarkan nominal sekaligus risiko transaksi.
Larang self-approval, pisahkan proses request dan pembayaran, berikan finance review untuk transaksi material, dan bangun audit trail yang jelas.
Jangan membuat approval berlapis tanpa alasan. Mulailah dengan matrix sederhana, ukur bottleneck-nya, lalu sesuaikan mengikuti kompleksitas bisnis.