Total penjualan yang tampil di dashboard GoFood, GrabFood, atau marketplace lain tidak selalu sama dengan dana yang masuk ke rekening restoran. Perbedaannya bisa berasal dari komisi, promo yang ditanggung merchant, refund, biaya platform, penyesuaian, atau jadwal pencairan yang berbeda dari tanggal pesanan.
Tujuan rekonsiliasi bukan memaksa semua angka terlihat sama, melainkan menjelaskan selisih dari setiap order sampai dana benar-benar diterima. Panduan ini membantu tim finance dan operasional memeriksa transaksi, menyusun lembar rekonsiliasi, serta menentukan kapan masalah perlu dieskalasi.
Bedakan Gross Order Value, Net Sales, dan Settlement
Gross order value (GOV) adalah nilai bruto pesanan dalam cakupan laporan yang sedang diperiksa, sebelum potongan dan biaya tertentu. Pastikan dahulu apakah laporan marketplace memasukkan order batal, pajak, atau ongkir ke dalam GOV; setiap platform dapat menggunakan definisi dan kolom berbeda.
Net sales adalah nilai penjualan setelah diskon yang ditanggung restoran, refund, dan pengurang penjualan relevan sesuai kebijakan pencatatan. Net sales tidak sama dengan kas masuk: komisi platform dan biaya layanan belum tentu mengurangi angka penjualan secara akuntansi, tetapi mengurangi dana yang dicairkan.
Settlement adalah jumlah bersih yang ditetapkan platform untuk dibayarkan kepada merchant setelah memperhitungkan komponen potongan, subsidi, pajak atau biaya yang relevan, dan adjustment. Bank receipt adalah uang yang benar-benar diterima di rekening. Satu settlement dapat berisi banyak order dan masuk ke bank pada tanggal berbeda.
Penting: gunakan definisi yang konsisten untuk satu periode dan hindari mengurangi diskon atau refund dua kali. Jika net sales sudah dikurangi keduanya, jangan menguranginya lagi ketika menyusun expected settlement.
Komponen yang Membuat Settlement Berbeda dari Penjualan
• Komisi marketplace: potongan berdasarkan perjanjian masing-masing platform dan merchant; tidak ada satu tarif yang berlaku universal.
• Promo dan subsidi: bedakan diskon yang ditanggung restoran dengan subsidi yang benar-benar dibayarkan platform; jangan menghitung subsidi dua kali jika sudah termasuk nilai order.
• Refund atau pembatalan: pengembalian penuh atau sebagian yang dapat muncul pada periode berbeda dari order awal.
• Adjustment: koreksi, kompensasi, penahanan, atau pelepasan dana dari settlement sebelumnya, dengan alasan yang harus dapat ditelusuri.
• Pajak dan fee: biaya administrasi, transaksi, dan perlakuan pajak sesuai rincian platform serta perjanjian merchant.
Periksa pihak penanggung setiap promo, tanggal refund, dan basis perhitungan setiap fee. Gunakan rincian resmi merchant; angka komisi atau biaya dalam simulasi berikut bukan benchmark industri.
Siapkan Empat Sumber Data untuk Dicocokkan
• Order report: order ID, outlet, channel, tanggal dan waktu, status, gross amount, diskon, refund, serta nominal yang menjadi hak merchant.
• Settlement report: settlement atau payout ID, kumpulan order terkait, komisi, biaya, subsidi, adjustment, jumlah payout, dan jadwal transfer.
• POS sales report: order ID marketplace yang ditautkan ke ID transaksi kasir, status cancel/refund, penjualan kanal, dan identitas outlet.
• Bank receipt: tanggal dana masuk, nominal, nomor referensi transfer, rekening penerima, serta nama pengirim.
Pastikan timezone, periode cut-off, mata uang, dan ID merchant/outlet sama. Order ID dipakai untuk menelusuri pesanan, sedangkan settlement ID atau payout batch lebih cocok untuk mencocokkan transfer bank karena banyak order bisa digabung dalam satu pencairan.
Baca juga: Order Management System (OMS): Pengertian, Cara Kerja, Manfaat, dan Tips Mengelolanya untuk Bisnis
Workflow Rekonsiliasi: Order → Marketplace → Settlement → Bank
1. Samakan cakupan dan cocokkan order dengan POS
Tentukan outlet, platform, periode order, dan periode settlement. Ekspor order report serta POS sales, lalu cocokkan order ID satu per satu. Tandai transaksi hilang, duplikat, dibatalkan, atau belum tersinkronisasi.
2. Periksa hak merchant dan komponen potongan
Untuk setiap order yang memenuhi syarat pembayaran, periksa harga awal, diskon merchant, refund, subsidi platform yang dibayar ke merchant, komisi, fee, pajak, dan adjustment. Cocokkan dengan dokumen transaksi atau kontrak yang berlaku.
3. Hitung expected settlement per payout batch
Kelompokkan order berdasarkan settlement ID. Hitung expected settlement dari basis nilai yang konsisten: nilai hak merchant dikurangi potongan settlement, lalu ditambah subsidi atau adjustment yang memang terutang. Hindari mencampur order yang belum masuk jadwal payout dengan order yang sudah jatuh tempo.
4. Bandingkan expected settlement dengan laporan platform
Hitung variance platform = expected settlement − actual settlement yang tercantum pada laporan marketplace. Selisih di tahap ini perlu ditelusuri pada level komisi, promo, refund, biaya, atau adjustment.
5. Cocokkan settlement yang jatuh tempo dengan penerimaan bank
Cocokkan settlement ID, rekening tujuan, referensi transfer, nominal, dan tanggal bank. Hitung variance bank = settlement yang sudah jatuh tempo untuk dibayar − penerimaan bank yang berhasil dipasangkan. Pencairan yang belum jatuh tempo diberi status pending, bukan langsung dicatat sebagai kehilangan dana.
6. Dokumentasikan hasil dan tindak lanjut
Tandai matched, pending, discrepancy, atau escalated. Simpan bukti laporan, mutasi, PIC pemeriksaan, tanggal investigasi, serta penyebab selisih. Jangan mengubah data penjualan hanya agar total akhir terlihat sama.
Simulasi: Penjualan Rp10 Juta, Dana Diterima Lebih Kecil
Simulasi berikut mengasumsikan Rp10.000.000 sebagai nilai order selesai pada periode yang sama. Subsidi platform Rp300.000 dibayarkan terpisah kepada merchant dan belum termasuk angka gross maupun net sales; tidak ada pajak atau adjustment tambahan di luar daftar ini.
| Komponen | Nominal |
| Gross order value (order selesai) | Rp10.000.000 |
| Diskon ditanggung restoran | −Rp500.000 |
| Refund ditanggung restoran | −Rp200.000 |
| Net sales (ilustrasi) | Rp9.300.000 |
| Komisi marketplace | −Rp1.000.000 |
| Fee layanan merchant | −Rp50.000 |
| Subsidi platform dibayarkan terpisah | +Rp300.000 |
| Expected settlement | Rp8.550.000 |
Perhitungan: Rp10.000.000 − Rp500.000 − Rp200.000 − Rp1.000.000 − Rp50.000 + Rp300.000 = Rp8.550.000. Semua nominal hanya simulasi, bukan tarif GoFood, GrabFood, atau standar industri.
Jika settlement report menunjukkan Rp8.550.000, variance platform = Rp0. Jika rekening baru menerima Rp8.300.000, terdapat selisih penerimaan bank Rp250.000. Periksa apakah Rp250.000 masih dalam payout berikutnya, ditahan, atau salah referensi sebelum mengategorikannya sebagai discrepancy.
Tangani Settlement yang Masuk pada Tanggal Berbeda
Misalnya, pesanan dibuat pada 30 Oktober, masuk settlement batch 1 November, lalu dana diterima bank pada 2 November. Jika laporan penjualan Oktober langsung dibandingkan dengan mutasi bank Oktober, hasilnya pasti tampak tidak cocok meskipun tidak ada dana hilang.
• Order date: tanggal terjadinya transaksi untuk pelaporan penjualan.
• Settlement or payout date: tanggal platform menetapkan atau menjadwalkan pembayaran.
• Bank receipt date: tanggal transfer benar-benar tercatat di rekening.
Buat daftar outstanding settlement per payout ID beserta expected transfer date dan statusnya. Transaksi yang belum sampai tanggal pencairan bukan variance final. Pada tutup buku, tim akuntansi perlu menilai piutang atau akun penampung sesuai kebijakan pencatatan yang berlaku.
Telusuri Missing Order, Cancelled Order, dan Refund
• Missing order: muncul di marketplace tetapi tidak ada pada POS, atau sebaliknya. Cek pemetaan order ID, integrasi, jam transaksi, serta status sinkronisasi.
• Cancelled order: pastikan order yang batal tidak tetap dihitung sebagai penjualan final; periksa apakah ada biaya pembatalan yang justru tetap ditagih.
• Refund order: cocokkan nominal, pihak penanggung, ID order asli, tanggal refund, dan settlement mana yang memuat pengurangannya.
• Duplicate order: satu order ID tercatat lebih dari sekali di POS atau di file konsolidasi sehingga gross sales tampak lebih besar.
Gunakan log perubahan status, bukti komplain, dan referensi refund. Pemisahan berdasarkan order ID lebih efektif daripada hanya mencari perbedaan total rupiah di akhir bulan.
Buat Reconciliation Sheet: Expected vs Actual vs Variance
Lembar rekonsiliasi sebaiknya bisa melacak selisih pada dua lapisan: perhitungan marketplace dan pencairan bank. Berikut kolom minimum yang dapat digunakan dalam spreadsheet.
| Field | Fungsi / pengisian |
| Merchant / outlet / channel | Memisahkan rekening dan cabang |
| Order ID dan status | Menelusuri transaksi asli dan pembatalan |
| Order date | Periode penjualan |
| Settlement / payout ID | Penghubung ke transfer marketplace |
| Settlement period / due date | Menentukan apakah pembayaran sudah jatuh tempo |
| Gross order value / net sales | Dasar nilai pesanan dan hak merchant |
| Merchant discount / refund | Pengurang yang telah dihitung satu kali |
| Commission / fee / tax | Rincian biaya platform yang relevan |
| Subsidy / adjustment | Penambah atau koreksi yang didukung bukti |
| Expected settlement | Hasil kalkulasi merchant |
| Reported settlement | Jumlah payout pada laporan platform |
| Variance platform | Expected − reported settlement |
| Bank receipt / date / reference | Nominal dan bukti dana masuk |
| Variance bank | Reported settlement due − bank receipt matched |
| Status / PIC / evidence | Matched, pending, discrepancy, escalated serta tindak lanjut |
Contoh kontrol: variance platform = Rp0 berarti perhitungan merchant dan laporan marketplace cocok. Namun, status bank baru matched jika dana yang sudah jatuh tempo benar-benar diterima. Satu transfer dapat menutup beberapa payout, sehingga pencocokan harus mengikuti referensi dan rincian batch.
Kapan Variance Perlu Dieskalasi?
Tidak semua angka berbeda memerlukan komplain langsung. Bedakan kasus yang masih dalam jadwal pencairan dari kesalahan yang sudah didukung bukti. Gunakan ambang nilai dan SLA internal restoran untuk menentukan prioritas.
• Pending wajar: tanggal payout belum jatuh tempo, bukti bank belum tersedia, atau transfer masih dalam proses sesuai jadwal.
• Butuh pemeriksaan internal: order tidak muncul di POS, ID ganda, promo salah dipetakan, atau refund belum ditautkan ke transaksi awal.
• Perlu eskalasi ke marketplace atau bank: dana melewati jadwal payout, potongan tak sesuai dokumen, atau reported settlement berbeda dengan bank receipt tanpa penjelasan.
• Prioritas tinggi: variance material, berulang, memengaruhi banyak outlet, atau menunjukkan indikasi double refund atau potongan duplikat.
Lampirkan order ID, settlement ID, tanggal, nominal, rincian fee, referensi transfer, dan hasil investigasi internal. Tetapkan PIC serta tenggat tindak lanjut dan periksa kembali statusnya pada siklus rekonsiliasi berikutnya.
Baca juga: Cara Baca Laporan Keuangan untuk Pebisnis Kuliner
FAQ Seputar Rekonsiliasi Settlement Marketplace
1. Mengapa omzet marketplace berbeda dari dana di rekening?
Karena nilai penjualan dan dana payout memiliki fungsi berbeda. Komisi, promo merchant, refund, fee, adjustment, serta tanggal pencairan dapat membuat jumlahnya tidak sama.
2. Apakah settlement boleh langsung dicatat sebagai omzet?
Tidak otomatis. Settlement adalah arus kas atau pembayaran bersih. Pendapatan, biaya marketplace, refund, dan pajak dicatat sesuai kebijakan akuntansi yang digunakan restoran.
3. Haruskah rekonsiliasi dilakukan setiap hari?
Pemeriksaan rutin harian cocok untuk volume tinggi; minimal lakukan setiap payout diterbitkan. Tetapkan review outstanding dan eskalasi menurut siklus marketplace.
4. Bagaimana jika settlement report sesuai tetapi uang belum masuk?
Cek tanggal jatuh tempo, referensi transfer, rekening tujuan, dan status bank. Jika melewati jadwal, eskalasi dengan settlement ID dan bukti terkait.
5. Apakah proses ini bisa diotomatisasi?
Sebagian pencocokan dapat dibantu sistem jika tersedia akses ke order, settlement, POS, dan data bank. Exception seperti refund atau adjustment tetap perlu aturan validasi dan review finance.
Kesimpulan
Rekonsiliasi marketplace yang benar menghubungkan order ID, hak penjualan merchant, biaya dan penyesuaian settlement, hingga dana yang diterima bank. Fokusnya bukan menyamakan angka bruto dengan saldo rekening, tetapi menyediakan jejak transaksi untuk menjelaskan setiap variance tanpa kehilangan riwayat koreksi.
Ketika volume pesanan dan jumlah outlet bertambah, spreadsheet terpisah semakin sulit dipelihara. Restoran membutuhkan data transaksi serta pencatatan keuangan yang terhubung, termasuk identitas payout, status outstanding, dan kontrol atas refund serta adjustment.
Untuk mendukung proses tersebut, ESB Core memiliki kapabilitas pelaporan keuangan, auto journal, dan financial/bank reconciliation. Hubungi tim ESB mengenai cakupan integrasi data marketplace serta alur pencocokan settlement yang sesuai dengan konfigurasi restoran, agar keputusan keuangan tidak hanya bergantung pada pemeriksaan manual.
