Pukul 16.20, invoice terakhir sebelum cut-off pembayaran masuk ke sistem procurement. Vendor sudah terdaftar, purchase order cocok, nilai invoice sama dengan penerimaan barang atau jasa, dan workflow approval berjalan otomatis. Dari sudut pandang operasi, semuanya terlihat rapi.
Masalah baru muncul ketika tax reviewer membuka detail transaksi. Sistem memberi tax code yang sama dengan pembelian vendor sebelumnya, padahal scope kontrak berubah. Dulu vendor menjual jasa implementasi lokal. Sekarang invoice berisi akses software, support, dan satu komponen lisensi dari entitas luar negeri dalam grup yang sama.
Tidak ada error merah. Tidak ada workflow yang berhenti. Justru itu masalahnya.
Digital procurement bisa membuat proses pembelian lebih cepat dan lebih konsisten, tetapi otomasi hanya sebaik data dan rule yang dimasukkan ke dalamnya. Sistem tidak memahami substansi transaksi hanya karena ia mampu mencocokkan PO, invoice, vendor master, cost center, dan approval matrix.
Per 13 Agustus 2026, perusahaan Indonesia yang mengotomasi procurement tetap harus membaca karakter pembayaran berdasarkan ketentuan pajak yang berlaku. PPN, pemotongan PPh, transaksi dengan pihak luar negeri, penerapan treaty, serta dokumentasi Coretax tidak berubah menjadi otomatis benar hanya karena proses source-to-pay sudah digital.
Untuk memperluas konteks pada bagian ini, lihat Tax Technology 2026: Otomasi Mana yang Membantu, Mana yang Justru Menambah Risiko Data?.
Masalah utama bukan apakah sistem bisa memilih tax code. Pertanyaannya adalah apakah sistem mempunyai informasi yang cukup untuk memilih tax code yang benar.
Tax code bukan atribut permanen vendor
Salah satu desain paling berbahaya dalam digital procurement adalah menganggap satu vendor identik dengan satu perlakuan pajak.
Vendor yang sama dapat menjual banyak hal.
Perusahaan teknologi dapat menjual konsultasi, implementasi, training, support, lisensi, subscription, hardware, atau kombinasi beberapa komponen. Agensi dapat menagih jasa kreatif, media placement, reimbursement biaya pihak ketiga, atau lisensi aset. Vendor cloud dapat menyediakan konsumsi komputasi, layanan dukungan, professional services, dan produk pihak ketiga melalui marketplace.
Jika vendor master hanya memiliki satu default tax code, sistem akan cenderung mengulang klasifikasi lama.
Default berguna untuk efisiensi. Default tidak boleh berubah menjadi kesimpulan hukum.
Dalam transaksi domestik, misalnya, DJP menjelaskan bahwa imbalan atas jasa tertentu kepada wajib pajak dalam negeri dapat menjadi objek PPh Pasal 23 dengan tarif 2 persen dari jumlah bruto sesuai kategorinya, sedangkan royalti berada pada kategori PPh Pasal 23 dengan tarif 15 persen. Itu berarti perbedaan antara jasa dan hak penggunaan bukan sekadar soal nama akun biaya.
Untuk transaksi luar negeri, analisis dapat bergeser ke PPh Pasal 26 dan, jika relevan, Persetujuan Penghindaran Pajak Berganda. Sejak PMK 112 Tahun 2025, penerapan P3B oleh Wajib Pajak Luar Negeri menggunakan Formulir DGT sesuai tata cara yang diperbarui dan administrasinya terhubung dengan Coretax.
Sistem procurement harus mampu menangkap perbedaan tersebut sebelum mengusulkan perlakuan pajak.
Deskripsi PO sering terlalu pendek untuk pajak
Coba lihat tiga deskripsi berikut.
“Software annual fee.”
“Professional service.”
“Digital solution package.”
Bagi procurement, deskripsi itu mungkin cukup untuk menerbitkan purchase order. Bagi tax, ketiganya belum menjawab apa-apa.
Tax perlu mengetahui siapa kontraktornya, negara penerima pembayaran, apa deliverable-nya, hak apa yang diperoleh, apakah ada penggunaan kekayaan intelektual, apakah ada jasa manusia, apakah layanan diberikan dari luar Indonesia, dan apakah vendor memungut PPN PMSE.
Kalau informasi tersebut hanya ada di kontrak PDF yang tidak pernah dibaca oleh rule engine, tax code otomatis sebenarnya sedang bekerja dengan data yang tidak lengkap.
Karena itu, digital procurement yang matang tidak hanya mengumpulkan nilai, vendor, dan cost center. Ia juga perlu mengumpulkan data yang mempunyai makna pajak.
Pembahasan yang masih berada dalam jalur isu yang sama dapat dilanjutkan ke Data Center Lokal untuk Perusahaan Asing: Kapan Kehadiran Digital Menjadi Isu Pajak?.
Beberapa field yang berguna antara lain jenis deliverable, negara entitas vendor, status pihak berelasi, komponen jasa, komponen lisensi, lokasi pemanfaatan, masa kontrak, pola pembayaran, serta apakah transaksi melibatkan barang atau jasa digital dari luar Daerah Pabean.
Tidak semua field harus diwajibkan untuk semua pembelian. Yang lebih efektif adalah membuat pertanyaan bercabang sesuai risiko.
Pembelian alat tulis lokal tidak membutuhkan questionnaire sepanjang pembelian software lintas negara.
PPN digital menunjukkan kenapa procurement dan tax harus bicara
Pembelian layanan digital dari luar negeri adalah contoh jelas.
DJP menjelaskan bahwa PPN PMSE dikenakan atas pemanfaatan Barang Kena Pajak tidak berwujud dan atau Jasa Kena Pajak dari luar Daerah Pabean di dalam Daerah Pabean melalui perdagangan elektronik. Untuk pelaku usaha PMSE yang ditunjuk sebagai pemungut, mekanisme pemungutan dijalankan oleh pemungut tersebut.
Pada rezim PPN yang berlaku saat ini, untuk barang nonmewah, jasa, dan barang tidak berwujud, PPN dihitung dengan tarif 12 persen atas dasar pengenaan pajak berupa nilai lain sebesar 11/12 dari nilai penggantian atau nilai relevan, sehingga secara matematis beban efektifnya setara 11 persen untuk kategori tersebut.
Di procurement, invoice vendor global mungkin sudah mencantumkan PPN.
Namun keberadaan PPN di invoice tidak otomatis menjawab apakah ada kewajiban pemotongan PPh atas pembayaran kepada pihak luar negeri.
PPN dan PPh adalah dua lapisan analisis berbeda.
Rule engine yang hanya membaca kolom “tax included” dapat melewatkan persoalan withholding. Sebaliknya, rule yang hanya fokus pada PPh dapat gagal menangkap dokumentasi PPN PMSE yang perlu disimpan untuk kepentingan perusahaan.
Otomasi seharusnya memecah lapisan, bukan mencampurnya.
Tiga-way match juga tidak memvalidasi pajak
Banyak perusahaan bangga ketika tiga-way match berjalan otomatis: purchase order, goods receipt atau service acceptance, dan invoice harus cocok sebelum pembayaran.
Kontrol itu penting, tetapi tujuan utamanya berbeda.
Tiga-way match memastikan transaksi komersial konsisten. Ia tidak membuktikan bahwa klasifikasi pajaknya tepat.
Invoice dapat cocok 100 persen dengan PO, tetapi PO sejak awal memakai kategori yang salah.
Misalnya, user memilih “IT services” karena opsi itu paling dekat dengan kebutuhannya. Di kontrak sebenarnya ada hak penggunaan software dan support yang dibundel. Sistem lalu meneruskan kategori IT services ke AP, tax code otomatis terisi, dan pembayaran selesai tanpa exception.
Secara proses, transaksi sempurna.
Secara pajak, mungkin belum dianalisis dengan benar.
Inilah alasan perusahaan perlu memisahkan commercial matching dari tax determination.
Tax determination membutuhkan rule dan data sendiri.
Vendor onboarding adalah titik kontrol yang murah
Banyak masalah pajak sebenarnya dapat dicegah sebelum invoice pertama masuk.
Saat vendor onboarding, perusahaan dapat meminta data dasar: nama legal entity, negara domisili, status pajak, NPWP atau identitas relevan untuk vendor lokal, jenis layanan, rekening bank, hubungan afiliasi, dan dokumen pendukung tertentu.
Untuk vendor luar negeri, onboarding dapat menanyakan apakah transaksi mungkin menggunakan treaty dan siapa yang bertanggung jawab memperoleh Form DGT jika memang diperlukan.
Untuk vendor digital, sistem dapat menandai apakah vendor atau platform merupakan pemungut PPN PMSE berdasarkan bukti yang tersedia pada invoice dan administrasi transaksi.
Tetapi onboarding juga tidak boleh menjadi jebakan baru.
Data vendor dapat berubah. Kontrak dapat ditandatangani oleh entitas grup yang berbeda. Invoice dapat diterbitkan oleh billing entity lain. Produk yang dibeli dapat berbeda dari produk awal.
Karena itu, data onboarding adalah baseline, bukan pengganti review transaksi.
Tax code perlu dipicu oleh kombinasi vendor plus transaksi, bukan vendor saja.
Gunakan rule untuk menandai risiko, bukan berpura-pura tahu semua jawaban
Tidak semua keputusan pajak cocok diotomasi penuh.
Rule yang baik misalnya dapat berkata: jika vendor luar negeri, kontrak digital, dan ada kata license atau right to use, kirim ke tax review.
Rule yang buruk langsung memutuskan: semua transaksi dengan kata license adalah royalti.
Bahasa kontrak komersial tidak selalu sama dengan klasifikasi pajak. Istilah license dapat digunakan untuk akses terbatas ke aplikasi, penggunaan aset, atau hak kekayaan intelektual yang jauh lebih luas. Substansi kontrak dan ketentuan hukum tetap perlu dibaca.
Hal yang sama berlaku untuk kata service.
Tidak semua pembayaran yang diberi label service mempunyai perlakuan yang sama. Penerima, jenis jasa, lokasi, dan ketentuan P3B bila lintas negara dapat relevan.
Karena itu, salah satu desain terbaik adalah menjadikan otomasi sebagai triage engine.
Transaksi berisiko rendah dapat diproses otomatis berdasarkan rule yang tervalidasi. Transaksi dengan karakter tertentu masuk exception queue untuk review manusia.
Kecepatan diperoleh tanpa berpura-pura bahwa seluruh interpretasi hukum dapat direduksi menjadi dropdown.
Coretax membuat kualitas data semakin terlihat
Coretax tidak menghilangkan kebutuhan rekonsiliasi. Justru digitalisasi administrasi membuat ketidakkonsistenan data lebih mudah terlihat.
PMK 81 Tahun 2024 menjadi fondasi ketentuan perpajakan dalam pelaksanaan Sistem Inti Administrasi Perpajakan, dan peraturan tersebut telah beberapa kali diubah, terakhir antara lain melalui PMK 1 Tahun 2026. Perubahan administrasi ini berarti perusahaan harus memperlakukan data pajak sebagai data operasional yang terkelola, bukan hasil perbaikan manual di akhir bulan.
Jika purchase order mengatakan satu jenis transaksi, invoice memakai deskripsi lain, kontrak menunjukkan substansi berbeda, dan bukti potong dibentuk dari tax code yang salah, rekonsiliasi menjadi mahal.
Masalahnya bukan sekadar salah posting.
Kesalahan dapat mengalir ke bukti pemotongan, pembayaran pajak, pelaporan, rekonsiliasi vendor, dan dokumentasi pemeriksaan.
Digital procurement seharusnya memutus rantai kesalahan itu lebih awal.
Bangun tax decision tree yang dapat diaudit
Perusahaan tidak perlu memulai dari sistem AI yang rumit.
Decision tree sederhana sering lebih berguna.
Pertama, siapa penerima pembayaran?
Kedua, lokal atau luar negeri?
Ketiga, apa substansi yang dibeli?
Keempat, apakah ada hak penggunaan atau kekayaan intelektual?
Kelima, apakah ada jasa manusia atau deliverable yang dapat dipisahkan?
Keenam, apakah vendor memungut PPN dan melalui mekanisme apa?
Ketujuh, apakah treaty relevan?
Kedelapan, dokumen apa yang wajib tersedia sebelum pembayaran?
Jawaban tersebut kemudian memicu tiga hasil: auto-pass, review, atau hold.
Yang penting, sistem menyimpan alasan keputusan. Jika tax code berubah, pengguna dapat melihat siapa yang mengubah, kapan, berdasarkan dokumen apa, dan rule versi berapa.
Tanpa audit trail, otomasi hanya mempercepat kesalahan sekaligus membuat asal kesalahan lebih sulit dilacak.
Tax dan procurement perlu mempunyai owner bersama
Kegagalan digital procurement sering bukan kegagalan software. Ia kegagalan governance.
Procurement merasa pajak adalah urusan finance. Finance merasa vendor classification adalah urusan procurement. Tax baru melihat transaksi ketika pembayaran sudah dekat. IT hanya menjalankan konfigurasi yang diminta.
Akibatnya, tidak ada satu pihak yang memiliki keseluruhan alur.
Model yang lebih sehat adalah membagi tanggung jawab secara eksplisit.
Procurement menjaga data vendor dan kontrak.
Business requester menjelaskan apa yang sebenarnya dibeli.
Tax menentukan rule dan exception criteria.
Finance memastikan pembayaran dan dokumen mengikuti hasil keputusan.
IT menjaga integritas workflow, akses, dan log perubahan.
Semua fungsi itu perlu menggunakan definisi data yang sama.
Satu field “service type” yang dimaknai berbeda oleh procurement dan tax sudah cukup untuk menghasilkan ratusan transaksi salah klasifikasi.
Uji rule dengan transaksi buruk, bukan hanya transaksi ideal
Sebelum rule tax code diaktifkan, jangan hanya mengetes invoice yang rapi.
Masukkan skenario yang memang sering terjadi: invoice tanpa PO, vendor global dengan billing entity berbeda, kontrak campuran jasa dan lisensi, reimbursement oleh karyawan, credit note, pembayaran tahunan di muka, perubahan mata uang, atau vendor yang berganti negara penagihan.
Tujuan testing bukan membuktikan sistem bekerja saat data sempurna.
Tujuannya mengetahui bagaimana sistem gagal saat realitas berantakan.
Perusahaan juga perlu melakukan sample review secara berkala. Ambil transaksi yang diproses otomatis, bandingkan tax code dengan kontrak dan invoice, lalu lihat apakah rule masih relevan.
Peraturan, produk vendor, dan model bisnis berubah. Rule yang benar tahun lalu dapat menjadi tidak memadai tahun ini.
Otomasi yang sehat tetap membutuhkan skeptisisme
Digital procurement sangat berguna untuk mengurangi pekerjaan manual, mempercepat approval, menutup kebocoran belanja, dan menjaga konsistensi proses.
Tetapi pajak bukan sekadar problem konsistensi. Pajak adalah problem klasifikasi yang bergantung pada fakta.
Sistem dapat secara konsisten salah jika input atau rule awalnya salah.
Karena itu, target perusahaan bukan membuat tax code selalu otomatis. Targetnya membuat keputusan pajak dapat dijelaskan, ditelusuri, dan dikoreksi sebelum kesalahan menyebar.
Otomasi harus menangani transaksi yang memang bisa distandardisasi.
Exception harus naik ke manusia yang memahami kontrak dan aturan.
Data vendor harus diperbarui.
PPN dan PPh harus dibaca sebagai lapisan terpisah.
Transaksi luar negeri harus memiliki jalur treaty dan dokumentasi sendiri.
Dan setiap keputusan penting harus meninggalkan audit trail.
Digital procurement terbaik bukan sistem yang tidak pernah meminta review. Ia sistem yang tahu kapan proses boleh berjalan sendiri dan kapan pajak terlalu penting untuk diserahkan kepada default code.