SPP-TDLN Mengubah Pemungutan PPN Transaksi Digital: Apa yang Perlu Disiapkan Tim Pajak Perusahaan?

Selama ini, pemungutan PPN atas produk digital luar negeri bergantung pada kepatuhan penjualnya. Pemerintah menunjuk sejumlah penyedia sebagai Pemungut PPN PMSE, lalu mengandalkan mereka untuk memungut, menyetor, dan melaporkan. Skema ini berjalan, tetapi otoritas sulit memastikan pemungutan benar-benar terjadi di setiap transaksi.

SPP-TDLN hadir untuk menutup celah itu. Dasar hukumnya berlapis: Perpres 68/2025, lalu aturan pelaksananya, PMK 49/2026, yang ditetapkan 14 Juli 2026 dan berlaku sejak 20 Juli 2026. Pemungutannya sendiri mulai berjalan pada 10 September 2026, diterapkan bertahap dengan bank-bank BUMN sebagai gelombang pertama.

Bagi perusahaan, kehadirannya membawa konsekuensi yang lebih besar daripada sekadar tambahan baris pajak di tagihan.

Pemungutan otomatis tidak dengan sendirinya memberi kepastian pajak. Tim pajak tetap harus memastikan pemungutannya benar, dokumennya memadai, PPN-nya dapat dikreditkan, dan perlakuannya konsisten dengan pencatatan serta pelaporan.

Guna memahami apa yang berubah, di mana risikonya, dan apa yang perlu disiapkan, Mekari Klikpajak bersama Praktisi Pajak dari Botax Consulting Indonesia, Raden Agus Suparman, memberikan insight yang penting untuk dipahami Head of Tax, Tax Director, CFO, Finance Director, Tax Manager, Financial Controller, Internal Audit, dan wajib pajak pada umumnya.

SPP-TDLN adalah Lapisan Pengawasan Baru, Bukan Pengganti PMSE

Sistem Pemungutan Pajak Transaksi Digital Luar Negeri (SPP-TDLN) adalah sistem baru untuk memungut PPN atas transaksi digital luar negeri yang memenuhi kriteria tertentu. 

Hal yang perlu dipahami sejak awal adalah sistem ini tidak menggantikan skema PMSE yang sudah berjalan.

Sebelum adanya SPP-TDLN, pemungutan PPN PMSE benar-benar menggantungkan kepatuhan kepada penyedia produk digital. Setelah adanya SPP-TDLN, pemerintah memiliki sistem pengawasan baru. Jadi ini benar-benar sistem baru, tapi tidak menggantikan sistem sebelumnya. Saya lebih berpendapat bahwa ini alat pengawasan.

Raden Agus Suparman

Praktisi Pajak, Botax Consulting Indonesia

Posisi yang lebih tepat untuk memahami PMSE vs SPP-TDLN adalah melihat keduanya sebagai dua lapisan yang saling melengkapi.

PMSE menangkap merchant yang sudah ditunjuk sebagai pemungut. SPP-TDLN memperluas pengawasan melalui jalur pembayaran, khususnya untuk transaksi digital luar negeri yang PPN-nya belum dipungut lewat skema PMSE.

Latar belakangnya bersifat praktis. Salah satu kelemahan skema PMSE adalah keterbatasan DJP dalam menjatuhkan sanksi administrasi kepada Wajib Pajak luar negeri. 

Hal yang bisa dilakukan otoritas adalah pemblokiran transaksi. Dengan SPP-TDLN, negara memperoleh data pembanding untuk menilai apakah merchant benar-benar patuh.

Data DJP memperlihatkan celah kepatuhan itu secara terukur. Hingga 30 Juni 2026, DJP telah menunjuk 271 pelaku usaha PMSE sebagai pemungut PPN, tetapi baru 236 di antaranya yang benar-benar memungut dan menyetorkan PPN, dengan nilai akumulatif Rp42,01 triliun sejak 2020.

Artinya, sekira 35 entitas yang sudah resmi ditunjuk belum menjalankan kewajibannya. Angka inilah yang menjelaskan mengapa pemerintah merasa perlu membangun lapisan pengawasan berbasis jalur pembayaran.

Setoran PPN PMSE naik konsisten setiap tahun, dari Rp731,4 miliar pada 2020 menjadi Rp10,32 triliun pada 2025. Namun angka ini hanya merefleksikan merchant yang patuh, bukan seluruh transaksi digital luar negeri yang terjadi.

