Banyak masalah pajak perusahaan sebenarnya dimulai sebelum invoice diterima.

Vendor sudah dipilih. Purchase order sudah terbit. Jasa sudah berjalan. Barang sudah dikirim. Baru ketika invoice masuk, accounts payable bertanya kepada tax team, “Ini dipotong PPh apa?”

Pertanyaan itu datang terlalu terlambat.

Kalau perusahaan baru menentukan perlakuan pajak saat invoice masuk, tax function selalu bekerja di hilir. Kesalahan pada nama vendor, NPWP, status PKP, jenis jasa, lokasi transaksi, bahkan hubungan afiliasi sudah telanjur masuk sistem.

Vendor tax master dibuat untuk memindahkan kontrol ke depan.

Ia bukan sekadar database alamat dan rekening bank. Vendor tax master adalah kumpulan data perpajakan yang membantu sistem dan manusia menentukan perlakuan transaksi sejak vendor pertama kali digunakan.

Dalam lingkungan Coretax, kualitas identitas semakin penting. Coretax mengintegrasikan berbagai proses seperti bukti potong, faktur pajak, pelaporan, pembayaran, dan profil Wajib Pajak. Data yang salah di master tidak berhenti sebagai salah ketik. Ia bisa mengalir ke dokumen pajak dan rekonsiliasi berikutnya.

Vendor master yang bersih membuat pajak lebih otomatis.

Vendor master yang kotor membuat automation memperbanyak kesalahan.

NPWP bukan satu-satunya field

Tim procurement sering merasa pekerjaan selesai ketika vendor menyerahkan NPWP.

Belum.

Perusahaan perlu mengetahui identitas pajak yang cukup untuk transaksi yang benar-benar dilakukan.

Minimal, vendor master sebaiknya mempunyai:

nama legal vendor,
NPWP atau identitas perpajakan yang relevan,
alamat,
status PKP,
jenis badan atau orang pribadi,
negara domisili,
jenis transaksi utama,
kategori barang atau jasa,
status afiliasi,
dokumen pendukung,
dan tanggal terakhir validasi.

Untuk cabang atau lokasi tertentu, NITKU juga dapat menjadi informasi penting dalam administrasi perpajakan.

DJP menjelaskan bahwa NITKU berfungsi sebagai identitas tempat kegiatan usaha dalam sistem administrasi yang terpusat. Kewajiban utama seperti pembuatan bukti potong dan faktur menggunakan NPWP pusat, tetapi NITKU tetap digunakan sebagai bagian data untuk membedakan tempat kegiatan usaha.

Artinya, perusahaan multi-site sebaiknya tidak menyederhanakan semua vendor hanya menjadi satu nomor tanpa memperhatikan lokasi transaksi yang relevan.

Nama legal harus sama dengan identitas pajak

Masalah klasik terlihat sederhana.

Di purchase order tertulis “ABC Consulting”.

Di invoice tertulis “PT ABC Konsultan Indonesia”.

Di NPWP tertulis nama lain karena perusahaan pernah berubah nama.

Di rekening bank menggunakan nama lama.

Di Coretax, identitas mengikuti data yang terdaftar.

Kalau perbedaan tidak diselesaikan di awal, AP dan tax harus menebak apakah seluruh dokumen berasal dari pihak yang sama.

Vendor onboarding perlu mempunyai identity validation.

Jangan hanya mengunggah foto kartu NPWP ke folder.

Pastikan nama, nomor, dan status sesuai dengan data yang berlaku.

Untuk orang pribadi, penggunaan NIK sebagai NPWP sejak implementasi administrasi baru juga membuat validitas identitas perlu diperhatikan.

DJP bahkan menyediakan mekanisme validasi dan registrasi NIK secara massal pada konteks tertentu karena identitas yang tidak tepat dapat mengganggu pembuatan bukti potong.

Pesannya jelas: identitas perpajakan adalah data operasional, bukan arsip statis.

Status PKP memengaruhi proses invoice

Vendor yang berstatus PKP mempunyai konsekuensi PPN berbeda dari vendor yang bukan PKP.

Karena itu, status PKP harus tersedia di master dan ditinjau secara berkala.

Masalah muncul ketika procurement mengaktifkan vendor berdasarkan data lama.

Vendor dulu belum PKP, sekarang sudah PKP.

Atau vendor yang sebelumnya aktif sudah mengalami perubahan status.

Jika master tidak diperbarui, AP dapat memperlakukan invoice dengan salah, tax team dapat terlambat memeriksa faktur, dan rekonsiliasi PPN menjadi lebih berat.

