Ada dua cara buruk menghadapi SP2DK. Cara pertama adalah memperlakukannya seperti vonis, lalu semua orang buru-buru mencari siapa yang salah. Cara kedua adalah menganggapnya “sekadar surat klarifikasi”, kemudian meletakkannya di antrean pekerjaan biasa. Keduanya keliru.
Surat Permintaan Penjelasan atas Data dan/atau Keterangan atau SP2DK merupakan sarana DJP meminta penjelasan atas data atau keterangan dalam kegiatan pengawasan. SP2DK bukan surat ketetapan pajak dan bukan dengan sendirinya pernyataan bahwa pelanggaran telah terbukti. Meski demikian, wajib pajak tetap perlu menanggapinya secara tertib. Panduan layanan DJP yang diperiksa pada Agustus 2026 menyebutkan jangka waktu pemberian tanggapan atau penjelasan paling lama 14 hari.
Empat belas hari terasa cukup sampai perusahaan mencoba menemukan kontrak tiga tahun lalu, memadankan faktur dengan ledger, meminta penjelasan mantan pegawai, dan menyatukan angka dari dua sistem. Karena itu, disiplin tim harus dimulai ketika surat diterima, bukan dua hari sebelum tenggat.
Berhenti mencari “jawaban yang enak”
Pada pagi pertama, tax manager sebuah perusahaan dapat saja menerima pertanyaan seperti ini dari kepala penjualan:
“Kalau transaksi itu dibatalkan, bilang saja batal, kan?”
Tax manager yang tertib tidak langsung menyetujui. “Bisa, kalau alurnya memang begitu. Saya perlu kontrak, bukti pembatalan, credit note, arus uang, dan perlakuannya di pembukuan serta SPT.”
Percakapan ilustratif itu menunjukkan perbedaan antara cerita dan penjelasan. Cerita adalah narasi yang terasa masuk akal. Penjelasan adalah posisi yang terhubung dengan data, dokumen, kronologi, dan perlakuan pajak. SP2DK sebaiknya dijawab dengan yang kedua.
Jangan memulai rapat dengan pertanyaan “bagaimana membantah angka DJP?” Mulailah dengan “apa yang sebenarnya terjadi, data mana yang dibandingkan, dan bukti apa yang dapat menunjukkan alurnya?” Bila ternyata perusahaan memang keliru, proses yang sama akan membantu manajemen mengukur dampak dan memilih tindak lanjut yang sah. Bila perbedaannya dapat dijelaskan, rekonsiliasi akan membuat penjelasan lebih kuat.
Bentuk tim sesuai isu, bukan sesuai jabatan
Tidak setiap SP2DK memerlukan ruang rapat penuh direktur. Tidak pula setiap SP2DK dapat diselesaikan seorang staf pajak sendirian. Komposisi tim harus mengikuti data yang dipertanyakan.
Tetapkan seorang response owner. Ia menjaga tenggat, daftar permintaan, struktur folder, versi dokumen, jadwal review, dan komunikasi. Response owner bukan orang yang harus mengetahui semua jawaban. Tugas utamanya memastikan tidak ada pekerjaan tanpa pemilik dan tidak ada angka keluar tanpa pemeriksaan.
Lalu petakan process owner. Bila isu menyangkut omzet, libatkan accounting dan sales operation. Bila menyangkut pemotongan pajak, payroll, procurement, treasury, atau accounts payable mungkin memegang fakta penting. Bila berkaitan dengan transaksi afiliasi, legal, business controller, dan pihak yang menerima manfaat jasa dapat diperlukan. Untuk data marketplace atau sistem digital, tim teknologi dan pemilik aplikasi mungkin lebih berguna daripada rapat tambahan dengan manajemen.
Reviewer sebaiknya terpisah dari penyusun utama jika kapasitas memungkinkan. Orang yang menyiapkan rekonsiliasi mudah menjadi terlalu akrab dengan asumsi sendiri. Reviewer menguji apakah angka dapat ditelusuri, istilah konsisten, dokumen benar-benar mendukung narasi, dan respons menjawab pokok surat.
Direksi masuk pada titik keputusan: dampak material, kebutuhan pembetulan, posisi yang mengandung ketidakpastian tinggi, konflik antarunit, atau komitmen yang akan disampaikan keluar. Direksi tidak perlu menyunting setiap kalimat, tetapi juga tidak boleh hanya diminta tanda tangan pada menit terakhir.
Ubah surat menjadi matriks kerja
Salin setiap poin dalam SP2DK ke matriks respons. Jangan meringkas terlalu agresif karena satu kalimat dapat memuat lebih dari satu data atau masa pajak. Matriks yang berguna setidaknya memuat:
1. nomor isu; 2. uraian data atau keterangan yang diminta; 3. masa dan jenis pajak; 4. angka atau fakta menurut surat; 5. angka menurut SPT dan pembukuan; 6. dokumen sumber; 7. penjelasan sementara; 8. pemilik data; 9. status verifikasi; 10. risiko dan tindakan berikutnya.
Berikan kode status yang bermakna. “Sudah” terlalu kabur. Gunakan “dokumen ditemukan”, “angka direkonsiliasi”, “substansi dikonfirmasi process owner”, “menunggu review”, dan “siap untuk respons”. Sebuah invoice yang ditemukan belum tentu membuktikan transaksi. Sebuah angka yang cocok belum tentu memiliki klasifikasi pajak yang benar.
Matriks juga mencegah respons melebar. Tim sering menemukan masalah lain saat melakukan review. Temuan tersebut tetap perlu dicatat dalam daftar terpisah, tetapi jawaban terhadap SP2DK harus terstruktur mengikuti isu yang diminta. Pisahkan response workstream dari remediation workstream agar keduanya tidak saling mengaburkan.
Bangun rekonsiliasi dari sumber, bukan dari hasil akhir
Misalkan data pihak ketiga menunjukkan penerimaan Rp10 miliar, sedangkan omzet pada pelaporan tertentu Rp9,4 miliar. Selisih Rp600 juta bukan penjelasan. Tim harus memecahnya sampai unit yang bisa diuji. Apakah ada PPN dalam angka bruto? Apakah terdapat uang muka? Adakah retur atau pembatalan? Apakah periode pengakuan akuntansi berbeda? Apakah satu NPWP digunakan oleh beberapa unit? Apakah angka pihak ketiga mencatat arus kas, sementara pembukuan mencatat pendapatan berdasarkan pemenuhan kewajiban kontrak?
Setiap jembatan angka perlu memiliki sumber. Jika baris rekonsiliasi menyebut “retur Rp150 juta”, lampirkan daftar transaksi, dokumen retur, pembukuan, dan pengaruhnya terhadap pelaporan. Jika penjelasannya adalah perbedaan waktu, tunjukkan tanggal dokumen, tanggal penyerahan atau kejadian yang relevan, pencatatan, dan pelaporan antarperiode.
Jangan menyesuaikan angka di spreadsheet hanya agar total bertemu. Selisih tanpa penjelasan harus tetap terlihat sebagai selisih. Menyembunyikannya dalam baris “lain-lain” hanya memindahkan masalah ke tahap review.
Buat indeks dokumen yang dapat dibaca orang lain
Folder bernama “Data SP2DK Final New” yang berisi 87 file acak bukan bukti kesiapan. Susun dokumen mengikuti nomor isu dan beri nama yang stabil. Misalnya, folder 01 berisi surat dan bukti penerimaan; folder 02 berisi SPT dan bukti penerimaan; folder 03 berisi rekonsiliasi; folder berikutnya mengikuti setiap pokok permintaan; folder review menampung versi respons dan catatan persetujuan.
Indeks dokumen dapat mencantumkan nama file, deskripsi, periode, sumber, pemilik, tanggal diperoleh, dan hubungan dengan isu. Bila suatu dokumen tidak tersedia, tulis statusnya. Ketiadaan bukti perlu dikelola secara terbuka. Tim kemudian dapat mencari bukti alternatif yang sah, mengonfirmasi fakta melalui sistem lain, atau menjelaskan keterbatasan tanpa menciptakan dokumen seolah-olah berasal dari masa lalu.
Pertahankan versi sumber. Jangan mengganti file asli dengan file yang sudah diberi komentar atau dipotong. Buat working copy. Catat transformasi data jika tim mengekspor, memfilter, menggabungkan, atau mengonversi mata uang. Reviewer harus mampu mengulang proses dari sumber menuju angka dalam respons.
Wawancarai orang yang menjalankan transaksi
Pembukuan memberi struktur, tetapi tidak selalu menjelaskan kejadian. Untuk transaksi yang tidak biasa, lakukan fact-finding interview singkat. Gunakan pertanyaan terbuka sebelum pertanyaan yang mengarahkan.
“Apa tujuan transaksi ini?” lebih baik sebagai pembuka daripada “Ini kan reimbursement, ya?” Tanyakan siapa yang meminta, siapa yang menyetujui, barang atau jasa apa yang diterima, bagaimana harga ditentukan, kapan kewajiban dilaksanakan, mengapa dokumennya berbentuk demikian, dan sistem mana yang mencatatnya.
Buat notulen faktual, kemudian minta pemilik proses mengoreksi bila ada salah pemahaman. Jangan menyulap percakapan menjadi testimoni sempurna. Jika dua orang memberi versi berbeda, catat perbedaannya dan cari bukti objektif. Perbedaan ingatan setelah beberapa tahun adalah hal yang mungkin terjadi; menutupinya justru memperlemah kontrol.
Uji respons dengan empat lapis review
Lapis pertama adalah mathematical review. Total harus cocok, formula benar, periode konsisten, dan tidak ada duplikasi data.
Lapis kedua adalah documentary review. Setiap klaim penting harus terhubung dengan dokumen yang relevan. Dokumen perlu dibaca substansinya, bukan hanya dilihat keberadaannya.
Lapis ketiga adalah tax review. Tim menilai aturan yang berlaku pada periode transaksi, karakter penghasilan atau biaya, kewajiban pemotongan atau pemungutan, perlakuan PPN jika relevan, serta dampak terhadap SPT. Hindari memakai ketentuan terbaru untuk menilai periode lama tanpa analisis transisi.
Lapis keempat adalah coherence review. Seorang pembaca yang tidak mengikuti seluruh proses harus dapat memahami apa data yang dipertanyakan, apa fakta perusahaan, mengapa ada perbedaan, bukti mana yang mendukung, dan apa tindakan yang diambil.
Jika perusahaan menggunakan konsultan, minta konsultan menguji posisi, bukan sekadar mempercantik surat. Pertanyaan yang lebih berguna adalah: asumsi apa yang paling lemah, dokumen apa yang belum mendukung, adakah konsekuensi pada jenis pajak lain, dan bagian mana yang berpotensi disalahpahami?
Kapan perlu berkomunikasi sebelum respons final
Ada kondisi ketika klarifikasi administratif melalui kanal resmi berguna, misalnya lampiran tidak dapat dibuka, ruang lingkup data ambigu, atau perusahaan memperkirakan ada kendala objektif dalam pengumpulan dokumen. Komunikasi harus dikoordinasikan oleh response owner dan dicatat. Jangan membiarkan beberapa pegawai menyampaikan versi berbeda.
Namun komunikasi awal bukan tempat menguji teori yang belum diverifikasi. Kalimat spontan seperti “mungkin memang belum dilaporkan” dapat diartikan lebih luas daripada maksud pembicara. Sampaikan fakta yang telah diketahui, pertanyaan yang spesifik, dan rencana tindak lanjut. Bila memerlukan perpanjangan atau perlakuan prosedural tertentu, cek dasar dan mekanisme yang berlaku, jangan menganggap permintaan informal otomatis mengubah tenggat.
Jika review menemukan kesalahan
SP2DK bukan kompetisi mempertahankan jawaban lama. Bila ditemukan kekeliruan, manajemen perlu memahami besar dampak, periode dan jenis pajak terkait, bunga atau sanksi yang mungkin relevan, keterkaitan dengan transaksi lain, serta opsi koreksi berdasarkan posisi proses saat itu. Keputusan tidak boleh dibuat hanya karena ingin “cepat selesai”.
Dokumentasikan siapa yang memutuskan, fakta apa yang menjadi dasar, saran apa yang diterima, dan tindakan apa yang dilakukan. Pembetulan tanpa root-cause analysis berisiko membuat kesalahan sama muncul lagi. Sesudah respons, masukkan perbaikan ke SOP, master data, konfigurasi sistem, atau pembagian tanggung jawab.
Satu kalender, satu versi, satu suara
SP2DK menjadi kacau bukan karena suratnya selalu rumit. Kekacauan sering lahir dari lima kalender, empat spreadsheet, tiga versi narasi, dan tidak ada seorang pun yang memiliki keputusan akhir.
Tim yang siap bekerja dengan satu kalender tenggat, satu matriks isu, satu repositori terkendali, satu versi respons yang sedang direview, dan satu jalur komunikasi. Mereka tetap dapat berbeda pendapat, tetapi perbedaan itu diselesaikan sebelum jawaban dikirim.
Jadi, jangan panik. Akan tetapi, jangan pula santai tanpa struktur. Perlakukan SP2DK sebagai kesempatan klarifikasi yang membutuhkan fakta, rekonsiliasi, bukti, dan keputusan. Ketika seluruh pekerjaan itu tertata, perusahaan tidak hanya menghasilkan surat tanggapan yang lebih kuat. Perusahaan juga memperoleh peta nyata tentang kualitas data dan kepatuhan pajaknya sendiri.
Bacaan dan rujukan terkait di ePajak.or.id
- Kategori: Pajak
- Topik: Registrasi Wajib Pajak
- Indeks: NPWP PKP
- Panduan: Panduan Registrasi Wajib Pajak
- Evidence: Procedure Source Map
- Entitas: Tax Litigation
- Evidence: Identity Source Map
- Artikel terkait: Permintaan Penjelasan atas Data dan Keterangan: Apa yang perlu disiapkan perusahaan secara tertib?