Pasal 5 ayat (1) PMK 49/2026 menegaskan posisi tersebut secara eksplisit: pemungutan melalui SPP-TDLN adalah pemungutan atas transaksi digital luar negeri yang PPN-nya dipungut oleh pihak selain pelaku usaha PMSE yang telah ditunjuk.

Dengan kata lain, SPP-TDLN berfungsi sebagai jaring kedua yang menangkap transaksi lolos dari skema PMSE, bukan penggantinya. Kategori yang selama ini paling sulit dijangkau PMSE adalah pembayaran ke freelancer asing dan langganan perangkat lunak niche.

Ekspektasi pemerintah atas sistem ini juga tidak kecil. Direktur Jenderal Pajak Bimo Wijayanto menyatakan penerapan SPP-TDLN diyakini dapat menaikkan basis pemajakan transaksi digital hingga hampir dua kali lipat dari kisaran Rp8–12 triliun yang berjalan saat ini.

Baca Juga: Sengketa Pajak: Kenapa Hasil Keberatan Ditentukan Dokumen, Bukan Argumen

Cara Kerja SPPP-TDLN: Pemungutan Bergeser ke Jalur Pembayaran

Perubahan paling nyata bagi perusahaan adalah letak titik pemungutannya. Penyelenggara SPP-TDLN menjalankan fungsi infrastruktur, yakni:

• Mengoperasikan sistem
• Melakukan konfirmasi
• Menerima aliran penyetoran sesuai ketentuan regulasi

Pemungutan di lapangan dilakukan oleh penyedia jasa pembayaran.

Penyelenggaranya adalah PT Jalin Pembayaran Nusantara, anak usaha BUMN yang ditugaskan berdasarkan Perpres 68/2025.

Pihak yang memungut di lapangan disebut Penerbit, yakni bank atau lembaga selain bank yang memfasilitasi pembayaran, dan ditunjuk oleh Direktur Jenderal Pajak setelah melalui tahap pengembangan sistem, stabilisasi, dan sandboxing.

Ilustrasi sederhananya seperti ini:

Sebuah perusahaan di Indonesia membeli layanan AI dari penyedia luar negeri, dan penyedia itu bukan Pemungut PPN PMSE.

Bank sebagai penyedia jasa pembayaran melakukan pemungutan setelah memperoleh konfirmasi SPP-TDLN. Tarif yang dipungut adalah 11/111 dari nilai transaksi yang sudah termasuk PPN.

Jika nilai yang dibayarkan Rp1.110.000, maka Rp1.000.000 merupakan nilai transaksi dan Rp110.000 adalah PPN yang dipungut.

Dari sisi waktu, PPN terutang pada saat Penyelenggara SPP-TDLN memberikan konfirmasi kepada Penerbit bahwa transaksi tersebut dikenai PPN.

PPN yang dipungut disetorkan melalui Penyelenggara paling lama tujuh hari sejak konfirmasi, lalu diteruskan ke kas negara.

Artinya, Pajak Pertambahan Nilai (PPN) kini bisa muncul di titik yang selama ini tidak dipantau tim pajak, yakni: rekening koran dan tagihan kartu, bukan hanya invoice dari vendor.

Dua jalur ini berjalan berdampingan. Bagian yang menentukan jalur mana yang berlaku atas sebuah transaksi adalah status entitas hukum supplier pada tanggal transaksi, bukan jenis produknya, dan bukan pula metode pembayarannya.

Apa yang Tidak Otomatis Selesai Meski Pemungutan Sudah Berbasis Sistem?

Di sinilah letak ketegangan utamanya. Sistem memang menyelesaikan masalah pemungutan manual, tetapi tidak menyelesaikan pertanyaan-pertanyaan yang justru paling menentukan:

• Apakah suatu transaksi memang objek PPN?
• Berapa dasar pengenaannya?
• Apakah PPN-nya sudah dipungut melalui kanal lain?

Alasannya terletak pada sifat data yang dibaca sistem pembayaran.

Sistem pembayaran pada dasarnya melihat data pembayaran, bukan substansi hukum transaksinya. Transfer ke luar negeri bisa merupakan pembayaran SaaS, lisensi, jasa profesional, reimbursement, pinjaman, pengembalian dana, atau bahkan transaksi non-objek.

