Uang Anda Bisa Tertahan Duluan, Bahkan Sebelum Invoice-nya Sendiri Terbit

Termin di kontrak forwarding hampir selalu tertulis jelas: 30 hari, kadang 45 atau 60, dihitung dari tanggal invoice. Yang jarang tertulis di mana pun adalah berapa hari yang sudah berlalu sebelum invoice itu sendiri sempat terbit. Rentang ini, pada contoh di artikel ini, cukup panjang untuk membuat DSO 41 hari yang sudah terlihat molor tetap kalah jauh dari 60 hari yang sebenarnya berlalu sejak barang diterima. Breakdown ini memecah perjalanan satu invoice jadi lima tanggal, supaya rentang yang hilang itu punya nama dan bisa diukur, bukan cuma jadi selisih yang tidak terjelaskan di rekening.

Angka 41 dan 60 hari di atas sepenuhnya rekaan, dipilih supaya cara membaca breakdown-nya gampang diikuti. Angka itu bukan rata-rata industri, dan bukan klaim bahwa semua job forwarder pasti molor sampai hari ke-60. Yang bisa langsung dipakai dari sini bukan kedua angka itu, melainkan kelima titik tanggal yang menyusunnya; cara mengukurnya sendiri di invoice-invoice Anda ada di bagian akhir artikel ini.

Pertanyaan "kenapa kas menipis padahal termin cuma 30 hari" biasanya dijawab dengan saling tunjuk: finance bilang customer telat bayar, sales membela diri karena terminnya sudah disepakati dan customer yang dimaksud termasuk yang tertib membayar. Ketiga versi itu bisa sama-sama benar, karena yang belum pernah diukur adalah rentang sebelum invoice itu terbit sama sekali. Rentang itu tidak masuk kolom mana pun di laporan umur piutang.

Lima tanggal yang menyusun satu siklus kas invoice

Untuk mengukur rentang itu, pecah dulu perjalanan satu invoice jadi lima tanggal. Kelimanya berlaku untuk hampir semua job forwarding, terlepas dari berapa pun nilai kontraknya.

Dari lima tanggal itu, ada dua angka yang sering dipertukarkan padahal mengukur rentang berbeda. DSO (days sales outstanding) yang lazim dilaporkan mengukur jarak T1 ke T4, dari invoice terbit sampai uang masuk. Siklus kas riil mengukur jarak T0 ke T4, dari job selesai sampai uang masuk. Selisih di antara keduanya, yaitu T1 dikurangi T0, adalah rentang yang tidak pernah muncul di laporan DSO standar mana pun, karena secara akuntansi piutang itu memang belum tercatat ada sebelum T1.

Kenapa definisi DSO yang baku justru jadi jebakan untuk perusahaan logistik

Dalam manajemen keuangan, siklus konversi kas mengukur berapa lama dana perusahaan tertahan sebelum kembali sebagai kas, dan DSO adalah salah satu komponennya. Definisinya baku di semua industri: dihitung sejak tanggal invoice terbit (T1) sampai uang diterima (T4).

Untuk perusahaan jasa seperti forwarding, definisi baku itu punya titik buta. Sumber daya Anda mulai terkunci sejak jasanya dijalankan (T0), bukan sejak invoice-nya terbit (T1), dan jarak antara keduanya bisa mencapai berminggu-minggu tergantung berapa banyak pihak yang harus menagih dulu ke Anda. Karena rumus DSO baru mulai berjalan dari T1, rentang T0 ke T1 otomatis jatuh di luar jangkauan pengukuran itu, bukan karena disembunyikan, tapi karena metodenya memang tidak dirancang untuk menangkap rentang tersebut.

Komponen T0 ke T1: kenapa invoice belum terbit padahal job sudah selesai

Rentang ini seluruhnya berada dalam kendali internal, tidak menunggu keputusan siapa pun di sisi customer. Tiga penyebab berikut yang paling sering menahannya.

Tagihan vendor yang belum lengkap

Satu job forwarding biasanya melibatkan banyak pihak: trucking, gudang, EMKL, agen di pelabuhan tujuan, kadang PPJK. Masing-masing menagih dengan ritmenya sendiri, dan invoice final ke customer sering baru bisa disusun setelah semua biaya diketahui, karena sebagian komponen ditagihkan ulang secara at-cost. Satu vendor yang lambat menagih sudah cukup menahan seluruh invoice, meski secara operasional job itu sendiri sudah lama selesai.

