Satu vendor dapat terlihat sederhana di sistem account payable. Ada satu nama, satu nomor vendor, dan beberapa invoice. Di meja tax, vendor yang sama bisa menghasilkan tiga persoalan sekaligus: faktur pajak masukan tidak cocok, bukti potong belum selesai, dan biaya pada ledger tidak dapat direkonsiliasi dengan komponen tagihan.
Keadaan ini sering dianggap kebetulan. Tim lalu memperbaiki setiap dokumen secara terpisah. Faktur pajak dikejar ke vendor, bukti potong dibuat ulang, dan jurnal disesuaikan. Bulan berikutnya masalah kembali muncul karena sumbernya bukan tiga kesalahan mandiri. Sumbernya adalah satu aliran transaksi yang dilihat AP dan tax melalui data, waktu, serta definisi selesai yang berbeda.
AP berorientasi pada invoice yang valid, approval bisnis, jatuh tempo, dan pembayaran. Tax perlu memahami siapa penerima, apa transaksi sebenarnya, kapan peristiwa pajak terjadi, bagaimana nilai dipecah, dan dokumen apa yang menyertainya. Tanpa titik sinkronisasi, satu invoice yang lolos kontrol AP bisa membawa beberapa error ke proses pajak.
Masalah pertama: identitas vendor tidak tunggal
Dalam master vendor mungkin tercatat nama dagang. Kontrak memakai nama badan. Faktur pajak menampilkan identitas pusat, sedangkan invoice dikirim oleh cabang. Payment instruction mengarah ke rekening yang dikelola grup. AP dapat memproses selama beneficiary dan approval sesuai. Tax perlu memastikan identitas pada dokumen berhubungan dengan pihak yang benar-benar menyerahkan barang atau jasa serta menerima penghasilan.
Per Agustus 2026, administrasi pajak menggunakan format identitas yang telah berkembang bersama Coretax DJP, termasuk NPWP 16 digit dan NITKU untuk konteks tempat kegiatan usaha. DJP menyediakan informasi mengenai status serta kategori wajib pajak melalui profil Coretax. Namun perusahaan tidak boleh mengubah data vendor hanya berdasarkan screenshot atau permintaan email. Perubahan perlu didukung dokumen, divalidasi, disetujui, dan diberi tanggal efektif.
Jika identitas salah sejak onboarding, dampaknya menyebar. Faktur pajak dapat memuat data yang tidak sesuai. Bukti potong mengarah kepada penerima yang keliru. Rekonsiliasi vendor memecah satu pihak menjadi beberapa record atau menggabungkan pihak berbeda. Satu error master kemudian terlihat sebagai tiga isu pajak.
Masalah kedua: satu invoice memuat beberapa cerita
Vendor mengirim tagihan Rp500 juta dengan deskripsi “project services”. Di balik angka itu mungkin ada fee profesional, lisensi, perjalanan, pembelian barang, serta reimbursement pihak ketiga. AP melihat satu approved invoice. Tax membutuhkan pemisahan berdasarkan substansi, kontrak, dan bukti.
Jika seluruh nilai dipetakan ke satu akun dan satu tax code, perlakuan PPh dan PPN dapat salah. Sebaliknya, memecah berdasarkan nama baris invoice tanpa membaca hubungan kontraktual juga berisiko. Istilah “reimbursement” pada invoice tidak otomatis membuktikan bahwa suatu komponen harus diperlakukan terpisah. Siapa menanggung biaya, atas nama siapa dokumen dasar diterbitkan, apakah terdapat markup, dan bagaimana kewajiban vendor dijelaskan perlu diperiksa.
AP dan tax membutuhkan invoice decomposition rule. Untuk jenis tagihan campuran, vendor wajib memisahkan komponen dan melampirkan bukti yang ditetapkan. Purchase order serta contract template harus mendukung pemisahan tersebut. Jika desain kontrak hanya menyebut satu lump-sum fee, tax tidak dapat menciptakan substansi baru setelah pembayaran.
Masalah ketiga: waktu proses tidak bertemu
AP bekerja menuju payment run. Tax bekerja menuju masa pajak. Satu invoice diterima pada akhir bulan, dibukukan sebagai biaya, dibayar awal bulan berikutnya, dan dokumen vendor datang kemudian. Tanpa aturan cut-off, masing-masing fungsi memasukkan transaksi ke periode yang berbeda.
Masalah waktu juga muncul ketika invoice di-block lalu dilepas setelah review, atau ketika pembayaran dilakukan lebih awal untuk menjaga pasokan. AP dapat mengubah status tanpa memicu notifikasi ke tax. Tax kemudian memakai extract lama dan kehilangan transaksi.
Sinkronisasi membutuhkan event, bukan sekadar jadwal kirim file. Event dapat berupa vendor approved, invoice posted, payment proposed, payment released, tax document received, serta transaction corrected. Setiap event yang relevan harus menghasilkan perubahan status atau data yang dapat dibaca fungsi berikutnya. Jika integrasi sistem belum tersedia, exception report harian atau mingguan dapat menjadi jembatan sementara.
Tiga masalah yang saling mengunci
Ambil ilustrasi vendor konsultasi yang juga menagihkan lisensi perangkat lunak dan perjalanan. Data NPWP pada master lama. Invoice hanya memiliki satu baris. AP membayar nett berdasarkan catatan kontrak, tetapi tax belum melihat rinciannya.
Pertama, bukti potong berisiko dibuat dengan identitas lama dan dasar yang tidak jelas. Kedua, faktur pajak masukan mungkin tidak cocok dengan entity atau nilai yang dipahami perusahaan. Ketiga, jurnal biaya tidak memisahkan komponen, sehingga rekonsiliasi antara invoice, tax document, dan ledger menghasilkan selisih.
Memperbaiki bukti potong saja tidak menyelesaikan faktur. Mengganti faktur tidak menjelaskan jurnal. Mengoreksi jurnal tidak memperbaiki master. Tim harus kembali ke akar yang sama: identitas, kontrak, struktur nilai, serta timeline transaksi.
Bangun vendor tax profile
Master vendor operasional biasanya menyimpan data pembayaran. Tambahkan vendor tax profile yang proporsional dengan risiko. Isinya dapat mencakup nama legal, identitas pajak, negara domisili, status yang relevan, lokasi usaha, jenis barang atau jasa, pihak kontrak, pola invoice, perlakuan pajak yang telah direview, dokumen pendukung, tanggal review, dan owner.
Profile bukan keputusan permanen untuk semua transaksi. Vendor yang sama dapat menyediakan objek berbeda. Karena itu, profile harus membantu routing, bukan menggantikan penilaian invoice. Misalnya, sistem menandai bahwa vendor biasanya memberi jasa, tetapi invoice berisi pembelian aset sehingga perlu review.
Perubahan profil harus memiliki maker dan approver. Field sensitif seperti identitas, bank, negara, atau status pajak perlu kontrol lebih tinggi. Gunakan effective date agar transaksi historis tidak otomatis dibaca dengan data baru.
Satu pre-payment gate bersama
Sebelum payment release, AP dan tax perlu sepakat pada kontrol minimum. AP membuktikan invoice, approval, kontrak, penerimaan barang atau jasa, serta data vendor. Tax menentukan status review dan kebutuhan dokumen. Treasury hanya menerima payment proposal yang membawa status jelas.
Gate tidak harus membuat tax menyetujui setiap invoice. Perusahaan dapat memakai risk-based routing. Transaksi rutin dengan profile valid dan tax code stabil bergerak otomatis. Vendor baru, nilai material, kontrak nett, pembayaran luar negeri, transaksi campuran, afiliasi, atau perubahan master masuk review.
Routing tersebut perlu mempunyai alasan yang dapat diuji. Jangan memberi label “rutin” hanya karena vendor sering dibayar. Uji apakah scope kontrak berubah, nilai melonjak, invoice memakai akun baru, atau dokumen berasal dari entitas lain. Sistem dapat membandingkan transaksi dengan pola historis dan memunculkan anomali. Tax reviewer kemudian menilai exception, bukan membaca ulang seluruh populasi.
AP juga perlu mendapat reason code yang mudah dipahami. Status “tax hold” tanpa penjelasan akan mendorong tim mencari jalan pintas. Gunakan alasan spesifik seperti identitas belum valid, komponen invoice belum terpisah, kontrak tidak tersedia, treatment menunggu keputusan, atau dokumen pajak tidak cocok. Sertakan data yang diminta dan target respons.
Exception tetap boleh dibayar jika decision owner menyetujui berdasarkan urgensi dan risiko. Namun pengecualian harus mencatat alasan, dampak, pemilik tindak lanjut, dan tanggal penyelesaian. Daftar “urgent payment” tanpa post-review hanya menjadi jalur permanen untuk melewati kontrol.
Rekonsiliasi empat populasi
Untuk vendor berisiko, rekonsiliasi sebaiknya mempertemukan empat populasi: invoice AP, payment bank, ledger, serta dokumen pajak. Gunakan vendor ID dan transaction ID yang konsisten. Total saja tidak cukup karena kesalahan dapat saling menutup.
Hasil pemeriksaan perlu menunjukkan invoice belum dibayar, pembayaran tanpa invoice, jurnal tanpa referensi, faktur pajak yang belum dipasangkan, bukti potong belum tersedia, nilai berbeda, dan identitas tidak cocok. Setiap exception mempunyai owner sesuai sumbernya. Tax tidak otomatis menjadi pemilik data kontrak atau bukti penerimaan jasa.
Tambahkan ageing berdasarkan jenis masalah. Item menunggu vendor mempunyai jalur berbeda dari item menunggu accounting correction. Dengan begitu, dashboard tidak hanya menunjukkan jumlah backlog, tetapi tempat proses tersumbat.
Rapat 20 menit yang lebih berguna
AP dan tax tidak memerlukan rapat panjang untuk membahas semua invoice. Mereka memerlukan exception huddle pada periode kritis. Daftarnya dibatasi pada vendor baru, transaksi material, data berubah, dokumen belum lengkap, nilai tidak cocok, dan payment yang mendekati cut-off.
Setiap item dijawab dengan format singkat: fakta, risiko, keputusan yang dibutuhkan, owner, dan target. Hindari diskusi interpretasi melalui potongan chat tanpa kontrak. Jika isu membutuhkan penelaahan, pindahkan ke jalur khusus dan jangan menahan semua populasi.
Ukuran keberhasilan bersama dapat mencakup persentase payment proposal dengan data lengkap, jumlah invoice yang dikembalikan karena isu pajak, waktu penyelesaian exception, koreksi dokumen setelah pembayaran, serta vendor complaint. Jika KPI AP hanya on-time payment dan KPI tax hanya on-time filing, keduanya dapat terlihat sukses sementara pekerjaan saling dilempar.
Satu metrik lain layak diperhatikan: first-time-right rate. Berapa persen transaksi selesai tanpa permintaan ulang data, pembetulan dokumen, jurnal ulang, atau keluhan vendor? Angka ini memaksa kedua tim melihat kualitas end-to-end. Tingkat pembayaran tepat waktu tetap dijaga, tetapi tidak boleh dicapai dengan memindahkan pekerjaan rusak ke bulan berikutnya.
Pada akhir masa, pilih beberapa transaksi yang lolos jalur otomatis dan buktikan bahwa klasifikasinya memang benar. Kontrol ini menangkap risiko rule yang salah konfigurasi. Otomatisasi dapat mengulang kesalahan ribuan kali dengan rapi, sehingga review desain rule sama pentingnya dengan review exception.
Ketika masalah sudah terjadi
Untuk vendor dengan tiga isu sekaligus, hentikan perbaikan parsial. Susun satu transaction dossier berisi master vendor beserta riwayat perubahan, kontrak, purchase order, invoice, bukti penerimaan, payment, jurnal, faktur pajak, bukti potong, dan korespondensi relevan. Buat timeline dan pisahkan fakta dari asumsi.
Tim yang kompeten kemudian menilai kebutuhan koreksi sesuai ketentuan terbaru. Prosedur Coretax, status dokumen, serta konsekuensi setiap tindakan perlu diverifikasi melalui panduan resmi DJP dan regulasi yang berlaku. Jangan membatalkan atau mengganti dokumen hanya untuk membuat report cocok tanpa memahami akibatnya.
Satu vendor bisa punya tiga masalah karena perusahaan memecah satu transaksi menjadi beberapa antrean tanpa pengenal dan ownership bersama. Sinkronkan identitas, struktur invoice, event, serta rekonsiliasi. Setelah itu, AP tidak perlu menjadi tax specialist dan tax tidak perlu menjadi payment clerk. Keduanya cukup melihat transaksi yang sama melalui data yang dapat dipertanggungjawabkan.
Bacaan dan rujukan terkait di ePajak.or.id
- Kategori: Pajak
- Topik: Data Wajib Pajak
- Entitas: Tax Compliance
- Topik: PPN Dan Faktur Pajak
- Indeks: PPN Faktur Pajak
- Artikel terkait: Vendor Sudah Dibayar, Bukti Potong Belum Beres: Risiko operasional yang sering dianggap kecil
- Artikel terkait: Faktur Fiktif dan Vendor Bermasalah: Prosedur onboarding vendor sebagai garis pertahanan pertama
