Rekonsiliasi harian toko online: menutup buku tanpa membuka mutasi bank

Rekonsiliasi harian sebuah toko yang menerima pembayaran otomatis dimulai dari menerima satu kenyataan: ada tiga angka, dan ketiganya tidak akan pernah sama. Yang dibayar pembeli, yang tercatat sebagai pendapatan bersih, dan yang benar-benar masuk ke rekening bank adalah tiga besaran berbeda pada tiga waktu berbeda. Pembukuan yang mengejar ketiganya menjadi satu angka akan selalu gagal.

Yang dikerjakan setiap hari karena itu bukan mencocokkan satu total dengan satu total, melainkan memastikan dua hal: setiap pesanan yang tercatat lunas punya pembayaran yang benar-benar berstatus succeeded, dan setiap selisih yang tersisa punya nama. Prosesnya sepuluh menit, dan tidak melibatkan mutasi rekening sama sekali.

Tiga angka, dan hubungannya

Setiap pembayaran membawa tiga nilai dalam rupiah utuh, tanpa pecahan: amount_gross, amount_fee, dan amount_net. Ketiganya terikat satu persamaan yang selalu berlaku:

amount_gross = amount_fee + amount_net

Besaran amount_fee mengikuti metode pembayarannya, dan bentuk tarifnya berbeda per metode. QRIS ditagih 0,7 persen ditambah Rp 250. Setiap Virtual Account ditagih Rp 5.000 tetap tanpa komponen persen. Kartu ditagih 2,8 persen ditambah Rp 2.500. Konsekuensinya untuk pembukuan: rasio biaya terhadap penjualan tidak stabil dari hari ke hari, dan itu normal. Hari yang penuh pesanan kecil lewat QRIS punya rasio biaya yang sama sekali berbeda dari hari yang berisi lima pesanan besar lewat Virtual Account. Bentuk kedua tarif itu dan titik potongnya dibahas pada panduan memilih QRIS atau Virtual Account.

Angka ketiga, yaitu yang masuk ke rekening, tidak muncul pada pembayaran sama sekali. Itu milik pencairan, dan dibahas di bawah.

Dua sumbu status, bukan satu

Halaman Transaksi punya dua kolom yang sering dikira satu. Kolom Status menjawab apakah pembayar sudah membayar, dengan nilai pending, succeeded, expired, canceled, dan failed. Kolom Dana cair menjawab pertanyaan yang berbeda, yaitu apakah banknya sudah menyerahkan uangnya, dengan dua nilai: Diproses dan Cair.

Kedua sumbu itu boleh berbeda, dan perbedaannya bukan kesalahan. Pembayaran lunas selesai diproses bank pada hari kerja berikutnya, sehingga sebuah baris bisa berstatus succeeded sekaligus Diproses selama beberapa hari, dan akhir pekan panjang memperlebarnya. Sumbu pencairan juga hanya berlaku pada baris yang sudah lunas: pembayaran yang kedaluwarsa tidak punya fakta pencairan sama sekali.

Aturan praktisnya: rekap penjualan dibaca dari sumbu status, rekap kas dibaca dari sumbu pencairan. Mencampur keduanya dalam satu tabel adalah cara paling cepat menghasilkan selisih yang tidak bisa dijelaskan.

Urutan lima langkah

1. Tetapkan rentangnya. Hari dihitung dalam zona waktu Asia/Jakarta, bukan UTC, jadi batas harinya jelas. Saring tanggal pada halaman Transaksi.
2. Saring modenya lebih dulu. Sebelum apa pun diunduh, pastikan yang tampil hanya transaksi uang sungguhan. Berkas ekspor memuat baris yang sama dengan yang sedang tampil di layar, jadi penyaring yang benar di layar adalah berkas yang benar.
3. Buka semua status. Tampilan bawaan hanya menampilkan pembayaran yang dibayar dan yang menunggu. Rekonsiliasi butuh yang kedaluwarsa juga, karena pesanan yang dikira lunas hampir selalu berhenti di sana. Tombol Tampilkan semua status yang membukanya.
4. Unduh ekspor CSV. Berkasnya membawa seluruh himpunan yang tersaring, bukan hanya halaman yang terlihat.
5. Cocokkan ke daftar pesanan sendiri, bukan sebaliknya. Yang ditelusuri adalah pesanan yang menurut catatan toko sudah lunas tetapi tidak punya baris succeeded. Arah ini penting: pembayaran tanpa pesanan hampir selalu tidak berbahaya, sedangkan pesanan tanpa pembayaran adalah barang yang dikirim gratis.

Arti tiap kolom ekspor