Raden Agus Suparman

Praktisi Pajak, Botax Consulting Indonesia

Transfer dana dan remitansi tidak otomatis menjadi objek PPN. Penegasan ini bukan hanya pendapat praktisi.

PT Jalin Pembayaran Nusantara selaku penyelenggara sistem menyatakan hal yang sama secara resmi: data transfer dana dan remitansi digunakan untuk pemetaan dan analisis transaksi digital luar negeri, dan itu tidak berarti setiap transfer atau remitansi menjadi objek PPN.

Jalin Pembayaran Nusantara  juga menegaskan SPP-TDLN tidak menciptakan jenis pajak baru dan tidak mengubah tarif PPN.

Konsekuensinya bagi perusahaan: kesalahan pemungutan tetap mungkin terjadi, dan beban untuk membuktikan perlakuan yang benar tetap ada di tangan Wajib Pajak.

Baca Juga: Cara Menghitung PPN Penjualan Barang

Petakan Transaksinya Sebelum Menentukan Perlakuan Pajaknya

Sistem PPN Indonesia menganut prinsip destinasi. PPN dikenakan atas konsumsi barang dan jasa di Indonesia, baik berwujud maupun tidak berwujud.

Dalam konteks produk digital, yang menjadi kunci adalah pemanfaatan Barang Kena Pajak tidak berwujud di dalam Daerah Pabean, bukan sekadar fakta bahwa vendornya berada di luar negeri.

Karena itu, langkah pertama bukan menghitung pajaknya, melainkan mengklasifikasikan transaksinya. Klasifikasi minimal yang disarankan:

Dengan klasifikasi ini, perusahaan dapat memisahkan mana yang benar-benar objek PPN dan mana yang bukan, sebelum sistem pembayaran memutuskannya untuk wajib pajak.

Verifikasi Status Pemungut Berdasarkan Entitas Hukum, Bukan Merk

Perpajakan Indonesia menganut prinsip substance over form. Verifikasi status Pemungut PPN PMSE, karena itu tidak boleh dilakukan berdasarkan nama merek (merk), melainkan berdasarkan entitas hukum yang menerbitkan invoice.

Prosedur yang disarankan:

1. Cocokkan nama badan hukum pada invoice atau order confirmation dengan Daftar Pemungut PPN PMSE resmi DJP.
2. Periksa statusnya pada tanggal transaksi, bukan pada tanggal pengecekan.
3. Simpan bukti verifikasi tersebut sebagai bagian dari vendor master.

Daftar DJP menampilkan entitas yang ditunjuk secara spesifik. Misalnya, yang tercantum bukan sekadar “Microsoft”, melainkan beberapa badan hukum Microsoft yang berbeda.

Status ini juga sebaiknya tidak hanya diperiksa saat vendor pertama kali didaftarkan, karena penunjukan dapat berubah, dicabut, atau diperbarui.

Catatan DJP sepanjang 2026 membuktikan bahwa ini bukan kekhawatiran teoretis:

• Pada Maret 2026 terjadi dua penunjukan baru, dua pencabutan (Zendrive Inc. dan Tencent Mobile International Limited), serta satu perubahan data.
• Pada April 2026, HashiCorp dan Perplexity AI ditunjuk, sementara OpenAI LLC justru dicabut sebagai bagian dari penyesuaian administratif.
• Pada Mei 2026, tujuh entitas baru ditambahkan sekaligus, termasuk Kling AI dan Envato.
• Pada Juni 2026, data Lemon Squeezy LLC diperbarui.

Perusahaan yang menyimpan status PMSE sebagai data statis akan salah menilai transaksinya begitu daftar berubah. Pengecekan berkala bukan pilihan, melainkan keharusan.

Dalam lima bulan, DJP melakukan 11 penunjukan baru, 3 pencabutan, dan 2 pembaruan data. Vendor master yang hanya menyimpan status “Ya/Tidak” tanpa tanggal efektif akan tertinggal dari perubahan ini.

Grup Perusahaan Bukan Satu Subjek Pajak

Satu asumsi yang sering keliru dalam pajak pembelian SaaS luar negeri adalah anggapan bahwa PPN dapat dipindahkan antar-entitas dalam satu grup.

Indonesia tidak mengenal konsep entitas grup untuk tujuan ini. Setiap badan hukum adalah subjek pajak tersendiri.