• Sepakati estimasi biaya di muka dengan vendor tetap, terbitkan invoice berdasarkan estimasi itu, lalu koreksi belakangan kalau meleset.
• Pecah invoice jadi komponen yang sudah pasti (freight, handling) dan komponen yang masih menunggu (biaya pelabuhan, storage), kalau kontraknya mengizinkan.
• Beri tenggat penagihan tertulis ke vendor. Vendor yang menagih belakangan pada dasarnya sedang memakai uang Anda tanpa bunga.

Selisih data antara operasional dan finance

Operasional mencatat job di satu tempat, finance menagih dari tempat lain, dan di antara keduanya ada proses penyalinan data: ekspor Excel, atau diketik ulang manual. Selisihnya biasanya sepele: nomor kontainer beda satu huruf, tanggal muat beda satu hari. Sepele bagi Anda, belum tentu bagi bagian hutang customer yang memang tugasnya mencocokkan dokumen sampai detail terkecil. Karena sumber jedanya ada di struktur internal sendiri, ini juga yang paling bisa dihapus: begitu invoice dibuat langsung dari data job yang sama tanpa salin-tempel di tengah jalan, kesalahan kelas ini nyaris hilang.

Persetujuan internal yang menumpuk

Banyak perusahaan mewajibkan invoice di atas nilai tertentu disetujui manajer dulu sebelum dikirim. Niatnya wajar, tapi praktiknya invoice sering menumpuk hanya karena menunggu satu tanda tangan yang kebetulan sedang di luar kota. Kalau rata-rata lama tunggu persetujuan di perusahaan Anda sudah lebih dari dua hari, kontrol itu mulai memakan biaya lebih besar daripada kerugian yang dicegahnya.

Komponen T1 ke T2: invoice terkirim, belum tentu tercatat sebagai diterima

Kebanyakan customer korporat tidak memproses invoice tanpa lampiran lengkap: POD bertanda tangan, surat jalan, kadang hasil timbangan atau berita acara. Kurang satu saja, invoice tertahan di tahap penerimaan dokumen, biasanya tanpa pemberitahuan apa pun ke Anda.

Penolakan semacam ini berbahaya justru karena senyapnya. Invoice tidak dikembalikan; ia hanya tidak pernah masuk antrean pembayaran. Anda baru sadar saat menagih dan diberi tahu dokumennya memang kurang sejak awal, dan T2 baru tercatat sejak dokumennya lengkap, bukan sejak tanggal Anda mengirim.

Komponen T2 ke T3: satu-satunya rentang yang memang milik kontrak

Berbeda dari komponen-komponen sebelumnya, rentang T2 ke T3 bukan jeda yang perlu diperbaiki. Ini termin yang memang disepakati, kredit yang secara sadar Anda berikan ke customer setelah invoice tercatat lengkap. Kalau kontraknya menulis 30 hari, maka 30 hari itulah yang seharusnya berjalan di sini, tidak lebih cepat, tidak juga molor tanpa alasan yang tercatat.

Nilainya berguna sebagai pembanding: kalau jarak T2 ke T3 yang benar-benar terjadi lebih panjang dari termin yang tertulis di kontrak, itu biasanya tanda ada kesalahan pencatatan tanggal jatuh tempo di sistem penagihan Anda sendiri, bukan tanda keterlambatan pembayaran dari customer, dan koreksinya ada di sistem itu, bukan di surat penagihan.

Komponen T3 ke T4: jatuh tempo tercapai, tapi siklus bayar customer punya jadwal sendiri

Rentang ini di luar kendali langsung Anda, tapi bisa diantisipasi. Banyak perusahaan besar hanya menjalankan proses pembayaran pada tanggal tertentu, misalnya setiap tanggal 25. Invoice yang jatuh tempo tanggal 26 bisa menunggu sampai siklus bayar berikutnya, meski secara kalender selisihnya cuma satu hari.

Informasi tanggal siklus bayar ini biasanya gratis, cukup ditanyakan langsung ke bagian hutang customer. Begitu tanggalnya diketahui, tim penagihan bisa bekerja mundur dari situ, memastikan T2 tercapai cukup jauh sebelum tanggal siklus bayar terdekat, bukan menebak-nebak setelah pembayarannya sudah telanjur molor.

Waterfall satu invoice, angka disederhanakan untuk menunjukkan caranya

Contoh berikut angka disederhanakan untuk menunjukkan cara membaca waterfall-nya, bukan catatan satu perusahaan atau satu customer tertentu, dan bukan rata-rata yang berlaku umum di industri. Anggap satu job dengan termin kontrak 30 hari, dihitung sejak T2.