Coretax juga mengelola profil PKP dan pembuatan faktur pajak. PER-19/PJ/2025 memperbarui aspek administrasi PKP dalam lingkungan Coretax.

Bagi perusahaan, implikasinya sederhana: jangan menyimpan status PKP sebagai informasi sekali isi selamanya.

Berikan review date.

Jenis jasa adalah field paling menentukan

Satu vendor dapat menjual lebih dari satu hal.

Vendor IT dapat menjual laptop, lisensi software, implementasi, maintenance, cloud service, dan training.

Vendor marketing dapat menjual media placement, creative production, event, influencer management, dan research.

Vendor logistik dapat menagih freight, warehousing, customs handling, dan jasa administrasi.

Kalau vendor master hanya mempunyai satu kategori “IT vendor” atau “marketing vendor”, tax engine tidak mempunyai cukup informasi.

Withholding ditentukan berdasarkan sifat pembayaran, bukan nama vendor.

Karena itu, perusahaan perlu memisahkan vendor identity dan transaction tax classification.

Satu vendor boleh memiliki beberapa tax treatment tergantung item.

Purchase order line harus membawa kategori transaksi yang cukup detail.

Tax master kemudian memetakan kategori tersebut ke tax code.

Ini jauh lebih aman daripada membuat satu tax code permanen per vendor.

Kontrak harus menjadi sumber klasifikasi

Invoice sering memakai deskripsi pendek.

“Professional fee”.

“Service charge”.

“Monthly support”.

Deskripsi seperti itu tidak cukup untuk menentukan pajak.

Tax team perlu mengetahui substansi berdasarkan kontrak atau statement of work.

Apa yang benar-benar dilakukan vendor?

Apakah ada lisensi?

Apakah vendor menyediakan tenaga kerja?

Apakah terdapat sewa?

Apakah ada reimbursement?

Apakah jasa dilakukan di Indonesia atau luar negeri?

Apakah ada material barang?

Apakah fee fixed atau berdasarkan penggunaan?

Vendor tax master sebaiknya mempunyai link ke contract repository atau setidaknya contract ID.

Ketika reviewer membuka transaksi material, ia bisa menemukan dasar klasifikasi tanpa mencari email lama.

Vendor luar negeri membutuhkan field tambahan

Vendor asing membawa lapisan baru.

Negara domisili.

Certificate of residence.

Treaty eligibility.

Permanent establishment risk.

Jenis jasa.

Lokasi pelaksanaan jasa.

Beneficial ownership jika relevan.

Royalty atau intellectual property element.

PPN atas pemanfaatan jasa atau barang tidak berwujud dari luar daerah pabean.

Satu field “foreign vendor = 20%” terlalu kasar dan berbahaya.

PPh Pasal 26 dapat mempunyai perlakuan yang berbeda tergantung jenis penghasilan dan apakah treaty berlaku.

Treaty juga tidak boleh diterapkan hanya karena vendor berasal dari negara yang mempunyai P3B dengan Indonesia.

Dokumen dan persyaratan harus terpenuhi.

Vendor master bisa menyimpan treaty review status:

not reviewed,
domestic rate,
treaty eligible,
treaty document expired,
atau special review required.

Dengan begitu, treasury tahu transaksi mana yang tidak boleh dibayar sebelum tax clearance.

Surat Keterangan juga perlu masa berlaku dan konteks

Beberapa vendor dapat mempunyai dokumen yang memengaruhi cara pemotongan, seperti Surat Keterangan berdasarkan rezim tertentu.

Dokumen tersebut tidak boleh hanya diunggah lalu dilupakan.

Master perlu mencatat:

jenis dokumen,
nomor,
tanggal,
periode berlaku,
jenis transaksi yang dicakup,
dan status validasi.

Jika vendor menyerahkan dokumen untuk satu badan tetapi invoice berasal dari badan lain dalam grup, jangan memakai dokumen secara otomatis.

Kalau dokumen kedaluwarsa, tax treatment perlu ditinjau.

Automation membutuhkan expiry alert.

Related party flag harus terlihat sejak awal

Transaksi afiliasi sering baru diketahui ketika tim menyusun transfer pricing documentation.

Itu terlalu terlambat.

Vendor master harus mempunyai related party indicator.

Jika ya, sistem dapat memicu kontrol tambahan:

intercompany agreement,
pricing policy,
benefit evidence,
cost allocation,
withholding,
treaty,
dan documentation threshold.

Perusahaan juga dapat membedakan vendor yang dimiliki pemegang saham, direksi, atau pihak dengan hubungan tertentu sesuai definisi perpajakan yang berlaku.