• Untuk PPN PMSE, bukti pungut harus dapat dikaitkan dengan pembeli yang akan mengkreditkan PPN.
• Untuk SPP-TDLN, dokumen pemungutan harus memuat identitas pemanfaat, termasuk nama, alamat atau email, nomor rekening, atau nomor telepon.

Pengkreditan pajak pertambahan nilai (PPN) juga mensyaratkan email atau nomor telepon tertentu telah terdaftar pada administrasi DJP.

Lima Risiko Pajak yang Meningkat Setelah SPP-TDLN

Sebelum SPP-TDLN, pertanyaan utama tim pajak atas belanja digital luar negeri relatif sederhana:

• Apakah PPN-nya sudah dipungut atau belum?

Setelah SPP-TDLN, pertanyaannya bergeser menjadi:

• Apakah pemungutan yang sudah terjadi itu benar?
• Apakah perusahaan mampu membuktikannya?

Pergeseran ini memunculkan risiko baru, bukan karena aturannya lebih rumit, melainkan karena kini ada dua jalur pemungutan yang berjalan bersamaan di atas satu transaksi yang sama.

Lima risiko berikut muncul dari titik lemah yang sama, yakni data transaksi tersebar di sistem yang berbeda dan tidak saling dikaitkan. Kelimanya juga memiliki pola serupa, masalahnya jarang terlihat saat pembayaran dilakukan, dan baru muncul ketika PPN hendak dikreditkan atau ketika transaksi diperiksa.

1. Potensi pemungutan ganda

Skenario yang paling mungkin:

Perusahaan membeli SaaS (Software as a Service) dari entitas asing yang sudah berstatus Pemungut PPN PMSE dan sudah mengenakan PPN di invoice, lalu transaksi dibayar dengan kartu yang terhubung SPP-TDLN.

Bila identifikasi merchant tidak sempurna, kanal pembayaran dapat kembali mengenakan PPN.

Secara hukum kondisi ini seharusnya tidak terjadi, karena Pasal 5 PMK 49/2026 membatasi SPP-TDLN pada transaksi yang pemungutannya dilakukan selain oleh pemungut PMSE yang ditunjuk.

Namun bila tetap terjadi, PMK 49/2026 menyediakan mekanisme pengembaliannya.

Pertanyaan bagaimana perusahaan mencegah double collection PPN karena itu dijawab paling awal di tahap deteksi. Indikator dini yang bisa dipantau:

• Invoice menunjukkan PPN Indonesia, tetapi rekening koran atau tagihan kartu juga menunjukkan komponen PPN.
• Total debet kartu lebih tinggi daripada nilai bruto invoice.
• Muncul descriptor seperti VAT, tax, atau Indonesia VAT di luar nilai yang sudah ditagihkan supplier.
• Vendor sudah tercantum dalam daftar PMSE DJP, tetapi sistem pembayaran masih memperlakukan transaksinya sebagai kandidat SPP-TDLN.

Kategori transaksi yang paling rentan adalah SaaS, cloud, digital advertising, AI subscription, software licence, dan layanan digital yang dipasarkan melalui beberapa entitas hukum atau reseller.

2. Bukti pungut yang tidak dapat dikaitkan

Dokumen ada, tetapi identitas di dalamnya tidak terhubung dengan entitas yang akan mengkreditkan PPN.

3. Kesalahan entitas pembeli

Invoice diterbitkan atas nama PT A, dibayar oleh PT B, sementara pengguna sebenarnya adalah PT C.

4. Ketidakpastian pengkreditan

PPN terpungut, tetapi belum tentu memenuhi syarat untuk dikreditkan.

5. Ketidakkonsistenan antara sistem pajak dan akuntansi

Contoh yang sering ditemukan di lapangan: ERP mencatat software expense Rp100 juta dengan Pajak Masukan Rp11 juta, tetapi invoice ternyata diterbitkan kepada entitas grup lain.

Saldo akuntansi benar secara matematis, namun perlakuan pajaknya salah secara hukum.

Baca Juga: Kesiapan Data Pajak Perusahaan: Insight Compliance dari Tax Manager Perusahaan Ritel Terbesar di Indonesia

Bukti Pungut dan Pengkreditan: Dua Standar yang Perlu Dibedakan

Pertanyaan apakah PPN SPP-TDLN dapat dikreditkan tidak dapat dijawab dengan ya atau tidak.

