2026 新舊發票制度大比拼：傳統紙本 vs LHDN 電子發票 5 大核心差異解析
還在用 PDF 或紙本開單？2026 馬來西亞電子發票進入新一輪實施階段。本文比較傳統發票與 LHDN e-Invoice 在驗證、格式、修改、零售彙整與特殊支出上的差別。
文章目录2 个段落
傳統發票開好後，工作大多留在企業內部。商家把紙本或 PDF 交給客戶，會計人員入帳，相關文件等到報稅、審計或查核時才拿出來。LHDN 電子發票把驗證放到了交易流程中。供應商要把交易資料提交至 MyInvois，通過驗證後才會取得 UUID、驗證時間和驗證連結。
這個差別會一路影響開單、改錯、零售彙整和海外支出的處理方式。先看清流程，比記住幾個新名詞有用。
本文依據 IRBM e-Invoice Guideline v4.7 與 IRBM e-Invoice Specific Guideline v4.8 整理。若你還需要實施時間表、豁免與完整操作框架，可先讀 2026 馬來西亞 e-Invoice 終極指南。
這篇文章可以直接跳到哪裡
- 先確認企業何時開始實施
- 用一張表看懂五項核心差異
- 驗證怎樣改變一張發票的生命週期
- 為什麼 PDF 漂亮仍然不等於資料正確
- 開錯以後應取消還是另開調整文件
- 普通收據與逐筆電子發票怎樣分流
- 哪些交易改由買方負責開票
- 用一筆 RM3,200 銷售走完整個流程
- 企業應先改系統還是先改分工
先確認你的實施日期
2026 年並不代表每一名納稅人的義務完全相同。Guideline v4.7 把年營業額或收入不超過 RM5 million 的既有納稅人列入 2026 年 1 月 1 日階段，也另外規定部分 2023 年至 2025 年開始營業的新業務在 2026 年 7 月 1 日實施。年營業額或收入低於 RM1 million 的納稅人目前獲豁免，但指南列出的例外、關聯實體和日後收入變化仍要分開判斷。
Specific Guideline v4.8 也為 2026 年階段提供截至 2027 年 12 月 31 日的 interim relaxation。期間可採用較寬鬆的合併處理方式。這項寬限有自己的條件，不能理解成電子發票義務整段延期。
五項核心差異一覽
| 比較項目 | 傳統發票 | LHDN 電子發票 |
|---|---|---|
| 驗證時間 | 發票由商家交給客戶，稅務機關通常在後續申報或查核時接觸文件 | 交易資料提交至 MyInvois，系統以 near real-time 方式驗證 |
| 文件形式 | 紙本、PDF 或會計系統列印格式，主要供人閱讀 | 核心是符合指定結構的 XML 或 JSON，PDF 只是視覺化版本之一 |
| 改錯方法 | 依企業原有流程作廢、重開或調整 | 驗證後 72 小時內可申請拒絕或取消，之後通常以 credit note、debit note 或 refund note 調整 |
| B2C 處理 | 消費者取得普通收據，商家按原有方式彙總收入 | 消費者不索取個別電子發票時可先拿普通收據，供應商其後提交 consolidated e-Invoice |
| 特殊支出 | 企業使用供應商發票、收據或付款文件入帳 | 指定交易由買方開 self-billed e-Invoice，責任落在實際付款或交易的一方 |
1. 驗證進入開單流程
傳統流程裡，發票先在買賣雙方之間流轉。LHDN 電子發票多了一個固定動作。供應商透過 MyInvois Portal 或 API 提交資料，MyInvois 驗證成功後回傳 UUID、驗證日期與時間，以及驗證連結。
供應商仍要把通過驗證的電子發票或其視覺化版本交給買方。若分享的是 PDF 等視覺化版本，QR Code 可讓買方查驗該電子發票是否存在，以及目前處於什麼狀態。
這也說明了為何普通 PDF 不能單靠檔名變成 LHDN 電子發票。PDF 可以是客戶看到的版面，MyInvois 驗證的是規定格式與欄位中的交易資料。
把兩套流程攤開後，差別不只多了一次上傳。
| 流程位置 | 傳統發票通常怎樣做 | LHDN 電子發票多了什麼 |
|---|---|---|
| 開票以前 | 業務把客戶名稱和金額交給會計 | 還要確認 TIN、註冊資料、交易分類及其他適用欄位 |
| 文件建立 | 系統產生內部發票號碼和 PDF | 系統另外建立可提交的結構化資料 |
| 對外發送 | PDF 或紙本直接交給客戶 | 先提交 MyInvois，驗證後才取得 UUID 與驗證資料 |
| 客戶核對 | 客戶查看版面、金額和付款條件 | 客戶仍要核對內容，也可透過驗證連結查看文件狀態 |
| 發現錯誤 | 依企業內部做法作廢或重開 | 依 72 小時窗口和調整文件規則處理，原驗證紀錄不會因刪除本地檔案而消失 |
| 保存紀錄 | 保存發票、付款和會計分錄 | 還要把本地單號、UUID、驗證狀態與後續調整連起來 |
內部發票號碼與 UUID 也不是同一樣東西。前者由企業的系統編排，方便銷售、收款和帳簿追蹤。後者在 MyInvois 驗證成功後產生，用來辨認那一份已驗證文件。企業若只保存 PDF，沒有把兩個識別資料建立對應，遇到退貨或查帳時仍要逐份尋找。
從這條文件路徑來看，我的理解是，電子發票真正增加的並非一次提交動作，而是交易狀態的交接責任。這是根據上述驗證、分享和修正流程形成的實務判斷，並非指南原文。系統可以回傳成功或失敗，企業仍要決定誰接收結果、誰處理錯誤，以及哪一份紀錄才是目前有效版本。
2. 格式從版面轉向結構化資料
紙本發票和一般 PDF 首先照顧人怎樣閱讀。公司名稱、日期、品項和金額排得清楚，客戶與會計人員便能處理。電子發票還要讓系統讀懂每一項資料。
IRBM 的驗證規則支援 XML 與 JSON，並採用 UBL 2.1 發票標準。TIN、註冊或身分資料、交易分類、幣別、稅務資料及品項明細要放在指定位置。實際必填內容會隨交易和適用情況改變，不能把一張固定的欄位清單套到所有交易。
企業挑選 POS、ERP 或會計軟體時，應檢查它能否保存原始交易資料、處理 MyInvois 回應，也能把 UUID 和驗證連結帶回客戶文件。只會輸出漂亮 PDF 的系統，仍缺少電子發票流程中最關鍵的一段。需要評估系統時，可參考 馬來西亞 Invoice 系統挑選指南。
實際準備時，可以把資料分成三層。第一層是客戶與供應商主檔，包括名稱、TIN、註冊號碼和聯絡資料。第二層是每筆交易才會改變的內容，包括品項、數量、稅務處理、折扣與幣別。第三層是提交後才出現的回應資料，包括 UUID、驗證時間、狀態和錯誤訊息。
三層資料混在同一個備註欄會很難維護。客戶更換註冊資料時，主檔要先更新，不能等到每張發票驗證失敗後才逐張補。交易資料也不能因上一張發票使用某個分類，就讓系統永久沿用。回應資料則應跟原交易綁定，否則同事只看見已寄出的 PDF，未必知道提交是否成功。
MyInvois 驗證通過，也不代表買賣雙方已經核對所有商業內容。買方仍應查看供應商、品項、金額和交易性質是否正確。系統驗證解決的是指定欄位與格式能否被接受，不能代替採購人員確認貨物有沒有收到，也不能代替財務人員判斷費用應歸在哪一家公司。
3. 驗證後的錯誤要留下調整紀錄
電子發票通過驗證後，買方可在驗證時間起 72 小時內提出 rejection request，並說明錯誤原因。供應商同意後，仍須在同一個 72 小時期限內完成取消。供應商發現自己開錯，也可以在驗證後 72 小時內主動取消。
72 小時過後，系統不再接受取消。後續金額或交易調整要視情況另開 credit note、debit note 或 refund note。這些文件各有用途。Credit note 用於減少原發票金額而沒有退款的情況，debit note 記錄追加費用，refund note 則確認款項已退回買方。
72 小時功能是方便買賣雙方快速處理錯誤的窗口。企業也可直接用調整文件處理，不一定要先走拒絕與取消。詳細流程可查看 Credit Note、Debit Note 與 Refund Note 處理指南。
實務上可以先問三個問題。錯誤是否在驗證後 72 小時內發現，原交易是否仍然成立，以及金額最後要增加、減少還是退還。還在窗口內而整張交易資料錯誤，可以考慮拒絕與取消。交易仍成立，只是其後出現折讓、追加費用或退款，便要按照實際變化選擇調整文件。這樣處理留下的是一條可追溯的文件鏈，不是一批互相看不出關係的 PDF。
4. 普通收據仍會存在，月底彙整方式改了
B2C 交易中，消費者不要求個別電子發票時，商家仍可照常發普通收據。供應商要把當月尚未開立個別電子發票的交易彙整，並在月末後七個日曆天內提交 consolidated e-Invoice。
消費者拿到收據後又想索取個別電子發票，原則上應在交易發生的同一個月提出。這個截止點讓商家知道哪些收據可以放入月底彙整。月底最後幾天的交易尤其要把索取方式和內部 cut-off 說清楚。
合併處理也有例外。Specific Guideline v4.8 列出不得合併的行業與交易。自 2026 年 1 月 1 日起，任何單筆超過 RM10,000 的交易原則上要逐筆開立。汽車銷售、機票、指定建築合約和部分其他活動也有逐筆要求。處於 interim relaxation 的納稅人可採用指南第 16 節的寬鬆安排，不能把正式規則與過渡安排混在一起。
收銀系統因此要能替每一筆收據留下後續狀態。消費者已索取個別電子發票的交易，不應再次進入同月的合併資料。尚未索取的交易可以留在待彙整清單，但到了企業設定的截止點，負責人要再次檢查單筆金額、交易類型和寬限期資格。
一名消費者在月初買貨，月中拿收據回來要求個別電子發票，商家完成逐筆開票後，應把原銷售列從待彙整名單移除。若系統只保存每日總額，沒有保存收據層級的狀態，到了月末便很難證明同一筆銷售沒有被重複納入。普通收據仍然存在，商家還要記錄收據之後走了哪一條文件路徑。
5. Self-billed 改變了誰負責開單
Self-billed e-Invoice 最容易出錯的地方，是企業只把它當成一種新文件名稱。這套機制改換了開單責任。指定交易中，買方要代替供應方建立電子發票並提交驗證。
常見情況包括向外國供應商購買商品或服務、支付代理商或經銷商報酬、若干利潤分配、與未從事業務的個人交易，以及指南列出的電商、利息與保險款項等場景。每一類都有例外。企業不能看到對方沒有提供馬來西亞電子發票，就自行假定可以開 self-billed。
海外採購還有具體時限。進口貨物的 self-billed e-Invoice 最遲要在取得海關放行月份之後第二個月月底前開立。進口服務則最遲在付款或收到外國供應商發票兩者較早發生月份的下一個月月底前開立。外國供應商原本開出的 invoice 或 receipt 仍要保留，它提供交易內容和供應商資料；MyInvois 驗證過的 self-billed e-Invoice則記錄馬來西亞買方的電子發票責任。
這類交易最需要保存觸發日期。外國供應商發票日期、企業收到文件的日期、付款日期和海關放行日期看起來都像日期，真正決定期限的欄位會隨進口貨物或進口服務而改變。若應付帳款系統只留下付款日，財務人員未必能重建期限從哪一天開始計算。
用一筆 RM3,200 銷售走完整個流程
假設一家本地設計公司向企業客戶提供 RM3,200 的服務。業務在報價單上用了客戶的品牌名稱，會計主檔保存的卻是另一家關聯公司的註冊資料。工作完成後，會計直接從舊主檔建立發票。
提交以前，負責人應把採購訂單、客戶確認的法定名稱、TIN 和交易內容對在一起。資料一致後再建立結構化文件並提交 MyInvois。驗證成功後，系統保存本地發票號碼、UUID 和驗證時間，再把帶有驗證連結的視覺化版本交給客戶。
若客戶在驗證後第二天指出買方實體錯誤，雙方仍處於 72 小時窗口。客戶可提出拒絕要求，供應商確認後在期限內取消，再用正確實體資料開立新文件。若錯誤到第五天才被發現，便不能把本地 PDF 改名後覆蓋，也不能在 MyInvois 取消原文件。企業要根據實際交易與調整性質，決定如何用適當文件留下更正紀錄，必要時交由稅務專業人士確認。
這個演示案例只用來說明已確認的流程，不代表每一種買方資料錯誤都有完全相同的處理結果。傳統發票常把改錯理解為換一份版面，電子發票還要同時處理交易事實、本地帳簿與 MyInvois 文件狀態。任何一層沒有連起來，後面對帳時都可能出現兩個版本。
企業現在應該先改哪一步
先從一張真實發票走完整個流程。看銷售資料在哪裡產生，誰負責補齊買方資料，MyInvois 驗證失敗由誰處理，UUID 回來後又保存在哪裡。退貨、月底收據彙整和海外軟體費用也各走一次。
| 工作位置 | 最少要回答的問題 | 建議留下的紀錄 |
|---|---|---|
| 銷售或收銀 | 客戶是否要個別電子發票，資料由誰收集 | 收據狀態、索取日期、客戶提交的資料 |
| 財務開票 | 這筆交易由誰開票，能否合併，何時到期 | 文件類型、期限、覆核人 |
| 系統提交 | 驗證失敗由誰查看，成功後資料回寫哪裡 | 錯誤訊息、UUID、驗證時間和狀態 |
| 售後調整 | 錯誤何時發現，金額如何變化 | 原文件、拒絕或取消紀錄、調整文件 |
| 每月關帳 | 哪些收據已逐筆開票，哪些仍要合併 | 排除清單、合併批次與總額對帳 |
這樣很快就能看出問題落在系統還是工作分工。交易量少的企業可以使用 MyInvois Portal。交易量大、資料分散在 POS 和 ERP 的企業，才需要進一步評估 API 或服務商。實務安排要依企業的實施日期、豁免資格、交易類型和 interim relaxation 狀態決定；本文提供一般資訊，個別稅務處理仍應由熟悉企業交易的稅務專業人士確認。
衍生閱讀
- 主篇｜2026 馬來西亞 e-Invoice 終極指南
- 2026 馬來西亞 SME 電子發票完整檢查清單
- Self-Billed 電子發票常見查稅風險
- Credit Note、Debit Note 與 Refund Note 處理指南
- 馬來西亞 Invoice 系統挑選指南
接着读
