Apa yang AutoCount, SQL, Bukku dan QNE hantar, dan apa yang mereka serahkan kepada anda

Terdapat sejenis kandungan integrator yang membayangkan pakej perakaunan Malaysia tidak boleh melakukan e-invois. Mereka boleh, dan modulnya lebih lengkap daripada yang dicadangkan oleh promosi. Sesiapa yang menjual jambatan kepada anda harus bermula dengan memberitahu anda apa yang anda sudah miliki, kerana dalam kebanyakan kes jawapannya ialah anda sudah memiliki cukup.

AutoCount menerangkan fungsi Get TIN untuk mengumpul nombor pengenalan cukai pelanggan dan butiran dalam satu tindakan, e-invois disatukan yang dijana daripada AutoCount POS untuk runcit dan F&B merentas pelbagai cawangan, e-invois bil sendiri yang dihasilkan secara automatik daripada data invois pembelian, mekanisme penyerahan pintar yang meletakkan invois dalam barisan semasa masa henti LHDN dan mencuba semula sehingga ia disahkan, dan kod QR pada resit POS supaya pelanggan boleh meminta e-invois selepas transaksi. Ia merangkumi AutoCount Accounting 2.0, Cloud Accounting, POS 5.0 dan OneSales.

SQL menyatakan penyerahan individu dan pukal, serahan kelompok satu klik dan e-mel kepada LHDN, e-invois disatukan bulanan, e-invois bil sendiri yang dikeluarkan daripada bil pembelian, lebih 1.4 juta rekod perniagaan terbina dalam supaya TIN pelanggan boleh dicari secara langsung, pembatalan dalam tempoh 72 jam dengan pemasa kira detik yang menunjukkan dokumen mana yang masih layak, mengimport e-invois terus daripada pembekal, dan penjejakan status masa nyata.

Bukku merangkumi MyInvois dan rangkaian Peppol, dengan penyerahan standard, disatukan dan bil sendiri, penyerahan berasingan atau pukal, semakan profil MyInvois Ready yang menandakan maklumat syarikat yang tidak lengkap, dan pembatalan 72 jam. Bukku juga mendakwa pelan e-invois percuma secara kekal, yang merupakan tuntutan mereka sendiri dan bukan penemuan bebas, tetapi itulah sebabnya ia muncul dalam begitu banyak susunan perniagaan kecil.

QNE, kini dijenamakan semula sebagai N3 AI Accounting, menyambung ke portal MyInvois untuk menjana dan mengesahkan e-invois daripada sistem perakaunan, dengan pengumpulan maklumat pelanggan dibina di sekitar masalah tangkapan yang sama yang dihadapi oleh semua orang.

Dirumuskan daripada halaman e-Invois semasa setiap vendor. Ini adalah apa yang mereka kata mereka lakukan, bukan ujian bebas terhadapnya, dan ia berubah dengan keluaran. Sahkan terhadap versi yang anda sebenarnya lesenkan sebelum membuat keputusan mengenainya.

Ini datang daripada dokumentasi SDK LHDN sendiri, dan ia terpakai pada pakej perakaunan anda, pada middleware, dan pada apa sahaja yang kami bina, secara sama rata. Ia adalah sebab penghantaran pukal adalah masalah kejuruteraan, bukan gelung.

Panduan pengesahan TIN adalah yang wajar dibaca dua kali. LHDN secara eksplisit memberi amaran bahawa permintaan berlebihan boleh menyebabkan throttling, memberitahu anda untuk tidak memanggil API berulang kali atau sebelum setiap penghantaran dokumen, dan mengesyorkan caching hasil pengesahan dalam ERP. Jadi alat yang menawarkan untuk mengesahkan setiap TIN dalam master pelanggan anda atas permintaan sedang menerangkan cara untuk dikenakan throttling.

Setiap modul di halaman ini menghantar apa yang dipegang oleh pakejnya sendiri. Itu bukan batasan perisian; itu adalah definisinya. Jurang terbuka apabila dokumen yang diterima pelanggan anda tidak dicipta di sana.

Ini adalah keadaan normal perniagaan operasi. Pengusaha pengangkutan mengebil dari perjalanan. Syarikat sewa kren mengebil dari hari-kren. Bengkel mengebil dari helaian kerja dengan bahagian dan buruh. Perunding mengebil dari penglibatan dan helaian masa. Dalam setiap kes, terdapat rekod operasi yang merupakan sumber sebenar invois, dan pakej perakaunan menerima versi ringkasan selepas itu, jika ia menerima langsung.

Apabila seseorang menaip semula rekod operasi itu ke dalam pakej perakaunan supaya modul e-invois boleh menghantarnya, anda mempunyai dua sistem rekod dan salinan manual di antaranya. Di situlah angka tersilap datang, dan yang lebih penting, di situlah penghantaran terlepas datang, kerana tiada apa-apa yang tahu tentang perjalanan yang tidak pernah ditaip. Modul tidak boleh membetulkan ini. Ia adalah hulu modul.