Perhatikan cara membacanya. Dari 60 hari total pada contoh ini, DSO standar yang dihitung dari T1 ke T4 akan menunjukkan angka 41 hari, sudah kelihatan lebih panjang dari termin 30 hari yang tertulis di kontrak. Tapi angka DSO itu sendiri masih menyembunyikan 19 hari di T0 ke T1, rentang yang terjadi sebelum invoice bahkan sempat terbit, dan sepenuhnya berada di tangan Anda sendiri untuk dipangkas.

“Anda tidak sedang merundingkan ulang termin pembayaran. Anda sedang mengukur hari-hari yang sudah lewat sebelum jam termin itu mulai berjalan.”

Cara mengukur kelima tanggal ini di 20 invoice terakhir Anda sendiri

Angka 60 hari di atas cuma alat bantu baca. Angka yang berguna untuk perusahaan Anda hanya bisa didapat dari invoice Anda sendiri, dan untuk itu cukup 20 invoice terakhir yang sudah lunas, supaya kelima tanggalnya sudah pasti tersedia semua, termasuk T4.

1. 1Kumpulkan 20 invoice terakhir yang sudah lunas. Bukan yang masih outstanding: tanpa T4 yang pasti, perhitungannya tidak bisa selesai.
2. 2Catat lima tanggalnya dari sumber yang sudah ada: T0 dari catatan job selesai atau POD, T1 dari tanggal invoice diterbitkan, T2 dari bukti terima kalau ada (kalau tidak ada, catat sebagai tidak diketahui, itu sendiri sudah jadi temuan), T3 dari klausul termin di kontrak dihitung dari T2, T4 dari tanggal mutasi rekening.
3. 3Hitung dua jarak per invoice: T1 dikurangi T0, dan T4 dikurangi T3. Dua angka ini yang paling sering luput dari laporan DSO standar.
4. 4Bandingkan T3 hasil hitungan dengan T3 yang tertulis di sistem penagihan. Kalau beda, itu tanda tanggal jatuh tempo di sistem Anda salah dihitung, bukan tanda customer telat.
5. 5Rata-ratakan tiap jarak dari 20 invoice itu. Itulah baseline nyata perusahaan Anda, bukan asumsi dari satu kasus yang paling diingat.

Urutan perbaikan berdasarkan segmen yang paling murah diperbaiki

Begitu 20 invoice sudah terukur, urutan berikut biasanya paling masuk akal, dari yang paling murah dikerjakan ke yang paling lama selesai.

1. 1Cari tahu tanggal siklus bayar lima customer terbesar Anda (memengaruhi T3 ke T4). Perbaikan paling murah yang ada: modalnya cuma lima kali telepon.
2. 2Pecah invoice menjadi komponen yang sudah pasti dan komponen yang masih menunggu (memangkas T0 ke T1), kalau kontraknya memungkinkan.
3. 3Beri tenggat ke vendor, tertulis, lalu pantau siapa yang paling sering telat menagih (T0 ke T1).
4. 4Minta bukti terima bertanggal untuk tiap invoice, supaya T2 tercatat akurat dan T3 tidak salah hitung.
5. 5Hilangkan penyalinan data antara operasional dan finance (T0 ke T1). Dampaknya paling besar, tapi juga paling lama dikerjakan, jadi wajar ditaruh paling akhir.

Yang tidak akan membantu, berdasarkan segmen mana yang sebenarnya bermasalah

• Menambah orang di tim penagihan: kalau jedanya terjadi di T0 ke T1 karena menunggu data, menambah penagih cuma menambah orang yang ikut menunggu.
• Memperketat termin di kontrak baru. Pada contoh di atas, termin (T2 ke T3) cuma menyumbang 30 dari 60 hari; sisanya sudah terjadi sebelum atau sesudah rentang itu.
• Mengirim surat peringatan lebih awal ke customer, padahal jedanya ternyata ada di T0 ke T1. Ini berisiko merusak hubungan komersial demi memperbaiki gejala yang salah.
• Denda keterlambatan yang dihitung dari T1, bukan dari T2. Kalau klausul kontrak menghitung termin dari T2, menagih denda sejak T1 bisa keliru secara kontraktual, dan jarang benar-benar ditagihkan ke customer yang masih ingin Anda pertahankan.

Satu-satunya intervensi yang hasilnya benar-benar bertahan adalah memperpendek jarak antara T0 dan T1: peristiwa fisik (barang diterima) dan peristiwa keuangan (invoice terbit). Makin dekat jaraknya, makin sedikit celah bagi uang Anda untuk tersangkut di rentang yang bahkan tidak muncul di laporan piutang mana pun.