電子發票加值中心如何比較？

如果您正在比較 e首發票與其他電子發票加值中心，請先確認自己的開立情境、異常處理與整合需求，再比較價格。這份指南協助營業人、財會與資訊人員用同一組問題評估各家服務；確認需求後，可取得 e首發票線上報價或聯絡客服／業務。

先說結論：比較的是整套營運流程

電子發票服務不只要「開得出來」，還要能回答四件事：

1. 交易資料從哪裡來，何時開立？
2. 開立、上傳或通知失敗時，誰會發現並處理？
3. 退貨、退款、作廢、折讓與申報前核對如何完成？
4. 日後對帳、客服或稽核時，是否找得到狀態與處理紀錄？

因此，單看每張價格或功能數量，無法判斷總成本與營運風險。正式比較時，應要求各家用相同情境、張數與責任範圍報價。

用八個面向比較各家服務

下表左欄是建議向每一家加值中心確認的共同問題。e首發票欄位只整理本站目前可供導入評估的方向；實際功能、限制、費用與服務責任，仍以報價單、合約、開通文件及技術評估為準。

手機閱讀時，可在表格內左右滑動查看完整內容。

比較面向	評估時應問什麼	e首發票的導入評估方向
開立方式	是否支援網頁、檔案匯入、電商、POS（銷售時點系統）、ERP（企業資源規劃系統）、API（應用程式介面）或無人設備？	可先依應用情境選擇網頁／Excel 試算表、電商、POS、ERP、API、無人設備或多通路方向。
開立與傳輸狀態	如何確認每張發票已開立、已上傳或失敗？失敗是否有查詢、重送與對帳方式？	導入時需定義開立時點、查詢、重試、補救與完成標誌；API 情境另見串接流程與例外。
異動與例外	退貨、退款、作廢、折讓、重複開立或資料錯誤時，誰判斷、誰執行、保留哪些紀錄？	本站將作廢、折讓與異常補救列為必要評估項目，不把交易與稅務判斷全部交給系統。
字軌與申報	字軌、空白未使用號碼及申報資料由誰整理？營業人如何查核結果？	可依服務設定協助相關作業；營業人仍須確認期別、號碼使用狀態、申報資料及主管機關結果。詳見發票字軌申請。
消費者服務	是否支援載具、開立通知、中獎通知、查詢與紙本證明聯？需要哪些模組或前端配合？	可分別評估會員載具與中獎處理及電子發票證明聯列印；是否支援及操作方式依已開通服務為準。
權限與稽核	是否能區分門市、財會、客服、系統與管理者權限？操作與異動紀錄保存多久、如何匯出？	導入時應把權限、操作紀錄、查詢與責任分工列入需求；個別權限與保存範圍須於正式方案確認。
整合與維運	正式契約在哪裡？如何測試、監控、處理版本變更、斷線與大量重送？	API 路徑、欄位、認證與限制以開通時交付的 Swagger／OpenAPI（API 契約文件）為準；網站只提供串接導覽。
費用與合約	報價是否包含年度張數、模組、導入、測試、教育訓練、客服與續約？超量或變更情境如何處理？	e首發票以年度可使用張數級距及所選模組評估；實際費用與服務範圍以正式文件為準。詳見導入預算評估。

e首發票特別適合先進一步評估的情境

下列情況不是自動核准或功能承諾，但通常值得安排導入評估：

• 發票來自電商、POS、ERP、APP（應用程式）或無人設備，希望減少重複輸入。
• 同時有線上與實體通路，需要集中查詢、對帳與追蹤異常。
• 財會、客服、門市與資訊人員需要清楚分工，不希望問題只靠單一人員口頭處理。
• 需要把退貨、作廢、折讓、通知、字軌或申報前核對納入日常流程。
• 未來張數、據點或系統可能增加，希望先確認擴充與維運責任。

若您只需要少量且單純的人工開立，可先從網頁／Excel 試算表評估，不一定要立即投入 API 串接。若涉及多家公司、特殊稅別、跨境、離線設備或既有自建發票平台，則應先由產品、財會與技術窗口共同釐清責任邊界。

三種常見選擇方式，差異在哪裡？

手機閱讀時，可在表格內左右滑動查看完整內容。

選擇方式	好處	容易忽略的風險
只比較最低價格	初期容易篩選預算	可能未包含導入、例外處理、客服、整合與續約成本；各家計價單位也可能不同。
只比較功能清單	能快速看出表面差異	同名功能的適用條件、限制、權限、紀錄與服務責任可能不同。
用實際情境驗證	能同時比較流程、責任、異常與總成本	前期需要整理交易來源、張數、角色與例外，但較容易得到可落地的報價與方案。

建議採用第三種方式：選一到三個真實情境，要求各家說明標準流程、失敗處理、完成標誌、需由營業人負責的事項及正式費用。

詢價前可直接使用的檢核表

• [ ] 過去 12 個月實際張數、旺季張數與下一年度預估張數已整理。
• [ ] 已列出網頁、Excel 試算表、電商、POS、ERP、APP、無人設備等交易來源。
• [ ] 已確認付款、出貨或服務完成後，哪個事件觸發開立發票。
• [ ] 已列出 B2B（企業對企業）、B2C（企業對消費者）、零稅率、免稅或混稅等情境。
• [ ] 已說明退貨、退款、作廢、折讓、斷線、重送與人工補救方式。
• [ ] 已列出門市、財會、客服、資訊及管理者需要的權限。
• [ ] 已確認載具、通知、列印、字軌、申報資料、API 或多公司管理需求。
• [ ] 已要求報價清楚列出包含、不包含、需另購、超量、導入與續約條件。
• [ ] 已確認正式功能、契約、服務水準與責任邊界的權威文件。

邊界條件與例外

• 加值中心可依服務範圍協助開立、傳輸、查詢、紀錄與資料整理，但營業人仍須對交易事實、原始資料、內部授權及依法申報負責。
• 稅務、會計與法規判斷應由營業人、記帳士、會計師或適當專業人員依個案確認。
• API 名稱、欄位、認證、錯誤回應與版本，以正式 Swagger／OpenAPI 及開通文件為準。
• 各家產品、價格、評比、認證及支援範圍可能變動；比較時應向各服務商取得同一日期、同一需求範圍的正式資料。
• 本頁不對未經查證的其他加值中心功能、價格或服務品質做正面或負面判定。

下一步

1. 還不確定整合方式：先看應用情境選擇。
2. 已知道情境但需要估費用：準備張數與模組後看導入預算評估。
3. 需要系統串接：讓資訊窗口閱讀電子發票 API 串接指南。
4. 準備比較正式方案：使用上方檢核表向各家取得同範圍資料，再取得 e首發票線上報價。