Membayar pajak pada hari terakhir masih dapat berarti tepat waktu jika seluruh proses berhasil sesuai ketentuan. Masalahnya, perusahaan bukan mesin yang bekerja tanpa friksi. Ada approval, kode billing, limit bank, cut-off transaksi, gangguan akses, kesalahan data, signer yang sedang bepergian, dan rekonsiliasi yang baru menemukan selisih beberapa jam sebelum deadline.
Karena itu kebiasaan membayar pajak selalu menjelang jatuh tempo sebaiknya dibaca sebagai risiko operasional, bukan sekadar pilihan kalender.
Pembahasan yang masih berada dalam jalur isu yang sama dapat dilanjutkan ke Sertifikat Elektronik dan Penagihan: Kenapa Kepatuhan Digital Bisa Berdampak Operasional?.
PMK 81 Tahun 2024 menyederhanakan sejumlah tenggat pembayaran atau penyetoran masa menjadi tanggal 15 bulan berikutnya untuk jenis pajak tertentu. Aturan tersebut kemudian mengalami beberapa perubahan, termasuk PMK 1 Tahun 2026. Namun keseragaman tanggal tidak menghilangkan kebutuhan membaca tenggat per jenis pajak. Tidak semua kewajiban mempunyai deadline yang identik.
Pada 2026, DJP juga terus mengedukasi bahwa pembayaran melalui administrasi Coretax tetap membutuhkan perhatian pada batas waktu sesuai jenis pajak. Bagi perusahaan, pelajaran utamanya bukan menghafal satu tanggal, tetapi membangun jadwal internal yang memberi buffer.
Deadline hukum bukan deadline kerja internal
Ini prinsip pertama yang perlu diubah.
Jika batas pembayaran menurut ketentuan adalah tanggal tertentu, perusahaan sebaiknya mempunyai internal cut-off lebih awal. Misalnya, data final selesai H-5, review H-4, approval H-3, billing H-2, dan pembayaran paling lambat H-1 atau lebih awal sesuai risk appetite.
Jadwal ini bukan aturan pajak. Ini kontrol operasional.
Tanpa internal cut-off, seluruh error menumpuk di hari terakhir. Satu invoice besar yang baru masuk bisa mengubah dasar perhitungan. Satu direktur yang belum approve dapat menahan pembayaran. Satu billing salah membuat tim kembali ke awal.
Membayar lebih awal bukan berarti menghitung pajak secara serampangan. Justru data cut-off harus dirancang agar jumlah yang dibayar sudah cukup andal.
Risiko pertama adalah approval chain
Banyak perusahaan membutuhkan dua atau tiga level persetujuan untuk pembayaran material. Sistem treasury mungkin memerlukan maker, checker, dan approver berbeda.
Pada hari biasa, alur itu aman. Pada hari deadline, satu orang yang tidak tersedia menjadi bottleneck.
Tax team sering merasa tugas selesai setelah mengirim nominal ke treasury. Treasury merasa belum bisa membayar karena approval belum masuk. CFO mengira pajak sudah beres karena mendapat email “payment request submitted”.
Solusinya adalah status yang lebih presisi. Gunakan label calculated, reviewed, approved, billing generated, bank submitted, paid, dan reconciled. Jangan gunakan satu status “done”.
Dengan begitu manajemen tahu pembayaran yang sudah dihitung tetapi belum dieksekusi berbeda dari pembayaran yang sudah mempunyai bukti penerimaan negara.
Risiko kedua adalah kode billing
Kode billing adalah jembatan antara kewajiban dan pembayaran. Kesalahan jenis pajak, masa, tahun, atau nominal dapat membuat pembayaran tidak menutup kewajiban yang dimaksud.
Jika billing baru dibuat beberapa menit sebelum pembayaran, tidak ada ruang untuk second review.
Perusahaan sebaiknya membuat billing setelah tax payment list disetujui, lalu checker memverifikasi elemen penting sebelum dikirim ke treasury. Untuk pembayaran besar, lakukan verbal confirmation atau kontrol tambahan sesuai materiality.
Jika billing salah tetapi baru diketahui setelah dana masuk, perusahaan mungkin harus menempuh proses administratif seperti pemindahbukuan sesuai kondisi. Itu menambah waktu dan pekerjaan yang sebenarnya dapat dicegah dengan review dua menit.
Risiko ketiga adalah limit dan cut-off bank
Tax calendar harus bertemu dengan treasury calendar.
Bank mempunyai limit transaksi, otorisasi, dan mekanisme pemrosesan. Perusahaan juga dapat menerapkan daily limit internal. Pembayaran besar mungkin memerlukan kenaikan limit atau persetujuan tambahan.
Hari terakhir bukan waktu ideal untuk pertama kali mengetahui bahwa token direktur tidak aktif atau limit akun hanya setengah dari pajak yang harus dibayar.
Lakukan liquidity and banking readiness check setidaknya beberapa hari sebelumnya. Pastikan saldo, limit, approver, device, dan jalur pembayaran tersedia.
Jangan mengasumsikan transaksi bank yang diinput sebelum tengah malam selalu otomatis berarti kewajiban telah dibayar tepat waktu. Gunakan bukti penerimaan negara dan ketentuan saat pembayaran yang relevan sebagai dasar, bukan timestamp screenshot dari aplikasi bank semata.
Risiko keempat adalah perbedaan hasil rekonsiliasi
Angka pajak yang dihitung tanggal 5 dapat berubah tanggal 13 karena vendor mengirim dokumen terlambat atau payroll melakukan koreksi.
Jika perusahaan selalu mengejar data sampai menit terakhir, tax team berada dalam konflik permanen antara completeness dan deadline.
Tentukan materiality rule. Data yang datang setelah cut-off harus mempunyai treatment yang jelas. Apakah dapat masuk masa berjalan? Apakah perlu koreksi? Apakah konsekuensinya material? Siapa yang menyetujui?
Jangan biarkan staf paling junior mengambil keputusan periode hanya karena waktu tinggal satu jam.
Risiko kelima adalah gangguan sistem
Sistem elektronik dapat mengalami gangguan, baik di sisi perusahaan, jaringan, bank, maupun platform administrasi. Tidak semua gangguan berarti wajib pajak otomatis bebas dari konsekuensi keterlambatan.
DJP memang pernah memberikan relaksasi atau penanganan tertentu ketika kendala sistem Coretax terjadi pada masa transisi. Namun perusahaan tidak boleh membangun SOP dengan asumsi bahwa setiap gangguan pada hari terakhir pasti mendapat penghapusan sanksi.
Jika ada kendala, dokumentasikan screenshot, waktu kejadian, tiket bantuan, komunikasi resmi, dan tindakan yang sudah dicoba. Dokumentasi ini penting bila kemudian perlu menjelaskan bahwa keterlambatan tidak terjadi karena kelalaian perusahaan.
Lebih baik lagi, jangan menempatkan seluruh pembayaran pada jendela waktu yang paling rentan.
Risiko keenam adalah cash flow yang terlalu ketat
Perusahaan kadang sengaja menunggu hari terakhir agar kas dapat digunakan selama mungkin. Secara treasury, menjaga likuiditas memang rasional. Namun manfaat beberapa hari tambahan harus dibandingkan dengan risiko sanksi dan gangguan proses.
Jika perusahaan hampir setiap bulan baru mempunyai dana untuk pajak pada hari jatuh tempo, itu bukan sekadar masalah tax team. Itu sinyal working capital.
Buat tax cash forecast. Setelah payroll, sales, dan purchase data cukup stabil, tax team memberi estimasi kewajiban kepada treasury lebih awal. Treasury kemudian mengunci sebagian kas sebagai committed tax cash.
Dengan cara ini dana pajak tidak bersaing pada menit terakhir dengan pembayaran vendor yang juga dianggap urgent.
Deposit pajak sebagai salah satu alat manajemen
PMK 81 Tahun 2024 memperkenalkan atau mengatur penggunaan Deposit Pajak dalam arsitektur pembayaran Coretax. DJP menjelaskan bahwa deposit dapat digunakan dalam administrasi pembayaran dan dapat membantu mengurangi risiko keterlambatan.
Bagi perusahaan dengan volume kewajiban rutin, konsep ini menarik dari sisi operasional. Namun penggunaannya harus disesuaikan dengan kebutuhan likuiditas, prosedur internal, dan mekanisme yang berlaku.
Deposit bukan alasan untuk berhenti melakukan rekonsiliasi. Dana yang tersedia tetap harus dialokasikan dengan benar terhadap kewajiban.
Perusahaan juga perlu memahami bagaimana pencatatan internal dilakukan agar deposit tidak membuat saldo kas pajak sulit ditelusuri.
Buat kalender H-7, bukan H-0
Salah satu desain yang lebih sehat adalah membuat control calendar berbasis hari sebelum jatuh tempo.
H-7: data source completeness check.
H-5: preliminary calculation dan exception list.
H-4: review transaksi material atau tidak biasa.
H-3: final calculation dan approval internal.
H-2: billing dan bank readiness.
H-1: pembayaran serta pengecekan bukti.
H+1: rekonsiliasi NTPN dan closing exception.
Jadwal ini harus disesuaikan dengan jenis pajak dan struktur perusahaan. Tujuannya bukan menciptakan ritual yang sama untuk semua kasus, tetapi menciptakan buffer yang nyata.
Untuk pajak dengan deadline berbeda, calendar engine harus membaca due date yang tepat. Jangan memaksa seluruh kewajiban ke tanggal 15 hanya karena banyak pembayaran masa telah diseragamkan.
Tentukan siapa yang boleh menyatakan pembayaran selesai
Kata “sudah bayar” harus mempunyai definisi operasional.
Apakah ketika transfer bank submitted? Ketika status bank successful? Ketika bukti penerimaan negara tersedia? Ketika pembayaran sudah matched ke kewajiban?
Untuk kontrol yang kuat, status final sebaiknya memerlukan bukti yang dapat ditelusuri. Simpan NTPN atau bukti penerimaan negara dan lakukan matching terhadap approved payment list.
CFO tidak perlu menerima bukti satu per satu. Dashboard dapat menunjukkan persentase paid and reconciled sebelum deadline.
Jika ada satu item belum match, status batch pembayaran belum sepenuhnya hijau.
Jangan menilai performa hanya dari tidak adanya denda
Perusahaan bisa setahun penuh tidak terkena sanksi tetapi selalu membayar pada menit terakhir. Secara outcome, berhasil. Secara proses, rapuh.
Tambahkan leading indicator: berapa persen pembayaran dilakukan minimal satu hari kerja sebelum deadline, berapa kali emergency approval terjadi, berapa billing yang harus dibuat ulang, berapa pembayaran gagal pada percobaan pertama, dan berapa exception yang ditemukan setelah bayar.
Leading indicator menunjukkan apakah organisasi aman atau sekadar beruntung.
Siapkan contingency playbook untuk hari kritis
Walau jadwal internal sudah maju, perusahaan tetap perlu rencana jika pembayaran belum selesai mendekati deadline. Playbook minimal menjawab siapa decision maker, siapa kontak treasury, siapa approver cadangan yang sah, bagaimana mengecek limit bank, bagaimana membuat ulang billing yang salah, dan bagaimana mendokumentasikan gangguan sistem.
Tentukan juga jalur komunikasi. Jika pukul 14.00 H-1 pembayaran belum berstatus paid, siapa yang menerima alert? Jika pukul 10.00 pada hari deadline masih ada exception, apakah CFO otomatis masuk dalam eskalasi? Batas waktu internal seperti ini mencegah tim menunggu sampai sore karena mengira orang lain sedang menangani masalah.
Setelah pembayaran berhasil, jangan bubarkan war room sebelum bukti penerimaan dan matching selesai. Kesalahan periode atau jenis pajak yang ditemukan setelah bank successful tetap membutuhkan tindakan administratif.
Setiap insiden deadline harus menghasilkan satu perbaikan. Jika penyebabnya limit bank, revisi kalender treasury. Jika penyebabnya data vendor terlambat, ubah cut-off AP. Jika penyebabnya signer tidak tersedia, benahi delegation plan. Dengan begitu buffer tidak sekadar memindahkan deadline, tetapi benar-benar meningkatkan ketahanan proses.
Hari terakhir seharusnya menjadi buffer, bukan rencana
Tidak ada kewajiban umum bahwa pajak harus dibayar jauh sebelum deadline. Perusahaan berhak mengelola kas sampai batas yang diperbolehkan. Tetapi dari sisi manajemen risiko, menjadikan hari terakhir sebagai jadwal normal membuat seluruh kontrol bekerja tanpa ruang kesalahan.
Bayar pajak bukan satu klik. Ia adalah rantai data, review, approval, billing, perbankan, bukti, dan rekonsiliasi. Setiap mata rantai dapat gagal.
Karena itu pertanyaan yang seharusnya diajukan CFO bukan, “Bukankah deadline masih besok?” Pertanyaannya, “Kalau satu hal gagal hari ini, apakah kita masih punya waktu memperbaikinya tanpa terlambat?”
Jika jawabannya tidak, organisasi terlalu dekat dengan batas.
Pembayaran menjelang jatuh tempo mungkin terlihat efisien karena kas bertahan sedikit lebih lama. Tetapi efisiensi yang menghilangkan buffer dapat berubah menjadi sanksi, pekerjaan tambahan, dan gangguan operasional. Internal deadline yang lebih awal memberi perusahaan sesuatu yang sangat berharga dalam administrasi pajak: waktu untuk menemukan kesalahan sebelum kesalahan itu mempunyai harga.