Reconciliation Selalu Match. Sampai Diskon Ikut Campur di Dalam Transaksi.

Reconciliation selalu match. Selama amount yang tersimpan di sistem sama persis dengan amount yang dikirim bank, tidak banyak yang perlu diperdebatkan. Satu transaksi. Satu angka. Satu sumber.

Lalu produk mulai berkembang. Ada diskon. Ada fee. Ada voucher. Ada komponen yang dibayar customer, komponen yang ditanggung platform, dan angka berbeda yang harus diterima merchant.

Reconciliation yang sebelumnya rapi berubah menjadi krisis setiap akhir bulan.

Bukan karena datanya salah. Datanya sudah tidak lengkap sejak pertama kali disimpan.

Satu angka cukup, sampai transaksi tidak lagi punya satu maknalink

Sejak awal, setiap transaksi kami simpan sebagai satu nilai: total_amount.

Untuk topup sederhana, keputusan itu masuk akal. Customer mengirim Rp100.000. Sistem menyimpan Rp100.000. Bank melaporkan Rp100.000. Tidak ada komponen lain yang perlu dijelaskan.

Masalahnya muncul ketika satu transaksi mulai mewakili lebih dari satu perpindahan nilai.

Misalnya, harga produk Rp100.000 dan customer membayar Rp90.000 setelah diskon Rp10.000. Menyimpan total_amount = Rp90.000 memberi tahu kita berapa yang dibayar customer.

Tapi angka itu tidak menjawab:

• siapa yang menanggung diskon Rp10.000,

• berapa yang tetap menjadi hak merchant,

• apakah ada fee yang dipotong sebelum settlement,

• dan komponen mana yang seharusnya muncul di partner statement.

Angka akhirnya benar. Konteks yang membentuk angka itu hilang.

Closing bulanan membongkar informasi yang hilanglink

Partner statement datang dengan breakdown per komponen. Base amount, discount, fee, dan settlement dicatat terpisah. Sistem kami hanya punya satu angka gabungan.

Ops akhirnya harus menghitung mundur. Mereka mengambil total_amount, mencari konfigurasi diskon yang berlaku saat transaksi terjadi, memeriksa fee provider, lalu mencoba merekonstruksi angka aslinya.

Kadang hasilnya cocok. Kadang tidak.

Ketika tidak cocok, kami tidak bisa langsung tahu penyebabnya. Bisa jadi rumus rekonstruksinya salah. Bisa jadi konfigurasi sudah berubah. Bisa jadi memang ada transaksi yang belum settle. Semua kemungkinan terlihat sama dari satu angka akhir.

Transaksi yang belum bisa dijelaskan mulai menumpuk. Selama hari biasa, tumpukan itu masih terlihat seperti pekerjaan operasional yang bisa ditunda. Begitu closing tiba, semuanya berubah menjadi krisis yang harus diselesaikan dalam beberapa hari.

Reconciliation tidak bisa mengembalikan data yang tidak pernah disimpanlink

Awalnya kami melihat ini sebagai masalah reconciliation. Mungkin query-nya kurang baik. Mungkin matching logic-nya perlu dibuat lebih pintar. Mungkin kami butuh tool yang bisa menangani lebih banyak exception.

Tapi reconciliation hanya bisa membandingkan data yang tersedia. Kalau komponen asli sudah hilang sebelum proses itu dimulai, tool reconciliation hanya punya dua pilihan: mengambil data dari sistem lain atau menebak.

Tidak ada algoritma yang bisa memastikan siapa yang menanggung diskon kalau keputusan itu tidak pernah dicatat bersama transaksinya.

Yang hilang bukan kemampuan untuk menjumlahkan. Yang hilang adalah provenance: dari mana setiap angka berasal, siapa yang menanggungnya, dan ke mana nilainya harus bergerak.

Keputusan sebenarnya ada di cara kita mencatat nilailink

Menyimpan satu angka gabungan memang lebih cepat untuk di-ship. Skemanya sederhana. Query produk mudah. Tim tidak perlu memikirkan entry, account, balancing, atau correction flow.

Untuk transaksi yang benar-benar hanya memiliki satu komponen, itu bisa menjadi keputusan yang tepat. Masalahnya adalah kami mempertahankan model yang sama setelah bentuk transaksinya berubah.

