Master vendor jarang masuk agenda direksi sampai pembayaran salah, vendor marah, atau audit menemukan dokumen yang tidak dapat dipasangkan. Selama transfer bank berhasil, tabel vendor dianggap urusan administrasi. Padahal setiap keputusan pajak atas pembelian bertumpu pada jawaban dasar: kita bertransaksi dengan siapa, dalam kapasitas apa, di lokasi mana, dan berdasarkan data yang berlaku pada tanggal transaksi.
Master yang berantakan membuat jawaban itu berubah tergantung file mana yang dibuka. Sistem procurement menyimpan nama dagang, ERP memakai singkatan, kontrak mencantumkan nama badan, faktur pajak membawa identitas berbeda, dan bank account berada pada entitas grup. Tax lalu diminta “cocokkan saja” karena barang atau jasa sudah diterima.
Ini bukan sekadar masalah data bersih. Master vendor adalah control layer yang memengaruhi pemotongan PPh, pengelolaan PPN masukan, pembayaran, rekonsiliasi, dan bukti bahwa perusahaan memahami lawan transaksinya.
Gejala yang sering dinormalisasi
Duplikasi adalah gejala paling mudah terlihat. Satu vendor memiliki tiga ID karena dibuat oleh unit berbeda. Nama berbeda sedikit, nomor rekening sama, atau NPWP baru ditambahkan pada record baru tanpa menutup record lama. Invoice dan pembayaran kemudian tersebar, sehingga volume transaksi vendor tidak terlihat utuh.
Gejala berikutnya adalah field penting berada di kolom catatan bebas. Staf menulis “NPWP baru”, “pakai pusat”, atau “jangan potong” tanpa dokumen, tanggal efektif, dan approver. Informasi tersebut tidak dapat divalidasi otomatis dan mudah hilang ketika staf berganti.
Ada pula record payee yang disamakan dengan supplier. Dalam beberapa model, pihak yang menerima pembayaran dapat berbeda karena collection agent, platform, atau arrangement tertentu. Perbedaan ini tidak otomatis salah, tetapi harus dijelaskan oleh kontrak dan approval. Mengganti nama beneficiary agar lolos bank tanpa menilai hubungan legal menciptakan risiko baru.
Terakhir, vendor inactive tetap dipakai kembali tanpa refresh. Identitas, status, alamat, lokasi, atau struktur bisnis dapat berubah selama jeda. Sistem menganggap record lama terpercaya karena pernah lolos onboarding bertahun-tahun lalu.
Bagaimana PPh ikut salah
Pemotongan PPh membutuhkan identifikasi penerima penghasilan dan karakter transaksi. Jika master tidak membedakan orang pribadi dengan badan, domestik dengan luar negeri, atau pihak independen dengan afiliasi, routing review dapat keliru.
Satu vendor juga dapat memberikan lebih dari satu jenis barang atau jasa. Master profile hanya memberi sinyal, bukan menentukan perlakuan setiap invoice. Namun tanpa profile, invoice rutin dan transaksi tidak biasa masuk jalur sama. Staf cenderung memakai tax code terakhir karena terlihat berhasil pada pembayaran sebelumnya.
Identitas yang salah dapat mengalir ke bukti potong. Nilai pemotongan mungkin benar, tetapi dikaitkan dengan pihak yang tidak tepat. Bila data baru diterima setelah pembayaran, koreksi menjadi lebih rumit dan vendor kesulitan merekonsiliasi jumlah bersih.
Untuk penerima luar negeri, country of residence, tax identification, status dokumen domisili, periode berlaku, serta fakta penerima penghasilan menjadi penting. Treaty benefit tidak dapat dijadikan default hanya karena vendor berkantor di negara mitra. Ketentuan terkini, termasuk PMK 112 Tahun 2025 mengenai tata cara penerapan Persetujuan Penghindaran Pajak Berganda, perlu dibaca untuk transaksi relevan.
Bagaimana PPN ikut terdampak
Faktur pajak masukan harus dapat dikaitkan dengan pembeli dan transaksi yang benar. Bila nama atau identitas pada master tidak cocok, AP mungkin memposting invoice ke vendor record yang salah, sedangkan dokumen pajak muncul di profil yang berbeda. Tim kemudian menganggap faktur belum diterima atau membuat mapping manual.
Coretax DJP meningkatkan kedekatan data antarpihak. Faktur yang diterbitkan dan berstatus sesuai dapat terlihat oleh lawan transaksi. Kemudahan ini tidak memperbaiki master internal secara otomatis. Perusahaan masih harus memasangkan dokumen sistem pajak dengan invoice, purchase order, penerimaan barang atau jasa, serta ledger.
Lokasi usaha juga tidak boleh disepelekan. Dengan penggunaan NPWP 16 digit dan NITKU dalam administrasi, perusahaan perlu memahami hubungan pusat serta lokasi kegiatan usaha yang relevan. Jangan menganggap NITKU hanya tambahan digit yang dapat diisi oleh AP tanpa governance.
Jika vendor mengirim faktur dengan identitas yang berbeda dari kontrak atau invoice, jangan langsung meminta penggantian. Verifikasi siapa sebenarnya melakukan penyerahan dan apakah master perusahaan yang justru salah. Koreksi harus mengikuti fakta, bukan preferensi agar matching menjadi mudah.
Rekonsiliasi berubah menjadi pekerjaan detektif
Master yang baik memberi kunci untuk menghubungkan purchase order, invoice, payment, ledger, bukti potong, dan faktur pajak. Jika satu vendor memiliki banyak ID tanpa parent linkage, tim harus mencocokkan nama, nominal, dan tanggal secara manual. Ini rentan salah pada vendor dengan transaksi berulang.
Duplikasi juga dapat menyembunyikan threshold internal. Total pembelian per vendor terlihat kecil karena terpecah. Review kontrak, related party, konsentrasi supplier, atau approval nilai mungkin tidak terpicu. Di sisi lain, dua vendor berbeda dapat keliru digabung karena nama mirip.
Rekonsiliasi total tidak menyelesaikan masalah ini. Perusahaan memerlukan canonical vendor ID serta relationship map. Record lama tidak selalu harus dihapus, karena dibutuhkan untuk histori. Namun status, pengganti, tanggal efektif, dan alasan penutupan harus jelas.
Anatomi master yang sehat
Tidak ada daftar field yang universal, tetapi desain umumnya mempunyai beberapa kelompok.
Identitas legal mencakup nama resmi, bentuk entitas, identitas pajak, negara, alamat, dan dokumen pendukung. Struktur organisasi mencakup parent, afiliasi, cabang atau lokasi, serta hubungan dengan beneficiary bila berbeda. Data transaksi mencakup kategori barang atau jasa, currency, payment term, dan contract owner. Data pajak mencakup sinyal status yang relevan, dokumen, periode berlaku, tax review flag, serta tanggal review. Governance mencakup maker, approver, tanggal dibuat, tanggal efektif, alasan perubahan, dan sumber.
Jangan mengumpulkan data tanpa tujuan. Field yang tidak pernah divalidasi atau dipakai hanya menambah ilusi kontrol. Untuk setiap field, tetapkan sumber, format, owner, kapan wajib, serta tindakan jika kosong.
Pisahkan pula data yang boleh diubah oleh vendor melalui portal dari data yang membutuhkan verifikasi internal. Nomor rekening, identitas pajak, dan nama legal memerlukan kontrol lebih tinggi daripada alamat korespondensi. Perubahan beberapa field sekaligus layak mendapat enhanced review karena dapat menandakan fraud atau restrukturisasi.
Onboarding adalah kontrol pajak pertama
Ketika vendor dibuat, perusahaan sudah dapat menangkap sebagian besar informasi yang tax perlukan. Procurement atau vendor management mengumpulkan dokumen. Legal memastikan contracting party. AP menilai data pembayaran. Tax menetapkan field serta risk flag. Information security menilai cara penyimpanan.
Sebelum aktivasi, jalankan duplicate check dengan beberapa kunci: identitas pajak, nama legal, rekening, alamat, email domain, atau parent group. Tidak satu pun kunci selalu sempurna. Kombinasi dan human review diperlukan untuk kandidat yang mirip.
Vendor berisiko rendah dapat melalui alur ringan. Vendor luar negeri, afiliasi, transaksi bernilai besar, jasa tidak rutin, atau struktur pembayaran kompleks membutuhkan review lebih dalam. Tujuannya bukan memperlambat onboarding, melainkan menghindari perbaikan setelah invoice jatuh tempo.
Perubahan dan reaktivasi lebih berbahaya daripada pembuatan
Tim biasanya berhati-hati saat membuat vendor, tetapi perubahan mendadak lewat email bisa lolos. Tetapkan change workflow yang memerlukan autentikasi sumber, dokumen, maker-checker, serta pemberitahuan kepada pihak terkait. Untuk perubahan rekening, gunakan verifikasi independen terhadap kontak yang sudah dikenal, bukan nomor pada email perubahan.
Dari sisi pajak, perubahan identitas, domisili, contracting entity, dan lokasi dapat memengaruhi dokumen. Jangan overwrite nilai lama tanpa effective dating. Transaksi sebelum dan sesudah perubahan harus tetap dapat direkonstruksi.
Untuk reaktivasi, lakukan refresh berbasis lamanya tidak aktif dan risiko. Vendor yang berhenti dua tahun tidak boleh otomatis dianggap sama. Cek keberadaan, identitas, bank, kontrak baru, serta tax profile.
Membersihkan tanpa merusak histori
Data cleansing sebaiknya dimulai dengan profiling, bukan delete massal. Ukur record duplikat, field kosong, ID tidak valid, vendor tanpa transaksi, perubahan tanpa approval, serta perbedaan antar sistem. Bentuk cluster kandidat dan tentukan canonical record.
Saat menggabungkan, pertahankan cross-reference dari ID lama. Invoice historis, bukti potong, faktur pajak, dan pembayaran harus tetap dapat ditelusuri. Uji pada sampel sebelum migrasi luas. Backup dan audit trail menjadi wajib karena pembersihan master dapat memengaruhi proses berjalan.
Setelah itu, rekonsiliasi master antarsistem secara berkala. ERP, procurement platform, expense system, tax workspace, dan bank master dapat kembali menyimpang jika integrasi serta ownership tidak dibenahi.
Sebelum cleansing dipindahkan ke produksi, lakukan impact test. Pilih vendor dengan invoice terbuka, vendor dengan dokumen pajak pada masa berjalan, dan vendor dengan beberapa lokasi. Pastikan penggabungan ID tidak mengubah payment instruction, approval history, reporting, atau akses dokumen. Sediakan rollback yang aman dan larang perubahan manual selama cutover kecuali melalui jalur darurat tercatat.
Data steward perlu memeriksa exception setelah migrasi. Record yang gagal dipasangkan tidak boleh otomatis masuk kategori miscellaneous vendor. Temporary vendor memang dapat diperlukan untuk kasus tertentu, tetapi penggunaannya harus dibatasi, disetujui, dan ditinjau. Jika satu temporary ID menampung banyak pihak, jejak pajak serta pembayaran cepat kehilangan identitas.
Ukuran yang pantas dibawa ke manajemen
Jumlah vendor bukan ukuran kualitas. Tampilkan duplicate rate, persentase record dengan field wajib lengkap, perubahan sensitif tanpa bukti, waktu onboarding, invoice tertahan karena master, tax document mismatch, serta pembayaran melalui exception. Kaitkan dengan nilai transaksi agar prioritas tidak ditentukan hanya oleh jumlah record.
Tetapkan data owner yang dapat memutuskan standar dan system owner yang menjalankan perubahan teknis. Tax menjadi stakeholder utama untuk field perpajakan, tetapi kualitas master harus dimiliki lintas fungsi. Jika semua masalah dikirim kepada tax setelah invoice masuk, governance sudah terlambat.
Buat forum data bulanan yang hanya membahas exception material dan tren. Procurement membawa onboarding, AP membawa payment block, tax membawa mismatch dokumen, serta IT membawa kegagalan integrasi. Forum tidak perlu mengoreksi record satu per satu. Tugasnya memutuskan perubahan kontrol yang mencegah pengulangan.
Audit akses juga perlu berjalan. Siapa dapat membuat, mengubah, mengaktifkan kembali, atau menonaktifkan vendor? Apakah orang yang mengubah rekening juga dapat melepas pembayaran? Apakah perubahan massal mempunyai approval terpisah? Master yang lengkap tetapi dapat diubah tanpa kontrol tetap merupakan fondasi yang rapuh.
Master vendor berantakan membuat PPh, PPN, dan ledger menceritakan vendor yang berbeda. Pembersihan satu kali akan membantu, tetapi tidak cukup. Perusahaan memerlukan canonical identity, onboarding berbasis risiko, change control, effective date, dan rekonsiliasi antarsistem. Saat fondasinya benar, tax dapat menilai transaksi. Saat fondasinya salah, tim terbaik pun hanya menebak dokumen mana yang mewakili pihak sebenarnya.
Bacaan dan rujukan terkait di ePajak.or.id
- Kategori: Pajak
- Topik: PPN Dan Faktur Pajak
- Indeks: PPN Faktur Pajak
- Panduan: Panduan PPN Dan Faktur Pajak
- Evidence: Procedure Source Map
- Topik: Data Wajib Pajak
- Evidence: Identity Source Map
- Artikel terkait: Faktur Fiktif dan Vendor Bermasalah: Prosedur onboarding vendor sebagai garis pertahanan pertama
