Kronologi Singkat
Pertengahan April 2026, sebuah UMKM hidroponik di rusunawa Jakarta Utara menagih pembayaran kepada kliennya — sebuah catering korporat — untuk dua komoditas: 54 kg kangkung dan 50 kg pakcoy. Total Rp 2.318.000.
Invoice dibuat dalam format PDF standar — kop surat, daftar item, nominal, nomor rekening Bank X berakhiran 4477, dan tanda tangan admin UMKM. File itu dikirim ke klien lewat WhatsApp, dari nomor bisnis UMKM. Berkas masuk, klien membuka, proses pembayaran berjalan.
Sampai di sini, tidak terdengar aneh. Justru karena terlalu biasa, kasus seperti ini layak dibedah.
Empat Titik Kerentanan yang Jarang Disadari
Invoice PDF seperti di atas, dalam perjalanan dari pengirim ke penerima, melewati beberapa tangan dan perangkat. Di tiap titik, ada celah yang tidak kelihatan:
- Nominal bisa diubah di editor PDF. Tools gratis di browser memungkinkan siapa pun mengganti "Rp 2.318.000" menjadi angka lain, lalu menyimpan ulang. Hasilnya tetap terlihat sebagai PDF yang wajar.
- Nomor rekening bisa diganti. Pihak yang menyamar sebagai UMKM bisa mengirim ulang "invoice" dengan rekening tujuan berbeda — mengatasnamakan vendor asli.
- Tanda tangan bisa disalin. Gambar tanda tangan yang tertempel di PDF, pada dasarnya, adalah PNG yang bisa di-copy-paste ke invoice lain dalam hitungan detik.
- Tidak ada cara klien memastikan yang diterima sama dengan yang dikirim. Setelah file berpindah tangan, tidak ada jalur verifikasi mandiri untuk penerima.
Empat hal di atas bukan hipotesis. Ini skenario yang rutin terjadi di rantai penipuan invoice — dan menargetkan UMKM bukan korporasi besar, justru karena infrastrukturnya longgar.
Apa yang Bisa Berubah dalam 10 Detik
Bayangkan invoice Rp 2.318.000 tadi dicegat di suatu titik — entah di level perangkat, email forwarding, atau bahkan chat WhatsApp yang diteruskan.
Dalam sepuluh detik dengan editor PDF sederhana:
- Nominal Rp 2.318.000 → Rp 23.180.000 (kesalahan "ketik nol lebih" yang masuk akal di mata klien yang buru-buru)
- Rekening berakhiran 4477 → diganti dengan rekening milik pihak lain
- Tanggal invoice digeser satu atau dua minggu untuk menyesuaikan alur jatuh tempo
File palsu itu lalu dikirim ke klien lewat chat yang terlihat biasa. Klien yang sedang mengejar deadline bisa membayar ke rekening yang salah — kepada pihak yang salah — tanpa merasa ada yang ganjil.
Mengapa UMKM Tidak Selalu Bisa Pakai TTE Tersertifikasi
Solusi paling "formal" untuk tanda tangan elektronik berkekuatan hukum adalah TTE dari PSrE tersertifikasi (Privy, Vida, Tilaka, dan seterusnya). Tapi untuk UMKM yang mengirim 10–50 invoice per bulan dengan nominal Rp 1–5 juta, TTE tersertifikasi sering kali tidak pas:
- Biaya per dokumen lebih tinggi dan umumnya dalam skema langganan
- Proses KYC untuk tiap pihak tidak sepadan untuk transaksi harian
- Penerima invoice (klien) sering tidak familier dengan aplikasi PSrE yang dipakai UMKM
Untuk kontrak bernilai tinggi, perjanjian formal, atau dokumen yang berpotensi dibantah di pengadilan, TTE tersertifikasi tetap jawaban yang paling tepat. Tapi invoice Rp 2–3 juta sehari-hari? Di situ ada ruang yang selama ini kosong — bukan karena masalahnya kecil, tapi karena solusinya belum pas.
Lapisan Verifikasi yang Pas untuk Kasus seperti Ini
Yang sebenarnya dibutuhkan invoice seperti contoh di atas cukup sederhana:
- Penerima harus bisa mengecek sendiri bahwa invoice yang ia terima adalah file yang benar-benar dikirim oleh UMKM
- Harus ada jejak timestamp yang tidak bisa diubah di dalam file
- Prosesnya harus ringan — bisa selesai dalam hitungan detik, bukan menit
Ini bukan tugas TTE tersertifikasi. Ini tugas lapisan verifikasi harian — dan itulah celah yang TTDsah coba isi. Posisi jujurnya dijelaskan di panduan terpisah: bukan pengganti PSrE, bukan pengganti e-Meterai.
Dengan stempel QR dan halaman verifikasi publik, invoice yang sama bisa membawa satu tambahan:
- UMKM sahkan invoice sebelum dikirim
- Stempel QR, hash dokumen, dan timestamp tercetak otomatis
- Klien scan QR saat menerima
- Halaman verifikasi terbuka di browser — menampilkan hash, tanggal pengesahan, dan identitas pengirim
- Jika file yang diterima sudah diubah bahkan satu byte, hash-nya tidak akan cocok — verifikasi gagal secara otomatis
Versi palsu tidak akan pernah lulus verifikasi publik. Klien tahu sebelum membayar, bukan setelah dana sudah pindah rekening.
Skenario Before / After
Tanpa lapisan verifikasi:
UMKM kirim invoice → file bisa diubah di jalan → klien tidak punya cara memastikan → pembayaran berisiko keliru.
Dengan lapisan verifikasi (Rp 2.500 per invoice):
UMKM sahkan invoice sebelum dikirim → QR dan timestamp tercetak → klien scan saat menerima → hash cocok berarti asli, hash tidak cocok berarti file sudah dimodifikasi.
Biaya per invoice Rp 2.500 — sekitar 0,1% dari nilai tagihan Rp 2,3 juta. Dibanding risiko pembayaran ke rekening yang salah, ini angka yang gampang diputuskan. Untuk panduan mana yang dipakai pada jenis dokumen apa, lihat kapan pakai e-Meterai, TTE, atau QR.
Penutup
Kasus invoice Rp 2,3 juta ini tidak istimewa — justru karena biasanya, ia penting. Ratusan ribu UMKM mengirim dokumen seperti ini tiap hari. Jika editor PDF butuh sepuluh detik untuk mengubah angka di dalamnya, pencegahannya harus lebih cepat dari itu.
Dokumen yang rapuh bukan hanya soal dokumen tanpa tanggal. Ia juga soal dokumen yang tidak bisa diverifikasi oleh penerima — dan itulah titik yang bisa ditutup dengan lapisan paling tipis sekalipun. Untuk memahami bagaimana cara kerjanya dari sisi penerima, cara verifikasi dokumen ber-QR menjelaskannya dalam satu menit.
→ Coba TTDsah dari paket Coba Dulu Rp 5.000 di ttdsah.com — dua invoice pertama untuk mengesahkan, atau menguji sendiri halaman verifikasi publiknya.
TTDsah dioperasikan oleh Renold Sutadi (NIB: 1204260052017). Kontak: hello@ttdsah.com
Seluruh detail pihak dalam studi kasus ini telah dianonimisasi: nama UMKM, nama klien korporat, nama admin, nomor rekening lengkap, dan nomor telepon tidak ditampilkan. Nominal tagihan, jenis komoditas, dan wilayah umum dipertahankan sebagai konteks karena tidak bersifat mengidentifikasi pihak tertentu.