Menagih klien sebagai freelance: dari invoice PDF ke tautan bayar

Masalah menagih sebagai freelance bukan pada sopan atau tidaknya kalimat penagihan. Masalahnya struktural: sebuah invoice PDF tidak punya status. Setelah terkirim, file itu tidak tahu apakah sudah dibayar, dan satu-satunya cara mengetahuinya adalah bertanya ke klien, lalu menunggu tangkapan layar, lalu mencocokkannya sendiri dengan mutasi rekening. Setiap tagihan berubah menjadi percakapan. Artikel ini tentang memindahkan status itu ke tempat yang bisa menjawab sendiri.

Yang berubah ketika tagihan punya tautan bayar

Tautan bayar adalah invoice yang tahu kondisinya sendiri. Nominalnya sudah terkunci, jadi tidak ada transfer kurang seratus ribu karena salah baca. Statusnya hanya tiga dan sama persis di dashboard maupun di API: pending selama belum dibayar, succeeded begitu pembayaran terkonfirmasi, dan expired bila masa berlakunya habis. Tidak ada status yang bergantung pada penilaian manusia terhadap sebuah gambar.

Efek praktisnya pada pekerjaan freelance ada tiga. Pertama, pertanyaan “sudah ditransfer belum” hilang karena jawabannya bisa dilihat tanpa bertanya. Kedua, bukti transfer palsu berhenti menjadi risiko, dan bentuk-bentuknya dibahas terpisah di artikel bukti transfer palsu. Ketiga, pekerjaan bisa dimulai berdasarkan konfirmasi, bukan berdasarkan janji.

Pecah menjadi termin, satu tautan per termin

Praktik yang sudah umum di pekerjaan lepas, yaitu uang muka di depan dan pelunasan saat serah terima, kebetulan juga bentuk yang paling cocok untuk tautan bayar. Buat satu tautan per termin, bukan satu tautan untuk keseluruhan proyek. Alasannya bukan administratif belaka: setiap termin menjadi peristiwa yang bisa ditunggu dan ditindak sendiri, sehingga pengerjaan tahap berikutnya punya penanda mulai yang jelas.

Untuk proyek Rp 8.000.000 dengan skema 50 persen di depan, artinya dua tautan senilai Rp 4.000.000. Beri masing-masing penanda sendiri pada external_id, misalnya nomor invoice ditambah nomor termin, supaya rekap di akhir bulan tidak perlu menebak tautan mana milik proyek mana. Penanda itu label untuk pencarian dan penyaringan, bukan pengaman terhadap tagihan ganda. Yang mencegah satu tagihan terkirim dua kali hanyalah header Idempotency-Key, dan alasannya diuraikan di artikel Idempotency-Key.

Ada batas yang memaksa pemecahan ini, dan lebih baik diketahui sebelum invoice pertama dikirim: satu pembayaran dibatasi maksimum Rp 10.000.000, dengan minimum Rp 10.000 dan total Rp 50.000.000 per hari. Nominal di luar rentang itu ditolak saat pembuatan dengan kode amount_too_large, amount_too_small, atau daily_amount_cap, dan angka yang berlaku ada di dokumentasi batas. Proyek Rp 25.000.000 tidak bisa menjadi satu tautan, dan memang sebaiknya tidak.

Memilih channel: persen melawan nominal tetap

Untuk tagihan besar, pilihan channel berpengaruh nyata pada penghasilan bersih, dan alasannya ada pada bentuk tarifnya, bukan besarnya. QRIS ditagih sebagai persentase, yaitu MDR 0,7 persen, ditambah biaya platform Rp 250 per transaksi berhasil. Karena komponen utamanya persen, biayanya tumbuh mengikuti nominal: pada termin Rp 4.000.000, QRIS menghabiskan Rp 28.250.

Virtual Account ditagih dengan bentuk yang berbeda, yaitu nominal tetap per transaksi tanpa komponen persen sama sekali. Biayanya tidak berubah apakah tagihannya Rp 500.000 atau Rp 9.000.000. Konsekuensinya sederhana dan jarang disadari: ada titik nominal di mana Virtual Account menjadi lebih murah daripada QRIS, dan di atas titik itu selisihnya terus melebar. Titik impasnya adalah nominal ketika 0,7 persen darinya sama dengan selisih antara tarif tetap Virtual Account dan Rp 250. Tarif yang berlaku untuk sebuah akun dikembalikan oleh GET /v1/payment_methods dalam bentuk percent_bps dan flat, jadi hitungannya bisa dilakukan dengan angka yang benar-benar berlaku, bukan angka yang disalin dari artikel.