Diskon, fee, voucher, dan settlement diperlakukan sebagai detail kalkulasi. Padahal masing-masing sudah menjadi klaim nilai yang harus bisa dijelaskan secara independen.

Kami menghemat kompleksitas saat build, lalu memindahkan cost-nya ke finance dan ops setiap akhir bulan.

Yang menyelesaikannya adalah ledger, bukan reconciliation tool barulink

Di satu perusahaan, kami membangun ulang lapisan pencatatan transaksi sebagai ledger dengan prinsip double-entry bookkeeping. Setiap perpindahan nilai dicatat sebagai entry yang seimbang. Base amount, diskon, fee, voucher, dan settlement tidak lagi hilang di dalam satu hasil kalkulasi.

total_amount masih boleh ada untuk kebutuhan baca yang cepat. Tapi dia bukan lagi satu-satunya sumber kebenaran. Sumber kebenarannya adalah entry yang menjelaskan bagaimana angka akhir itu terbentuk.

Perubahan itu membuat pertanyaan yang sebelumnya sulit menjadi mekanis:

• Berapa yang dibayar customer?

• Siapa yang mendanai diskon?

• Berapa yang menjadi hak merchant?

• Fee mana yang dipotong provider?

• Entry mana yang belum punya pasangan di partner statement?

Kami tidak perlu membongkar angka akhir untuk menjawabnya. Komponennya memang sudah disimpan sejak awal.

Reconciliation yang sebelumnya menjadi krisis bulanan berubah menjadi rutinitas harian. Tumpukan transaksi menjelang closing hilang. Proses manual untuk menghitung ulang breakdown bisa dihapus. Ops hanya menangani exception yang benar-benar membutuhkan keputusan, bukan angka yang seharusnya sudah bisa dijelaskan oleh sistem.

Tapi tidak setiap transaksi membutuhkan ledgerlink

Ini batasan yang penting. Ledger bukan jawaban otomatis setiap kali ada payment. Membangunnya membawa cost sendiri: skema yang lebih ketat, idempotency, correction entry, balancing rule, dan disiplin operasional yang harus dijaga.

Kalau flow kamu benar-benar satu amount, satu pihak, dan satu settlement event, tabel transaksi sederhana mungkin sudah cukup.

Ledger mulai layak ketika satu transaksi harus menjelaskan beberapa komponen nilai, beberapa pihak, atau beberapa tahap settlement tanpa kehilangan sejarahnya.

Jadi pertanyaannya bukan “apakah payment system yang mature harus punya ledger?” Pertanyaannya:

Apakah kita masih bisa menjelaskan setiap rupiah tanpa merekonstruksi masa lalu?

Empat tes sebelum menyimpan semuanya sebagai satu angkalink

Sebelum transaksi multi-komponen disimpan hanya sebagai total_amount, saya ingin empat pertanyaan ini punya jawaban:

1. Breakdown: bisakah kita melihat kembali komponen asli tanpa menghitung mundur?

2. Allocation: bisakah kita menjelaskan siapa yang membayar dan menerima setiap komponen?

3. Correction: kalau ada kesalahan, bisakah kita memperbaikinya tanpa menghapus sejarah sebelumnya?

4. Reconciliation: bisakah partner statement dicocokkan secara deterministik tanpa asumsi dari konfigurasi hari ini?

Kalau jawabannya iya untuk semua, kamu mungkin belum membutuhkan ledger. Kalau jawabannya tidak, reconciliation bukan masalah pertama kamu. Pencatatan transaksinya yang belum cukup.

AI bisa membantu menebak. Tapi tebakan tetap bukan sumber kebenaranlink

AI bisa generate query reconciliation. Bisa mencari pola selisih. Bahkan bisa memperkirakan breakdown dari total_amount dan data historis lain.

Tapi AI tidak bisa mengembalikan provenance yang tidak pernah dicatat. Dia hanya bisa membuat tebakan terlihat lebih meyakinkan.

Ledger bukan soal membuat pembukuan terlihat lebih sophisticated. Ledger adalah keputusan bahwa setiap perpindahan nilai harus bisa dijelaskan tanpa menebak.

Kalau sistem kamu masih menyimpan transaksi multi-komponen sebagai satu angka, reconciliation mungkin terlihat baik-baik saja hari ini. Tapi closing berikutnya tidak akan bertanya seberapa cepat sistem itu dulu di-ship.

Finance hanya akan bertanya satu hal:

Angka ini sebenarnya datang dari mana?