Cash Application: Alokasi Pembayaran Piutang & Jurnalnya

Terakhir diperbarui: 11 November 2026

Cash application adalah proses mencocokkan setiap uang yang masuk ke rekening dengan invoice pelanggan yang tepat, lalu mencatat jurnalnya. Masalahnya, pelanggan jarang membayar persis sesuai tagihan: ada yang membayar beberapa invoice dalam satu transfer, ada yang mencicil tanpa kesepakatan tertulis, ada yang transfer tanpa berita, dan ada yang kurang bayar beberapa ribu karena biaya transfer. Jika semua itu dicatat asal “masuk ke piutang”, laporan umur piutang jadi tidak bisa dipercaya dan tim penagihan mengejar pelanggan yang sebenarnya sudah membayar.

Di artikel ini kami membahas alur cash application yang rapi untuk tim finance, aturan alokasi saat pelanggan tidak menyebut nomor invoice, contoh jurnal untuk enam skenario pembayaran, dan satu studi kasus mutasi bank harian sebuah distributor lengkap dengan hasil pencocokannya. Anda juga akan mendapat KPI sederhana untuk menilai apakah proses ini sudah sehat.

Ringkasan Cepat

• Cash application = identifikasi pembayar + alokasi ke invoice + penanganan selisih + posting jurnal, idealnya selesai di hari yang sama dengan mutasi bank.
• Urutan aturan alokasi: remittance advice/berita transfer → invoice yang disepakati → invoice tertua (FIFO) → jangan alokasikan ke invoice yang sedang disengketakan.
• Transfer yang belum jelas pemiliknya dicatat ke akun Penerimaan Belum Teridentifikasi (kewajiban), bukan ke pendapatan.
• Selisih kecil karena biaya transfer diselesaikan dengan batas toleransi tertulis; di atas batas tetap ditagih.
• Pantau tiga angka: tingkat pencocokan otomatis, saldo dan umur penerimaan belum teridentifikasi, serta waktu dari mutasi sampai posting.

Apa itu cash application dan mengapa bukan sekadar “terima pembayaran”?

Cash application (alokasi pembayaran piutang) adalah proses menghubungkan setiap penerimaan kas atau transfer bank dengan pelanggan dan invoice yang dilunasinya, menangani selisih bayar (kurang, lebih, atau sebagian), lalu memposting jurnal pelunasan piutang. Hasilnya, saldo piutang per invoice selalu mencerminkan tagihan yang benar-benar belum dibayar.

Perbedaannya dengan “mencatat penerimaan kas” terletak pada tingkat detail. Mencatat penerimaan cukup membuat saldo bank cocok dengan rekening koran. Cash application memastikan invoice mana yang berkurang. Tanpa tingkat detail ini, total piutang di neraca bisa benar, tetapi laporan umur piutang (aging) salah: invoice lama tampak menunggak padahal sudah dibayar, sementara invoice baru tampak lunas padahal belum.

Dampaknya terasa di tiga tempat: tim penagihan salah prioritas, pelanggan yang sudah bayar merasa ditagih dua kali, dan saat tutup buku muncul selisih antara buku besar piutang dan buku pembantu (subledger) yang memakan waktu berjam-jam untuk ditelusuri.

Bagaimana alur cash application yang rapi?

Alur berikut kami susun agar bisa dijalankan setiap hari kerja oleh staf AR (accounts receivable) dan direviu oleh kepala akunting.

1. Tarik mutasi bank harian. Ambil mutasi seluruh rekening penerimaan (termasuk virtual account dan QRIS bila ada) setiap pagi untuk transaksi hari sebelumnya.
2. Identifikasi pembayar. Cocokkan nama pengirim, nomor rekening pengirim, atau nomor virtual account dengan master data pelanggan. Simpan nomor rekening yang pernah dipakai pelanggan agar pengenalan berikutnya otomatis.
3. Kumpulkan dokumen pendukung. Remittance advice (rincian pembayaran dari pelanggan), berita transfer, atau email konfirmasi dari tim sales.
4. Alokasikan ke invoice mengikuti aturan alokasi yang tertulis (lihat tabel di bawah).
5. Tangani selisih: pembayaran sebagian, kurang bayar karena biaya transfer, lebih bayar, atau transfer tidak teridentifikasi.
6. Posting jurnal dan kirim konfirmasi ke pelanggan bila ada selisih atau sisa tagihan.
7. Review harian akun penampung. Saldo Penerimaan Belum Teridentifikasi dan Saldo Kredit Pelanggan dicek umurnya; item yang melewati batas waktu dieskalasi.