Jawabannya bergantung pada dua hal yang berbeda:

• kelengkapan dokumen; dan 
• pemenuhan syarat pengkreditan.

A. Standar dokumen untuk pelaporan

Untuk PMSE, bukti pungut dapat berupa commercial invoice, billing, order receipt, atau dokumen sejenis yang menunjukkan pemungutan dan pembayaran PPN.

Agar dapat menjadi dasar Pajak Masukan, identitas pembeli juga harus memenuhi ketentuan:

• nama dan NPWP/NIK;
• email terdaftar; atau
• dilengkapi bukti akun pembeli yang memuat identitas tersebut.

Untuk bukti pungut SPP-TDLN, Pasal 10 PMK 49/2026 mengatur lebih spesifik.

• Dokumen sekurang-kurangnya harus menunjukkan identitas Pihak Lain, merchant, dan pemanfaat, tanggal pemungutan, Nomor Referensi, Dasar Pengenaan Pajak, serta nilai PPN.
• Bill statement dapat berfungsi sebagai dokumen tertentu sepanjang seluruh informasi itu terpenuhi.

Poin ini penting dan sering luput: dokumen pemungutan tersebut dipersamakan kedudukannya dengan Faktur Pajak.

Konsekuensinya, tagihan kartu atau rekening koran yang selama ini diperlakukan tim finance sebagai dokumen administratif kini berpotensi menjadi dokumen perpajakan, dengan syarat kelengkapan data yang tidak bisa ditawar.

B. Syarat pengkreditan

Secara prinsip, hanya Pengusaha Kena Pajak (PKP) yang dapat mengkreditkan Pajak Masukan, dan syarat pengkreditan umum tetap berlaku.

Untuk SPP-TDLN, PMK 49/2026 menyatakan PPN dalam dokumen pemungutan dapat dikreditkan sepanjang email atau nomor telepon yang relevan terdaftar pada administrasi DJP dan ketentuan umum terpenuhi.

Dari sisi waktu, Pajak Masukan dikreditkan pada masa yang sama. Bila belum, ketentuan umum masih memberi ruang sampai tiga Masa Pajak berikutnya, sepanjang belum dibebankan sebagai biaya atau dikapitalisasi.

PPN tidak dapat dikreditkan antara lain:

• Apabila konsumsinya bukan untuk kegiatan usaha yang menghasilkan penyerahan terutang PPN, dokumennya tidak memenuhi syarat.
• Identitas pembelinya salah.
• Pajak Masukan tersebut memang termasuk kategori yang tidak dapat dikreditkan menurut UU PPN.

C. Standar dokumen untuk kesiapan pemeriksaan

Kebutuhan saat audit berbeda dari kebutuhan saat pelaporan. Praktik yang disarankan adalah menyusun satu audit pack per transaksi, berisi:

• kontrak atau order/ToS
• persetujuan pembelian
• Invoice
• bukti status PMSE supplier
• identitas akun
• bukti pembayaran
• rekening koran atau tagihan kartu
• dokumen pemungutan PMSE atau SPP-TDLN
• jurnal akuntansi
• bukti penggunaan oleh perusahaan
• rekonsiliasi ke SPT Masa PPN

Untuk transaksi material, tambahkan:

• tangkapan layar akun langganan
• daftar pengguna, cost center
• penjelasan business purpose

Tujuannya sederhana. Dua atau tiga tahun kemudian, pemeriksa harus tetap dapat memahami siapa membeli apa, dari siapa, untuk siapa, berapa nilainya, bagaimana dibayar, siapa yang memungut PPN, dan di mana PPN itu dilaporkan.

Sudahkah dokumen pajak Anda tersimpan di satu tempat? Menyusun audit pack menjadi jauh lebih ringan ketika bukti pembayaran, dokumen pemungutan, dan catatan jurnal tidak tersebar di folder yang berbeda. Pelajari pengelolaan dokumen pajak di Mekari Klikpajak -> Simpan Arsip Pajak Anda dengan Aman dan Rapi.

Tax Control Framework: Pertanyaan yang Paling Sering Gagal Dijawab

Perusahaan umumnya mampu menjawab pertanyaan kuantitatif. Namun yang sering tidak bisa dijawab justru pertanyaan kualitatif tentang substansi transaksinya.