Ujiannya mudah dan anda boleh menjalankannya hari ini. Ambil invois bulan lepas kepada pelanggan dan tanya, untuk setiap satu, sama ada ia lahir dalam pakej perakaunan atau tiba di sana secara manual. Jika bahagian yang bermakna tiba secara manual, masalah e-invois anda adalah masalah penangkapan dan membeli penghantar yang lebih baik tidak akan menyentuhnya.

Setiap pakej menawarkan beberapa bentuk bantuan TIN. SQL membawa lebih 1.4 juta rekod perniagaan supaya anda boleh mencari TIN pelanggan secara langsung. AutoCount mempunyai fungsi Get TIN. Ini benar-benar berguna dan ia menyelesaikan separuh masalah yang salah.

Carian memberitahu anda TIN bentuk yang betul yang dikaitkan dengan nama yang menyerupai pelanggan anda. Hanya LHDN yang boleh memberitahu anda sama ada TIN itu betul untuk pembeli itu, dan ia melakukannya melalui API Validate Taxpayer's TIN, yang mengambil TIN bersama-sama dengan jenis dan nilai pengenalan — NRIC, pasport, BRN atau tentera — dan menjawab 200, 400 atau 404. Itu soalan yang berbeza daripada "adakah ini kelihatan seperti TIN", dan itulah soalan yang menentukan sama ada penghantaran anda disahkan.

Pengesahan format bukan pengesahan kebenaran. TIN bentuk yang betul boleh menjadi milik entiti yang berbeza sepenuhnya, dan semakan jurang yang melaporkan master pelanggan sebagai lengkap sedang melaporkan bahawa medan diisi, bukan bahawa ia betul. Mana-mana alat yang mendakwa telah mengesahkan senarai pelanggan anda tanpa memanggil LHDN adalah melebih-lebihkan dirinya.

Kesannya pada binaan ialah pengesahan adalah pada penciptaan pelanggan, dicache, dengan jenis dan nilai pengenalan disimpan bersama TIN supaya jawapan boleh disemak semula. Melakukannya dalam laluan penghantaran adalah lebih perlahan dan, mengikut panduan LHDN sendiri, cara untuk dikenakan throttling. Kebanyakan modul vendor tidak mendedahkan cache atau pasangan pengenalan, yang baik untuk seratus pelanggan dan masalah untuk empat ribu.

Semasa tempoh kelonggaran, penerangan produk teks bebas dibenarkan, sebab itu tiada siapa yang merasainya sekarang. Kelonggaran untuk kumpulan PKS berjalan sehingga 31 Disember 2027 dan penguatkuasaan penuh bermula pada 1 Januari 2028. Mulai tarikh itu, setiap baris memerlukan kod klasifikasi yang betul.

Ini adalah projek data, bukan ciri perisian. Setiap produk dan perkhidmatan yang anda jual perlu dipetakan kepada kod, pemetaan perlu disimpan terhadap item dan bukannya dipilih pada masa invois, dan seseorang yang mempunyai pengetahuan komersial perlu membuat keputusan apabila pemetaan tidak jelas. Perniagaan dengan empat puluh produk boleh melakukannya dalam satu petang. Perniagaan dengan empat ribu SKU sedang menjalankan projek.

Modul vendor akan menghantar apa sahaja kod yang ada pada baris. Apa yang tidak dilakukan oleh mana-mana daripada mereka ialah memberitahu anda item mana daripada empat ribu item anda yang belum ada kod yang boleh dipertahankan, atau mengesan corak di mana keseluruhan keluarga produk diberikan kod terdekat dalam dropdown kerana ia lebih cepat daripada berfikir. Laporan itu — liputan dan keyakinan merentas master item — adalah perkara yang berbaloi untuk dibina, dan ia berbaloi untuk dibina sekarang semasa ia kerja beransur-ansur dan bukannya pada suku terakhir 2027 bersama semua orang lain.

Modul penyerahan menolak keluar. Hampir tiada yang menarik balik dan membandingkan, dan asimetri itu adalah sebab begitu banyak perniagaan tidak dapat menjawab satu-satunya soalan yang penting: berapa banyak invois suku lepas yang LHDN benar-benar pegang sebagai disahkan?

Anda tidak boleh menjawabnya dari portal, kerana portal hanya tahu apa yang sampai kepadanya. Anda tidak boleh menjawabnya dari pakej perakaunan, kerana ia hanya tahu apa yang anda terbitkan dan, paling baik, apa yang ia fikir ia hantar. Jawapannya hanya wujud dalam perbezaan antara dua set, berdasarkan pengecam dokumen dan amaun. Kiraan baris yang sepadan tidak membuktikan apa-apa — set penyerahan yang terlepas dan set pendua yang bersaiz serupa membatalkan satu sama lain dalam jumlah.