Aturan alokasi apa yang dipakai bila pelanggan tidak menyebut invoice?

Inilah sumber perdebatan paling sering antara finance dan sales. Agar konsisten dan bisa diaudit, tetapkan hierarki aturan alokasi berikut dalam kebijakan piutang, dan cantumkan di syarat pembayaran pada invoice.

Prioritas	Kondisi	Aturan alokasi	Dokumentasi
1	Ada remittance advice atau nomor invoice di berita transfer	Alokasikan persis sesuai instruksi pelanggan	Lampirkan remittance/berita transfer
2	Ada kesepakatan tertulis (mis. cicilan atas invoice tertentu)	Ikuti kesepakatan	Lampirkan email/surat kesepakatan
3	Tidak ada instruksi, pelanggan teridentifikasi	Invoice tertua lebih dulu (FIFO), invoice penuh sebelum parsial	Catat “alokasi FIFO” di memo jurnal, konfirmasi ke pelanggan
4	Ada invoice yang sedang disengketakan	Lewati invoice sengketa, alokasikan ke invoice berikutnya	Catat nomor sengketa/komplain
5	Pelanggan tidak teridentifikasi	Jangan dialokasikan; catat ke Penerimaan Belum Teridentifikasi	Log investigasi dan batas waktu

Aturan FIFO membuat umur piutang lebih jujur: pembayaran tanpa keterangan tidak dipakai untuk “menutupi” invoice baru sementara invoice lama terus menua.

Bagaimana jurnal untuk 6 skenario pembayaran pelanggan?

Akun yang dipakai dalam contoh: Bank, Piutang Usaha (per invoice di subledger), Beban Administrasi Bank, Penerimaan Belum Teridentifikasi (kewajiban lancar), dan Saldo Kredit Pelanggan atau Uang Muka Pelanggan (kewajiban lancar). Semua angka adalah contoh.

1. Pembayaran penuh satu invoice

Akun	Debit	Kredit
Bank	Rp 15.000.000
Piutang Usaha – INV-1099		Rp 15.000.000

2. Satu transfer untuk beberapa invoice

Jurnalnya tetap satu, tetapi baris kredit dipecah per invoice agar subledger berkurang dengan benar.

Akun	Debit	Kredit
Bank	Rp 21.250.000
Piutang Usaha – INV-1101		Rp 12.500.000
Piutang Usaha – INV-1108		Rp 8.750.000

3. Pembayaran sebagian (partial payment)

Kredit hanya sebesar uang yang diterima. Sisa tagihan tetap tercatat di invoice yang sama, sehingga umur piutang sisa tidak “direset” ke nol.

Akun	Debit	Kredit
Bank	Rp 10.000.000
Piutang Usaha – INV-1095		Rp 10.000.000

Sisa INV-1095: Rp 14.000.000. Kirim konfirmasi sisa tagihan ke pelanggan pada hari yang sama.

4. Kurang bayar karena biaya transfer (short payment)

Jika selisih berada di bawah batas toleransi yang ditetapkan kebijakan (contoh: maksimal Rp 10.000 per transaksi), selisih dibebankan agar invoice tidak menggantung dengan saldo receh.

Akun	Debit	Kredit
Bank	Rp 6.293.500
Beban Administrasi Bank	Rp 6.500
Piutang Usaha – INV-1110		Rp 6.300.000

Jika selisih di atas toleransi, jangan dibebankan: biarkan sisa di invoice dan tagih kembali. Jika kekurangan berasal dari potongan pajak oleh pelanggan, perlakuannya berbeda (menunggu bukti potong) dan sebaiknya dikonsultasikan dengan tim pajak Anda.

5. Transfer tidak teridentifikasi

