Tax technology sering dijual dengan satu janji besar: pekerjaan pajak akan menjadi lebih otomatis.
Janji itu tidak salah. Yang sering salah adalah asumsi bahwa semakin banyak proses diotomasi, semakin rendah risiko pajaknya.
Pembahasan yang masih berada dalam jalur isu yang sama dapat dilanjutkan ke Digital Procurement dan Pajak: Otomasi Tidak Menjamin Kode Pajak Selalu Benar.
Dalam praktik, ada dua jenis otomasi.
Jenis pertama menghilangkan pekerjaan manual yang berulang tanpa mengubah substansi keputusan. Misalnya menarik data transaksi, mencocokkan dokumen, mengingatkan deadline, membentuk rekonsiliasi awal, atau membuat exception list.
Jenis kedua mencoba mengambil keputusan yang sebenarnya membutuhkan interpretasi. Misalnya menentukan jenis pajak hanya dari deskripsi invoice, menyimpulkan tarif treaty dari negara vendor, atau menganggap transaksi tertentu pasti jasa hanya karena nama produknya.
Jenis pertama biasanya memberi efisiensi yang sehat. Jenis kedua dapat mempercepat kesalahan.
Per 13 Agustus 2026, administrasi perpajakan Indonesia sudah semakin bertumpu pada Coretax. PMK 81 Tahun 2024 menjadi salah satu fondasi pelaksanaan Sistem Inti Administrasi Perpajakan dan telah beberapa kali diubah, termasuk melalui PMK 1 Tahun 2026. Digitalisasi administrasi membuat kualitas data, konsistensi identitas, dan audit trail semakin penting.
Pertanyaan perusahaan bukan lagi “apakah tax perlu teknologi?”
Pertanyaannya adalah “bagian mana yang aman diotomasi, dan bagian mana yang tetap membutuhkan judgment manusia?”
Otomasi terbaik dimulai dari pekerjaan yang deterministik
Ada banyak pekerjaan tax yang mempunyai rule jelas.
Mencocokkan nomor invoice dengan data AP.
Mendeteksi vendor tanpa NPWP atau identitas yang diperlukan.
Menandai bukti potong yang belum tersedia.
Mencari transaksi duplikat.
Membandingkan nilai di ledger dengan file pajak.
Mengidentifikasi transaksi lintas negara berdasarkan vendor master.
Membuat daftar invoice yang memakai tax code tertentu.
Mengukur perbedaan antara periode akuntansi dan periode dokumen pajak.
Pekerjaan seperti itu sangat cocok untuk otomasi karena sistem tidak diminta menafsirkan hukum. Sistem diminta menemukan pola atau ketidakcocokan berdasarkan aturan yang telah ditentukan.
Nilai terbesar tax technology sering muncul dari hal sederhana tersebut.
Tax team tidak perlu menghabiskan waktu mencari transaksi. Mereka dapat menggunakan waktu untuk membaca transaksi yang memang membutuhkan judgment.
Exception engine lebih berguna daripada mesin yang pura-pura tahu semuanya
Bayangkan perusahaan memproses 20.000 invoice per bulan.
Tidak realistis meminta tax membaca semuanya satu per satu.
Tetapi juga berbahaya jika sistem mengeksekusi semua tanpa exception.
Model yang lebih matang adalah membuat lapisan risiko.
Transaksi vendor lokal berulang dengan scope dan tax treatment yang sudah tervalidasi dapat berjalan otomatis.
Vendor baru, pembayaran luar negeri, kontrak yang mengandung kata license, royalty, technical service, management fee, reimbursement, atau related party dapat masuk review queue.
Sistem tidak harus menentukan jawaban akhir.
Ia cukup berkata: transaksi ini berbeda dari pola normal dan perlu diperiksa.
Dengan desain itu, otomasi menjadi alat untuk memusatkan perhatian manusia.
Bukan alat untuk menggantikan interpretasi hukum dengan confidence score.
Tax code otomatis hanya aman jika input-nya sehat
Rule engine dapat sangat konsisten.
Masalahnya, ia juga sangat konsisten ketika data salah.
Misalnya vendor master menyatakan vendor sebagai perusahaan Indonesia, padahal invoice terbaru diterbitkan entitas Singapura dalam grup yang sama.
Rule engine akan terus memilih perlakuan domestik karena master data tidak diperbarui.
Atau procurement memakai kategori “software” untuk seluruh pembelian digital. Sistem kemudian memberi satu tax code untuk SaaS, enterprise license, cloud marketplace, support, dan database access.
Tidak ada error teknis. Hasilnya tetap bisa salah secara pajak.
Karena itu, tax technology harus dibangun di atas data governance.
Siapa yang boleh membuat vendor?
Siapa yang mengubah negara?
Siapa yang memperbarui status pihak berelasi?
Apakah billing entity pada invoice dibandingkan dengan vendor master?
Apakah perubahan kontrak memicu review?
Tanpa kontrol itu, rule canggih hanya menutupi data yang buruk dengan interface yang lebih rapi.
Coretax memperbesar nilai rekonsiliasi
Digitalisasi administrasi tidak menghapus rekonsiliasi. Ia justru meningkatkan kebutuhan rekonsiliasi lintas sistem.
Data di ERP, procurement, payroll, bank, contract repository, dan Coretax harus dapat dijembatani.
Contoh sederhana adalah bukti pemotongan.
Dari satu transaksi, perusahaan perlu menjaga hubungan antara invoice, vendor, dasar pemotongan, bukti potong, pembayaran, dan pencatatan akuntansi.
Kalau nomor referensi berbeda-beda dan tidak ada key bersama, tax team akan menghabiskan waktu melakukan matching manual.
Tax technology yang membantu adalah teknologi yang membuat relasi itu terlihat.
Bukan sekadar dashboard cantik.
Sistem yang baik memungkinkan tax menelusuri dari nilai di SPT atau bukti potong kembali ke invoice dan kontrak. Jalur itu sangat penting ketika ada review internal atau pemeriksaan.
RPA masih berguna, tetapi jangan menjadikannya fondasi tanpa kontrol
Robotic Process Automation dapat membantu pekerjaan yang repetitif, terutama ketika sistem tidak mempunyai integrasi langsung.
Bot dapat memindahkan data, mengunduh dokumen, mengisi field, atau menjalankan langkah standar berdasarkan trigger.
Namun RPA mempunyai kelemahan klasik: ia meniru proses antarmuka.
Jika layout berubah, field bergeser, atau validasi aplikasi berubah, bot dapat gagal.
Lebih berbahaya lagi, bot dapat tetap berjalan tetapi memasukkan data ke field yang salah jika kontrolnya lemah.
Karena itu, RPA untuk fungsi pajak sebaiknya memiliki logging, exception handling, maker-checker, dan reconciliation setelah proses.
Jangan menilai keberhasilan bot hanya dari status “completed”.
Uji apakah output-nya benar.
Untuk proses kritis, perusahaan juga perlu mengetahui siapa yang bertanggung jawab ketika bot gagal. Tidak boleh ada kondisi di mana tax mengira IT memantau, sementara IT mengira business owner yang memantau.
AI bisa membantu review, tetapi tidak boleh menciptakan fakta
Generative AI membuka peluang baru.
Tax team dapat menggunakannya untuk merangkum kontrak, mencari clause, membuat daftar pertanyaan, membandingkan versi dokumen, atau membantu mengelompokkan transaksi untuk review awal.
Tetapi AI tidak boleh dijadikan sumber fakta hukum tanpa verifikasi.
Model dapat salah menyebut nomor peraturan, mencampur ketentuan lama dan baru, atau menghasilkan jawaban yang terdengar sangat meyakinkan padahal dasarnya keliru.
Untuk pajak, risiko ini tinggi karena aturan dapat berubah dan satu detail tanggal berlaku dapat menentukan hasil.
Karena itu, hasil AI yang menyentuh tarif, dasar hukum, deadline, treaty, prosedur Coretax, atau kewajiban formal harus diverifikasi ke sumber resmi yang berlaku.
AI paling berguna sebagai analyst assistant, bukan authority.
Ia mempercepat pencarian dan pembacaan. Keputusan tetap harus ditopang sumber yang benar.
Treaty automation perlu rem
Perusahaan multinasional sering ingin membuat tabel tarif P3B otomatis berdasarkan negara vendor.
Itu berguna sebagai starting point, tetapi berbahaya jika dijadikan final decision engine.
Penerapan treaty tidak hanya bergantung pada negara.
Karakter penghasilan, status penerima, persyaratan substantif, dan dokumentasi juga relevan.
PMK 112 Tahun 2025 mengatur tata cara penerapan P3B oleh Wajib Pajak Luar Negeri dengan Formulir DGT. Dokumen tersebut menjadi bagian penting administrasi treaty dalam ekosistem Coretax.
Rule yang sehat dapat menandai: vendor luar negeri dari negara mitra P3B, cek Form DGT dan karakter pembayaran.
Rule yang tidak sehat langsung memasukkan tarif treaty tanpa memastikan syaratnya dipenuhi.
Dengan kata lain, otomasi boleh mempercepat identifikasi. Jangan biarkan otomasi melompati pembuktian.
PPN PMSE adalah contoh bagus untuk data matching
Pembelian produk dan jasa digital dari luar negeri menjadi area yang cocok untuk automated reconciliation.
Pada area pajak digital, DJP menjelaskan bahwa pemanfaatan BKP tidak berwujud dan JKP dari luar Daerah Pabean di Indonesia melalui PMSE berada dalam cakupan PPN PMSE. Pelaku usaha PMSE yang ditunjuk sebagai pemungut memungut PPN sesuai mekanisme yang berlaku.
Rule rekonsiliasi jangan sekadar menguji apakah angka PPN sama dengan 12 persen dari invoice bruto. Untuk kategori nonmewah terkait, sistem perlu mengakomodasi DPP nilai lain 11/12, sehingga penerapan tarif 12 persen menghasilkan jumlah pajak yang ekuivalen dengan 11 persen dari nilai transaksi yang relevan.
Perusahaan dapat membuat kontrol otomatis untuk mendeteksi invoice vendor digital luar negeri, mengecek apakah PPN tercantum, menghubungkan bukti pungut dengan invoice, dan menandai transaksi yang belum mempunyai dokumen memadai.
Itu pekerjaan data matching yang cocok untuk sistem.
Tetapi jangan menyimpulkan bahwa karena PPN sudah dipungut, analisis PPh selesai. Withholding adalah lapisan berbeda.
Tax technology harus menjaga kedua layer tetap terpisah.
Access control adalah masalah pajak juga
Coretax dan sistem internal menyimpan data sensitif perusahaan.
Jika terlalu banyak user mempunyai akses luas, risiko kesalahan dan penyalahgunaan meningkat.
Jika terlalu sedikit user mempunyai akses, proses bergantung pada satu orang dan mudah terganggu.
Karena itu, role-based access penting.
Maker tidak harus menjadi approver.
User yang mengubah tax rule sebaiknya tidak menjadi satu-satunya pihak yang memvalidasi hasilnya.
Credential pribadi jangan dibagikan ke tim.
Bot atau integrasi sebaiknya mempunyai identitas dan akses sesuai kebutuhan, bukan menggunakan akun superuser hanya karena lebih mudah.
Audit log harus dipertahankan.
Ketika angka berubah, perusahaan perlu tahu apakah perubahan berasal dari transaksi asal, rule, user, atau interface.
Tanpa log, troubleshooting menjadi opini.
Rule versioning sering dilupakan
Peraturan berubah. Interpretasi internal berubah. Produk berubah. Tax code berubah.
Jika perusahaan memperbarui rule engine, versi lama jangan hilang tanpa jejak.
Misalnya rule baru berlaku mulai periode tertentu. Sistem harus menyimpan kapan rule diaktifkan dan transaksi mana yang diproses dengan versi tersebut.
Kalau seluruh histori dihitung ulang memakai rule terbaru, perusahaan bisa kehilangan kemampuan menjelaskan kenapa transaksi lama diperlakukan berbeda.
Versioning membuat tax automation dapat diaudit.
Ia juga membantu saat terjadi perubahan regulasi. Tim dapat menguji rule baru pada sample sebelum aktivasi penuh.
Shadow run lebih aman daripada langsung live
Untuk otomasi baru, perusahaan dapat menjalankan shadow mode.
Sistem menghasilkan rekomendasi tax code atau exception, tetapi belum mengeksekusi posting final.
Tax team membandingkan hasil mesin dengan keputusan manusia selama beberapa periode.
Dari sana terlihat false positive, false negative, data yang hilang, dan rule yang terlalu agresif.
Setelah akurasi dan kontrol dianggap memadai, barulah sebagian keputusan dipindahkan ke straight-through processing.
Pendekatan ini lebih aman daripada mengaktifkan otomatisasi penuh karena demo vendor terlihat bagus.
Tax data mart lebih berguna daripada dashboard yang terputus
Banyak proyek tax technology berhenti pada visualisasi.
Ada dashboard PPh, dashboard PPN, dashboard vendor, dan dashboard pembayaran. Semua bagus, tetapi data dasarnya tidak konsisten.
Yang lebih penting adalah membangun tax data layer yang menghubungkan transaksi.
Minimal perusahaan perlu bisa menautkan legal entity, vendor, invoice, account, cost center, kontrak, tax code, bukti potong atau pungut, pembayaran, serta periode pelaporan.
Untuk memperluas konteks pada bagian ini, lihat FinOps Bertemu Tax: Kenapa Tagihan Cloud Harus Bisa Ditelusuri per Entity.
Setelah fondasi itu ada, dashboard menjadi mudah.
Tanpa fondasi, dashboard hanya mempercepat tampilan data yang belum tentu benar.
Ukuran keberhasilan bukan berapa persen yang otomatis
Ada kecenderungan menjadikan straight-through processing sebagai KPI utama.
Misalnya target 95 persen transaksi tanpa sentuhan manusia.
KPI itu bisa mendorong perilaku yang salah. Tim menurunkan exception agar angka otomasi naik, padahal transaksi berisiko justru lolos tanpa review.
Ukuran yang lebih sehat antara lain penurunan error, waktu rekonsiliasi, jumlah exception material yang ditemukan sebelum pembayaran, completeness dokumen, kecepatan tracing transaksi, dan konsistensi antara sistem sumber dengan pelaporan pajak.
Otomasi adalah sarana.
Ketepatan dan auditability adalah tujuan.
Tax technology yang matang tahu batasnya sendiri
Pada 2026, perusahaan mempunyai lebih banyak alat daripada sebelumnya: ERP rules, workflow engine, RPA, API, data platform, machine learning, dan generative AI.
Tidak semuanya harus dipakai untuk semua masalah.
Automate pekerjaan deterministik.
Gunakan analytics untuk menemukan anomali.
Gunakan AI untuk membantu membaca dan mengelompokkan.
Gunakan human review ketika substansi kontrak, treaty, klasifikasi penghasilan, atau fakta transaksi membutuhkan judgment.
Jaga vendor master dan legal entity mapping.
Pisahkan PPN dari PPh.
Simpan dokumen dan audit trail.
Versioning setiap rule yang memengaruhi keputusan.
Dan jangan pernah menganggap status “success” pada sistem berarti kewajiban pajak sudah benar.
Tax technology yang bagus tidak berusaha menghilangkan manusia dari proses. Ia menghilangkan pekerjaan manual yang tidak perlu, lalu membawa manusia tepat ke transaksi yang memang membutuhkan keputusan.
Itulah perbedaan antara otomasi yang memperkuat kontrol dan otomasi yang hanya membuat kesalahan bergerak lebih cepat.