E invoice POS system Malaysia: apa yang LHDN perlukan

Peniaga yang menaip e invoice pos system malaysia ke dalam enjin carian biasanya sudah ada satu sistem di kaunter dan satu masalah: dia tidak pasti sama ada sistem itu boleh menghantar e-invois, atau dia perlu beli yang baharu. Vendor berkata boleh. Juruwang berkata sistem selalu tergantung. Pemilik kedai pula sedang mengira berapa jam kerja bulanan yang akan hilang.

Artikel ini bukan panduan cukai. Ia menerangkan paip data: medan apa yang perlu ada pada satu transaksi jualan, apa yang MyInvois balas, dan di mana sistem POS biasa gagal. Kalau anda sudah tahu kewajipan e-invois dan sedang menilai sistem, bahagian yang berguna bermula pada medan, bukan pada tarikh.

Satu perkara perlu jelas di depan. E-invois tidak mengubah resit yang pembeli pegang. Ia menambah satu dokumen berasingan yang dihantar ke LHDN dalam bentuk XML atau JSON, dan dokumen itu mesti lulus pengesahan sebelum ia sah. Resit kertas atau fail PDF bukan e-invois.

Apa yang berubah untuk kedai kecil: satu resit, satu e-invois

Pada kaunter, aliran kerja kelihatan sama. Pembeli bayar, juruwang serahkan resit. Yang berubah ialah selepas itu: setiap transaksi perlu wujud sebagai fail berstruktur yang dihantar ke sistem MyInvois, dan sistem itu memulangkan status. Untuk kedai yang menjual kepada orang awam, jualan harian tidak perlu dihantar satu per satu.

LHDN membenarkan e-invois konsolidasi, iaitu satu dokumen yang merangkum semua transaksi dalam sebulan, dan ia mesti dihantar dalam tujuh hari kalendar selepas bulan berakhir. Inilah yang menyelamatkan kedai runcit daripada menghantar dua ratus dokumen sehari.

Soal sama ada kedai itu sudah wajib bergantung pada perolehan tahunan. Fasa terakhir meliputi perniagaan dengan perolehan sehingga RM5 juta mulai 1 Januari 2026, manakala perniagaan dengan perolehan di bawah RM3 juta dikecualikan mulai 30 Ogos 2026, tertakluk kepada syarat pemilikan dan syarikat berkaitan. Peniaga yang tidak layak dikecualikan tetapi perolehannya di bawah RM3 juta memulakan kewajipan pada 1 Julai 2026.

Kedai yang belum wajib pun masih terdorong menyambung sistemnya. Sebaik pembeli perniagaan meminta e-invois, penjual mesti boleh mengeluarkannya. Menolak permintaan itu bermakna kehilangan akaun, bukan kehilangan satu resit.

Risiko kegagalan pula bukan kecil. Kegagalan mengeluarkan e-invois ialah kesalahan di bawah seksyen 120(1)(d) Akta Cukai Pendapatan 1967, dengan denda antara RM200 dan RM20,000 atau penjara sehingga enam bulan, atau kedua-duanya, bagi setiap kes.

Medan yang mesti betul sebelum butang hantar ditekan

Di sinilah kebanyakan projek integrasi tersekat. Sistem POS biasanya menyimpan apa yang perlu untuk mencetak resit, bukan apa yang perlu untuk lulus pengesahan. Lima kumpulan medan berikut menentukan sama ada dokumen diterima atau ditolak.

• ▸ TIN pembekal. TIN dalam dokumen mesti sama dengan TIN yang terikat pada token API. Kalau tidak, MyInvois memulangkan ralat bahawa TIN yang disahkan tidak sepadan dengan TIN dokumen.
• ▸ TIN individu bermula dengan IG dan panjang maksimum 14 aksara termasuk huruf awalan. TIN bukan individu berakhir dengan sifar, dan sifar di hadapan selepas awalan mesti dibuang.
• ▸ Kod jenis dokumen. 01 untuk invois, 02 nota kredit, 03 nota debit, 04 nota refund, dan 11 hingga 14 untuk dokumen self-billed.
• ▸ Kod klasifikasi dan jenis cukai pada setiap baris. Ini kerja data, bukan kerja pembangunan: setiap item dalam item master perlu kod klasifikasi yang betul sebelum sistem boleh menghantar apa-apa.
• ▸ Butiran pembeli. Nama sehingga 300 aksara, setiap baris alamat sehingga 150 aksara, poskod lima digit untuk alamat Malaysia, telefon antara 8 dan 20 aksara, e-mel mengikut format RFC, dan nombor SST sehingga 35 aksara.

Dua medan teknikal pula sering dilupakan. Tarikh dan masa pengeluaran dokumen mesti dalam UTC, dan dokumen yang terlalu lama tidak diterima kerana hadnya 72 jam sebelum penghantaran. Dokumen dihantar sebagai teks Base64 bersama nilai hash SHA-256, dan had saiz fail 300KB, jadi invois yang panjang perlu dikecilkan sebelum dihantar.