Hal yang paling berbahaya justru ketika perusahaan dapat menjawab ‘berapa nilainya’, tetapi tidak dapat menjawab ‘transaksinya sebenarnya apa?’ Jangan sampai Wajib Pajak di Indonesia membayar PPN padahal bukan objek PPN PMSE.

Raden Agus Suparman

Praktisi Pajak, Botax Consulting Indonesia

Kerangka kontrol yang relevan untuk konteks SPP-TDLN dapat disusun dalam delapan lapis, masing-masing dengan satu pertanyaan keputusan:

Satu Transaksi, Tiga Sumber Data yang Harus Dicocokkan

Setelah SPP-TDLN, satu transaksi meninggalkan jejak di tiga tempat berbeda:

• Vendor/invoice: merchant, deskripsi, nilai bruto, PPN.
• Bank/pembayaran: merchant descriptor, tanggal, mata uang, nilai settled, PPN SPP-TDLN, nomor referensi.
• Pelaporan pajak: DPP, PPN, masa pajak, identitas Wajib Pajak, status Pajak Masukan.

Ketiganya sering tidak sinkron karena tanggal settlement berbeda dengan tanggal invoice, nilai tukar berbeda, merchant descriptor tidak sama dengan entitas hukumnya, refund terjadi setelah invoice terbit, kartu korporat tercatat atas nama pegawai, dan sistem pajak membutuhkan identitas yang tidak tersedia di ERP.

Oleh karena itu nomor invoice saja tidak cukup sebagai matching key. Solusinya bukan menjadikan salah satu sumber sebagai acuan tunggal.

Namun perusahaan perlu membangun identitas transaksi internal yang menghubungkan purchase order, invoice, vendor, pembayaran, pemungutan pajak, dan SPT.

Urutan rekonsiliasi yang disarankan:

Transaksi hukum → invoice → pembayaran → pemungutan pajak → akuntansi → SPT.

Hal yang pertama harus dipastikan adalah apa transaksi itu sebenarnya. Baru setelah itu dapat dinilai apakah pembayaran dan pajaknya sudah benar.

Ketika data akuntansi dan data pajak berhenti menjadi dua dunia terpisah

Sebagian besar kesulitan di bagian ini lahir dari satu penyebab yang sama: catatan akuntansi dan catatan perpajakan hidup di sistem yang berbeda, lalu dipertemukan secara manual di akhir bulan, biasanya lewat spreadsheet, dan biasanya oleh orang yang berbeda pula.

Integrasi Mekari Jurnal dan Mekari Klikpajak dirancang untuk bekerja dalam satu alur. Transaksi yang tercatat di pembukuan dapat mengalir ke administrasi pajak tanpa harus disalin ulang, sehingga:

• Angka yang dibandingkan berasal dari sumber yang sama. Nilai transaksi, entitas, dan periode tidak lagi bergantung pada ketelitian salin-tempel antar-file.
• Jejak dokumen tetap melekat pada transaksinya. Bukti pembayaran dan dokumen perpajakan tersimpan terhubung dengan catatan jurnalnya, bukan terpisah di folder lain.
• Selisih terlihat lebih awal. Ketidakcocokan antara pembukuan dan pelaporan dapat muncul saat monthly close, bukan saat SPT sedang disusun, apalagi saat pemeriksaan pajak.
• Satu entitas, satu jejak. Untuk grup multi-entitas, pencatatan per badan hukum membantu menjaga agar transaksi tidak tertukar antar-perusahaan.

Sistem tidak menggantikan pertimbangan profesional tim pajak. Hal yang dikerjakannya adalah memastikan data yang menjadi dasar pertimbangan itu lengkap, konsisten, dan dapat ditelusuri kembali.

Lihat bagaimana aplikasi pajak online Mekari Klikpajak dan software akuntansi Mekari Jurnal bekerja bersama mengelola dokumen transaksi dan pajak secara otomatis.

Jadwalkan demo untuk tim finance dan tax Anda sekarang!

Alur Eskalasi Ketika Ditemukan Penyimpangan

Dari berbagai skenario penyimpangan, pola yang paling sering muncul adalah data tidak sinkron dan status supplier yang tidak teridentifikasi sejak awal.

Hal yang berpotensi meningkat setelah SPP-TDLN adalah pemungutan ganda dan refund setelah pemungutan.

