Gangguan sistem selalu terasa lebih panjang ketika tenggat tinggal beberapa jam. Tim sudah menyiapkan SPT, pihak yang berwenang siap menandatangani, tetapi laman tidak dapat dibuka atau proses berhenti di tengah jalan. Refleks pertama biasanya mencoba berulang kali. Refleks kedua adalah mengambil screenshot. Setelah itu, banyak tim tidak tahu harus berbuat apa selain menunggu.
Direktorat Jenderal Pajak memang mengumumkan waktu henti terencana Coretax dari waktu ke waktu. Pada 2026, misalnya, terdapat pengumuman pemeliharaan dengan rentang waktu tertentu yang membuat Coretax dan layanannya tidak dapat diakses sementara. Pengumuman resmi seperti ini penting disimpan. Namun, tim tidak boleh menganggap setiap masalah pada laptop otomatis merupakan downtime resmi, atau menganggap screenshot error otomatis menghapus konsekuensi keterlambatan.
Tujuan dokumentasi bukan mengumpulkan gambar sebanyak-banyaknya. Tujuannya membangun kronologi yang dapat menunjukkan kesiapan wajib pajak, tindakan yang dicoba, karakter kendala, durasi, dampak, dan langkah tindak lanjut.
Bedakan downtime terencana, gangguan luas, dan kendala lokal
Downtime terencana biasanya diumumkan DJP melalui kanal resmi dengan jadwal mulai dan selesai serta layanan yang terdampak. Jika jadwalnya diketahui, perusahaan seharusnya menyesuaikan kalender internal. Menunggu menit terakhir meski pemeliharaan sudah diumumkan melemahkan posisi operasional perusahaan sendiri.
Gangguan luas terjadi tanpa perencanaan yang diketahui tim dan dapat dialami banyak pengguna. Indikasinya dapat berupa pengumuman atau informasi resmi, laporan dari kanal bantuan, serta kegagalan konsisten pada lebih dari satu perangkat atau jaringan. Tetap berhati-hati terhadap rumor di grup. Banyak orang mengeluh pada waktu yang sama belum tentu membuktikan penyebab yang sama.
Kendala lokal berasal dari perangkat, jaringan kantor, browser, akun, role, data, kode otorisasi, atau langkah pengguna. Jika satu user gagal tetapi user lain dengan kewenangan benar berhasil pada perangkat berbeda, masalahnya belum layak disebut downtime sistem. Diagnosis awal perlu dilakukan agar bukti yang dikumpulkan relevan.
Catatan satu halaman yang harus mulai dibuat sejak percobaan pertama
Begitu kendala material terjadi, tunjuk satu orang sebagai pencatat. Ia tidak harus menjadi orang yang mengoperasikan Coretax. Log sebaiknya memuat tanggal dan waktu WIB, modul, jenis dokumen, masa pajak, langkah yang sedang dilakukan, status sebelum kendala, pesan yang tampil persis, serta dampaknya.
Catat juga pengguna dan role tanpa menulis kata sandi atau passphrase. Tuliskan perangkat, browser dan versinya bila diketahui, jaringan yang dipakai, serta apakah uji dilakukan melalui perangkat atau jaringan lain. Jika tim menghapus cache, masuk ulang, atau mengganti browser, tulis hasil setiap percobaan. Log ini mencegah sepuluh orang mengulang langkah yang sama tanpa belajar apa pun.
Gunakan waktu dari sistem perangkat yang sudah disinkronkan. Screenshot yang tidak menampilkan waktu dapat dilengkapi dengan catatan, tetapi jangan mengedit gambar untuk menambahkan informasi seolah berasal dari sistem. Simpan file asli dan beri nama terstruktur.
Screenshot yang berguna mempunyai konteks
Gambar penuh layar biasanya lebih kuat daripada potongan kecil karena menunjukkan domain, menu, waktu perangkat, dan posisi proses. Namun, sebelum menyimpan atau membagikan gambar, perhatikan data sensitif. NPWP, NIK, alamat, nilai transaksi, email, dan informasi bisnis tidak boleh disebarkan ke grup yang tidak berwenang.
Ambil gambar pada titik penting, bukan setiap kali menekan tombol. Dokumentasikan pesan error pertama, status sebelum pengiriman, hasil percobaan setelah langkah pemulihan, dan kondisi ketika sistem kembali normal. Jika ada nomor referensi atau tiket, sertakan dalam log. Screenshot hanyalah satu lampiran dari kronologi.
Jangan menutupi elemen penting pada file bukti internal. Untuk keperluan berbagi eksternal, buat salinan yang disamarkan dan pertahankan file asli dalam akses terbatas. Dengan begitu, keamanan data dan integritas bukti sama-sama dijaga.
Simpan bukti kesiapan, bukan hanya bukti kegagalan
Jika perusahaan ingin menunjukkan bahwa pekerjaan sebenarnya siap, arsipkan konsep SPT, kertas kerja final, bukti review, persetujuan, data pembayaran, serta catatan kapan dokumen siap dikirim. Bukti tersebut harus sudah ada sebelum kendala, bukan dibuat mundur setelah deadline.
Audit trail internal dapat membantu: email persetujuan, timestamp file, status workflow ERP, atau catatan reviewer. Hindari merekayasa waktu. Dokumentasi yang jujur dengan satu kekurangan lebih aman daripada kronologi sempurna yang tidak dapat dipercaya.
Untuk pembayaran, simpan billing, instruksi kepada treasury, status transaksi bank, dan bukti penerimaan yang relevan. “Kami sudah berniat membayar” bukan bukti eksekusi. Sebaliknya, uang yang terdebit tanpa referensi pajak yang dapat ditelusuri juga belum menjawab seluruh persoalan.
Pantau kanal resmi dan arsipkan pengumuman
Periksa pajak.go.id, kanal resmi DJP, Coretaxpedia, serta pemberitahuan pada akun bila dapat diakses. Simpan URL, judul, waktu pemeriksaan, dan salinan atau PDF halaman bila relevan. Jangan hanya menyimpan screenshot unggahan akun tidak resmi yang mengutip pengumuman.
Jika DJP mengumumkan downtime, catat cakupan layanan dan rentangnya. Jangan memperluas arti pengumuman. Pemeliharaan pada malam tertentu tidak membuktikan kegagalan yang terjadi sehari sebelumnya. Demikian pula, berakhirnya jadwal downtime tidak selalu berarti semua kendala lokal otomatis selesai.
Peraturan, pengumuman, atau kebijakan mengenai tenggat harus dibaca dari sumber resmi terbaru. Jangan mengasumsikan ada perpanjangan hanya karena sistem sempat sulit diakses. Perpanjangan atau perlakuan tertentu memerlukan dasar yang jelas, bukan kesimpulan dari percakapan WhatsApp.
Eskalasi dengan paket informasi yang bisa didiagnosis
Saat menghubungi KPP, Kring Pajak 1500200, atau kanal resmi lain yang relevan, berikan informasi ringkas dan terstruktur. Sebut jenis wajib pajak, modul, jenis dokumen, masa, waktu kejadian, pesan error, langkah yang sudah dicoba, serta nomor referensi. Lampirkan gambar yang sudah disamarkan bila diminta.
Jangan mengirim kata sandi, OTP, passphrase kode otorisasi, atau akses jarak jauh kepada orang yang menghubungi melalui kanal tidak dikenal. Petugas atau konsultan yang sah pun tidak memerlukan perusahaan membagikan rahasia autentikasi melalui chat biasa.
Catat waktu kontak, kanal, nama atau identitas petugas bila diberikan, nomor tiket, dan arahan yang diterima. Jika arahan dilakukan, tulis hasilnya. Dengan demikian, pergantian shift tidak memutus cerita dan perusahaan tidak perlu memulai penjelasan dari nol.
Apa yang dilakukan selama menunggu
Downtime tidak membuat semua pekerjaan berhenti. Tim dapat memeriksa kembali identitas, periode, nilai, lampiran, dan otorisasi. Pastikan file final tidak berubah tanpa review. Siapkan jalur perangkat serta jaringan cadangan yang aman. Pastikan pihak penandatangan tetap tersedia pada jendela waktu berikutnya.
Tetapi jangan memakai waktu tunggu untuk membuat banyak versi dokumen tanpa kontrol. Tetapkan satu master candidate. Setiap perubahan diberi versi dan reviewer. Ketika sistem kembali, tim tahu file mana yang harus digunakan.
Buat decision clock. Misalnya, pemeriksaan status dilakukan setiap interval yang masuk akal, bukan setiap dua menit oleh seluruh tim. Tentukan siapa yang memutuskan eskalasi, siapa yang berkomunikasi dengan manajemen, dan siapa yang tetap menjaga data. Ritme ini mengurangi tindakan panik.
Ketika akses pulih, jangan langsung berlomba menekan submit
Pertama, pastikan login dilakukan pada domain resmi. Periksa apakah konsep lama masih ada dan bagaimana status percobaan sebelumnya. Jangan membuat konsep baru sebelum yakin tindakan lama tidak berhasil diam-diam. Cocokkan nomor referensi dan riwayat.
Kedua, ulangi pemeriksaan final. Gangguan dan percobaan berulang dapat membuat tim kehilangan fokus. Pastikan dokumen, masa, dan penandatangan benar. Setelah pengiriman, simpan bukti penerimaan atau keluaran resmi. Catat waktu pemulihan dan waktu tindakan berhasil.
Ketiga, tutup log dengan hasil. Apakah pelaporan selesai, pembayaran tercatat, atau masih ada item terbuka? Jika melewati tenggat, dokumentasi disimpan untuk evaluasi dan penanganan sesuai ketentuan. Jangan menulis “aman karena error” tanpa dasar resmi.
Pencegahan yang lebih bernilai daripada bukti terbaik
Bukti kendala penting, tetapi strategi terbaik tetap mengurangi eksposur terhadap jam terakhir. Buat cut-off internal beberapa hari sebelum batas resmi. Uji akun dan kode otorisasi lebih awal. Pastikan role pengganti. Pantau jadwal pemeliharaan. Selesaikan rekonsiliasi sebelum hari kirim.
Lakukan simulasi satu kali: sistem tidak dapat diakses selama empat jam. Siapa mencatat, siapa mengecek kanal resmi, siapa menghubungi bantuan, file apa yang harus tersedia, dan siapa melakukan pengiriman setelah pulih? Jika jawabannya masih “nanti lihat situasi”, SOP belum siap.
Bedakan log internal dan laporan kepada pihak luar
Log internal boleh sangat rinci karena dipakai untuk diagnosis. Ia memuat percobaan, nama file, pergantian perangkat, komunikasi, dan keputusan. Laporan kepada pihak luar cukup memuat fakta yang relevan dan data yang diminta. Jangan mengirim seluruh folder hanya karena ingin terlihat lengkap. Kelebihan data meningkatkan risiko kebocoran dan dapat mengaburkan inti masalah.
Sebelum mengirim laporan, minta reviewer membaca kronologi tanpa penjelasan lisan. Jika ia tidak memahami urutan, tambahkan waktu dan hubungan antarperistiwa. Jika ia menemukan kesimpulan yang tidak didukung lampiran, ubah menjadi dugaan atau hapus. Kalimat “sistem down sejak pagi” tidak layak dipakai jika bukti pertama baru muncul pukul 15.40.
Gunakan tabel empat kolom: waktu, tindakan, hasil, bukti. Pada bagian atas, tulis identitas kasus, modul, masa, dampak, dan pemilik. Pada bagian bawah, tulis status terkini serta langkah berikutnya. Format ini lebih mudah diaudit daripada percakapan grup yang diekspor mentah.
Jangan lupa bukti komunikasi internal
Saat kendala terjadi, keputusan manajemen juga penting. Siapa menyetujui menunggu, siapa memutuskan tidak membayar ulang, siapa meminta eskalasi, dan apa dasar waktunya? Simpan persetujuan pada kanal perusahaan. Ini bukan untuk mencari kambing hitam. Ini menunjukkan bahwa tindakan berisiko diambil secara sadar dengan informasi yang tersedia.
Jika ada pergantian orang selama insiden, lakukan handover tertulis. Cantumkan status dokumen, percobaan terakhir, nomor tiket, file master, dan batas tindakan yang tidak boleh diulang. Handover lisan mudah kehilangan detail saat semua orang lelah.
Evaluasi setelah insiden tanpa menyalahkan operator
Dalam dua hari kerja setelah masalah selesai, lakukan review singkat. Pisahkan penyebab yang berada di luar kendali perusahaan dari kelemahan internal. Downtime resmi mungkin eksternal, tetapi ketergantungan pada satu penandatangan, konsep yang baru selesai satu jam sebelum batas, atau tidak adanya perangkat cadangan adalah risiko internal.
Tetapkan maksimal tiga perbaikan dengan pemilik dan tanggal. Misalnya memajukan cut-off, memperbarui daftar kontak, atau menguji role pengganti. Review yang menghasilkan dua puluh saran biasanya tidak dijalankan. Simpan hasilnya bersama log agar insiden berikutnya tidak dimulai dari nol.
Saat downtime benar-benar terjadi, perusahaan tidak membutuhkan album screenshot. Ia membutuhkan kronologi yang rapi, bukti kesiapan yang lahir sebelum masalah, sumber resmi tentang gangguan, tiket eskalasi, dan bukti hasil setelah layanan pulih. Dokumentasi seperti itu tidak menjanjikan perlakuan hukum tertentu. Ia membuat perusahaan mampu menjelaskan apa yang terjadi secara jujur, tepat waktu, dan dapat diverifikasi.
Bacaan dan rujukan terkait di ePajak.or.id
- Kategori: Pajak
- Topik: Coretax DJP
- Indeks: Coretax
- Panduan: Panduan Coretax DJP
- Evidence: Administration Source Map
- Topik: Troubleshooting Pajak Online
- Artikel terkait: Coretax 2026 Sudah Jadi Rutinitas, Tapi Kenapa Tim Finance Masih Sering Nyangkut di Hal Kecil?
- Artikel terkait: Satu Perusahaan, Banyak User: Cara Membagi Peran Akses Coretax Tanpa Semua Orang Pegang Kendali
