Dokumen pembayaran dapat tampak lengkap di layar, tetapi tetap gagal saat berpindah dari SPP ke SPM atau dari SPM ke SP2D. Penyebabnya sering bukan satu kolom kosong. Nilai pada rincian tidak sama dengan ringkasan, pihak yang memeriksa berbeda dengan pemilik otorisasi, bukti pajak belum final, rekening berubah, status sistem dibaca sebagai persetujuan, atau dokumen hasil cetak tidak lagi sama dengan data yang terakhir disimpan. Masalah ini makin sulit dilacak ketika tim hanya menyimpan tangkapan layar tanpa versi, waktu, dan penanggung jawab.
Jawaban langsung: Readback SPP–SPM–SP2D di SIPD RI perlu dilakukan sebagai pemeriksaan tiga arah: dokumen sumber, data yang tersimpan dalam sistem, dan keluaran yang akan diotorisasi. Kunci satu baseline pembayaran, cocokkan identitas pihak, dasar tagihan, akun, nilai bruto, potongan, pajak, nilai bersih, rekening, kewenangan, serta status. Setiap koreksi membuka versi baru dan mengulang field terdampak. Status “tersimpan” atau “terkirim” tidak boleh diperlakukan sebagai bukti bahwa substansi telah disetujui.
Artikel ini mendukung Bimtek Implementasi SIPD RI dalam Penatausahaan Keuangan Daerah dan melengkapi panduan uji bukti belanja bendahara pengeluaran. Dasar umumnya adalah PP 12/2019 tentang Pengelolaan Keuangan Daerah dan Permendagri 77/2020 tentang Pedoman Teknis Pengelolaan Keuangan Daerah. Batas penerapan: matriks ini adalah alat kendali dokumen dan data, bukan pengganti ketentuan daerah, konfigurasi SIPD RI yang berlaku, pemeriksaan berwenang, atau keputusan pejabat yang diberi kewenangan.
Matriks delapan gerbang SPP–SPM–SP2D
| Gerbang | Pertanyaan uji | Bukti minimum | Keputusan | Red flag |
|---|---|---|---|---|
| Paket | Apakah satu tagihan memiliki baseline yang jelas? | kontrak/PO, BAST, invoice | kunci/lengkapi | lampiran campur |
| Pihak | Apakah penyedia, penerima, PA/KPA, PPK-SKPD, PPTK, dan bendahara sesuai? | master pihak dan kewenangan | cocok/perbaiki | akun dipakai silang |
| Akun | Apakah program, kegiatan, subkegiatan, rekening, dan sumber dana konsisten? | DPA/DPPA dan rincian | pakai/telaah | akun hanya disalin |
| Nilai | Apakah bruto, potongan, pajak, dan bersih dapat dihitung ulang? | kertas kalkulasi | setuju/koreksi | selisih pembulatan |
| Rekening | Apakah nama, nomor, bank, dan tujuan pembayaran tervalidasi? | dokumen bank/master vendor | valid/tahan | perubahan lewat chat |
| Otorisasi | Apakah pembuat, pemeriksa, dan pemberi persetujuan terpisah? | matriks kewenangan | lanjut/eskalasi | self-approval |
| Status | Apakah arti status dan timestamp dibaca benar? | log sistem | lanjut/tunggu | tersimpan dianggap sah |
| Readback | Apakah keluaran identik dengan baseline final? | log dua petugas | otorisasi/perbaiki | PDF beda dari layar |
Kunci baseline sebelum membuka alur
Satu paket pembayaran perlu memiliki identitas yang tidak berubah diam-diam: nomor paket, pihak, dasar tagihan, jenis pembayaran, periode, DPA atau DPPA, program, kegiatan, subkegiatan, rekening belanja, sumber dana, nilai kontrak, nilai yang diminta, serta daftar lampiran. Beri nomor versi dan waktu cut-off. Jika ada adendum, koreksi BAST, perubahan rekening, atau faktur pengganti, jangan menimpa baseline lama tanpa jejak. Hubungkan perubahan dengan field yang terdampak dan orang yang memutuskan. Langkah ini membuat tim dapat menjelaskan mengapa angka pada versi sekarang berbeda dari versi sebelumnya.
Pisahkan pemeriksaan substansi dan pemeriksaan input
Pemeriksaan substansi menjawab apakah hak tagih, prestasi, masa pembayaran, akun, dan perlakuan pajak didukung bukti. Pemeriksaan input menjawab apakah hasil pemeriksaan itu diterjemahkan dengan benar ke field SIPD RI. Keduanya tidak boleh digabung menjadi tanda centang generik “sudah dicek”. Petugas yang membaca invoice dan BAST mencatat temuannya; petugas input menunjukkan field tujuan; pemeriksa kedua membaca kembali dari dokumen sumber ke layar. Dengan cara ini, kesalahan logika tidak tersembunyi di balik input yang rapi, dan kesalahan ketik tidak dianggap sebagai masalah kebijakan.
Rekonsiliasi nilai sebagai persamaan tertutup
Susun kalkulasi yang dapat diulang: nilai bruto dikurangi potongan dan kewajiban yang relevan menghasilkan nilai bersih yang dibayarkan. Setiap elemen memiliki dasar, formula, pembulatan, serta pemilik data. Jumlah rincian harus sama dengan ringkasan, dan nilai pada SPP harus dapat ditelusuri sampai ke SPM lalu SP2D. Jika satu koreksi pajak mengubah nilai bersih, ulangi pemeriksaan rekening tujuan, total paket, dan keluaran. Jangan menutup selisih dengan angka penyeimbang yang tidak memiliki bukti.
Kontrol identitas dan rekening tujuan
Nama penyedia atau penerima, NPWP atau identitas relevan, nomor rekening, nama bank, dan pemilik rekening perlu dibandingkan dengan master yang disahkan. Perubahan rekening merupakan event berisiko tinggi: minta dokumen formal, verifikasi melalui kanal yang disepakati, catat pemeriksa, dan pisahkan orang yang mengubah master dari orang yang menyetujui pembayaran. Pesan singkat, surat elektronik tunggal, atau salinan buku tabungan tanpa validasi tidak cukup menjadi satu-satunya dasar. Untuk pembayaran nonpenyedia, sesuaikan bukti identitas dengan konteks yang berlaku.
Baca status sistem sebagai peristiwa, bukan kesimpulan
Status “draft”, “tersimpan”, “dikirim”, “diverifikasi”, “ditolak”, atau istilah lain pada konfigurasi yang aktif perlu dipetakan ke tindakan, pemilik, waktu, dan bukti. Status teknis tidak otomatis membuktikan kebenaran material atau persetujuan pejabat. Simpan timestamp, pengguna, versi, alasan penolakan, serta field yang berubah setelah dikembalikan. Bila sistem atau integrasi mengalami gangguan, gunakan prosedur resmi yang berlaku dan hindari membuat jalur bayangan yang tidak dapat direkonsiliasi ketika layanan kembali normal.
Jaga pemisahan peran dan otorisasi
Naskah resmi Permendagri 77/2020 menegaskan bahwa pengelolaan keuangan daerah melibatkan aliran data dan penggunaan dokumen secara elektronik serta membagi peran pengelola sesuai fungsi. Karena itu, matriks kewenangan perlu menyebut siapa yang menyiapkan, memeriksa, mengoreksi, menyetujui, dan menindaklanjuti penolakan. Akun pengguna tidak boleh dipinjamkan untuk mengejar waktu. Cuti, pergantian pejabat, atau delegasi sementara harus mempunyai dasar dan masa berlaku. Pemeriksa readback sebaiknya bukan orang yang baru saja mengubah field kritis.
Register selisih dan koreksi
Register berikut menghubungkan temuan dengan sumber, versi, dampak, tindakan, pemilik, dan bukti penutupan. Satu temuan baru ditutup setelah dokumen sumber, data sistem, dan keluaran final kembali konsisten.
| ID | Temuan | Dampak | Tindakan | Pemilik/tenggat | Status |
|---|---|---|---|---|---|
| PAY-031 | rekening pada master berubah | risiko salah bayar | tahan dan validasi formal | PPK-SKPD/H-2 | Hold |
| PAY-042 | pajak pada rincian berbeda dari ringkasan | nilai bersih | hitung ulang dan input ulang | Bendahara/H-1 | Berjalan |
| PAY-053 | akun subkegiatan tidak sama dengan DPA | klasifikasi belanja | telaah baseline anggaran | PPTK/H-1 | Terbuka |
| PAY-064 | PDF SPM dibuat sebelum koreksi terakhir | otorisasi versi lama | hasilkan ulang dan readback | Operator/Hari H | Exception |
Contoh ilustratif
Contoh ilustratif. Sebuah tagihan jasa telah memiliki BAST dan invoice. SPP menampilkan nilai bruto yang benar, tetapi potongan pajak pada ringkasan berbeda dari rincian dan rekening penyedia baru saja diubah. Tim tidak meneruskan paket hanya karena status sudah “terkirim”. Mereka membuka dua temuan, memvalidasi rekening melalui dokumen formal, menghitung ulang pajak, membuat versi baru, lalu pemeriksa kedua membaca dokumen sumber ke SPP, SPM, dan keluaran SP2D. Contoh ini rekaan.
Matriks keputusan sebelum otorisasi
| Kondisi | Keputusan kerja | Bukti penutupan |
|---|---|---|
| Substansi, input, peran, dan keluaran konsisten | lanjutkan sesuai kewenangan | log readback dua petugas |
| Dokumen sumber belum final | tahan field dan status terkait | dokumen final berversi |
| Rekening atau identitas berubah | tahan pembayaran dan validasi | master disahkan dan jejak verifikasi |
| Keluaran berbeda dari data terakhir | jangan otorisasi | keluaran baru dan readback ulang |
Alur pemeriksaan
- Kunci identitas dan versi paket.
- Uji hak tagih dan kelengkapan bukti.
- Cocokkan DPA/DPPA, subkegiatan, akun, dan sumber dana.
- Hitung ulang bruto, potongan, pajak, dan bersih.
- Validasi pihak dan rekening.
- Periksa pemisahan peran serta masa berlaku kewenangan.
- Baca status dan timestamp.
- Bandingkan dokumen sumber ke input SPP.
- Bandingkan SPP ke SPM dan keluaran SP2D.
- Tutup selisih atau tahan otorisasi.
Checklist readback
- Satu baseline dan nomor versi tersedia.
- Dasar tagihan serta bukti prestasi tertaut.
- Pihak dan kewenangan cocok.
- DPA/DPPA, subkegiatan, akun, dan sumber dana konsisten.
- Bruto, potongan, pajak, dan bersih dapat dihitung ulang.
- Rekening tervalidasi, terutama setelah perubahan.
- Status dibaca bersama timestamp dan pelakunya.
- Setiap koreksi membuka versi baru.
- PDF atau keluaran dibuat setelah koreksi terakhir.
- Pemeriksa kedua membaca sumber ke keluaran final.
Untuk latihan penerapan sesuai konteks pemerintah daerah, lihat Bimtek Implementasi SIPD RI dalam Penatausahaan Keuangan Daerah atau hubungi tim melalui WhatsApp.