台灣電子發票串接指南：開立、作廢、折讓與載具處理
網站要收錢，很多人會先想到金流；但真正在上線前才被發現、然後開始加班的，往往是發票。
原因很簡單：發票不是單一動作，而是一整組情境。開立只是其中最順利的那一種，退貨、換貨、部分退款、客人打錯統編、載具格式不對、對帳少一筆——每一種都要有對應的處理方式，而且錯了會直接牽動帳務。
這篇用非工程背景也能理解的方式，說明電子發票串接該怎麼規劃，以及驗收前要確認哪些事。
電子發票在系統裡扮演什麼角色
台灣的電子發票制度，簡單說是把原本的紙本流程移到數位：商家開立後上傳至財政部的整合服務平台，消費者可以用載具歸戶、查詢與對獎，商家也依規定進行後續的存查與申報。
對系統而言，這代表發票不是印出來就結束，它至少涉及三個方向的往返：
- 送出去：把交易資料依規定格式開立並上傳。
- 改回來：作廢、折讓、退回等後續異動也要同步回報。
- 對得上：你自己的訂單紀錄、金流的入帳紀錄、以及發票紀錄，三者必須能互相勾稽。
第三項是最常被低估的。金流成功但發票開失敗、或發票開了但訂單其實被取消，這類不一致如果沒有機制主動偵測，通常要等到月底結帳才會爆出來。金流端的對帳設計可以一併參考台灣金流串接指南，兩者的邏輯是同一套。
具體的格式規範、時限與申報方式屬於會變動的法遵細節，開發前請以財政部與你選用的服務商的官方文件為準，必要時請會計師一起確認。
兩種串接路線
透過加值中心或具備開立服務的業者：你的系統呼叫對方提供的介面送出交易資料，由對方負責格式轉換、上傳、存查與相關流程。
自行對接：自己處理字軌與號碼的管理、資料格式組裝、上傳與後續程序。
| 面向 | 透過服務商 | 自行對接 |
|---|---|---|
| 開發工作量 | 相對集中在介面串接 | 需處理格式與流程細節 |
| 法規變動的跟進 | 由服務商更新 | 自行追蹤並改版 |
| 彈性 | 受限於服務商功能範圍 | 可完全依需求設計 |
| 長期成本型態 | 持續性的服務費用 | 開發與維護人力 |
| 適合對象 | 多數中小型電商與系統 | 交易量大、有帳務團隊 |
沒有哪一種天生比較好，兩種在市場上都很常見。判斷可以從三個問題下手：你的交易量會不會大到讓服務費成為結構性負擔？團隊有沒有人能長期維護法遵變動？既有的 ERP 或帳務系統是不是已經有相關能力？ 如果第二題的答案是否定的，選服務商通常比較安全，因為要維護的不是第一次串接，而是往後每一次規範調整。
無論走哪一條，都要留意一件事：不要把發票邏輯直接寫死在結帳流程裡。把它獨立成一個明確的模組，日後換服務商或調整規則時，影響範圍才控制得住，這也是系統整合與 API 串接的基本原則。
一定要處理的幾種情境
規劃需求時，下面這幾種都要各自寫清楚誰觸發、什麼條件、失敗怎麼辦。
開立。最單純的一種，但要決定觸發時機：付款成功當下開、出貨時開、還是隔日批次開？不同商業模式答案不同，預購與客製商品尤其要想清楚。
作廢。交易根本不成立時使用，有適用的時間限制。系統要能從訂單取消的動作連動，而不是靠人記得去後台處理。
折讓。已經開立且不適合作廢時的處理方式，退貨、部分退款、事後折扣都可能走這條。要特別設計的是部分退款與同一訂單多次退貨的累計邏輯，這是最容易算錯的地方。
載具與歸戶方式。結帳時消費者可能選擇個人載具、公司統編、或捐贈。這些選項彼此互斥，而且各有必要欄位：開公司戶要有統一編號並驗證格式，捐贈要有可選的受贈單位，手機條碼要先檢查格式是否有效。錯誤的輸入應該在結帳當下就擋下來，而不是等開立失敗才回頭找客人。
中獎與通知。使用載具的消費者由平台端對獎，商家端要處理的是自己開立紀錄的完整性；若你有提供會員查詢發票的功能，要確認顯示的資料來源與狀態是最新的。
失敗重試。介面逾時、服務商暫時異常、資料驗證不通過，都要有明確處理：記錄失敗原因、可重送、且重送不會重複開立。重複開立比開不出來更麻煩，因為它必須再走一次作廢或折讓。
與訂單金流的對應
把三者的關係想成一條鏈：訂單狀態 → 金流狀態 → 發票狀態。設計時要逐一回答這些問題：
- 付款成功但發票開立失敗時，訂單要不要照常出貨？誰會被通知？
- 訂單取消時，作廢或折讓由系統自動觸發，還是需要人工確認？
- 使用折價券、紅利折抵、運費、贈品時，發票金額的組成怎麼計算？
- 分批出貨時，發票是一次開還是分次開？
- 每天有沒有一支自動對帳的程序，比對訂單、入帳與發票三方的差異並回報？
最後一項強烈建議做。只要有一個環節可能失敗，就必然會出現不一致，差別只在你是主動發現還是被動等人反映。這類自動對帳的機制，和物流端的狀態同步屬於同一類設計思維，可以一併參考物流與配送串接的處理方式。
測試環境與正式切換
發票是少數「測試不完整就上線，代價立刻具體化」的功能。
在測試環境要跑過的情境，至少包含：一般開立、統編開立、載具開立、捐贈、作廢、全額折讓、部分折讓、多次部分折讓、以及各類失敗與重送。把它們列成清單逐一驗，做法可以直接沿用軟體驗收怎麼做裡的測試案例整理方式。
切換到正式環境時要確認幾件事：測試用的識別資料是否已完全替換、金鑰與憑證是否妥善保管而非寫在程式裡、字軌與號碼是否已正確設定、以及上線後第一天要有人實際盯著前幾筆交易的完整結果。
上線後的第一個對帳週期是真正的驗收。把當期的訂單、入帳與發票三方比對一次，確認沒有缺漏，這一步做完才算真的上線。
三個常見誤區
以為開得出來就完成了。開立是最順的那條路徑，真正吃工時的是異常處理與後續異動。估算時要把這部分算進去，否則時程一定會延，原因和軟體專案為什麼總是延誤講的低估整合與測試完全一致。
把發票邏輯散落在各處。結帳、後台、排程各寫一份，規則一改就漏改。集中成單一模組是基本要求。
沒有規劃人工介入的後路。再完善的自動化也會有例外，後台必須保留讓會計查詢、補開、補作廢與匯出的能力，否則出狀況時只能改資料庫。
還有一個容易被忽略的角色問題：發票流程橫跨行銷、客服、會計與工程四種人。行銷決定折扣與贈品怎麼搭，客服面對客人打錯統編的抱怨，會計負責申報與帳務正確，工程把規則寫成程式。需求訪談時如果只找其中一方談，做出來的東西幾乎一定會在另一方那裡卡住。比較可靠的做法是把會計拉進需求會議，讓他直接說明每一種異動情境實際上是怎麼處理的——這段對話通常會比任何規格文件更快揭露真正的規則。
發票串接的難度不在技術本身，而在情境的完整度與帳務的嚴謹度。需求階段多花時間把上述情境逐一寫清楚，上線後省下的往返會多得多。規範細節請務必以財政部與服務商的現行官方說明為準，並讓會計與稅務專業一起確認。
如果你正在規劃電商或系統的發票流程，或現有的開立常常需要人工補救，和 NETVANA 討論你的串接需求。軟體服務採詢問報價制，沒有固定套餐，我們會先釐清情境與現有系統再談範圍；各項服務的內容與交付物可以看軟體服務介紹。
延伸閱讀：收款端的設計與對帳，看台灣金流串接指南；還在選開店平台或客製開發，看電商網站開發指南；要把多個系統打通，看系統整合與 API 串接開發指南；出貨與物流狀態怎麼同步，看物流與配送串接指南；上線前的測試清單怎麼列，看軟體驗收怎麼做；出貨與退貨牽動發票，串接電子發票是必修課，可以看進銷存系統開發指南。
