依應用情境選擇 e首發票¶
選擇電子發票服務時，先看交易資料從哪裡來、發票要在什麼時點開立，以及發生錯誤時由誰處理。整合可能使用 API（應用程式介面）或檔案交換，但不是越複雜越好；能穩定對帳並清楚追蹤才是重點。
六種常見導入情境¶
| 情境 | 常見對象 | 可能的導入方向 | 評估前先確認 |
|---|---|---|---|
| 網頁／Excel 試算表 | 張數不高、沒有 ERP 或 POS 的中小型營業人 | 後台開立或檔案批次匯入 | 每月與旺季張數、誰負責整理資料與檢查結果 |
| 電商訂單 | 品牌官網、平台賣家、DTC（直接面向消費者）電商 | 訂單完成後以 API 或既有整合流程開立 | 付款、出貨或完成交易何時開立發票；退貨如何同步 |
| 門市 POS | 零售、餐飲、連鎖門市、觀光工廠 | POS 即時開立、載具、通知或列印整合 | 結帳速度、混稅、斷線、門市與總部權限 |
| ERP／B2B | 製造、批發、供應鏈與企業客戶交易 | ERP 產生發票資料，再與 e首發票交換狀態 | 稅別、買受人資料、月結、對帳與異動責任 |
| 無人設備 | 販賣機、自助 Kiosk、停車或自助繳費設備 | 金流完成後自動開立，保留補送與查詢機制 | 網路中斷、重送不重開、消費者通知與設備識別 |
| 多通路／多公司 | 電商加門市、多品牌、集團或多套來源系統 | 分流字軌、整合狀態與集中查詢 | 各來源的字軌、開立責任、權限與異動流程 |
情境一：沒有複雜系統，只想減少手工作業¶
如果目前以試算表、訂單明細或少量人工資料為主，可以先評估網頁／Excel 試算表流程，不必一開始就投入 API 串接。
適合的訊號：
- 發票量可由固定人員整理與覆核。
- 資料格式相對一致。
- 不要求付款後數秒內自動開立發票。
若資料來源已經很多、每天都需要重複整理，或常發生漏開與重匯，則應改評估自動串接。
情境二：電商、平台或訂閱服務¶
這類情境的重點是「訂單狀態與發票開立時點一致」。需要先定義付款成功、出貨或服務完成的哪一個事件會觸發開立發票，以及退款後應走作廢或折讓的責任流程。
適合評估 e首發票的訊號：
- 希望訂單與發票狀態自動同步。
- 不希望人工每天匯出、整理再上傳。
- 需要將開立結果回寫原系統或通知消費者。
情境三：門市、餐飲與 POS¶
門市情境除了開立發票，還要考慮結帳速度、載具、列印、混稅、斷線以及總部對帳。多門市尤其需要先定義門市可操作的範圍與總部的查詢、異動權限。
情境四：ERP、製造與 B2B¶
ERP 通常已掌握客戶、品項、稅別與應收資料。導入重點在欄位對照、字軌責任、月結對帳，以及 ERP 與 e首發票之間誰是資料權威。
如果來源系統已自行取號，與只傳交易資料交由服務端取號，會是不同的整合設計，應在報價與技術評估前說清楚。
情境五：無人設備與自助服務¶
無人設備不能假設網路永遠正常。評估時應確認設備離線、金流已成功但發票尚未開立、重送及人工補救等情境，避免重複開立或長時間無人發現。
情境六：多通路、多品牌或多家公司¶
當電商、門市、ERP 與其他來源同時存在，最大的風險通常是資料不同步、字軌混用與異動責任不一致。這類需求應先畫出來源清冊與責任分工，再進行方案評估。
完成評估前，請準備這些資訊¶
- 過去一年實際發票量與下一年度預估量。
- B2B、B2C、零稅率、免稅或混稅等交易情境。
- 每一個交易來源及其目前系統。
- 希望在哪個事件後開立發票。
- 退貨、退款、作廢與折讓由誰決定及執行。
- 是否需要載具、列印、通知、申報、API 或多公司管理。
下一步¶
本頁提供導入方式的選擇方向，不構成整合承諾；正式支援範圍以線上報價、合約、訂單及技術評估結果為準。