一、 電子發票系統的核心行為邏輯

電子發票在馬來西亞的推行，本質上不是憑證形式的變化，而是責任記錄方式的變化。LHDN 的 MyInvois 系統只關心三件事：

1. 這筆交易是否必須進入 IRBM 系統？
2. 由誰承擔「進入系統」的責任？
3. 以哪一種發票結構進入系統？

所有的規則、例外、權變，均圍繞這三點展開。

graph TD
    Start[發生商業交易] --> Q1{交易是否須進入系統?}
    Q1 -- 是 --> Q2{誰承擔記錄責任?}
    Q1 -- 否 --> End[非受控交易]
    Q2 -- 供應商 --> Type1[標準電子發票 / 綜合發票]
    Q2 -- 買方補位 --> Type2[自開電子發票 Self-billed]

---

二、 發票類型的功能劃分

系統不關心交易細節，只關心是否有一張「合法結構」的記錄。對應三種發票行為：

發票行為	系統目的	記錄責任方
標準電子發票	供應商確認收入	供應商提交
自開電子發票	買方確認費用	買方補位提交
綜合電子發票	供應商確認匯總收入	供應商月底匯總提交

---

三、 標準電子發票的適用邊界與限制

3.1 適用前提

標準流程只在一個條件下成立：供應商本身受馬來西亞電子發票制度約束。只要供應商無法、無需、或不被要求開票，標準流程即失效。

3.2 綜合電子發票的硬性限制 (2026 起)

以下交易被系統定義為「高價值、可追溯、不可模糊化交易」，原則上禁止使用綜合電子發票：

• 汽車銷售、建築工程與材料、航空服務。
• 支付代理佣金、博彩獎金。
• 單筆超過 RM 10,000 的交易。
• 電信、電力服務。

---

四、 自開電子發票 (Self-billed) 的系統本質

自開電子發票不是一種便利機制，而是系統補位機制。當記錄責任被強制轉移給買方時，具備以下共同特徵：

1. 收款方不在馬來西亞系統內（外國供應商）。
2. 收款方不是商業主體（個人）。
3. 收款方不承擔開票義務。

4.1 強制自開的主要情境

情境	收款方	開票責任補位者
外國供應商	境外實體	馬來西亞買方
非商業個人	個人	付款公司
代理佣金	代理/經銷商	支付公司
平台結算	商家/司機	電商平台
保險理賠	受益人	保險公司

---

五、 跨境交易的責任切割

跨境交易不存在中間態，只有單向的責任歸屬。

graph LR
    subgraph 進口流程
    A[外國供應商] -->|不屬 IRBM 管轄| B[馬來西亞買家]
    B -->|強制自開| C[IRBM 系統記錄費用]
    end
    
    subgraph 出口流程
    D[馬來西亞賣家] -->|承擔系統責任| E[標準電子發票]
    E -->|發送| F[外國買家]
    end

外國 TIN 的系統處理

系統並不要求真實性，只要求結構成立：

• 外國買方：固定代碼 EI00000000020
• 外國供應商：固定代碼 EI00000000030

---

六、 平台型交易的三重角色切換

電子商務平台在系統中具有多重身份節點：

對象	平台角色	發票類型
消費者	供應商	標準 / 綜合電子發票
商家/服務提供者	買方	自開電子發票 (記錄支出)
商家收費 (服務費)	供應商	標準電子發票 (記錄收入)

---

七、 墊付款 (Disbursement) 與 報銷 (Reimbursement)

系統判斷的唯一標準：原始發票開給誰？

1. 墊付款 (Disbursement)：
   • 發票流向：原始供應商 → 最終客戶。
   • 系統結果：中介不重新開票，僅代付。
2. 報銷 (Reimbursement)：
   • 發票流向：原始供應商 → 中介。
   • 系統結果：中介必須在對外發票中列示該費用，作為獨立項目。

---

八、 員工費用的權變結構

這是系統中唯一允許「非完美數據」的區域。IRBM 允許企業接受以員工名義開具的電子發票、傳統收據或海外單據，無需強制自開電子發票。

---

九、 過渡期的系統行為變化

過渡期放鬆的是精度，而不是義務。

• 不變的底線：必須提交、必須在期限內、必須有結構。
• 允許的靈活性：所有交易可綜合、描述欄可簡化、無需逐筆回應。

---

十、 結論：MySignalForge 的系統思維

電子發票是一個嚴密的責任映射系統。理解了自開是「缺口補償」、跨境是「責任單向化」、平台是「多身份節點」，您就能在數位化轉型中精準掌控風險。

MySignalForge 將持續為您監控系統變動，提煉數據價值。