Peraturan Baru tapi Sistem Belum Siap: Apa yang harus dilakukan wajib pajak secara dokumentatif?

IDTAX.OR.ID KNOWLEDGE SYSTEM

Peraturan Baru tapi Sistem Belum Siap: Apa yang harus dilakukan wajib pajak secara dokumentatif?

FormatPost
Diperbarui13 August 2026
Waktu baca8 menit
KonteksPanduan praktis

Regulasi sudah berlaku.

ERP belum update.

Coretax error.

Vendor belum bisa membuat dokumen.

User access bermasalah.

Tax engine masih memakai rule lama.

Apakah perusahaan boleh diam dan menunggu sistem siap?

Tidak sesederhana itu.

Kewajiban pajak lahir dari hukum, bukan dari kenyamanan software.

Tetapi pada saat yang sama, Wajib Pajak juga tidak boleh mengabaikan kendala teknis nyata yang membuat pelaksanaan administrasi tidak dapat dilakukan secara normal.

Dalam kondisi seperti ini, dokumentasi menjadi sangat penting.

Dokumentasi tidak otomatis menghapus pajak.

Tidak otomatis menghapus sanksi.

Tidak otomatis membuktikan perusahaan benar.

Tetapi dokumentasi menunjukkan apa yang terjadi, apa yang sudah dilakukan, kapan kendala muncul, dan tindakan apa yang diambil untuk tetap patuh.

Pada masa implementasi Coretax, DJP sendiri beberapa kali menerbitkan kebijakan relaksasi formal.

Untuk menelusuri pembahasan lain dalam indeks topik yang sama, lihat arsip Tax Consultant IDTAX.

KEP-67/PJ/2025 memberikan penghapusan sanksi administratif tertentu atas keterlambatan pembayaran, penyetoran, dan pelaporan yang terkait implementasi Coretax pada periode yang ditentukan.

Pada 2026, KEP-55/PJ/2026 dan KEP-71/PJ/2026 kembali memberikan relaksasi terkait SPT Tahunan tahun pajak 2025 bagi orang pribadi dan badan dalam scope masing-masing.

Pelajarannya jelas.

Kalau sistem bermasalah, lihat apakah ada kebijakan formal.

Jangan menciptakan relaksasi sendiri.

Langkah pertama: bedakan hukum belum siap dan sistem belum siap

Kadang regulasi baru sudah final tetapi aturan teknis belum lengkap.

Kadang aturan lengkap tetapi software internal belum update.

Kadang software internal siap tetapi Coretax mengalami kendala.

Kadang semua siap tetapi user perusahaan belum aktif.

Empat masalah berbeda.

Buat root cause.

Legal ambiguity.

Internal IT delay.

DJP system issue.

User/access issue.

Third-party issue.

Setiap root cause punya response berbeda.

Jangan semua diberi label “sistem belum siap”.

Langkah kedua: tetap hitung kewajiban secara substantive

Portal error tidak menghalangi tax team membuat working paper.

Hitung PPh.

Reconcile PPN.

Hitung withholding.

Siapkan payroll tax.

Determine invoice tax treatment.

Siapkan return data.

Kalau law sudah jelas, tax computation harus mengikuti law.

System issue hanya memengaruhi execution.

Ini penting karena ketika portal pulih, perusahaan tinggal submit.

Kalau tax calculation sendiri belum selesai, perusahaan tidak bisa mengatakan seluruh keterlambatan karena system.

Separate delays.

Langkah ketiga: buat incident log

Satu spreadsheet.

Tanggal.

Jam.

User.

Entity.

Process.

Error message.

Screenshot reference.

Action attempted.

Helpdesk ticket.

Alternative channel.

Status.

Impact.

Incident log tidak perlu rumit.

Tujuannya chronology.

Contoh:

10 Agustus 09.15, gagal submit SPT, error X.

09.30, logout-login.

10.00, coba user backup.

11.15, tiket helpdesk dibuat.

14.00, masih gagal.

16.30, berhasil draft tetapi submit error.

Chronology jauh lebih kuat daripada kalimat “Coretax error seharian”.

Langkah keempat: simpan screenshot dengan konteks

Screenshot tanpa timestamp dan URL bisa lemah.

Simpan:

tanggal.

jam.

user.

entity.

menu.

error code.

browser or system.

Jika memungkinkan, export full-page.

Jangan edit screenshot.

File name:

2026-08-10_0915_PTABC_SPT-submit_error-X.png

Sederhana.

Kalau error terjadi berkali-kali, tidak perlu screenshot setiap menit.

Ambil sample saat perubahan status.

Incident log mencatat frekuensi.

Langkah kelima: simpan bukti kewajiban sudah siap

Ini sangat penting.

Tax computation final date.

Approval date.