Saat diterima:

Akun	Debit	Kredit
Bank	Rp 4.750.000
Penerimaan Belum Teridentifikasi		Rp 4.750.000

Setelah diketahui sebagai pelunasan INV-1087 (reklasifikasi):

Akun	Debit	Kredit
Penerimaan Belum Teridentifikasi	Rp 4.750.000
Piutang Usaha – INV-1087		Rp 4.750.000

6. Lebih bayar (overpayment)

Akun	Debit	Kredit
Bank	Rp 15.250.000
Piutang Usaha – INV-1099		Rp 15.000.000
Saldo Kredit Pelanggan		Rp 250.000

Saldo kredit ini nantinya dipakai untuk invoice berikutnya atau dikembalikan. Langkah pengembaliannya kami bahas di artikel jurnal refund pelanggan.

Seperti apa contoh cash application dalam satu hari?

Contoh kasus: PT Contoh Niaga, distributor bahan bangunan di Jawa Timur, menerima lima transfer pada 10 November. Staf AR mencocokkannya dengan daftar invoice terbuka sebagai berikut.

No	Pengirim / berita	Jumlah diterima	Invoice terbuka	Hasil pencocokan	Skenario
1	Toko Sinar Jaya / “INV1101 1108”	Rp 21.250.000	INV-1101 Rp 12.500.000; INV-1108 Rp 8.750.000	Dua invoice lunas	Multi-invoice
2	CV Maju Bersama / tanpa berita	Rp 10.000.000	INV-1095 Rp 24.000.000	Sisa Rp 14.000.000	Sebagian
3	UD Berkah Tani / “INV1110”	Rp 6.293.500	INV-1110 Rp 6.300.000	Selisih Rp 6.500 (di bawah toleransi)	Short pay
4	“BUDI S” / tanpa berita	Rp 4.750.000	Belum diketahui	Ke akun penampung, investigasi	Tidak teridentifikasi
5	PT Andalan Retail / “INV1099”	Rp 15.250.000	INV-1099 Rp 15.000.000	Lebih Rp 250.000	Lebih bayar
	Total mutasi masuk	Rp 57.543.500

Dua hari kemudian, tim sales mengonfirmasi bahwa “BUDI S” adalah pemilik Toko Sumber Rejeki yang melunasi INV-1087, sehingga dibuat jurnal reklasifikasi seperti skenario 5. Perhatikan pembelajaran dari kasus ini:

• Total Rp 57.543.500 cocok dengan rekening koran sejak hari pertama, tetapi baru empat dari lima transfer yang langsung bisa dialokasikan. Inilah sebabnya rekonsiliasi bank yang cocok belum berarti piutang benar.
• Transfer nomor 2 dialokasikan ke INV-1095 karena itu satu-satunya invoice terbuka CV Maju Bersama. Jika ada beberapa invoice, aturan FIFO berlaku dan pelanggan diberi konfirmasi.
• Rekening pengirim “BUDI S” kemudian ditambahkan ke master data Toko Sumber Rejeki agar transfer berikutnya langsung dikenali.

Proses ini terhubung erat dengan rekonsiliasi bank bulanan: semakin rapi cash application harian, semakin sedikit item terbuka yang harus ditelusuri di akhir bulan.

Bagaimana mengukur kualitas cash application?

Kepala akunting tidak perlu memeriksa setiap transaksi. Cukup pantau beberapa indikator berikut setiap minggu. Target di tabel adalah contoh target internal yang bisa Anda sesuaikan.

KPI	Rumus	Contoh target	Sinyal masalah
Tingkat pencocokan otomatis/langsung	Transfer yang langsung teralokasi ÷ total transfer	≥ 80%	Master data rekening pelanggan tidak terawat
Saldo Penerimaan Belum Teridentifikasi	Saldo akun penampung akhir periode	Nol saat tutup buku	Ada uang pelanggan yang “hilang” dari aging
Umur item tidak teridentifikasi	Hari sejak transfer diterima	≤ 5 hari kerja	Eskalasi ke sales tidak berjalan
Waktu posting	Hari dari mutasi bank sampai jurnal terposting	H+1	Aging dan penagihan memakai data basi
Frekuensi short pay	Jumlah transfer kurang bayar ÷ total transfer	Turun dari bulan ke bulan	Instruksi pembayaran di invoice kurang jelas