Sedangkan hal yang paling sulit diselesaikan adalah kesalahan entitas, karena persoalannya bukan sekadar mengubah jurnal, melainkan menyangkut invoice, pihak penerima jasa, akun pengguna, jejak pembayaran, intercompany charge, hingga pihak yang telanjur mengkreditkan Pajak Masukan.

Alur eskalasi empat tingkat yang disarankan:

1. Deteksi di AP/Treasury. Tim melihat anomali: PPN ganda, merchant asing, selisih jumlah, atau instrumen pembayaran yang tidak semestinya.
2. Validasi pajak. Tim pajak menentukan status PMSE, penerapan SPP-TDLN, taxability, kemungkinan pengkreditan, dan perlakuannya.
3. Remediasi vendor oleh Procurement. Permintaan koreksi invoice, refund, perubahan identitas penagihan, atau klarifikasi merchant.
4. Eskalasi ke Financial Controller/CFO. Dilakukan bila nilainya material, melibatkan banyak entitas, memerlukan pembetulan SPT, atau memiliki eksposur pemeriksaan.

Satu prinsip yang menurut Raden Agus Suparman menjadi inti dari seluruh kerangka ini:

Rencana Kesiapan 30-60-90 Hari

Roadmap berikut adalah praktik tata kelola yang baik, bukan tenggat formal yang diwajibkan PMK 49/2026.

Tujuannya bukan membangun sistem sempurna sejak awal, melainkan memastikan perusahaan lebih dulu mengetahui eksposurnya, lalu menguji apakah datanya bisa direkonsiliasi, dan akhirnya memastikan kontrolnya berjalan konsisten.

30 Hari – Pemetaan dan Baseline

Perusahaan menyusun daftar seluruh transaksi digital lintas negara minimal 6–12 bulan terakhir, daftar vendor beserta entitas hukum dan status PMSE-nya, pemetaan metode pembayaran, serta identifikasi pengguna dan entitas penerima manfaat.

Di akhir hari ke-30, perusahaan idealnya sudah bisa menjawab lima pertanyaan dasar: 

• vendor siapa
• transaksi apa
• dibayar oleh siapa
• siapa yang memungut PPN
• dan entitas mana yang mengkreditkan PPN.

Keluaran konkretnya berupa digital cross-border transaction register, vendor master dengan penanda status PMSE, daftar transaksi kartu korporat maupun kartu pribadi, dan risk heatmap dengan tiga kelompok:

• Hijau: perlakuan jelas dan dokumentasi lengkap.
• Kuning: data atau identitas belum lengkap.
• Merah: indikasi PPN ganda, kesalahan entitas, atau bukti pajak bermasalah.

Target yang realistis bukan 100% sempurna, melainkan sekira 95% transaksi material sudah terpetakan dan seluruh transaksi berisiko tinggi sudah teridentifikasi.

60 Hari – Pengujian Rekonsiliasi

Perusahaan mulai menguji apakah data vendor, akuntansi, pembayaran, dan pelaporan pajak benar-benar saling cocok.

90 Hari – Monitoring dan Stabilisasi Kontrol

Fokus bergeser dari menemukan masalah menjadi memastikan masalah tidak berulang. 

Perusahaan sudah memiliki laporan exception monitoring rutin, antara lain:

• transaksi dengan status PMSE collector sekaligus pemungutan SPP-TDLN
• entitas invoice yang berbeda dari entitas pembayar
• vendor asing tanpa klasifikasi pajak
• transaksi kartu pribadi
• dokumen PPN yang hilang
• dan refund tanpa penyesuaian PPN,

Frekuensinya mengikuti volume transaksi. Untuk perusahaan dengan transaksi digital tinggi, pemantauan idealnya mingguan atau bahkan otomatis harian. Untuk volume rendah, monthly close masih memadai.

Lima kondisi yang diharapkan tercapai di akhir hari ke-90:

1. seluruh vendor digital lintas negara memiliki status pajak;
2. seluruh transaksi memiliki transaction owner;
3. pemungutan ganda dapat dideteksi sebelum SPT;
4. rekonsiliasi akuntansi–pembayaran–pajak sudah menjadi bagian monthly close;
5. dan pengecualian material sudah memiliki jalur eskalasi.

Kesalahan yang Paling Sering Terjadi di Fase Pemetaan

Kesalahan paling umum adalah memulai pemetaan dari daftar vendor, bukan dari substansi transaksi.