Payment instruction.

Draft SPT.

Invoice list.

Bukti potong data.

Faktur data.

Kalau perusahaan mengatakan telat karena portal, harus terlihat bahwa data memang sudah ready sebelum deadline.

Jika computation baru selesai tiga hari setelah deadline, system explanation menjadi lebih lemah.

Readiness evidence memisahkan internal delay dan external delay.

Management harus jujur.

Langkah keenam: buat ticket resmi

Gunakan helpdesk atau kanal DJP yang tersedia.

Simpan nomor ticket.

Email.

Chat official jika ada.

Correspondence.

Jangan hanya bertanya di grup WhatsApp informal.

Ticket memberi evidence bahwa perusahaan mencoba menyelesaikan.

Kalau KPP memberi guidance, simpan.

Tetapi ingat, guidance operational bukan selalu dasar mengubah substantive tax.

Jika diarahkan menggunakan channel alternatif, dokumentasikan.

Follow instruction yang memang official dan applicable.

Langkah ketujuh: monitor pengumuman resmi

DJP mempunyai halaman pengumuman dan siaran pers.

Pada 2026, halaman tersebut memuat pemberitahuan downtime Coretax dan berbagai kebijakan relaksasi.

Tax team perlu monitor.

Kalau ada downtime announced, simpan copy atau link reference internal.

Kalau ada KEP relaksasi, baca scope.

Jenis pajak.

Masa.

Deadline original.

Relief.

Last date.

Condition.

Jangan hanya membaca headline “denda dihapus”.

KEP-67/PJ/2025 misalnya sangat period-specific.

Tidak berlaku untuk seluruh keterlambatan selamanya.

KEP-71/PJ/2026 juga khusus SPT Tahunan badan tahun pajak 2025 dalam window yang ditentukan.

Scope is everything.

Langkah kedelapan: jangan menunda pembayaran kalau payment channel masih bisa

System filing error tidak selalu berarti payment impossible.

Kalau jumlah pajak sudah diketahui dan pembayaran masih dapat dilakukan melalui mekanisme yang tersedia, pertimbangkan membayar tepat waktu sesuai ketentuan.

Jangan menahan payment hanya karena SPT belum bisa submit, kecuali sistem dan rule memang membuat pembayaran tidak dapat dilakukan atau ada guidance khusus.

Pisahkan:

payment issue.

filing issue.

Document issue.

Satu area error tidak otomatis membuat semua area berhenti.

This reduces exposure.

Langkah kesembilan: gunakan manual control untuk ERP internal

Regulasi berubah 1 Agustus.

ERP baru update 1 September.

Perusahaan tetap punya transaksi Agustus.

Buat temporary tax register.

Transaction ID.

Old system tax.

Correct tax.

Manual adjustment.

Invoice correction if needed.

Reviewer.

Status.

Begitu system ready, reconcile.

Jangan biarkan satu bulan transaksi hilang.

Temporary control harus punya owner dan sunset date.

Kalau tidak, manual workaround menjadi permanent shadow system.

Langkah kesepuluh: buat deviation memo

Untuk kendala material, satu memo internal sangat berguna.

Judul:

Temporary Tax Process Deviation.

Isi:

regulation.

effective date.

normal process.

system limitation.

interim process.

control.

approval.

start date.

sunset.

reconciliation plan.

Memo ini membuktikan perusahaan tidak improvisasi tanpa governance.

CFO atau tax head approve sesuai materiality.

Internal audit bisa review.

Ketika system siap, close memo.

Langkah kesebelas: jangan backdate dokumen

Karena sistem tidak siap, perusahaan mungkin tergoda membuat dokumen dengan tanggal seolah normal.

Hati-hati.

Jangan memalsukan timestamp.

Jangan membuat screenshot palsu.

Jangan mengubah log.

Jangan backdate approval.

Jika document legally perlu date tertentu dan system baru memungkinkan kemudian, ikuti mekanisme correction or guidance yang berlaku.

Document actual sequence.

Transparency lebih defensible daripada memalsukan kesempurnaan.

Langkah keduabelas: bedakan formal relaxation dan discretion

KEP-DJP dapat secara formal memberi penghapusan sanksi pada scope tertentu.

Itu berbeda dari berharap petugas “maklum”.

Compliance strategy tidak boleh berbasis asumsi discretion.

Jika tidak ada relief formal, lakukan best effort untuk comply.

Jika penalty muncul dan law memberi mekanisme permohonan pengurangan atau penghapusan dalam kondisi tertentu, gunakan prosedur yang benar.

Evidence incident dapat mendukung.

Tetapi hasil tidak boleh diasumsikan.

Tax provision mungkin perlu mempertimbangkan exposure sampai relief clear.

Langkah ketigabelas: document official advice

