Di banyak perusahaan, proses persetujuan pengeluaran tersendat bukan karena orangnya lambat, tetapi karena aturan limit dan jalur otorisasi tidak konsisten. Ketika batas persetujuan ditetapkan lewat chat, email, atau spreadsheet, risiko salah approve, keterlambatan pembayaran, dan temuan audit meningkat. Panduan ini menjelaskan cara mengotomasi approval limit dengan software approval internal dan pendekatan yang umum dipakai di Indonesia, sehingga kontrol internal lebih kuat tanpa menambah beban tim finance.
Memetakan kebijakan approval limit dan risiko yang ingin ditutup
Sebelum mengatur sistem, pastikan kebijakan approval limit jelas dan dapat dijadikan aturan. Kepala finance biasanya sudah punya matriks otorisasi, namun sering kali masih bercampur antara jenis transaksi, unit bisnis, dan kondisi khusus seperti pembelian mendesak.
Mulailah dengan peta sederhana namun lengkap: jenis transaksi, nilai, dan siapa yang berwenang menyetujui. Di Indonesia, praktik umum adalah memisahkan approval untuk pengadaan (PO), pembayaran (payment request), dan klaim biaya (expense claim) karena risikonya berbeda.
Agar kebijakan bisa diaudit, tentukan juga tujuan kontrolnya. Misalnya, mencegah satu orang membuat dan menyetujui permintaan yang sama, serta memastikan transaksi material melewati tingkat manajemen yang sesuai.
- Jenis transaksi: PO, invoice/GRN, pembayaran vendor, reimburse karyawan, petty cash.
- Dimensi limit: nominal (mis. sampai Rp10.000.000), kategori biaya, proyek/cost center.
- Level approver: supervisor, manager, head, direktur.
- Kondisi khusus: vendor baru, kontrak belum ada, biaya di luar budget, transaksi mendekati akhir bulan.
- Kontrol tambahan: lampiran wajib, verifikasi 3-way matching, pembatasan perubahan setelah submit.
Uji kebijakan dengan contoh nyata. Misalnya, PO Rp8.500.000 untuk marketing mungkin cukup disetujui manajer, tetapi invoice Rp8.500.000 dari vendor baru sebaiknya memicu persetujuan tambahan dari procurement atau compliance.
Mendesain alur otomatis: rule-based routing, eskalasi, dan pengecualian
Otomasi efektif bukan sekadar memindahkan form ke aplikasi, melainkan membuat sistem memilih jalur persetujuan sesuai aturan. Biasanya dibutuhkan kombinasi rule-based routing, eskalasi bila melewati SLA, dan pengecualian yang terkontrol.
Aturan dasar biasanya limit bertingkat berdasarkan nominal. Contoh: sampai Rp5 juta disetujui supervisor, Rp5–25 juta disetujui manajer, di atas Rp25 juta disetujui head, dan di atas Rp100 juta disetujui direktur.
Tambahkan dimensi bisnis yang sering menimbulkan risiko. Misalnya, transaksi di luar budget harus selalu menambah satu lapis persetujuan, walau nominalnya kecil.
Rancang pula eskalasi. Jika approver tidak merespons dalam 24 jam kerja, sistem mengingatkan dan bisa meneruskan ke atasan fungsional sambil mencatat siapa yang akhirnya memberi keputusan.
- Rule nominal: bertingkat berdasarkan rentang nilai transaksi.
- Rule atribut: vendor baru, kategori sensitif (hadiah, entertainment), atau proyek tertentu.
- Rule budget: dalam budget vs di luar budget, plus toleransi (mis. deviasi 5%).
- Eskalasi SLA: reminder otomatis dan eskalasi jika melewati batas waktu.
- Pengecualian: urgent tetap bisa jalan, tetapi wajib alasan, lampiran, dan approval level lebih tinggi.
Tutup celah perubahan data setelah disetujui. Praktik aman: setelah submit, field kritikal (vendor, nominal, rekening, cost center) dikunci; jika perlu diubah, ajukan ulang agar approval mengikuti data baru.
Jika Anda sedang menyusun kerangka kontrol dan jejak audit yang lebih kuat, referensi praktis tentang penguatan keamanan persetujuan dan kesiapan audit bisa dibaca di panduan keamanan dan audit pada aplikasi approval.
Menyiapkan kontrol kepatuhan: segregasi tugas, audit trail, dan retensi dokumen
Auditor biasanya bertanya: siapa mengajukan, siapa memeriksa, siapa menyetujui, dan apa buktinya. Oleh karena itu, desain approval limit harus terkait langsung dengan kontrol kepatuhan.
Pertama, pastikan segregasi tugas (SoD) diterapkan secara konsisten. Contoh: pemohon tidak boleh menjadi approver untuk transaksi yang sama, dan pembuat vendor master tidak boleh sendirian menyetujui pembayaran pertama ke vendor tersebut.
Kedua, audit trail harus otomatis dan tidak dapat diubah. Simpan minimal waktu submit, urutan approver, keputusan (approve/reject), komentar, revisi dokumen, dan daftar lampiran yang diunggah.
Ketiga, dokumentasi harus mudah ditelusuri. Di Indonesia, bukti yang sering diminta saat audit meliputi purchase requisition, PO, bukti penerimaan barang/jasa, invoice, serta bukti pembayaran termasuk dasar penunjukan vendor bila ada kebijakan tender.
- SoD: blokir self-approval dan konflik peran pada proses yang sama.
- Jejak audit: log lengkap keputusan, waktu, dan alasan.
- Versi dokumen: setiap revisi membuat jejak versi baru, bukan menimpa.
- Retensi: tetapkan masa simpan sesuai kebijakan perusahaan dan kebutuhan audit.
- Akses: prinsip least privilege untuk melihat, menyetujui, dan mengunduh dokumen.
Untuk transaksi yang berpotensi berdampak pajak, disiplin dokumentasi membantu saat rekonsiliasi dan pemeriksaan. Jika tim Anda perlu rujukan seputar administrasi perpajakan dan layanan pajak di Indonesia, informasi dasar tersedia di situs Direktorat Jenderal Pajak: https://www.pajak.go.id/.
Implementasi dan uji coba: dari pilot hingga monitoring yang terukur
Setelah aturan ditetapkan, jalankan pilot pada satu proses dengan volume tinggi, misalnya reimburse atau payment request vendor. Tujuannya melihat apakah routing sudah tepat dan apakah pengguna memahami alasan approval tambahan.
Siapkan skenario uji yang mencerminkan kondisi lapangan. Contoh: transaksi Rp9.900.000 dalam budget, transaksi Rp9.900.000 di luar budget, vendor baru, lampiran tidak lengkap, dan perubahan nominal setelah submit yang perlu resubmission.
Pantau metrik selama 2–4 minggu pertama. Jika waktu persetujuan membaik tetapi jumlah pengecualian naik, kemungkinan aturan terlalu longgar atau pengguna menemukan celah proses.
- Cycle time: rata-rata waktu dari submit sampai approve.
- Backlog: jumlah permintaan menunggu persetujuan per approver.
- Exception rate: persentase transaksi urgent atau di luar policy.
- Rework: transaksi ditolak karena dokumen kurang atau salah coding akun.
- Compliance flags: potensi konflik peran dan approval yang tidak sesuai matriks.
Jadwalkan review berkala terhadap matriks limit, terutama saat ada perubahan struktur organisasi, pembukaan unit baru, atau perubahan threshold materialitas. Approval limit yang baik selalu relevan dengan risiko dan kapasitas pengambilan keputusan, bukan sesuatu yang dibuat sekali lalu dibiarkan.
Dengan aturan limit yang terpetakan, routing otomatis yang tegas, dan kontrol audit yang kuat, proses persetujuan bisa lebih cepat tanpa mengorbankan kepatuhan. Anda juga mendapatkan konsistensi keputusan, bukti yang rapi saat audit, serta ruang bagi tim finance untuk fokus pada analisis, bukan mengejar tanda tangan.
Jika perlu, susun daftar aturan dan skenario uji untuk ditinjau bersama sebelum penerapan penuh.
Pelajari Epruvo lebih lanjut: https://epruvo.com