Berkasnya berisi sepuluh kolom, dengan urutan tetap: date, reference, merchant_ref, description, status, amount_gross, amount_fee, amount_net, source, dan is_test. Empat di antaranya punya perilaku yang perlu diketahui sebelum angkanya dipercaya.

• status adalah status efektif, bukan yang tersimpan. Baris yang masih tercatat pending tetapi masa berlakunya sudah lewat terekspor sebagai expired. Ini yang diinginkan: rekap tidak boleh menghitung tagihan mati sebagai pembayaran yang masih ditunggu.
• description berisi teks yang diketik pembayar. Sel yang diawali =, +, -, atau @ diberi tanda kutip tunggal di depannya supaya aplikasi lembar kerja memperlakukannya sebagai teks dan bukan sebagai rumus. Tanda kutip itu memang ada di berkas, dan bukan kerusakan data.
• source menyebut asal pembuatan permintaannya, yaitu dashboard, API, atau halaman pembayaran. Kolom ini yang menjawab pertanyaan seperti berapa banyak penjualan yang masih dibuat manual.
• is_test adalah kolom paling penting yang paling sering diabaikan. Nominal simulasi tidak bisa dibedakan dari uang sungguhan hanya dengan melihat angkanya, dan kolom inilah satu-satunya yang membedakannya setelah berkas keluar dari dashboard.

Sama pentingnya adalah yang tidak ada di berkas itu: tidak ada kolom pencairan, tidak ada tanggal dana cair, dan tidak ada metode pembayaran. Berkas ekspor menjawab pertanyaan penjualan, bukan pertanyaan kas. Pertanyaan kas dijawab oleh kolom Dana cair di layar dan oleh halaman Pencairan.

Dua batas teknis yang ada baiknya diketahui sebelum bertemu: satu ekspor membawa paling banyak 50.000 baris, dan permintaan di atas itu ditolak dengan pesan yang meminta rentang tanggalnya dipersempit. Ekspor juga dibatasi sepuluh kali per menit, karena satu ekspor sama beratnya dengan ribuan halaman daftar.

Mencocokkan ke satu baris mutasi bank

Rekening bank tidak akan pernah menampilkan pembayaran satu per satu, dan memang tidak seharusnya. Satu baris masuk di rekening berasal dari satu pencairan yang menyapu sejumlah pembayaran yang sudah cair sekaligus. Hubungannya:

jumlah yang ditransfer = total pembayaran yang disapu - Rp 3.000

Biaya Rp 3.000 itu dipotong sekali per pencairan, bukan per pembayaran, sehingga frekuensi pencairan yang dipilih ikut menentukan ongkosnya. Halaman Pencairan menyebutkan berapa pembayaran yang ikut dalam satu pencairan, dan angka itulah jembatan antara rekap penjualan dan baris mutasi. Aturan kelayakan, jadwal, dan arti tiap status pencairan dibahas pada panduan pencairan dana.

Karena itu urutan pencocokan ke bank adalah dua langkah, bukan satu: nominal pencairan dicocokkan dengan baris mutasi, lalu isi pencairan dicocokkan dengan rekap penjualan pada rentang tanggal yang disapunya. Mencoba mencocokkan penjualan harian langsung ke mutasi harian tidak akan pernah cocok, karena keduanya memang tidak berpasangan satu lawan satu.

Selisih yang wajar, dan yang harus dikejar

Dua baris terakhir dari daftar itu adalah satu-satunya yang benar-benar mendesak. Yang pertama menghabiskan barang, yang kedua menahan pesanan yang sebenarnya sudah dibayar. Kedua arah kesalahan itu, beserta cara memisahkannya dalam satu menit, dibahas pada artikel tentang pembayaran yang menurut pembeli sudah dilakukan.

Kenapa harian, bukan bulanan

Perbedaannya bukan soal kerajinan, melainkan soal apakah selisihnya masih bisa ditelusuri. Selisih yang ditemukan hari ini masih menempel pada satu pesanan yang namanya diingat, satu percakapan yang masih terbuka, dan satu pengiriman yang mungkin belum berangkat. Selisih yang sama ditemukan tiga puluh hari kemudian hanya berupa angka, dan hampir selalu diselesaikan dengan menuliskannya sebagai kerugian. Sepuluh menit sehari jauh lebih murah daripada satu hari penuh di akhir bulan yang hasilnya tetap tidak menjelaskan apa pun.

Untuk penerimaan yang bentuknya iuran berulang alih-alih penjualan, urutan penutupan bulanannya sedikit berbeda dan dibahas pada panduan iuran komunitas. Penutupan harian juga bukan tempat menilai penjualan sebulan penuh: angka bulanan punya jebakan bacanya sendiri, dan keempatnya diuraikan di cara membaca angka penjualan bulanan.

Pertanyaan yang sering muncul