Contoh: bila dalam sebulan ada 120 transfer masuk dan 96 langsung teralokasi, tingkat pencocokan Anda 80%. Sisa 24 transfer itulah yang menyerap sebagian besar waktu staf AR, sehingga perbaikan master data dan instruksi pembayaran biasanya memberi hasil paling cepat. Saldo akun penampung dan saldo kredit pelanggan juga sebaiknya masuk daftar rekonsiliasi akun neraca bulanan.

Kesalahan yang Sering Terjadi

• Mencatat transfer tidak teridentifikasi sebagai pendapatan lain-lain. Pendapatan menjadi lebih saji, sementara piutang pelanggan tetap tampak menunggak.
• Mengalokasikan pembayaran ke invoice terbaru. Invoice lama terus menua dan cadangan kerugian piutang menjadi tidak akurat.
• Menghapus selisih kurang bayar tanpa batas toleransi. Selisih kecil yang dibebankan setiap hari bisa menjadi angka material dalam setahun, dan membuka celah penyalahgunaan.
• Membuat satu baris kredit “Piutang Usaha” untuk multi-invoice. Buku besar cocok, subledger per invoice tidak.
• Tidak mengirim konfirmasi sisa tagihan. Pelanggan menganggap pembayaran sebagian sudah melunasi, dan sengketa baru muncul berbulan-bulan kemudian.
• Membiarkan saldo kredit pelanggan bertahun-tahun. Saldo ini adalah kewajiban kepada pelanggan dan perlu ditindaklanjuti, baik dipakai untuk invoice berikutnya maupun dikembalikan.

Pertanyaan yang Sering Diajukan (FAQ)

Apa beda cash application dan rekonsiliasi bank?

Rekonsiliasi bank memastikan saldo bank di buku sama dengan rekening koran. Cash application memastikan setiap penerimaan dialokasikan ke pelanggan dan invoice yang benar. Rekonsiliasi bank bisa cocok sempurna walaupun alokasi ke invoice salah, sehingga keduanya perlu dijalankan.

Akun Penerimaan Belum Teridentifikasi termasuk aset atau kewajiban?

Akun ini disajikan sebagai kewajiban lancar karena perusahaan sudah menerima uang tetapi belum tahu kewajiban apa yang dilunasi atau kepada siapa uang itu harus dikembalikan. Saldonya seharusnya diselesaikan sebelum laporan bulanan difinalkan.

Bolehkah pembayaran tanpa keterangan dialokasikan ke invoice tertua?

Boleh, asalkan pembayar sudah teridentifikasi, tidak ada instruksi lain dari pelanggan, dan aturan FIFO tercantum dalam kebijakan piutang perusahaan. Kirim konfirmasi alokasi ke pelanggan agar tidak ada perbedaan pencatatan di kedua pihak.

Berapa batas toleransi selisih kurang bayar yang wajar?

Tidak ada angka baku; batas ini adalah kebijakan internal yang biasanya disesuaikan dengan biaya transfer antarbank yang umum dibebankan kepada pengirim. Tetapkan nominal per transaksi, siapa yang berwenang menyetujui, dan akun bebannya secara tertulis.

Penutup

Cash application yang rapi membuat laporan umur piutang bisa dipercaya, tim penagihan fokus pada pelanggan yang benar-benar menunggak, dan tutup buku tidak lagi tersandera oleh transfer misterius. Kuncinya ada pada aturan alokasi tertulis, akun penampung yang dipantau setiap hari, batas toleransi selisih yang jelas, dan jurnal yang memecah kredit per invoice.

Jika saat ini tim Anda masih mencocokkan mutasi bank dengan daftar invoice di Excel setiap pagi, pertimbangkan sistem yang menghubungkan penerimaan kas dengan invoice dan piutang pelanggan dalam satu tempat. Lihat bagaimana modul kas & bank Zahir Online membantu mencatat penerimaan pelanggan dan memantau saldo piutang secara real-time.