Jika KPP atau helpdesk memberi instruction:

Catat tanggal.

Nama channel.

Nomor ticket.

Isi guidance.

Siapa internal yang menerima.

Action.

Kalau advice diberikan lisan dan material, buat meeting note.

Bila memungkinkan, minta confirmation tertulis.

Jangan mengandalkan ingatan.

Tetapi tetap check regulation.

Operational advice can help navigate system.

It does not necessarily override law.

Langkah keempatbelas: lakukan post-incident reconciliation

System sudah normal.

Jangan berhenti.

Tarik seluruh affected transactions.

Check:

submitted?

paid?

receipt?

correct period?

correct amount?

manual adjustment cleared?

credit note?

duplicate?

missing?

Temporary workaround sering menciptakan double posting.

Post-reconciliation menutup.

Buat sign-off.

Incident closed.

Langkah kelimabelas: simpan evidence package

Regulation.

Official announcement.

Incident log.

Screenshots.

Helpdesk ticket.

Tax computation.

Approval.

Payment proof.

Draft.

Submission proof.

Reconciliation.

Deviation memo.

Simpan satu folder.

Kalau dua tahun kemudian ada pertanyaan, file sudah lengkap.

Jangan mencari chat lama.

Incident package adalah institutional memory.

Untuk system vendor internal, buat service-level evidence

Kalau ERP vendor terlambat update, simpan:

change request.

vendor response.

expected release.

UAT.

go-live.

Internal tax logic.

Management should know delay is internal, not DJP.

Jika akibat internal delay ada tax exposure, jangan salah attributing.

Root cause informs remediation.

Maybe contract vendor perlu SLA regulatory update.

System readiness becomes procurement issue.

User access problem seharusnya dicegah sebelum deadline

DJP pada 2025 dan 2026 berulang kali mengedukasi aktivasi akun Coretax dan role.

Kalau Wajib Pajak baru mencoba aktivasi pada hari terakhir, sulit menyebut seluruh masalah external.

Governance harus punya readiness checklist.

Account active.

PIC.

Role.

Kuasa.

Certificate or authorization.

Browser.

Contact data.

Payment channel.

Test login.

Selesaikan sebelum peak filing.

Best effort harus terlihat.

Downtime resmi juga perlu dimasukkan calendar

Jika DJP mengumumkan planned downtime, tax team jangan menjadwalkan submission di jam tersebut.

Reschedule.

Planned maintenance bukan unexpected incident.

Kalau deadline dekat, submit earlier.

Perusahaan yang selalu bekerja pada menit terakhir mempunyai operational risk sendiri.

Documentation tidak menggantikan buffer.

Management deadline sebaiknya lebih awal daripada statutory deadline.

Itu mitigasi paling murah.

Apa yang tidak boleh dilakukan?

Diam.

Menunggu tanpa mencoba.

Menghapus error evidence.

Membuat dokumen palsu.

Mengasumsikan semua denda pasti dihapus.

Mengubah tax treatment supaya cocok dengan limitation software.

Menyalahkan Coretax tanpa root cause.

Membiarkan manual workaround tanpa reconciliation.

Semua itu memperburuk posisi.

Apa yang harus dilakukan?

Hitung benar.

Siapkan data.

Coba comply.

Catat error.

Buka ticket.

Cari channel alternatif resmi.

Monitor announcement.

Baca relief formal.

Gunakan temporary control.

Reconcile setelah normal.

Simpan evidence.

Itu response yang professional.

Dokumentasi bukan alat untuk membebaskan pajak

Ini boundary akhir.

Screenshot error tidak menghapus PPh terutang.

Ticket helpdesk tidak otomatis menghapus PPN.

Deviation memo tidak mengalahkan Undang-Undang.

Dokumentasi membuktikan fakta proses.

Kalau pemerintah kemudian memberi relaksasi untuk kondisi tersebut, evidence membantu perusahaan menunjukkan scope.

Kalau tidak ada relaksasi, documentation masih berguna untuk memahami error dan menggunakan remedy yang tersedia sesuai hukum.

Peraturan baru dan sistem lama adalah risiko transition.

Perusahaan tidak bisa mengontrol kapan regulator menerbitkan aturan.

Perusahaan juga tidak selalu bisa mengontrol kapan external system stabil.

Tetapi perusahaan bisa mengontrol satu hal:

jejak tindakan sendiri.

Kapan rule dianalisis.

Kapan system gagal.

Apa yang dicoba.

Apa yang dihitung.

Apa yang dibayar.

Kapan berhasil.

Bagaimana dikoreksi.

Jejak itu yang membedakan compliance problem yang dikelola dengan baik dari kekacauan yang baru dijelaskan setelah surat datang.

Leave a Comment

Your email address will not be published. Required fields are marked *