Akibatnya satu vendor diberi satu label pajak, padahal satu penyedia teknologi bisa menjual SaaS, lisensi, jasa implementasi, cloud, dukungan teknis, hingga konsultansi, dengan perlakuan pajak yang berbeda-beda.

Kesalahan lain yang kerap muncul:

1. Menggunakan nama merek, bukan entitas hukum, padahal status pemungut PMSE melekat pada entitas hukum.
2. Menganggap semua pembayaran digital ke luar negeri otomatis merupakan objek PPN.
3. Tidak memetakan entitas penerima manfaat, yang menjadi sumber mismatch serius dalam grup multi-entitas.
4. Mengabaikan metode pembayaran, padahal SPP-TDLN sangat terkait dengan jejak pembayaran.
5. Menyimpan status PMSE sebagai “Ya/Tidak” permanen tanpa tanggal efektif.
6. Mengandalkan deskripsi invoice yang terlalu umum seperti subscription atau service fee.
7. Tidak menghubungkan pemetaan vendor dengan dokumen pajaknya.
8. Melewatkan transaksi kecil dan kartu pribadi, yang justru sering menjadi titik buta.

Titik buta terakhir itu punya dasar empiris yang kuat. Riset pengelolaan SaaS menunjukkan unit bisnis kini mengendalikan sekitar 81% belanja SaaS perusahaan, sementara tim IT hanya mengelola langsung sekitar 15%.

Aplikasi yang dibeli lewat mekanisme expense pegawai hanya menyumbang sekitar 3,7% dari total nilai belanja SaaS, tetapi mencakup sekira 45% dari jumlah aplikasinya.

Artinya, mayoritas nama vendor yang harus dipetakan tim pajak justru berada di kelompok bernilai kecil yang paling mudah terlewat, dan pertumbuhan tercepat datang dari aplikasi AI, kategori yang persis menjadi sasaran SPP-TDLN.

Pemetaan yang hanya mengejar nilai transaksi terbesar akan melewatkan hampir separuh vendor yang perlu diklasifikasikan status pajaknya.

9. Tidak menetapkan kepemilikan, sehingga pemetaan berhenti sebagai spreadsheet tanpa penanggung jawab.

Prinsip pengendaliannya dapat diringkas menjadi satu kalimat: jangan mulai dari daftar vendor, mulailah dari daftar transaksi, lalu tarik vendor, pembayaran, pemungutan pajak, dan pelaporan ke satu transaction ID.

Baca Juga: LKPM OSS 2026: Cara Lapor dan Panduan dari Sudut Pandang Perpajakan

Kesimpulan: Kesiapan Tax Team Menghadapi SPP-TDLN

SPP-TDLN memindahkan sebagian beban pemungutan ke sistem, tetapi tidak memindahkan beban pembuktian.

Kepastian pajak tetap bergantung pada kemampuan perusahaan menghubungkan data supplier, transaksi, pembayaran, bukti, akuntansi, dan pelaporan menjadi satu rangkaian yang utuh dan dapat direkonstruksi.

Di titik inilah administrasi pajak yang terpusat menjadi relevan. Mekari Klikpajak dirancang untuk membantu perusahaan menata administrasi perpajakannya dalam satu tempat, menjaga keterlacakan dokumen, merapikan alur pelaporan, dan mendorong konsistensi yang lebih baik antara data keuangan dan data pajak.

Fondasi itulah yang membuat pertanyaan-pertanyaan di setiap lapis kontrol tadi bisa dijawab ketika dibutuhkan, bukan dicari ketika sudah terlambat.

Mulai dari Fondasi Datanya

Tim pajak tidak bisa mengendalikan kapan regulasi berubah. Hal yang bisa dikendalikan adalah seberapa siap datanya ketika perubahan itu datang.

Konsultasi gratis dengan tim Mekari.

Saya Mau Coba Gratis Mekari Klikpajak Sekarang!

Referensi

Datacenter Ortax. “Peraturan Menteri Keuangan No. 49 Tahun 2026”
DDTCNews.”DPP-TDLN Diterapkan Bertahap, Dimulai dari Bank-Bank BUMN”
Pajak.go.id. “Siaran per DJP: Pajak Digital Tembus Rp50,5 Triliun, PPN PMSE dan SIPP jadi Penopang Utama”
Jalin.”Laman Resmi SPP-TDLN”
Zylo. “2026 SaaS Management Index”
Asset Management Global. “SaaS Management in Enterprises”