台灣每年電商糾紛申訴案中，發票問題佔有相當高的比例，但多數都不是商家惡意逃漏稅，而是系統設定沒有跟上合規要求。一張發票漏開、統編填錯，或是作廢流程沒有走完整，輕則讓消費者投訴，重則面臨稽查補稅，損失遠超過一套外掛的年費。

WooCommerce 電子發票的整合，在技術上並不複雜，但選型邏輯、與金流的串接方式、B2B 統編開立細節，以及作廢補開流程，每個環節都有容易忽略的設定。這篇文章依序把這四塊拆開說清楚，讓開站後的發票合規問題一次解決。

財政部自 2025 年 1 月 1 日起修正《加值型及非加值型營業稅法》相關規定，明確要求營業人開立電子發票後，B2C 發票須在 48 小時內、B2B 發票須在 7 日內將資料傳輸至財政部電子發票整合服務平台存證，未依規定時限傳輸者得按次處以行為罰。這個背景讓「外掛能否自動即時上傳」從選配功能，變成選型時的首要考量。

雲端發票外掛的 4 個選型關鍵

台灣市場上專為 WooCommerce 設計的電子發票外掛選擇不少，但選錯會讓後續維護成本大增。把候選外掛壓到 2 至 3 款後，用下面這 4 個指標逐一比對，比看功能截圖更有效率。

• 即時傳輸能力：外掛是否在訂單完成當下自動呼叫發票 API、即時傳輸至財政部平台，還是需要手動批次處理。B2C 48 小時的時限對多數商店問題不大，但 B2B 發票若涉及大客戶對帳，即時傳輸可避免對方催單的困擾。
• 載具類型覆蓋：至少要支援手機條碼、自然人憑證條碼、捐贈碼三種，加上 B2B 統編開立。若商店有會員系統，能否在會員資料儲存常用載具，也直接影響回購的結帳體驗。
• 發票管理後台：能否在 WooCommerce 訂單頁面直接查看發票號碼、手動重開、手動作廢，而不必跳回發票加值中心的後台操作。管理動作整合在同一介面，出問題時的處理速度差距很大。
• 版本維護與相容性：WordPress 核心與 WooCommerce 更新頻率高，外掛若停止維護，新版 PHP 或 WooCommerce 9.x 以上版本就可能出現不相容問題。選擇有持續更新紀錄、且明確標示相容 WooCommerce 版本的外掛，可以省去大量除錯時間。

金流綁定的問題也值得提早考慮。有些外掛只支援單一金流服務商的發票 API，若商店未來要新增其他收款方式，就必須另尋解法。選擇以獨立外掛形式運作、與金流解耦的方案，彈性較高。

主流外掛功能橫向比較

目前台灣 WooCommerce 電子發票外掛主要分為三類，一是金流服務商隨附或官方釋出的專用外掛，二是第三方開發者發布的獨立外掛，三是整合金流、物流、發票的訂閱制套件。以下依幾個決策面向橫向比較這三類的代表方案。

表格之外有幾個判斷點值得補充說明。如果商店的主要收款方式是綠界信用卡或超商代碼，使用官方外掛可以讓設定路徑最短；但若商店同時整合多種金流，或對延遲開立有需求（例如預購商品或虛擬商品要確認後才開票），第三方獨立外掛通常提供更細的控制選項。訂閱制套件適合剛起步、希望一次解決多個模組的商店，但要留意月費會隨功能模組數量累積。

外掛安裝後的金流串接設定

外掛本身只是前端介面，真正讓發票能夠開立並合法傳輸的，是背後與發票加值中心 API 的連線設定。這塊沒設好，外掛裝了也無法運作。

取得 API 金鑰與測試環境憑證

正式上線前，必須先在所選擇的電子發票加值中心（如綠界）完成商家帳號申請、開通電子發票功能，並取得商店代號（MerchantID）與 Hash Key、Hash IV 等 API 憑證。加值中心通常提供沙盒（Sandbox）測試環境，建議先用測試憑證在開發站完整執行一次開立、作廢、補開流程，確認資料正確無誤後，再切換為正式環境憑證上線。

測試時要特別注意，沙盒憑證與正式憑證格式相同但值不同，切換時必須逐一比對，漏改一個欄位就會導致正式環境出現「憑證驗證失敗」的錯誤。

外掛設定頁面的必填欄位

進入 WooCommerce 後台的外掛設定頁，需要填入的核心欄位通常包括環境模式（測試／正式）、商店代號、Hash Key 與 Hash IV，以及發票字軌號碼的前兩碼（由國稅局核准後取得）。字軌號碼這個欄位是最容易漏填的一項，因為它不在發票加值中心後台，而是要另外向所在地國稅局申請電子發票字軌、核准後才能在財政部平台取號，再填入外掛設定。