Untuk pekerjaan lepas yang nilainya jutaan, kesimpulannya biasanya searah: tawarkan Virtual Account untuk termin besar, dan biarkan QRIS untuk tagihan kecil seperti biaya revisi tambahan atau pembelian aset. Delapan bank Virtual Account yang aktif tercantum di dokumentasi metode pembayaran. Satu hal teknis yang perlu diingat: Virtual Account membutuhkan customer.name karena nama itu yang muncul di aplikasi bank pembayar, dan hari ini Virtual Account diambil lewat Direct API sementara halaman checkout menuntaskan QRIS. Perbedaan antara Virtual Account dan transfer biasa, terutama soal kenapa yang satu bisa dicocokkan otomatis, dibahas di artikel Virtual Account.

Pertanyaan berikutnya biasanya siapa yang menanggung biaya itu. Keduanya sah: biaya bisa dipotong dari yang diterima, atau ditambahkan ke nominal yang dilihat pembayar. Untuk pekerjaan lepas, memasukkan biaya ke dalam harga penawaran sejak awal lebih rapi daripada menambahkannya di akhir, karena angka di invoice menjadi sama dengan angka di kontrak. Cara menghitung nominal penawaran agar hasil bersihnya persis sesuai target, yang ternyata pembagian dan bukan penjumlahan, ada di artikel menetapkan harga setelah biaya transaksi.

Masa berlaku harus mengikuti tempo pembayaran

Ini kesalahan yang paling sering terjadi saat memindahkan invoice ke tautan bayar. Masa berlaku bawaan dirancang untuk penjualan yang dibayar saat itu juga, sedangkan invoice pekerjaan lepas biasanya bertempo, misalnya dibayar dalam 14 hari setelah diterima bagian keuangan. Tautan yang kedaluwarsa sebelum tempo pembayaran habis akan memaksa pengiriman ulang, dan setiap pengiriman ulang mengembalikan percakapan yang tadi ingin dihilangkan.

Sebaliknya, masa berlaku yang terlalu panjang juga bukan pilihan gratis, karena tagihan lama yang masih hidup menumpuk sebagai kewajiban yang bisa dibayar kapan saja. Cara memilih angkanya per situasi, termasuk apa yang terjadi saat masa berlaku habis, ada di artikel masa berlaku tagihan. Untuk invoice bertempo, aturan praktisnya adalah menyamakan masa berlaku dengan tempo pembayaran di kontrak, lalu menerbitkan tautan baru bila tempo itu terlewat.

Selesaikan verifikasi sebelum invoice pertama, bukan sesudah

Ada dua tingkat verifikasi dan fungsinya berbeda. Dengan email, nomor ponsel, dan profil usaha terverifikasi, pembayaran sudah bisa diterima. Untuk menarik dana ke rekening bank diperlukan verifikasi penuh: nama sesuai KTP, NIK, foto KTP, selfie, dan rekening bank atas nama sendiri. Badan usaha tidak disyaratkan, dan urutan lengkapnya dibahas di panduan payment gateway tanpa PT.

Urutannya penting justru karena kedua tingkat itu terpisah. Menerima pembayaran lebih dulu lalu mengurus verifikasi belakangan berarti dana klien sudah masuk sementara jalan keluarnya belum dibuka, dan itu terjadi tepat ketika uangnya paling dibutuhkan. Selesaikan keduanya sebelum invoice pertama dikirim.

Satu kebiasaan lagi yang menghemat: pencairan dikenakan biaya per pencairan, sebesar Rp 3.000 menurut syarat dan ketentuan. Mencairkan setiap kali satu termin masuk berarti membayar biaya itu berulang kali untuk uang yang sama. Menjadwalkan pencairan mingguan, atau menunggu beberapa termin terkumpul, memangkasnya menjadi satu.

Yang tetap tidak diselesaikan oleh tautan bayar

Tautan bayar menghilangkan keraguan tentang apakah pembayaran sudah masuk. Tautan bayar tidak membuat klien membayar. Kesepakatan lingkup pekerjaan, jumlah revisi yang termasuk, tempo pembayaran, dan konsekuensi keterlambatan tetap urusan kontrak, dan tetap harus disepakati tertulis sebelum pekerjaan dimulai. Yang berubah hanyalah ini: ketika kesepakatan itu dilanggar, pelanggarannya terlihat sebagai status pending yang tidak kunjung berubah, bukan sebagai perasaan tidak enak yang sulit ditindak.

Untuk yang mengirim invoice dari aplikasi sendiri, alur teknisnya pendek: buat permintaan pembayaran lewat endpoint create dengan header Idempotency-Key, kirim tautannya bersama invoice, lalu tandai invoice lunas saat webhook payment.paid bertanda tangan Kasera-Signature-V1 diterima. Rinciannya ada di dokumentasi webhook.