Ini lebih penting sejak Julai 2026, kerana kini terdapat laluan yang ditakrifkan untuk populasi yang didedahkannya. Program Pendedahan Sukarela Khas e-Invois berjalan dari 7 Julai 2026 hingga 31 Disember 2027, dan pendedahan di bawahnya menggunakan versi dokumen khusus, SVDP 1.2 tanpa tandatangan digital dan SVDP 1.3 dengan tandatangan. Dokumen bertarikh belakang yang diserahkan di bawah versi biasa disahkan dengan sempurna dan bukan pendedahan di bawah program.

Jadi ada soalan khusus untuk diajukan kepada vendor anda, dan ia bukan "adakah anda menyokong e-invois". Ia adalah: bolehkah ini mengeluarkan versi dokumen SVDP, dan bolehkah ia menunjukkan saya tempahan berbanding disahkan untuk tempoh tertutup? Beberapa alat yang menyerahkan dengan cekap tidak boleh melakukan kedua-duanya, kerana program ini wujud selepas mereka.

Arahan persediaan QNE sendiri berbaloi untuk dibaca walau apa pun pakej yang anda gunakan, kerana ia menjadikan ciri struktur pasaran ini eksplisit. Arahan tersebut meminta anda menambah QNE Software Malaysia Sdn. Bhd. sebagai Perantara dalam portal MyInvois, dengan TIN dan nombor pendaftaran perniagaannya, tetapkan tarikh perwakilan, dan togol semua kebenaran. Produk kemudian didaftarkan sebagai sistem ERP utama anda dengan rahsia klien ditetapkan untuk tamat tempoh dalam tiga tahun.

Itu bukan kritikan terhadap QNE. Itulah cara model perantara berfungsi dan ia sah — seseorang perlu berkebolehan dari segi teknikal untuk bertindak bagi pihak anda, dan portal mempunyai mekanisme yang betul untuknya. Tetapi ia bermakna pihak ketiga mewakili syarikat anda kepada LHDN di bawah set kebenaran yang anda berikan, dan kebanyakan perniagaan yang memberikannya tidak membaca apa yang dilindungi.

Tiga perkara yang berbaloi untuk diketahui, untuk mana-mana vendor. Siapa perantaranya, tarikh perwakilan apa yang anda tetapkan, dan bagaimana anda menarik baliknya. Jawapan itu perlu ditulis di tempat yang boleh dicari oleh ketua kewangan anda, bersama tarikh tamat tempoh rahsia klien, kerana rahsia yang tamat tempoh secara senyap dalam tiga tahun adalah gangguan penyerahan pada tarikh yang tiada siapa ada dalam kalendar.

Model alternatif ialah syarikat anda sendiri memegang pendaftaran ERP dan sijil digital, dan perisian menyerahkan sebagai anda dan bukannya bagi pihak anda. Itu memerlukan pendaftaran ERP dengan LHDN dan sijil daripada pihak berkuasa pensijilan berlesen Malaysia yang dipegang oleh syarikat anda. Ia lebih banyak kerja untuk disediakan dan ia bermakna identiti yang menghadap LHDN adalah milik anda.

Lihat lajur kiri. Jika kebanyakan jawapan anda berada di tengah, modul vendor anda adalah pembelian yang tepat dan anda patut belanjakan wang untuk pembersihan data. Jika ia berada di sebelah kanan, jambatan sedang melakukan kerja yang tiada modul diliputi untuk dilakukan.

Empat perkara, mengikut urutan, dan tiada satu pun memerlukan vendor di dalam bilik. Ambil invois pelanggan bulan lepas dan kira berapa banyak yang lahir dalam pakej perakaunan berbanding yang ditaip ke dalamnya. Nombor itu sahaja yang menentukan isu penangkapan data.

Kemudian jalankan semakan kelengkapan ke atas master pelanggan anda: berapa banyak rekod yang membawa TIN pembeli, jenis dan nilai pengenalan, pendaftaran SST jika wujud, kod negeri dan maklumat hubungan. Asingkan medan kosong dan medan yang salah format, kerana medan kosong bermakna kerja belum siap dan nilai yang salah format bermakna kerja yang dilakukan dengan salah tetapi kelihatan siap.

Kemudian lakukan perkara yang sama ke atas master item anda untuk kod klasifikasi, dan jujurlah tentang kod mana yang dipilih kerana paling hampir dan bukannya yang betul. Kemudian, akhir sekali, tarik senarai invois lejar anda untuk tempoh tertutup dan bandingkan dengan apa yang LHDN pegang sebagai disahkan untuk tempoh yang sama, berdasarkan pengecam dan amaun dan bukannya kiraan.

Empat nombor itu memberitahu anda pembelian mana yang anda lakukan. Jika penangkapan data bersih dan data lengkap, beli modul itu dan jangan belanja apa-apa lagi. Jika jurangnya pada data, wang itu pergi kepada pembersihan dan penangkapan data dan bukannya pada penghantar. Jika invois lahir di luar lejar, tiada modul yang dapat mencapainya, dan itulah kes di mana jambatan adalah jawapan sebenar dan bukannya jualan tambahan.