Kod negeri 00 juga tidak lagi sah untuk penghantaran melalui API. Ini jenis butiran yang tidak muncul dalam demo vendor, tetapi muncul pada hari pertama go-live.

Tiga cara patuh: portal, POS berintegrasi, sistem berasingan

Ada tiga jalan, dan pilihan yang betul bergantung pada bilangan dokumen sebulan, bukan pada saiz kedai.

• ▸ Portal MyInvois. Percuma, disediakan LHDN, dan boleh menerima muat naik spreadsheet. Sesuai untuk kedai yang mengeluarkan puluhan dokumen sebulan dan tiada kakitangan teknikal. Kerjanya manual dan berulang.
• ▸ POS berintegrasi melalui API. Sistem menghantar sendiri setiap dokumen dan menyimpan status. Sesuai apabila transaksi harian ramai atau apabila pembeli perniagaan kerap meminta e-invois serta merta. Ia memerlukan pembangunan, sijil digital dan ujian.
• ▸ Sistem berasingan. POS kekal, dan satu alat invois lain menarik data jualan setiap hari. Jalan tengah apabila POS tidak boleh diubah tetapi datanya boleh dieksport.

Perbandingan yang jujur dibuat dalam jam kerja bulanan, bukan dalam senarai ciri. Portal menuntut dua hingga empat jam sebulan untuk tiga ratus resit, termasuk masa membetulkan ralat taip. API hampir sifar kerja manual selepas stabil, tetapi ia menuntut kerja pembangunan dan ujian sebelum itu. Sistem berasingan berada di tengah, dengan satu risiko tambahan: dua tempat data boleh bercanggah.

Aliran sebenar: jualan ke pengesahan

Dalam sistem yang sudah bersambung, satu jualan bergerak melalui enam langkah. Juruwang menutup transaksi, POS membina dokumen, dokumen ditandatangani dengan sijil digital organisasi, dokumen dihantar ke API, MyInvois mengesahkan, dan status dikemas kini dalam pangkalan data kedai. Empat status yang akan anda lihat ialah:

• ▸ 1, submitted: struktur asas lulus, pengesahan lanjut belum selesai.
• ▸ 2, valid: dokumen sah dan boleh dikongsi.
• ▸ 3, invalid: ada isu pengesahan, dan dokumen mesti dibetulkan.
• ▸ 4, cancelled: dokumen dibatalkan oleh pengeluar.

Kesilapan biasa ialah mencetak tanda sah pada resit sebaik dokumen dihantar. Status 1 bukan status 2. Kalau dokumen kemudiannya menjadi invalid, pembeli sudah membawa pulang resit yang merujuk dokumen yang tidak sah, dan pembetulan menjadi lebih mahal daripada menunggu tiga puluh saat.

Dua had masa menentukan reka bentuk sistem. Token API sah selama 60 minit, jadi sistem perlu menyimpan token dan menggunakannya berulang, bukan log masuk bagi setiap transaksi. Pembatalan hanya dibenarkan dalam 72 jam selepas pengesahan, dan selepas itu pembetulan mesti dibuat dengan nota kredit, nota debit atau nota refund yang merujuk UUID dokumen asal. Maksudnya POS mesti menyimpan UUID itu bersama setiap jualan, bukan sekadar nombor resit.

Ada juga keadaan di luar kawalan kedai. Apabila sistem LHDN terganggu, pembekal diberi 72 jam untuk mengeluarkan e-invois selepas sistem pulih, dan sistem kedai perlu cuba semula secara automatik. Sistem yang hanya mempunyai butang hantar manual akan tertinggal beratus dokumen dalam keadaan itu.

Bila jualan runcit tidak perlu butiran pembeli

Ini soalan yang paling kerap diajukan oleh kedai runcit, dan jawapannya ada pada jenis dokumen, bukan pada jenis pelanggan. E-invois konsolidasi dibenarkan untuk transaksi yang pembeli tidak meminta e-invois, termasuk transaksi antara perniagaan, bukan hanya jualan kepada orang awam. Pengecualiannya ialah aktiviti yang disenaraikan dalam seksyen 3.7 garis panduan khusus LHDN.

E-invois konsolidasi tidak perlu dikongsi dengan pembeli. Ia dokumen antara kedai dan LHDN. Pembeli tetap menerima resit biasa, dan tiada kewajipan menghantar salinan digital kepadanya.

Ada satu syarat yang selalu terlepas pandang. Perniagaan kecil dengan ambilan kasar melebihi RM150,000 setahun mesti mengeluarkan resit bernombor bersiri, dan nombor rujukan resit itu mesti dimasukkan ke dalam e-invois konsolidasi. Di bawah ambilan itu, resit bernombor bersiri tidak diwajibkan dan e-invois konsolidasi juga tidak diwajibkan.