Related party flag bukan hanya untuk perusahaan multinasional.

Grup domestik pun perlu mengidentifikasi hubungan istimewa.

Jangan biarkan rekening bank mengalahkan identitas pajak

Fraud control sering fokus pada perubahan rekening.

Tax control perlu memastikan rekening pembayaran konsisten dengan pihak yang bertransaksi.

Situasi seperti ini perlu review:

invoice dari PT A,
NPWP PT A,
tetapi pembayaran diminta ke rekening PT B.

Bisa saja ada alasan legal yang sah, misalnya assignment atau treasury arrangement.

Tetapi alasan tersebut harus didokumentasikan.

Kalau perusahaan membayar pihak berbeda tanpa mengetahui hubungan dan dasar kontraknya, bukti transaksi menjadi lebih lemah.

Vendor master perlu mempunyai approved bank account dan workflow perubahan.

Tax dan fraud control dapat memakai data yang sama.

Negative testing lebih penting daripada review transaksi yang sudah benar

Setiap bulan, tax team sebaiknya tidak hanya melihat vendor yang sudah mempunyai tax code.

Cari yang tidak mempunyai tax code.

Ambil akun jasa.

Filter vendor baru.

Cari transaksi tanpa withholding.

Cari invoice dengan status PKP tidak jelas.

Cari foreign vendor tanpa treaty status.

Cari vendor related party tanpa intercompany agreement.

Ini negative testing.

Tujuannya menemukan transaksi yang lolos dari classification process.

Kalau hanya mereview transaksi yang sudah diberi label pajak, perusahaan tidak akan menemukan apa yang sejak awal tidak diberi label.

Vendor onboarding harus mempunyai tax gate

Proses ideal kira-kira seperti ini.

Procurement mengajukan vendor.

Vendor menyerahkan identitas dan dokumen.

Master data memvalidasi.

Tax menentukan profile atau rule yang relevan.

Vendor aktif.

PO dibuat dengan transaction category.

Invoice masuk.

Sistem menerapkan tax treatment.

AP memproses.

Tax mereview exception.

Tidak semua vendor perlu review manual mendalam.

Vendor barang rutin dengan data lengkap dapat diproses otomatis.

Vendor asing, related party, professional service material, property, financing, atau transaksi tidak biasa dapat masuk enhanced review.

Risk based lebih efisien daripada memaksa tax memeriksa semua vendor dengan intensitas sama.

Jangan membuat master terlalu kompleks sampai tidak dipakai

Vendor tax master gagal jika membutuhkan lima puluh field yang tidak pernah diperbarui.

Mulai dari data yang benar-benar memengaruhi pajak.

Identity.

PKP.

Residence.

Transaction type.

Related party.

Treaty status.

Document expiry.

Tax code rule.

Review owner.

Last review date.

Kemudian tambah field jika bisnis membutuhkan.

Data quality lebih penting daripada jumlah field.

Satu field NPWP yang 99,9 persen benar lebih berguna daripada dua puluh field yang setengah kosong.

KPI vendor master harus mengukur exception

CFO tidak perlu melihat seluruh vendor.

Dashboard dapat menampilkan:

jumlah vendor aktif tanpa NPWP valid,
vendor dengan status PKP belum diverifikasi,
foreign vendor tanpa treaty review,
related party tanpa agreement,
dokumen yang akan kedaluwarsa,
invoice yang memerlukan manual tax override,
dan nilai transaksi dengan tax exception.

Kalau angka exception turun, control membaik.

Kalau manual override terus meningkat, master tidak bekerja.

Vendor tax master mengubah tax closing

Tanpa master yang bersih, tax closing dipenuhi pertanyaan transaksi satu per satu.

Dengan master yang baik, sebagian besar transaksi rutin sudah diklasifikasikan sebelum invoice.

Tax team kemudian fokus pada exception dan transaksi material.

Itulah tujuan sebenarnya.

Bukan menghapus judgment tax.

Tetapi memastikan judgment digunakan pada transaksi yang memang membutuhkan judgment.

NPWP yang benar membantu identitas.

Status PKP membantu PPN.

Jenis jasa membantu withholding.

Residence membantu cross-border tax.

Related party flag membantu transfer pricing.

Dokumen expiry membantu treaty dan fasilitas.

Semua itu harus tersedia sebelum invoice menjadi masalah.

Kalau perusahaan menunggu invoice untuk mulai bertanya siapa vendor dan apa yang dibeli, sebenarnya proses pajak sudah terlambat satu tahap.