Robot Process Automation atau RPA biasanya masuk ke finance karena satu alasan yang masuk akal: pekerjaan repetitif terlalu banyak.
Robot dapat mengambil invoice dari email, membaca nomor dokumen, mencocokkan vendor, membuat jurnal, memindahkan data ke ERP, menyiapkan pembayaran, bahkan meneruskan informasi ke proses pajak. Pada volume transaksi besar, manfaatnya jelas. Waktu kerja turun, kesalahan input manual dapat berkurang, dan tim bisa fokus pada exception.
Pembahasan yang masih berada dalam jalur isu yang sama dapat dilanjutkan ke Data Annotation Outsourcing: PPh Apa yang Mungkin Relevan bagi Pemberi Kerja?.
Untuk memperluas konteks pada bagian ini, lihat Invoice Vendor AI Global Tanpa NPWP Indonesia: Apa yang Harus Dilakukan Tim Finance?.
Masalah muncul ketika perusahaan menyamakan otomatisasi dengan kontrol.
Per 13 Agustus 2026, administrasi perpajakan Indonesia semakin terintegrasi melalui Coretax. Itu membuat kualitas data sumber, identitas lawan transaksi, masa pajak, kode objek, dan dokumen pendukung menjadi semakin penting. Robot dapat mempercepat proses yang benar. Robot juga dapat mengulang kesalahan yang sama ribuan kali dengan disiplin sempurna.
Karena itu, pertanyaan tax bukan “apakah RPA akurat?” Pertanyaannya adalah “siapa yang memastikan rule yang dijalankan robot masih benar?”
Robot tidak punya tanggung jawab hukum
Bayangkan sebuah bot yang diberi aturan sederhana.
Jika vendor adalah badan lokal dan deskripsi invoice mengandung kata “consulting”, bot memberi kode PPh Pasal 23. Jika vendor asing, bot meneruskan transaksi ke tabel withholding luar negeri. Jika invoice memiliki PPN, bot mengambil nilai pajak dan mencocokkannya dengan dokumen.
Secara demo, workflow itu terlihat bagus.
Namun siapa yang bertanggung jawab jika kata “consulting” dipakai untuk transaksi yang bukan objek yang diasumsikan? Siapa yang menilai perubahan kontrak? Siapa yang memeriksa apakah vendor asing berhak menggunakan treaty? Siapa yang memperbarui rule setelah regulasi berubah?
Jawabannya tetap perusahaan.
Otomasi memindahkan pekerjaan, bukan tanggung jawab.
Kontrol pertama: pisahkan rule engine dari keputusan profesional
Tidak semua keputusan pajak cocok dibuat secara otomatis.
Ada transaksi yang sangat rule based. Misalnya pengecekan apakah field wajib terisi, apakah NPWP atau identitas vendor sesuai master, apakah nominal invoice sama dengan purchase order, atau apakah dokumen tertentu tersedia.
Ada pula transaksi yang membutuhkan judgement. Misalnya menentukan apakah pembayaran teknologi merupakan royalti atau jasa, menilai substansi reimbursement, membaca manfaat jasa afiliasi, atau mengevaluasi penerapan P3B.
RPA sebaiknya kuat pada kelompok pertama dan berhati-hati pada kelompok kedua.
Desain yang sehat bukan “robot menentukan semuanya”, tetapi “robot menyelesaikan kasus standar dan mengirim exception ke manusia yang tepat”.
Ini membuat automation rate mungkin sedikit lebih rendah, tetapi kualitas kontrol lebih tinggi.
Kontrol kedua: vendor master harus menjadi sumber data yang dijaga
Banyak kegagalan RPA sebenarnya dimulai dari vendor master.
Satu vendor dapat memiliki nama dagang, nama legal, beberapa entitas, NPWP, negara domisili, status PKP, serta jenis transaksi yang berbeda. Jika master hanya berisi nama dan nomor rekening, bot kekurangan konteks.
Untuk kebutuhan pajak, perusahaan dapat menambahkan field seperti entitas legal, identitas pajak, negara, status domestik atau luar negeri, status PKP bila relevan, default tax treatment, tanggal review, sumber dokumen, serta flag yang mewajibkan pemeriksaan manual.
Namun default treatment tidak boleh dibaca sebagai kebenaran permanen.
Satu vendor konsultan dapat menjual jasa konsultasi, lisensi software, reimbursement, dan training. Tax treatment sebaiknya dapat ditentukan pada level transaksi atau kategori produk, bukan hanya level nama vendor.
Kontrol ketiga: jangan biarkan deskripsi invoice menjadi satu-satunya otak
Invoice description sering terlalu pendek.
“Professional fee.”
“IT services.”
“Subscription.”
“Project support.”
Jika bot menentukan pajak hanya dari empat kata seperti itu, perusahaan sedang mengotomatiskan tebakan.
RPA perlu mengambil konteks dari purchase order, contract ID, service category, cost center, atau material group. Untuk transaksi tertentu, robot juga bisa memeriksa apakah dokumen kontrak, Form DGT, faktur pajak, atau dokumen lain telah tersedia sebelum pembayaran dilepas.
Dengan begitu, keputusan tidak bergantung pada satu field yang mudah berubah.
Kontrol keempat: perubahan regulasi harus punya owner
Rule pajak bukan software yang dipasang sekali lalu dibiarkan.
PMK 81 Tahun 2024 tentang pelaksanaan Sistem Inti Administrasi Perpajakan telah mengalami beberapa perubahan, termasuk PMK 1 Tahun 2026 sebagai perubahan keempat. Di area treaty, PMK 112 Tahun 2025 memperbarui tata cara penerapan P3B dan Form DGT.
Ini menunjukkan sesuatu yang sederhana: rule yang benar tahun lalu belum tentu cukup untuk proses tahun ini.
Perusahaan perlu mempunyai tax rule owner.
Tugasnya bukan menulis kode RPA, tetapi menyatakan versi rule yang sah, tanggal efektif, dokumen sumber, kondisi penggunaan, serta kapan rule harus dinonaktifkan.
Tim automation kemudian menerjemahkan rule tersebut ke sistem.
Tanpa ownership seperti ini, programmer dapat menjadi pihak yang secara tidak sengaja “menentukan pajak” karena mereka yang paling memahami workflow.
Kontrol kelima: effective date harus masuk desain
Regulasi pajak sering memiliki tanggal berlaku.
Jika perusahaan mengubah rule hari ini, pertanyaannya bukan hanya “rule baru sudah aktif?” tetapi “transaksi periode mana yang harus memakai rule baru?”
Bot yang tidak memahami effective date dapat menerapkan perlakuan baru ke transaksi lama atau mempertahankan rule lama untuk transaksi baru.
Karena itu, setiap rule sebaiknya memiliki minimal empat metadata: versi, tanggal mulai berlaku, tanggal berhenti bila ada, dan sumber regulasi.
Untuk rule yang bergantung pada periode, bot harus membaca tanggal transaksi atau masa pajak, bukan sekadar tanggal proses.
Ini terlihat teknis, tetapi dampaknya sangat pajak.
Kontrol keenam: exception queue harus benar-benar dikerjakan
Banyak proyek automation bangga dengan angka straight through processing.
Misalnya 92 persen invoice diproses tanpa sentuhan manusia.
Angka itu belum tentu berarti kontrol bagus.
Pertanyaan yang lebih penting adalah apa yang terjadi pada 8 persen sisanya.
Apakah exception dikirim ke tax? Apakah ada SLA? Apakah kasus ditutup dengan alasan yang terdokumentasi? Apakah keputusan manual dipakai untuk memperbaiki rule, atau hanya diselesaikan satu per satu tanpa pembelajaran?
Exception queue adalah tempat paling bernilai bagi tim tax karena di sanalah transaksi baru, kontrak aneh, data tidak lengkap, dan perubahan bisnis muncul.
Jangan anggap exception sebagai kegagalan bot. Anggap sebagai sensor risiko.
Kontrol ketujuh: maker checker tetap relevan
RPA sering dipromosikan sebagai pengganti pekerjaan maker.
Robot dapat membuat draft jurnal, draft pembayaran, atau draft data pajak.
Untuk transaksi material atau berisiko, fungsi checker tetap diperlukan.
Checker tidak harus memeriksa setiap field satu per satu. Ia dapat bekerja berbasis threshold dan risk score.
Misalnya, pembayaran luar negeri di atas nilai tertentu wajib review. Vendor baru wajib review. Perubahan bank account wajib review. Tax code yang berbeda dari histori wajib review. Transaksi dengan treaty wajib review dokumen. Nilai PPN atau withholding yang menyimpang dari pola normal wajib review.
Dengan desain ini, manusia fokus pada titik yang mempunyai risiko nyata.
Kontrol kedelapan: simpan alasan keputusan, bukan hanya hasil
Audit trail RPA sering hanya menunjukkan bahwa bot A memproses transaksi pada pukul tertentu.
Untuk pajak, itu belum cukup.
Perusahaan perlu dapat menjelaskan mengapa tax code tertentu dipilih.
Apakah karena vendor masuk kategori tertentu? Karena contract type? Karena rule version 3.2? Karena dokumen DGT valid? Karena transaksi masuk exception dan disetujui tax manager?
Reason code membuat keputusan dapat ditelusuri.
Tanpa reason code, perusahaan mungkin tahu apa yang dilakukan bot, tetapi tidak tahu mengapa.
Kontrol kesembilan: rekonsiliasi output dengan data pelaporan
RPA finance tidak boleh berhenti setelah jurnal dibuat.
Jika bot menghasilkan data yang kemudian masuk ke bukti potong, SPT Masa, atau rekonsiliasi PPN, perlu ada kontrol ujung ke ujung.
Coretax mengintegrasikan berbagai proses administrasi pajak, termasuk pendaftaran, pembayaran, pelaporan, dan proses lain. DJP juga menyediakan panduan untuk bukti potong dan SPT Masa dalam ekosistem Coretax.
Artinya, kesalahan upstream dapat bergerak jauh sebelum terlihat.
Perusahaan sebaiknya merekonsiliasi transaksi sumber, jurnal, pembayaran, bukti potong atau faktur yang relevan, dan data pelaporan.
Jumlah yang sama perlu dapat ditelusuri dari invoice sampai output pajak.
Kontrol kesepuluh: robot juga perlu diuji setelah perubahan
User acceptance test bukan acara satu kali sebelum go live.
Setiap perubahan rule pajak, ERP, format invoice, vendor integration, atau Coretax interface dapat mengubah hasil.
Regression test perlu memiliki kasus yang mewakili transaksi nyata.
Contohnya, vendor lokal jasa, vendor lokal bukan objek yang diasumsikan, vendor asing tanpa treaty document, vendor asing dengan dokumen valid, invoice campuran, reimbursement, credit note, pembayaran sebagian, dan pembetulan transaksi.
Tujuannya bukan mencari sebanyak mungkin skenario, tetapi memastikan rule kritis tidak rusak ketika sistem berubah.
RPA dan AI berbeda, tetapi risiko kontrolnya bertemu
Banyak perusahaan sekarang menambahkan AI ke proses RPA.
AI membaca invoice yang tidak terstruktur, mengklasifikasikan deskripsi, atau menyarankan tax code. RPA kemudian menjalankan action berdasarkan hasil tersebut.
Di sini, confidence score menjadi penting.
Jika model hanya 70 persen yakin bahwa suatu invoice adalah jasa konsultasi, perusahaan tidak boleh memperlakukannya sama dengan rule deterministik yang 100 persen sesuai field master.
Buat threshold.
Hasil dengan confidence tinggi dan risiko rendah dapat diproses otomatis. Hasil ambigu atau material dikirim ke manusia.
AI membantu membaca ketidakpastian. Ia tidak menghapus kebutuhan judgement.
KPI automation jangan hanya mengukur kecepatan
Jika proyek RPA hanya dinilai dari jumlah FTE yang dihemat dan kecepatan posting, tim akan terdorong mengejar automation rate.
Tambahkan KPI kontrol.
Berapa persen transaksi memiliki reason code?
Berapa exception yang overdue?
Berapa perubahan rule tanpa approval tax?
Berapa koreksi bukti potong yang berasal dari salah klasifikasi upstream?
Berapa vendor yang tax profile-nya kedaluwarsa?
Berapa transaksi yang melewati manual override?
KPI seperti ini menunjukkan apakah otomatisasi benar-benar meningkatkan kualitas proses.
Buat kill switch
Salah satu kontrol paling sederhana sering dilupakan: kemampuan menghentikan robot.
Jika tax menemukan bahwa rule tertentu salah, perusahaan harus dapat menonaktifkan workflow sebelum kesalahan menyebar ke ribuan transaksi.
Kill switch dapat berlaku pada rule, vendor group, tax code, atau seluruh proses.
Setelah dihentikan, transaksi masuk ke queue manual sampai perbaikan diuji.
Tidak elegan, tetapi jauh lebih aman daripada membiarkan robot “konsisten” menerapkan kesalahan.
Otomasi yang sehat membuat manusia lebih terlihat
RPA yang baik bukan sistem yang menghilangkan manusia dari finance.
RPA yang baik menghilangkan pekerjaan mekanis sehingga judgement manusia dipakai di tempat yang memang memerlukannya.
Tax manager tidak perlu mengetik data invoice. Ia perlu mengendalikan rule. Finance staff tidak perlu mencocokkan field yang sama ribuan kali. Ia perlu menangani exception. Automation engineer tidak perlu menafsirkan regulasi sendirian. Ia perlu menerima spesifikasi rule yang jelas.
Di situlah pembagian tanggung jawab menjadi penting.
Boleh otomatis, jangan anonim
Setiap rule pajak harus punya owner.
Setiap perubahan harus punya tanggal efektif.
Setiap exception harus punya jalur eskalasi.
Setiap keputusan material harus dapat dijelaskan.
Setiap output harus dapat direkonsiliasi kembali ke transaksi sumber.
Kalau lima hal itu tidak ada, perusahaan hanya memindahkan risiko dari meja finance ke bot.
RPA memang bisa bekerja malam hari tanpa lelah. Pemeriksaan pajak juga tidak akan menerima jawaban “robot yang memilih kode itu” sebagai pengganti penjelasan substansi.
Otomasi terbaik bukan yang paling sedikit melibatkan manusia. Otomasi terbaik adalah yang tahu tepat kapan manusia harus masuk.