Jualan melalui platform e-dagang berbeza. Tanggungjawab mengeluarkan e-invois terletak pada platform, bukan pada penjual yang berjual di platform itu. Kedai yang hanya berjual di Shopee atau TikTok Shop tidak perlu membina integrasi untuk jualan tersebut, tetapi jualan di kaunter fizikal masih dikira.

Kos integrasi: apa yang menaikkan harga

Kerja integrasi bermula sekitar RM1,000 untuk skop yang kecil: satu kaunter, satu kadar cukai, item master yang kemas dan tiada cawangan kedua. Selebihnya ditentukan oleh skop, dan skop ditentukan oleh enam perkara berikut.

• ▸ Bilangan kaunter dan peranti yang perlu menghantar dokumen, termasuk tablet dan telefon yang dipakai sebagai terminal.
• ▸ Bilangan item dalam item master, kerana setiap item perlu kod klasifikasi dan kod cukai yang betul.
• ▸ Pulangan barang dan tukar barang, yang menuntut aliran nota kredit yang merujuk dokumen asal.
• ▸ Diskaun baris, baucar dan pembayaran bercampur, yang mengubah cara jumlah dikira sebelum cukai.
• ▸ Sijil digital organisasi tahunan, yang mesti diperbaharui dan dipasang pada pelayan.
• ▸ Latihan juruwang dan seorang yang akan menjawab apabila dokumen ditolak.

Ada kos yang jarang disebut dalam sebut harga. Spesifikasi dokumen berubah: versi 1.0 digantikan versi 1.1 dengan pengesahan tandatangan, dan versi 1.2 serta 1.3 hanya untuk program pendedahan sukarela sehingga 31 Disember 2027. Sistem yang dibina rapat pada satu versi perlu diuji semula apabila LHDN mengemas kini struktur.

Satu nasihat praktikal: jangan bayar penuh sebelum vendor menunjukkan satu dokumen ujian yang lulus pengesahan dalam sandbox, dengan data kedai anda, bukan data demo.

Ujian sebelum go-live: lapan kes dalam sandbox

Sandbox MyInvois berasingan sepenuhnya daripada pengeluaran. Hosnya preprod.myinvois.hasil.gov.my untuk portal dan preprod-api.myinvois.hasil.gov.my untuk API. Lapan kes berikut menutup sebahagian besar kegagalan sebenar.

• ▸ Jualan tunai tanpa butiran pembeli, dihantar sebagai konsolidasi.
• ▸ Jualan kepada pembeli perniagaan dengan TIN yang sah, dihantar sebagai invois biasa.
• ▸ Jualan dengan diskaun pada baris, untuk memastikan jumlah sebelum dan selepas cukai betul.
• ▸ Jualan dengan dua kadar cukai dalam satu resit.
• ▸ Pulangan barang, yang menghasilkan nota kredit yang merujuk UUID invois asal.
• ▸ Pembatalan dalam tempoh 72 jam, dan percubaan pembatalan selepas tempoh itu.
• ▸ Dokumen besar melebihi 300KB, untuk menguji pengecilan fail.
• ▸ TIN pembeli yang salah, untuk memastikan sistem menangkap ralat sebelum juruwang menutup transaksi.

Ralat yang hampir pasti muncul ada dua. Invalid Structure bermaksud urutan elemen dalam dokumen tidak mengikut skema. Item code atau kod negeri yang tidak aktif pula bermaksud data item dalam sistem kedai sudah lama tidak dikemas kini. Kedua-duanya bukan masalah MyInvois. Kedua-duanya masalah data dalam sistem kedai.

Apa yang tidak termasuk dalam kerja ini

Kerja integrasi menghantar data. Ia tidak mendaftarkan perniagaan anda dengan LHDN, tidak menyelesaikan isu TIN dalam MyTax, tidak memberi nasihat cukai, dan tidak menggantikan akuan juruaudit. Kalau vendor menjanjikan semua itu dalam satu pakej integrasi, tanya siapa yang menandatangani akuan itu.

Tanggungjawab undang-undang kekal pada pemilik perniagaan. Sistem yang betul mengurangkan kerja dan mengurangkan ralat, tetapi ia tidak memindahkan tanggungjawab itu kepada pembangun.

Kalau anda mahu tahu sama ada POS sedia ada boleh dihubungkan, mulakan dengan satu dokumen. Hantar satu contoh resit jualan dengan nama dan nombor pembeli dibuang, dan saya akan tandakan medan mana yang belum ada dalam sistem itu. Dari situ keputusan sama ada sambung atau tukar menjadi lebih jelas. Halaman perkhidmatan menerangkan skop kerja, dan halaman mula di sini menerangkan urutan projek dari dokumen pertama hingga go-live.