Terakhir diperbarui: 12 November 2026
Rekonsiliasi payment gateway adalah proses mencocokkan tiga sumber data: pesanan yang berstatus lunas di sistem penjualan, laporan settlement dari penyedia payment gateway, dan dana yang benar-benar masuk ke rekening bank. Kuncinya: catat penjualan secara bruto, catat biaya layanan payment gateway sebagai beban, dan tampung selisih waktu pencairan di akun perantara “Piutang Payment Gateway” sampai dana diterima.
Masalahnya, mutasi bank hanya menampilkan satu angka bersih per batch pencairan, sementara di baliknya ada ratusan transaksi, potongan biaya, refund, sampai sengketa kartu (chargeback). Tanpa prosedur yang rapi, tim finance biasanya mencatat penjualan sebesar dana bersih yang masuk ke bank — omzet jadi terlalu kecil, biaya tersembunyi, dan selisih menumpuk di akhir bulan. Artikel ini memberi Anda alur rekonsiliasi tiga arah, contoh jurnal lengkap, matriks penyebab selisih, dan cara mengotomatiskannya.
Ringkasan Cepat
- Akui penjualan sebesar nilai yang dibayar pelanggan (bruto), bukan sebesar dana bersih yang cair ke bank.
- Gunakan akun perantara Piutang Payment Gateway (dana dalam penyelesaian) untuk menampung dana yang belum dicairkan.
- Biaya layanan (MDR/fee per transaksi), refund, chargeback, dan dana yang ditahan dipisahkan ke akun masing-masing.
- Rekonsiliasi dilakukan tiga arah: sistem order ↔ laporan settlement ↔ mutasi bank, idealnya harian.
- Saldo Piutang Payment Gateway di akhir bulan harus sama dengan saldo “belum dicairkan” di dashboard payment gateway.
Apa Itu Rekonsiliasi Payment Gateway?
Daftar Isi
- 1 Apa Itu Rekonsiliasi Payment Gateway?
- 2 Mengapa Dana yang Masuk ke Bank Tidak Sama dengan Penjualan?
- 3 Akun Apa Saja yang Perlu Disiapkan?
- 4 Bagaimana Contoh Jurnal Rekonsiliasi Payment Gateway?
- 5 Bagaimana Langkah Rekonsiliasi Tiga Arah Setiap Hari?
- 6 Bagaimana Contoh Kasus Selisih yang Sering Ditemukan?
- 7 Kesalahan yang Sering Terjadi
- 8 Pertanyaan yang Sering Diajukan (FAQ)
- 8.1 Apakah penjualan lewat payment gateway dicatat bruto atau neto?
- 8.2 Akun apa yang dipakai untuk dana payment gateway yang belum cair?
- 8.3 Seberapa sering rekonsiliasi payment gateway sebaiknya dilakukan?
- 8.4 Bagaimana mencatat chargeback yang masih dalam proses sengketa?
- 8.5 Apakah biaya layanan dikembalikan jika ada refund?
- 9 Kesimpulan
Definisi singkat: Rekonsiliasi payment gateway (payment gateway reconciliation) adalah pencocokan transaksi pembayaran online antara catatan penjualan perusahaan, laporan settlement penyedia payment gateway, dan mutasi rekening bank, untuk memastikan setiap pembayaran pelanggan tercatat, setiap potongan biaya dapat dijelaskan, dan setiap dana yang dijanjikan benar-benar diterima perusahaan.
Payment gateway (gerbang pembayaran) menerima pembayaran dari berbagai metode — virtual account, dompet digital (e-wallet), kartu kredit/debit — lalu mencairkannya ke rekening Anda secara berkala, umumnya beberapa hari kerja setelah transaksi (sering ditulis T+1, T+2, dan seterusnya, tergantung metode dan kontrak). Jeda inilah yang membuat saldo bank hampir tidak pernah sama dengan omzet harian.
Prosesnya mirip dengan rekonsiliasi QRIS & EDC di toko fisik, tetapi volumenya biasanya lebih besar dan jenis penyesuaiannya lebih beragam karena ada refund parsial, chargeback, dan dana cadangan (reserve).
Mengapa Dana yang Masuk ke Bank Tidak Sama dengan Penjualan?
Sebelum membuat jurnal, pahami dulu penyebab selisihnya. Hampir semua selisih payment gateway jatuh ke salah satu kategori di bawah ini. Matriks ini bisa langsung Anda pakai sebagai daftar periksa saat rekonsiliasi.
| Penyebab selisih | Tanda di data | Perlakuan akuntansi | Perlu tindak lanjut? |
|---|---|---|---|
| Jeda pencairan (timing) | Ada di laporan settlement, belum ada di mutasi bank | Tetap di Piutang Payment Gateway | Tidak, cukup dipantau umurnya |
| Biaya layanan (MDR/fee transaksi) | Selisih bruto vs neto per transaksi | Beban Layanan Payment Gateway | Cocokkan tarif dengan kontrak |
| Refund ke pelanggan | Baris negatif di laporan settlement | Retur/pengurang penjualan atau pelunasan utang refund | Pastikan ada persetujuan refund |
| Chargeback (sengketa kartu) | Dana ditarik kembali oleh penerbit kartu | Piutang Sengketa Chargeback, lalu beban jika kalah | Ya, siapkan bukti pengiriman |
| Dana ditahan (rolling reserve) | Persentase settlement tidak dicairkan | Dana Ditahan Payment Gateway (aset) | Catat jadwal pelepasan |
| Status order salah | Order “lunas” di sistem, tidak ada di laporan settlement | Batalkan penjualan atau tagih ulang | Ya, cek integrasi sistem |
| Transaksi tidak terhubung ke order | Ada di settlement, tidak ada order-nya | Akun penampung sementara, lalu dialokasikan | Ya, telusuri ID transaksi |
Akun Apa Saja yang Perlu Disiapkan?
Sebelum memasang prosedur, tambahkan akun-akun berikut ke bagan akun (chart of accounts). Penamaan bisa disesuaikan, yang penting fungsinya terpisah:
- Piutang Payment Gateway (aset lancar) — dana dari pelanggan yang sudah dibayar tetapi belum dicairkan. Buat satu akun per penyedia jika Anda memakai lebih dari satu payment gateway.
- Dana Ditahan Payment Gateway (aset lancar) — jika kontrak mengatur rolling reserve.
- Piutang Sengketa Chargeback (aset lancar) — dana yang ditarik selama sengketa berlangsung.
- Beban Layanan Payment Gateway (beban penjualan/operasional) — MDR, fee per transaksi, fee refund, fee chargeback.
- Retur dan Pengurang Penjualan — untuk refund atas penjualan yang sudah diakui.
- Penampung Transaksi Belum Teridentifikasi — saldo akun ini harus nol di setiap tutup buku.
Bagaimana Contoh Jurnal Rekonsiliasi Payment Gateway?
Contoh (angka fiktif): PT Sinar Rumah Tangga menjual peralatan dapur lewat toko online sendiri. Pada 30 Oktober, pesanan yang berstatus lunas berjumlah Rp100.000.000, terdiri atas tiga metode bayar. Tarif di bawah ini hanyalah contoh; tarif sebenarnya mengikuti kontrak Anda dengan penyedia payment gateway.
| Metode bayar (contoh) | Jumlah transaksi | Nilai bruto (Rp) | Tarif contoh | Biaya layanan (Rp) | Jadwal cair |
|---|---|---|---|---|---|
| Virtual account | 120 | 48.000.000 | Rp4.000/transaksi | 480.000 | T+1 |
| E-wallet | 200 | 30.000.000 | 1,5% | 450.000 | T+1 |
| Kartu kredit/debit | 40 | 22.000.000 | 2,9% | 638.000 | T+3 |
| Total | 360 | 100.000.000 | 1.568.000 |
Pada batch pencairan 31 Oktober, laporan settlement juga memuat refund Rp1.500.000 atas pesanan minggu sebelumnya dan satu chargeback kartu Rp800.000.
1. Saat pesanan berstatus lunas (30 Oktober)
| Akun | Debit (Rp) | Kredit (Rp) |
|---|---|---|
| Piutang Payment Gateway | 100.000.000 | |
| Penjualan | 100.000.000 |
Penjualan diakui bruto sebesar yang dibayar pelanggan. Pencatatan HPP dan persediaan berjalan terpisah sesuai metode persediaan Anda.
2. Saat laporan transaksi harian menampilkan biaya layanan
| Akun | Debit (Rp) | Kredit (Rp) |
|---|---|---|
| Beban Layanan Payment Gateway | 1.568.000 | |
| Piutang Payment Gateway | 1.568.000 |
3. Refund dan chargeback yang dipotong dari settlement (31 Oktober)
| Akun | Debit (Rp) | Kredit (Rp) |
|---|---|---|
| Retur dan Pengurang Penjualan | 1.500.000 | |
| Piutang Sengketa Chargeback | 800.000 | |
| Piutang Payment Gateway | 2.300.000 |
Jika refund sudah dicatat sebelumnya sebagai utang refund kepada pelanggan, debitnya adalah akun Utang Refund, bukan Retur. Panduan lengkap skenario refund ada di artikel jurnal refund pelanggan.
4. Dana masuk ke rekening bank (31 Oktober)
Batch virtual account dan e-wallet cair: Rp78.000.000 − Rp930.000 (biaya layanan) − Rp1.500.000 (refund) − Rp800.000 (chargeback) = Rp74.770.000.
| Akun | Debit (Rp) | Kredit (Rp) |
|---|---|---|
| Bank | 74.770.000 | |
| Piutang Payment Gateway | 74.770.000 |
5. Posisi saat tutup buku 31 Oktober
Transaksi kartu (T+3) belum cair. Saldo Piutang Payment Gateway: Rp100.000.000 − Rp1.568.000 − Rp2.300.000 − Rp74.770.000 = Rp21.362.000, yaitu tepat nilai neto transaksi kartu (Rp22.000.000 − Rp638.000). Angka ini harus sama dengan saldo “menunggu pencairan” di dashboard payment gateway per 31 Oktober. Jika sama, rekonsiliasi selesai; jika tidak, telusuri dengan matriks penyebab selisih di atas.
6. Penyelesaian chargeback
Jika sengketa dimenangkan dan dana dikembalikan: debit Piutang Payment Gateway, kredit Piutang Sengketa Chargeback Rp800.000. Jika kalah: debit Retur dan Pengurang Penjualan (atau Beban Kerugian Chargeback, sesuai kebijakan akuntansi Anda), kredit Piutang Sengketa Chargeback Rp800.000. Biaya penanganan chargeback, bila ada, masuk ke Beban Layanan Payment Gateway.
Bagaimana Langkah Rekonsiliasi Tiga Arah Setiap Hari?
- Tarik tiga laporan pada periode yang sama: daftar pesanan lunas dari sistem penjualan, laporan transaksi dan settlement dari dashboard payment gateway (format CSV/Excel), serta mutasi rekening bank.
- Cocokkan sistem order dengan laporan transaksi payment gateway memakai kunci unik: nomor order atau ID transaksi (reference ID). Tandai order lunas yang tidak ada di laporan payment gateway, dan sebaliknya.
- Hitung ulang biaya layanan per metode bayar berdasarkan tarif kontrak. Selisih kecil karena pembulatan wajar; selisih sistematis berarti tarif berubah atau ada fee tambahan yang perlu dikonfirmasi.
- Cocokkan laporan settlement dengan mutasi bank per batch pencairan (bukan per transaksi). Nilai neto setiap batch harus sama persis dengan satu baris dana masuk di bank.
- Posting jurnal penyesuaian untuk refund, chargeback, dan dana ditahan dari laporan settlement.
- Bandingkan saldo Piutang Payment Gateway dengan saldo belum dicairkan di dashboard. Buat daftar umur (aging) untuk dana yang belum cair lebih dari jadwal kontrak.
- Dokumentasikan dan setujui: simpan kertas kerja rekonsiliasi, siapa yang menyusun, siapa yang memeriksa. Ini akan sangat membantu saat tutup buku bulanan dan audit.
Rekonsiliasi harian terasa berat bila dikerjakan di Excel, tetapi justru membuat tutup buku bulanan jauh lebih cepat: selisih ditemukan saat masih segar dan mudah ditelusuri, bukan tiga minggu kemudian.
Bagaimana Contoh Kasus Selisih yang Sering Ditemukan?
Contoh: Saat rekonsiliasi, tim finance PT Sinar Rumah Tangga menemukan 6 order senilai Rp2.150.000 berstatus lunas di toko online tetapi tidak ada di laporan payment gateway. Setelah ditelusuri, pelanggan membuat nomor virtual account lalu tidak membayar sampai kedaluwarsa, tetapi plugin toko online keliru mengubah status menjadi lunas. Tanpa rekonsiliasi, barang sudah dikirim dan piutang Rp2.150.000 tidak akan pernah cair. Perbaikannya ada dua: koreksi status dan jurnal penjualan, serta perbaiki pengaturan notifikasi (callback) agar status lunas hanya berubah setelah konfirmasi pembayaran dari payment gateway.
Kasus kedua yang umum: satu batch pencairan dari payment gateway masuk ke bank tanpa keterangan jelas, lalu dicatat sebagai “pendapatan lain-lain”. Akibatnya penjualan tercatat ganda. Prinsipnya sama seperti pada rekonsiliasi bank: setiap dana masuk harus dicocokkan ke sumbernya sebelum diposting.
Kesalahan yang Sering Terjadi
- Mencatat penjualan sebesar dana bersih. Omzet tampak lebih kecil dan biaya payment gateway tidak pernah terlihat, sehingga keputusan harga dan pilihan metode bayar tidak berbasis data.
- Langsung mendebit Bank saat order lunas. Saldo bank di sistem akuntansi jadi lebih besar dari rekening sebenarnya selama masa jeda pencairan.
- Menggabungkan beberapa payment gateway dalam satu akun perantara. Selisih sulit ditelusuri karena jadwal cair dan struktur biaya berbeda.
- Mengabaikan chargeback sampai akhir bulan. Batas waktu pengajuan bukti sengketa bisa terlewat dan dana hilang permanen.
- Membiarkan saldo akun penampung menumpuk. Akun penampung yang tidak nol saat tutup buku adalah tanda ada transaksi yang belum dijelaskan.
- Tidak mengecek perubahan tarif. Tarif dapat berubah sesuai kontrak; tanpa hitung ulang, kenaikan biaya baru ketahuan berbulan-bulan kemudian.
Pertanyaan yang Sering Diajukan (FAQ)
Apakah penjualan lewat payment gateway dicatat bruto atau neto?
Penjualan dicatat bruto, yaitu sebesar nilai yang dibayar pelanggan. Biaya layanan payment gateway adalah biaya yang Anda bayar kepada pihak ketiga, sehingga dicatat terpisah sebagai beban. Dengan begitu omzet dan biaya transaksi sama-sama terlihat di laporan laba rugi.
Akun apa yang dipakai untuk dana payment gateway yang belum cair?
Gunakan akun aset lancar seperti “Piutang Payment Gateway” atau “Dana dalam Penyelesaian”. Akun ini didebit saat pesanan lunas dan dikredit saat dana masuk ke bank serta saat ada potongan biaya, refund, atau chargeback. Saldonya harus sama dengan saldo belum dicairkan di dashboard penyedia.
Seberapa sering rekonsiliasi payment gateway sebaiknya dilakukan?
Untuk toko online dengan transaksi harian, rekonsiliasi sebaiknya dilakukan setiap hari kerja per batch pencairan. Bisnis dengan volume kecil bisa mingguan, tetapi tetap ditutup penuh setiap akhir bulan sebelum laporan keuangan diterbitkan.
Bagaimana mencatat chargeback yang masih dalam proses sengketa?
Pindahkan dana yang ditarik ke akun “Piutang Sengketa Chargeback” sambil menunggu hasil. Jika dimenangkan, dana kembali ke Piutang Payment Gateway; jika kalah, nilainya dibebankan sebagai pengurang penjualan atau kerugian sesuai kebijakan akuntansi perusahaan.
Apakah biaya layanan dikembalikan jika ada refund?
Tergantung kontrak dengan penyedia payment gateway. Sebagian penyedia tidak mengembalikan biaya layanan transaksi awal saat refund, bahkan ada yang mengenakan biaya refund. Cek kontrak Anda dan pastikan perlakuan ini tercermin di jurnal.
Kesimpulan
Rekonsiliasi payment gateway yang rapi bertumpu pada tiga hal: penjualan diakui bruto, semua potongan dipisahkan ke akun yang tepat, dan saldo Piutang Payment Gateway dicocokkan dengan dashboard penyedia serta mutasi bank secara rutin. Dengan pola ini, tim finance tahu persis berapa biaya pembayaran online yang sebenarnya, selisih tertangkap lebih cepat, dan tutup buku tidak lagi tertunda karena “uang yang tidak jelas asalnya”.
Jika rekonsiliasi Anda masih dikerjakan manual di Excel, fitur Kas & Bank Zahir Online membantu mencatat penerimaan, memisahkan biaya, dan mencocokkan mutasi bank dalam satu sistem, sehingga tim Anda bisa fokus menelusuri selisih, bukan menyalin data.
