Pajak potong bukan atas pembayaran itu, melainkan atas tahun kalendernya
24 Agustus 2026 · Taro — Pendiri KAZENA
Pajak potong bukan pajak atas pembayaran itu sendiri. Ia hanya cicilan di tengah jalan atas pajak untuk satu tahun kalender. Saya kira saya memahaminya, tetapi kode kami tidak ditulis seperti itu. Setiap pembayaran diperlakukan sebagai perhitungan yang selesai dengan sendirinya. Akibatnya, kalau orang yang sama dibayar 2 kali, potongan pada pembayaran kedua menjadi kurang.
Yang menemukannya adalah V. Dia akuntan di Jakarta yang menguji KAZENA Books dengan data aslinya sendiri, dan sudah lebih dari 20 kali menyusun dokumen menghadap Coretax yang sesungguhnya lalu mengirimkan kembali setiap tempat yang gagal. Yang sampai kepada saya hanya satu baris: potongan pada pembayaran kedua persis sama besarnya dengan yang pertama.
Ini angkanya. Imbalan kepada orang pribadi yang bukan pegawai: 150.000.000 rupiah kepada orang yang sama sebanyak 2 kali, pada bulan Februari dan Agustus. Untuk kategori ini dasar pengenaannya adalah separuh dari bruto, jadi 75.000.000 rupiah setiap kali. Tarifnya progresif menurut Pasal 17 — 5% sampai 60.000.000 rupiah, lalu 15% sampai 250.000.000.
Perhitungan yang benar bersifat kumulatif. Pembayaran pertama adalah pajak atas dasar kumulatif 75.000.000 rupiah, yaitu 5.250.000 rupiah. Pembayaran kedua adalah pajak atas dasar kumulatif 150.000.000 rupiah — sebesar 16.500.000 rupiah — dikurangi 5.250.000 rupiah yang sudah dipotong, sehingga tersisa 11.250.000 rupiah. Perangkat lunak kami justru mengeluarkan 5.250.000 rupiah lagi untuk pembayaran kedua. Selisihnya 6.000.000 rupiah.
Yang terjadi adalah lapisan 5% terpakai 2 kali. Setiap orang hanya punya 1 lapisan 60.000.000 rupiah dalam satu tahun kalender. Kalau tiap pembayaran dihitung sendiri-sendiri, lapisan tarif terendah dibagikan sekali untuk setiap pembayaran. Makin banyak pembayarannya, makin besar kekurangannya.
Siapa yang menanggung kekurangan itu. Pemotongan adalah kewajiban pihak yang membayar, jadi kekurangannya disetor belakangan oleh pihak pembayar, ditambah sanksi. Penerimanya memang membawa pulang lebih banyak, tetapi menagih selisih itu berbulan-bulan kemudian nyaris mustahil dalam praktik. Jadi ini bukan selisih tampilan, melainkan bug yang mengeluarkan uang.
Kenapa ia lolos dari pengujian kami. Di data uji kami, setiap orang hanya punya 1 pembayaran. Menambah jumlah orang lebih mudah daripada menambah riwayat, jadi datanya kami susun satu pembayaran untuk setiap orang. Membayar orang yang sama 2 kali — hal yang sangat biasa dalam pekerjaan nyata — sama sekali belum pernah ada di dalamnya.
Akar persoalannya adalah salah menetapkan satuan perhitungan. Kami memakai pembayaran sebagai satuan. Satuan yang dilihat undang-undang adalah orang dikali tahun kalender. Ketika keduanya tidak sejalan, semua angka tampak benar selama kita hanya menatap 1 pembayaran. Benar bila berdiri sendiri, salah bila dijumlahkan — bentuk yang paling sulit ditemukan.
Saat mulai memperbaikinya muncul pertanyaan berikutnya: tanggal apa yang menentukan sesuatu masuk ke dalam tahun itu. Bukan tanggal pencatatannya, melainkan tanggal pembayarannya. Lalu, jam siapa yang menentukan pergantian tanggal. Kalau dibaca dari waktu server, pembayaran pada pagi 1 Januari di Jakarta jatuh ke 31 Desember tahun sebelumnya. Satu pembayaran yang melewati pergantian tahun menggeser titik awal seluruh akumulasi. Sekarang hal itu ditentukan dengan waktu setempat di masing-masing negara.
Kami juga harus memutuskan nasib dokumen yang sudah diterbitkan. Menghitung ulang secara kumulatif bisa membuat bukti potong yang terbit lebih dulu tidak lagi cocok dengan angka yang baru. Menulis ulang diam-diam, bagi saya, adalah hal yang paling tidak boleh dilakukan. Yang kami tampilkan sekarang adalah total yang sudah dipotong, total yang seharusnya dipotong, dan selisih keduanya, berjajar. Yang memutuskan cara memperbaikinya adalah manusia, bukan perangkat lunak.
Akumulasi kami juga ada batasnya: ia hanya kumulatif atas pembayaran yang tercatat di KAZENA, tidak lebih. Kalau orang yang sama juga dibayar perusahaan lain, akumulasi setahunnya yang sebenarnya lebih besar. Ketika perangkat lunak diam, orang membaca angka di layar sebagai keseluruhannya. Sekarang di samping angka itu kami mencetak 1 baris tentang apa saja yang tidak termasuk di dalamnya.
Layarnya pun berubah. Dulu yang tampil hanya jumlah bersih setelah potongan. Sekarang tampil berurutan: dasar pengenaan untuk pembayaran ini, akumulasi dasar sepanjang tahun berjalan, pajak atas akumulasi itu, jumlah yang sudah dipotong, dan jumlah yang dipotong kali ini. Layarnya menjadi lebih ramai daripada sebelumnya, tetapi angka yang tidak bisa diperiksa ulang oleh V juga tidak bisa kami periksa ulang.
Perlu saya tulis terus terang bahwa saya bukan konsultan pajak. Tarif dan kategori yang saya tulis di sini adalah pemahaman kami sejauh yang sudah kami terapkan, dan keputusan akhirnya ada pada profesional yang Anda tanyai. Yang bisa kami lakukan hanyalah membuat setiap langkah perhitungannya terlihat. Kalau perangkat lunak Anda mengeluarkan angka potongan yang sama pada pembayaran kedua kepada orang yang sama seperti pada yang pertama, ada baiknya sekali saja diperiksa dengan tangan.
Ceritakan pendapat Anda
Kesan setelah memakai aplikasi KAZENA, hal yang perlu diperbaiki, fitur yang Anda harapkan — kalau Anda pemilik usaha kecil-menengah atau pekerja lepas di Indonesia atau Filipina, suara Anda-lah yang paling ingin kami dengar. Pesan dalam bahasa Indonesia atau Inggris akan dijawab oleh rekan kami yang benar-benar memahami pasar lokal. KAZENA Books sudah dipastikan hadir di Filipina dan Indonesia — dan jika perusahaan Anda ingin menghadirkannya di negara-negara lain sebagai mitra kerja sama, atau tertarik membeli sistemnya, kami dengan senang hati menunggu kabar Anda. Kami juga menerima pengembangan sistem baru. Tim kami kecil, jadi tidak selalu bisa langsung mulai — tetapi yang kami bangun membawa kualitas buatan Jepang dan tetap dekat dengan cara bisnis berjalan di sini, satu proyek demi satu.
Hubungi saya