商店開立第一張發票前，必須確認字軌號碼已核准並正確填入，否則即便 API 連線成功，發票仍會因為缺少合法字軌而無法傳輸存證。

自動開立時機的選擇

多數外掛提供兩種自動開立觸發時機，一是「訂單付款成功」，二是「訂單狀態變更為已完成」。兩者各有適用場景。數位商品或即時交付的服務，建議設定付款成功即開立，符合 48 小時傳輸要求並降低遺漏風險。實體商品若有備貨或出貨確認流程，可考慮設定在訂單完成後才開立，避免因退貨頻繁而增加作廢次數。

延遲開立功能（部分外掛支援）適用於有多日備貨期的商店，但要留意延遲時間加上傳輸時間，仍須在法定期限內完成。

B2B 統編發票的開立設定

B2B 統編發票在技術上的差異其實只有一個，就是發票資料中是否帶入買方統一編號。帶了統編，財政部平台就識別為 B2B 電子發票；不帶就是 B2C。圍繞這個「帶不帶統編」的問題，有幾個設定細節值得單獨說清楚。

結帳頁面的「公司抬頭／統一編號」欄位，必須讓買家主動勾選或填寫，而不能預設勾選或隱藏。這是消費者保護的基本要求，也讓商家在資料面可以明確區分 B2C 與 B2B 訂單。大多數外掛在結帳頁的欄位設計符合這個邏輯，但有些版本的預設設定會把統編欄位設為必填，導致一般消費者結帳時被迫填寫。這個設定要確認是「選填」而非「必填」。

買方填入統編後，部分外掛（如綠界 2024 年更新版）新增了統編格式驗證功能，會在結帳頁即時比對財政部資料庫確認統編是否存在，避免因填錯統編而導致後續 B2B 發票認列失敗。這個功能在多數第三方外掛尚未普及，若商店的 B2B 訂單量大，可以把這個功能的有無列為選型時的加分項。

發票開立後，B2B 的傳輸時限是 7 日，這個時間比 B2C 寬鬆，但並不代表可以拖延。企業買家通常有固定的對帳週期，若發票遲遲未入財政部平台，對方的財務人員可能無法正常報帳，進而影響商業關係。建議 B2B 訂單一律設定即時開立或最多隔日開立，而非使用較長的延遲設定。

發票作廢、折讓與補開的處理邏輯

電子發票一旦開立並傳輸至財政部平台，就無法直接修改，任何異動都必須走特定流程。這個設計確保了存證資料的完整性與不可竄改性，但對商家來說意味著退換貨、取消訂單、填錯資訊等情況都需要額外操作。

發票作廢適用於發票開立後尚未申報、且買賣雙方合意取消的情況。在 WooCommerce 後台，多數外掛允許管理員在訂單頁面直接點選「作廢發票」，外掛會呼叫加值中心 API 將作廢資料回傳至財政部平台。B2B 作廢有額外要求，財政部規定應取得買方同意的書面紀錄（電子郵件確認即可），這是商家自行存檔的內部管理要求，而非外掛端的設定問題。作廢後若需重新開立正確發票，必須在後台修正訂單資訊後，由外掛重新呼叫 API 開立新發票，而不是直接編輯原始發票。

折讓（銷貨退回）適用於買賣雙方針對已申報銷售額進行部分或全額退款的情況。這個流程比作廢複雜，因為 B2B 折讓需要買方出具「銷貨退回或折讓證明單」，且只有在原始發票上有載明買方名稱與統一編號的情況下才能適用。目前多數電子發票外掛對折讓的自動化支援程度不一，部分只能在加值中心後台手動建立折讓單，而無法在訂單頁面一鍵操作。選型時若退換貨頻率高，值得優先確認外掛對折讓流程的支援深度。

補開發票的情境通常是「訂單付款成功但發票未自動開立」，這種情況可能來自 API 逾時、設定漏填，或外掛版本衝突。補開時要注意開立日期的問題：B2C 發票若超過 48 小時仍未傳輸，技術上已逾期，補開後仍需盡快傳輸。若商店每月都出現補開案例，代表外掛的自動開立觸發機制有問題，應回頭排查 API 連線設定或版本相容性，而非把補開流程視為常態。

發票合規的問題，大多不在第一次設定，而在日後版本更新後的設定偏移。WooCommerce 或外掛更新後，建議至少在一筆測試訂單上確認發票仍能正常開立與傳輸，避免靜默失敗——系統沒有報錯，但發票其實沒有傳出去。