Menagih perusahaan yang membayar lewat bagian keuangan: nomor yang bisa disalin, dan tiga default yang harus diubah

Pembeli berupa perusahaan membayar dengan cara yang berbeda dari pembeli perorangan, dan perbedaannya bukan soal nominal. Tiga hal berubah sekaligus: orang yang memesan bukan orang yang menekan tombol bayar, pembayarannya lewat antrian persetujuan yang memakan hari bukan menit, dan nominalnya sering melewati plafon per pembayaran. Setiap satu dari ketiganya mematahkan default yang bekerja mulus untuk pembeli perorangan.

Yang perlu diubah ada tiga, dan semuanya ditentukan saat permintaan pembayaran dibuat, bukan sesudahnya: metodenya, waktu penerbitannya, dan penanda yang menempel padanya.

Kirim nomor yang bisa disalin, bukan kode yang harus dipindai

Bagian keuangan membayar dari internet banking atau dari sistem kas perusahaan, di depan komputer, sering dengan dua orang yang berbeda: satu menyiapkan, satu menyetujui. QRIS menuntut kebalikannya, yaitu satu orang memegang ponsel dengan aplikasi pembayaran terpasang pada saat pembayaran dilakukan. Kode yang dipindai juga tidak bisa dilampirkan ke formulir persetujuan internal dalam bentuk yang berguna.

Virtual Account menghasilkan sesuatu yang bentuknya sudah dikenal keuangan mana pun: nomor rekening tujuan yang bisa disalin, ditempel ke daftar pembayaran, dan diteruskan lewat email tanpa berubah. Delapan bank tersedia, dan daftar kodenya ada di daftar metode pembayaran.

Ada satu detail yang menentukan apakah nomor itu bisa ikut di dalam invoice atau tidak. Menyebut satu kode metode saja pada permintaan pembayaran membuat instrumennya dicetak saat itu juga, sehingga nomor Virtual Account ikut kembali bersama respons pembuatan. Menyebut beberapa kode, atau tidak menyebut sama sekali, berarti pembeli belum memilih jalur, jadi belum ada nomor yang dicetak dan yang tersedia hanya tautan halaman pembayaran. Untuk tagihan korporat, sebutkan satu kode Virtual Account, lalu cantumkan nomornya langsung di badan invoice. Perbedaan antara “silakan buka tautan ini” dan “transfer ke nomor ini” adalah perbedaan antara tagihan yang menunggu seseorang mengklik dan tagihan yang sudah masuk antrian pembayaran.

Nomor Virtual Account tidak bisa terbit tanpa nama pembayar, dan nama itu juga yang terbaca pada halaman pembayaran. Isi dengan nama perusahaan pembayar, bukan nama orang yang memesan, karena nama itulah yang akan dicocokkan keuangan dengan catatan mereka sendiri. Alasan tarif untuk memilih Virtual Account pada nominal besar dibahas terpisah di panduan memilih QRIS atau Virtual Account; di sini alasannya operasional, dan berlaku bahkan seandainya tarifnya sama.

Terbitkan tagihan saat keuangan siap membayar, bukan saat pesanan dibuat

Ini kesalahan yang paling mahal dan paling sering, karena kebiasaannya datang dari menjual ke perorangan. Permintaan pembayaran punya masa berlaku, default 60 menit, dan plafon akun default 24 jam. Nilai di atas plafon itu ditolak dengan 422 expiry_too_long, seperti tercantum di referensi batas dan laju.

Tempo pembayaran korporat berbicara dalam satuan yang sama sekali berbeda: 14 hari, 30 hari, kadang lebih. Tidak ada satu pun nilai masa berlaku yang bisa menutup jarak itu. Konsekuensinya jelas dan sebaiknya diterima sejak awal daripada dilawan: tautan pembayaran bukan pengganti invoice, melainkan langkah terakhir sesudah invoice.

Urutan yang bekerja:

• Kirim invoice sendiri, dengan tempo, nomor PO, dan rincian pekerjaannya. Ini dokumen yang masuk ke antrian persetujuan, dan bisa berumur berminggu-minggu.
• Tanyakan tanggal pembayaran yang dijadwalkan. Bagian keuangan hampir selalu punya jawabannya, dan jawaban itu yang menentukan kapan tagihannya diterbitkan.
• Buat permintaan pembayaran pada hari itu, lalu kirim nomor Virtual Accountnya sebagai balasan atas invoice yang sudah mereka pegang.

Tagihan yang telanjur kedaluwarsa tidak diperpanjang, melainkan diterbitkan ulang dengan nomor baru, dan nomor lama berhenti menerima uang. Karena itu nomor Virtual Account sebaiknya tidak pernah disebarkan lebih awal daripada perlu: nomor yang sudah beredar di beberapa lampiran email lalu diterbitkan ulang adalah cara termudah membuat keuangan mentransfer ke nomor yang sudah mati.

Dua plafon yang menentukan bentuk tagihannya

Nominal maksimum satu pembayaran adalah Rp 10.000.000, ditolak dengan 422 amount_too_large, dan total nominal per hari adalah Rp 50.000.000, ditolak dengan 429 daily_amount_cap. Jumlah permintaan per hari dibatasi 100, dan harinya dihitung dalam zona waktu Asia/Jakarta, bukan UTC. Nilainya default dan dapat berbeda per akun.

Untuk penjual yang pembelinya perorangan, angka-angka itu jarang terasa. Untuk penjual yang satu proyeknya bernilai puluhan juta, keduanya mengenai langsung. Tagihan di atas Rp 10.000.000 harus dipecah menjadi beberapa pembayaran, dan pemecahan itu paling baik mengikuti termin yang memang sudah disepakati di kontrak, bukan dipecah sembarangan hanya agar lolos plafon. Pertimbangan memecah satu pesanan menjadi dua pembayaran, termasuk komponen biaya mana yang benar-benar bertambah, ada di perbandingan uang muka dan pembayaran penuh di muka.

