Seksyen 17 Garis Panduan Khusus e-Invois membuka tetingkap pendedahan dari 7 Julai 2026 hingga 31 Disember 2027 untuk penyerahan yang terlepas, tidak sah, atau yang sudah berada di bawah semakan pematuhan IRBM.
Disahkan terakhir pada 24 Ogos 2026 terhadap Garis Panduan Khusus e-Invois LHDN v4.8 (7 Julai 2026).
Program Pendedahan Sukarela Khas e-Invois ialah Seksyen 17 Garis Panduan Khusus e-Invois. Ia berjalan dari 7 Julai 2026 hingga 31 Disember 2027, yang merupakan tarikh yang sama dengan tamatnya tempoh kelonggaran untuk kumpulan SME, dan ia wujud kerana LHDN dapat melihat perkara yang sama seperti yang dilihat oleh setiap akauntan: sebilangan besar perniagaan melintasi ke dalam kumpulan yang diwajibkan, terus menerbitkan invois seperti biasa, dan menyerahkan sebahagian kecil daripadanya.
Ia adalah program pendedahan, bukan pengecualian. Anda masih menyerahkan dokumen. Apa yang berubah ialah apa yang berlaku kepada anda kerana lewat, dan mekanisme yang anda gunakan untuk memfailkan yang bersejarah. Program ini bersifat pentadbiran dan bukannya punitif, dan garis panduan menetapkannya sebagai laluan yang ditakrifkan dengan versi dokumen sendiri, bukan sebagai konsesi budi bicara yang perlu anda pertikaikan kes demi kes.
Rangka kerja ini penting untuk cara anda merancang kerja. Konsesi yang anda runding ialah latihan undang-undang. Laluan yang ditakrifkan dengan versi dokumen yang ditakrifkan ialah latihan kejuruteraan: tentukan dengan tepat apa yang hilang, hasilkan dokumen dalam bentuk yang diperlukan, dan serahkan dalam urutan yang diperlukan. Langkah pertama daripada tiga langkah itu ialah yang hampir tiada siapa lakukan.
Garis panduan menyenaraikan tiga kategori yang layak, dan ia lebih luas daripada yang kebanyakan orang anggap. Yang pertama ialah pembayar cukai yang terlepas penyerahan — invois yang diterbitkan kepada pelanggan dan tidak pernah dihantar ke MyInvois langsung. Ini adalah kumpulan terbesar dan biasanya paling kurang sedar, kerana penyerahan yang terlepas tidak menghasilkan mesej ralat dan tiada dokumen yang ditolak. Ia tidak menghasilkan apa-apa, yang mana itulah sebabnya ia tidak disedari.
Yang kedua ialah pembayar cukai yang menyerahkan e-invois yang tidak mematuhi. Dokumen itu masuk, tetapi ada sesuatu yang salah padanya: TIN pembeli yang dimiliki oleh entiti yang berbeza, kod klasifikasi yang dipilih kerana ia yang paling hampir dalam senarai juntai, dokumen konsolidasi yang meliputi transaksi yang sepatutnya diterbitkan secara individu. Ini lebih sukar dicari daripada penyerahan yang terlepas, kerana invois mempunyai rujukan pengesahan dan kelihatan lengkap.
Yang ketiga ialah pembayar cukai yang sudah berada di bawah semakan pematuhan IRBM. Ini patut dibaca dua kali, kerana ia menyongsangkan andaian biasa bahawa program sukarela ditutup sebaik sahaja pihak berkuasa menghubungi anda. Di bawah program ini, berada di bawah semakan tidak dengan sendirinya meletakkan anda di luar — walaupun ia adalah kes yang tepat di mana anda patut mengambil arahan ejen cukai anda sebelum memfailkan apa-apa, bukan arahan kami.
Pelepasan penalti dan pendakwaan terpakai kepada pendedahan yang dibuat dalam tetingkap. Secara berasingan, garis panduan menyatakan bahawa semasa tempoh kelonggaran tiada pendakwaan di bawah seksyen 120 Akta Cukai Pendapatan 1967, yang merupakan peruntukan yang sebaliknya akan membawa kegagalan pematuhan.
Terdapat tiga pengecualian, dan ia dinyatakan sebagai pengecualian kepada pelepasan dan bukannya sebagai pengecualian daripada program: penipuan, keingkaran sengaja, dan kecuaian. Dua yang pertama ialah yang orang jangkakan. Kecuaian ialah yang menentukan bagaimana anda patut mendekati latihan ini, kerana perniagaan yang menyelaraskan kedudukannya, mencari jurang dan memfailkannya dalam tetingkap sedang melakukan perkara yang bertentangan dengan mengabaikannya — dan perniagaan yang tahu ia mempunyai jurang, telah tahu selama setahun, dan tidak memfailkan apa-apa adalah tidak.
Itulah hujah praktikal untuk melakukan penyelarasan lebih awal dan secara bertulis. Output kerja di bawah ialah laporan bertarikh yang menunjukkan apa yang direkodkan, apa yang disahkan, dan apa yang diserahkan untuk menutup perbezaan. Apa sahaja yang ejen cukai anda putuskan untuk lakukan dengannya, artifak itu ialah perkara yang membezakan kedudukan yang diperbetulkan daripada yang diabaikan.
Ini ialah keseluruhan kerja, dan ia adalah bahagian yang tiada siapa menjual kepada anda. Setiap laluan ke SVDP melalui satu soalan yang kedengaran remeh tetapi tidak: invois mana yang wujud dalam buku anda yang LHDN tiada rekod disahkan?
Anda tidak boleh menjawabnya dari portal MyInvois, kerana portal hanya tahu apa yang sampai kepadanya. Anda tidak boleh menjawabnya dari pakej perakaunan anda, kerana ia hanya tahu apa yang anda terbitkan. Jawapannya hanya wujud dalam perbezaan antara dua set itu, dan tiada siapa menghasilkan perbezaan itu secara tidak sengaja. Jurang seperti ini ditemui dengan membina perbandingan secara sengaja. Ia tidak muncul dalam perjalanan kerja biasa, kerana dari sudut pandangannya sendiri kedua-dua sistem tidak kehilangan apa-apa.
Mekaniknya ialah penyelarasan set dalam satu tempoh. Tarik senarai penuh invois yang direkodkan dalam lejar anda — nombor, tarikh, pembeli, jumlah, cukai — dan senarai penuh dokumen yang LHDN pegang sebagai disahkan untuk tempoh yang sama. Padankan antara satu sama lain. Empat keadaan keluar, dan ia perlu diasingkan kerana setiap satu ialah kerja yang berbeza.
Keadaan satu: direkodkan dan disahkan, dan angka bersetuju. Tiada apa-apa yang perlu dilakukan. Keadaan dua: direkodkan dan tidak pernah diserahkan. Ini ialah populasi SVDP — dokumen yang anda failkan dalam tetingkap. Keadaan tiga: direkodkan dan diserahkan, tetapi angka tidak bersetuju. Seseorang menaip semula nombor, dan ini ialah pembetulan dan bukannya penyerahan baharu; versi dokumen dan laluan bergantung pada apa yang salah, dan ia adalah keadaan yang paling mungkin memerlukan pandangan ejen cukai anda sebelum anda menyentuhnya. Keadaan empat: disahkan tetapi tidak direkodkan. Lebih jarang, lebih membimbangkan, dan hampir selalu penyerahan pendua atau dokumen yang dibangkitkan dalam portal secara manual dan tidak pernah dimasukkan ke dalam akaun.
Dua kiraan baris yang sepadan bukan penyelarasan. Sesuatu tempoh boleh menunjukkan bilangan invois direkodkan yang sama dengan dokumen disahkan dan masih salah dalam kedua-dua arah sekaligus, kerana set penyerahan terlepas dan set pendua yang bersaiz serupa membatalkan satu sama lain dalam jumlah. Padankan pada pengecam dokumen dan jumlah, jangan sekali-kali pada kiraan.
Penyelarasan juga perlu boleh diulang, kerana anda akan menjalankannya lebih daripada sekali: sebelum anda memfailkan, selepas anda memfailkan, dan setiap bulan selepas itu untuk memastikan jurang tidak terbuka semula. Hamparan sekali sahaja yang dibina secara manual pada akhir bulan ialah bagaimana jurang itu muncul pada mulanya. Ini ialah bahagian kerja yang kami bina sebagai perisian dan bukannya hantar sebagai laporan.
Output penyelarasan, dalam bentuk yang kami paparkan di skrin. Kiraan adalah milik anda; keadaan adalah tetap.
| Keadaan | Maksudnya | Apa yang anda lakukan dengannya |
|---|---|---|
| Direkodkan dan disahkan, angka sepadan | Dokumen wujud pada kedua-dua belah dan sepadan. | Tiada apa-apa. Ini adalah populasi yang anda cuba kembangkan. |
| Direkodkan, tidak pernah dihantar | Invois yang dipegang oleh pelanggan anda yang tiada rekod dalam LHDN. | Populasi SVDP. Failkan dalam tempoh yang ditetapkan. |
| Direkodkan dan dihantar, angka tidak sepadan | Dokumen telah dihantar, tetapi ada sesuatu yang tidak kena padanya. | Pembetulan, bukan penghantaran baharu. Ambil arahan ejen cukai anda terlebih dahulu. |
| Disahkan, tidak direkodkan | LHDN memegang dokumen yang tiada dalam lejar anda. | Biasanya penghantaran pendua atau dokumen yang dimasukkan melalui portal tetapi tidak pernah direkodkan dalam akaun. Siasat sebelum memfailkan apa-apa lagi. |
Pendedahan di bawah program ini menggunakan versi dokumen khusus. SVDP 1.2 ialah versi tanpa tandatangan digital; SVDP 1.3 ialah versi dengan tandatangan digital. Mana satu yang anda gunakan bergantung pada cara anda menghantar — laluan penghantaran bertandatangan menggunakan 1.3, yang tidak bertandatangan menggunakan 1.2.
Medan ini mudah terlepas pandang kerana penghantaran yang dibina untuk operasi biasa membawa versi standard dan disahkan dengan sempurna. Itulah perangkapnya. Dokumen bertarikh belakang yang dihantar di bawah versi standard ialah e-invois yang sah; ia hanya bukan pendedahan di bawah program ini, dan ia tidak membawa layanan program tersebut. Medan versi ialah apa yang menandakan penghantaran sebagai pemfailan SVDP.
Dalam amalan, ini bermakna proses backlog adalah laluan kod yang berasingan daripada penghantaran harian anda, bukan fungsi yang sama dipanggil dengan tarikh yang lebih lama. Jika anda membina atau membeli jambatan, tanya secara khusus sama ada ia boleh mengeluarkan versi dokumen SVDP. Beberapa alat yang menghantar dengan cekap tidak boleh, kerana program ini wujud selepas alat tersebut dibina.
| Versi | Tandatangan digital | Digunakan apabila |
|---|---|---|
| SVDP 1.2 | Tidak | Pendedahan dihantar tanpa tandatangan digital. |
| SVDP 1.3 | Ya | Pendedahan dihantar dengan tandatangan digital. |
Contoh 23 dalam garis panduan menerangkan perkara yang sering menjebak mereka yang cuba menjadi efisien dalam hal ini. Apabila pendedahan dibuat melalui e-invois konsolidasi yang merangkumi tempoh lalu, dokumen konsolidasi tersebut difailkan bulan demi bulan. Anda tidak menggabungkan lapan belas bulan jualan yang tidak dihantar ke dalam satu dokumen konsolidasi bertarikh hari ini.
Sebabnya ialah e-invois konsolidasi mewakili satu tempoh, dan tempoh yang diwakilinya adalah sebahagian daripada apa yang menjadikannya betul. Satu dokumen yang merangkumi setahun setengah bukanlah pemfailan lewat bagi lapan belas dokumen bulanan; ia adalah dokumen kesembilan belas yang tidak sepadan dengan mana-mana akaun bulanan anda. Menyelaraskannya semula ke dalam buku anda selepas itu hampir mustahil, yang menjejaskan tujuan latihan ini.
Ini memberi kesan langsung kepada cara kerja dirancang. Pendedahan yang merangkumi, katakan, empat belas bulan ialah empat belas penghantaran konsolidasi, setiap satu dibina daripada transaksi bulan tersebut, setiap satu menyelaras dengan lejar bulan tersebut. Jika data anda tidak boleh dihiris mengikut bulan dengan bersih — kerana ia dimigrasikan, atau kerana tempoh ditutup dan diselaraskan — itu menjadi masalah pertama yang perlu diselesaikan, sebelum sebarang kod penghantaran dijalankan.
Contoh 24 membincangkan ambang transaksi RM10,000, iaitu garis yang dilukis oleh garis panduan antara transaksi yang boleh berada dalam dokumen konsolidasi dan transaksi yang dilayan secara berasingan.
Ia berinteraksi dengan kelonggaran dengan cara yang perlu dinyatakan dengan jelas. Semasa tempoh kelonggaran, e-invois konsolidasi dibenarkan untuk semua aktiviti, jadi ambang ini bukan kekangan kepada operasi semasa anda seperti yang akan berlaku selepas tempoh kelonggaran tamat. Untuk pendedahan bertarikh belakang, ini adalah soalan tentang tempoh yang didedahkan, bukan tentang hari ini, dan jawapannya boleh berbeza merentas bulan yang anda failkan.
Ini adalah kes untuk membaca Contoh 24 bersama ejen cukai anda terhadap saiz transaksi anda sendiri sebelum anda memutuskan bagaimana sesuatu tempoh disusun. Ini adalah pertimbangan tentang pemfailan anda; kami membina mengikut jawapan yang anda berikan, dan kami membinanya supaya ambang digunakan oleh sistem setiap transaksi, bukan oleh seseorang yang melihat senarai secara manual.
Portal MyInvois ialah papan kekunci. Bagi perniagaan yang mendedahkan tiga puluh invois, ia adalah petang yang perlahan. Bagi perniagaan yang mendedahkan dua ribu invois merentas empat belas bulan, ia bukan pelan, dan mod kegagalannya bukan kerana ia mengambil masa terlalu lama — tetapi entri manual pada volum tersebut memperkenalkan kesilapannya sendiri, yang merupakan kategori kedua yang layak dalam program yang anda baru sahaja daftarkan diri anda.
Alternatifnya ialah buku kerja kelompok LHDN, yang dimuat naik oleh seseorang, dan penghantaran API, yang memerlukan pendaftaran ERP dengan LHDN dan sijil digital daripada pihak berkuasa pensijilan berlesen Malaysia. Kedua-duanya adalah laluan sebenar. Buku kerja adalah jawapan yang jujur untuk perniagaan yang belum memegang pendaftaran dan sijil tersebut, dan itulah yang kami bina untuk pelanggan dalam kedudukan itu daripada menulis klien penghantaran terhadap kelayakan yang tidak wujud. Ia adalah laluan yang dihantar untuk OKAYA Transport, yang lejar dieksport sebagai buku kerja kelompok LHDN sendiri untuk dimuat naik oleh seseorang.
Mana-mana laluan yang anda gunakan, larian penghantaran harus enggan menjadi naif. Sebelum apa-apa dihantar, ia harus menjawab berapa banyak dokumen yang akan dihantar, yang mana ditahan, dan apa yang setiap dokumen yang ditahan itu kekurangan. Alternatifnya ialah penolakan sejam kemudian yang menamakan nombor baris dan bukannya pelanggan, pada fail yang anda tidak dapat bina semula lagi.
Urutan kerja, untuk perniagaan yang bermula dari kosong: selaraskan dahulu dan paparkan jurang pada skrin; betulkan penangkapan di sumber supaya jurang berhenti membesar semasa anda mengusahakannya; susun pendedahan bulan demi bulan; serahkan di bawah versi SVDP yang betul; kemudian selaraskan semula dan terus selaraskan setiap bulan. Membina penghantaran sebelum penyelarasan ialah urutan biasa dan yang salah — ia menghasilkan sistem yang memfailkan dengan yakin terhadap data yang belum diperiksa oleh sesiapa.
Ejen cukai anda menentukan kedudukan pemfailan anda, kelayakan anda dan pendedahan anda. Kami membina sistem yang menghasilkan dan menyerahkan dokumen. Tiada apa-apa di halaman ini adalah nasihat cukai.
Disahkan terakhir pada 24 Ogos 2026 terhadap Garis Panduan Khusus e-Invois LHDN v4.8 (7 Julai 2026).