Batas Rp 50.000.000 sehari menuntut satu kebiasaan tambahan: pada bulan dengan beberapa termin besar jatuh tempo bersamaan, jangan terbitkan semuanya pada tanggal yang sama. Menyebar penerbitan ke beberapa hari kerja jauh lebih mudah daripada menjelaskan tagihan yang gagal terbit kepada klien yang sedang siap membayar.

Empat penanda, dan mana yang bisa dipakai mencocokkan PO

Transfer yang masuk perlu bisa dikembalikan ke pesanan asalnya tanpa menebak. Ada empat field yang menempel pada permintaan pembayaran, dan tugasnya berbeda-beda:

• merchant_ref adalah referensi internal penjual, maksimal 64 karakter, dikembalikan pada respons dan bisa difilter pada endpoint daftar transaksi. Ini tempat yang tepat untuk nomor PO pembeli.
• external_id adalah nomor pesanan di sistem penjual sendiri, juga bisa difilter. Memakai keduanya sekaligus berarti satu pembayaran bisa dicari dari sisi pembeli maupun dari sisi penjual.
• description tampil pada halaman pembayaran, maksimal 255 karakter. Yang dibaca orang keuangan sebelum menyetujui ada di sini, jadi tulis nomor invoice dan periode pekerjaannya, bukan nama produk saja.
• order_items memuat sampai 50 baris berisi nama, harga, dan kuantitas, dan ikut tampil pada halaman pembayaran. Jumlah harga dikali kuantitas harus sama persis dengan nominal, kalau tidak permintaannya ditolak. Untuk PO berbaris banyak, ini yang membuat halaman pembayaran terbaca seperti dokumen yang sudah disetujui, bukan seperti angka yang muncul entah dari mana.

Satu peringatan yang mahal kalau dilewatkan: tidak satu pun dari keempatnya mencegah duplikat. Mengirim ulang permintaan dengan merchant_ref atau external_id yang sama menghasilkan permintaan pembayaran kedua, bukan mengembalikan yang pertama. Satu-satunya yang mencegah tagihan ganda adalah header Idempotency-Key, dan cara memakainya dibahas di artikel tagihan ganda dan Idempotency-Key. Pada tagihan korporat risikonya lebih besar dari biasa, karena penagihan ulang memang sering dilakukan manual saat klien menanyakan invoice yang belum dibayar.

Bukti yang bisa dan tidak bisa disediakan sisi pembayaran

Bagian keuangan hampir selalu meminta dokumen setelah membayar. Yang tersedia dari sisi pembayaran adalah halaman pembayaran yang tetap terbuka setelah statusnya succeeded, memuat nominal, metode, waktu, serta keterangan dan rincian baris yang tadi diisi; daftar transaksi pada dashboard yang bisa difilter menurut penanda tadi lalu diekspor; serta notifikasi otomatis ke sistem penjual lewat webhook, sehingga status di sistem sendiri berubah tanpa ada yang mengecek mutasi bank manual.

Yang tidak disediakan sisi pembayaran adalah dokumen perpajakan dan kuitansi resmi atas nama penjual. Dokumen semacam itu terbit dari sisi penjual, mengikuti kewajiban penjual sendiri, dan sebaiknya disepakati bentuknya sejak penawaran, bukan setelah uang masuk. Menyamakan halaman bukti pembayaran dengan faktur adalah salah satu sumber tarik ulur paling lama pada pembayaran korporat pertama.

Selisih biayanya, pada nominal yang memang besar

Bentuk tarif tiap metode berbeda, dan pada nominal korporat perbedaannya berhenti menjadi detail. Tarif yang berlaku hari ini ada di halaman harga: QRIS 0,7 persen ditambah Rp 250, Virtual Account Rp 5.000 tetap, kartu 2,8 persen ditambah Rp 2.500. Pada satu tagihan Rp 5.000.000, ketiganya berbunyi Rp 35.250, Rp 5.000, dan Rp 142.500. Angka itu ilustrasi, tetapi polanya tetap: komponen tetap Virtual Account tidak bergerak sama sekali mengikuti nominal, sementara dua metode lain bergerak penuh.

Ada satu hal yang berjalan berlawanan arah, dan layak diketahui sebelum memilih. Dari tiga metode aktif, hanya kartu yang punya jalur pengembalian dana lewat sistem. Kelebihan bayar atau pembatalan pada Virtual Account diselesaikan dengan transfer balik manual dari rekening penjual. Untuk pembeli korporat yang pesanannya jarang berubah setelah PO terbit, itu pertukaran yang mudah diterima; untuk pekerjaan yang lingkupnya masih bergerak dan nominalnya masih mungkin turun setelah dibayar, kesepakatan tertulis tentang cara mengembalikan selisih lebih penting daripada metode mana yang dipilih.

Ringkasnya

Menagih perusahaan bukan soal menaikkan nominal pada cara menagih yang sudah biasa dipakai. Sebutkan satu kode Virtual Account supaya nomornya terbit dan bisa masuk ke invoice, terbitkan tagihannya pada tanggal pembayaran yang dijadwalkan dan bukan pada hari pesanan dibuat, pecah nominal di atas Rp 10.000.000 mengikuti termin kontrak, dan isi nomor PO pada merchant_ref sejak permintaan pertama. Empat kebiasaan itu menyelesaikan hampir semua gesekan pembayaran korporat, dan keempatnya gratis.