🔢 串接電子發票卡在測試統編？一鍵產生檢核碼正確的假統編

為什麼你會需要一組「假的但合法」的統編

場景大概都長這樣：發票串接寫到一半，要測「買方統編」欄位，你隨手打了 12345678，綠界測試環境直接回一個錯誤碼，說統編格式不正確。

於是你開始 Google 一家公司的統編來貼。這是很多人做過的事，但它有兩個麻煩：一是你把別人真實的稅籍號碼寫進測試資料、寫進 log、甚至 commit 進 repo；二是 QA 要跑 50 筆批次匯入時，你不可能去查 50 家公司。

統編不是隨便 8 碼數字都算數。財政部有一套加權檢核規則，格式對不上的號碼，發票 API、金流平台、稍微嚴謹一點的結帳表單都會直接擋掉。

所以你需要的東西很明確：一批「通過檢核碼演算法、但不對應任何真實登記資料」的號碼。概念跟信用卡測試卡號 4242 4242 4242 4242 完全一樣，開發時人人都用，只是統編這邊一直沒有一個順手的產生器。

常見會用到的時機：

• 串接電子發票 API（綠界 ECPay、藍新 NewebPay、ezPay）測買方統編、賣方統編欄位
• B2B 結帳流程要驗證「打錯統編會不會被擋下來」
• ERP、進銷存、CRM、會員系統要一批匯入測資
• QA 自動化測試需要每次都不重複的合法號碼

統編檢核碼是怎麼算的，以及 2023 新制改了什麼

統一編號是 8 碼，每一碼對應一組固定的加權係數：

[1, 2, 1, 2, 1, 2, 4, 1]

算法分三步：

1.每一位數字乘上對應係數

2.乘積如果大於等於 10，把十位數與個位數相加（例如 14 就變成 1 + 4 = 5）

3.八個結果全部加總

加總出來的數字，能被 5 整除就是合法格式。另外有個特例：第 7 碼是 7 的時候，加總或加總再加 1 能被 5 整除，都算合法。

這裡是最多人踩坑的地方。網路上一堆教學和舊的驗證函式寫的是「要被 10 整除」，那是舊制。2023 年（民國 112 年）財政部因為號碼快用完，把規則放寬成能被 5 整除，舊制其實是新制的子集。

實務上的後果是：如果你的系統還在用舊制驗證，2023 之後新發放的合法統編，會被你自己的表單誤判成無效，客人在結帳頁打了真統編卻一直被擋，你還以為是他打錯。

這個工具兩邊都照新制走。產生時保證產出的號碼通過新制檢核，驗證時也用新制判定，並且會告訴你判定的理由。

三十秒拿到一批測試統編

步驟 1：選數量，按下產生

打開工具，左邊是產生器。數量有 1、5、10、20、50 五個選項，依用途選：

• 手動測一個發票欄位，選 1
• 前端表單來回測幾輪，選 5 或 10
• ERP 批次匯入、QA 跑迴歸，選 50

按「產生統編」之後就直接出清單，系統會自動去重，同一批裡不會出現重複號碼。要換一批就按「重新產生」。

步驟 2：複製，貼進你的測試環境

每一組右邊有單獨的複製鈕，要一次全拿就按上方的「複製全部」，號碼會以每行一組的格式進剪貼簿，貼進 CSV、Excel、測試腳本都不用再整理格式。

拿去測的時候建議從「最陽春的那一關」開始：先確認發票 API 收得下去、不回格式錯誤，再往上測 ERP 匯入與前端驗證。

步驟 3：用右邊的驗證器反向確認

右邊是驗證器，輸入框只吃數字、上限 8 碼，邊打邊驗，不用按送出。合法會顯示綠色的「合法統編格式」，不合法顯示紅色，下面都會附一句判定理由。

這格最常見的用法不是驗自己產生的號碼，而是驗別人給你的號碼：客人在後台留的統編、業務從 Excel 貼來的名單、或是你自己寫的驗證函式判定結果，拿來對照一下就知道是誰算錯。

幾個會讓你少踩坑的用法

1.先拿產生的號碼去打自己的表單：如果你的結帳表單把這些檢核碼正確的號碼擋掉了，那八成是驗證邏輯還停在舊制（被 10 整除）。這是最快找出舊制殘留的方法。

2.反過來測「該擋的有沒有擋掉」：把產生的號碼隨便改掉一碼，貼進驗證器確認變成不合法，再拿去打你的表單。表單如果照收，代表你根本沒做檢核，客人打錯統編會一路寫進發票。

3.測資固定存一份：QA 迴歸測試最好用固定的幾組號碼，而不是每次重產。產一次 20 組存成 fixture，之後每次跑測試都用同一批，出問題比較好回溯。

4.不要拿去對真實資料：這個工具只做數學檢核，不查商工登記。想知道某個統編是「哪一家公司」、有沒有真的存在、是不是停業狀態，那是另一件事，要走真實登記資料查詢。

5.測試資料要標記清楚：把測試統編寫進 DB 的時候，配合一個明顯的測試公司名稱（例如「測試股份有限公司」），避免哪天測試資料混進正式環境，還被拿去開發票。

三個實際情境

情境 A：串綠界電子發票，測試環境一直回格式錯誤

工程師拿 12345678 當買方統編打 B2B 開立 API，回應一直是參數錯誤。問題不在串接寫錯，是那組號碼根本過不了檢核。

用產生器出 5 組，換上去，API 立刻通。這種問題卡住半天很不值得，因為錯誤訊息通常只講「格式不正確」，不會告訴你是檢核碼的事。

情境 B：B2B 結帳頁的統編欄位驗證做得對不對

一個做辦公用品批發的電商，客人下單要開三聯式發票。工程師想確認前端驗證的兩件事：合法統編會不會被誤擋、亂打的會不會被放行。

作法是產 10 組貼進表單，全部應該順利通過；再把其中幾組改動一碼（先用右邊驗證器確認它已經變成不合法），貼進表單應該全部被擋下來。兩邊都符合預期，這個欄位才算測過。

情境 C：ERP 匯入 50 筆企業客戶測資

要驗證新的客戶匯入功能，欄位包含統編。過去的做法是複製同一組統編 50 次，結果反而測不出「重複統編」的判斷邏輯。

改用產生器選 50，一次拿到 50 組不重複且格式合法的號碼，複製全部貼進 CSV。這時候再刻意複製其中兩筆製造重複，就能順便測到系統會不會擋重複統編。

產生完之後，接下來做什麼

如果你手上是別人給的統編，想知道是哪家公司：這個產生器只做格式檢核，查不到公司名稱。改用統一編號驗證器，它支援單筆與批次檢查，合法的號碼可以直接接去查商工登記資料。

如果你是在測 B2B 結帳流程：欄位驗證只是最基本的一關。統編欄位放在哪一步、要不要預設展開、打錯時錯誤訊息怎麼寫，這些對轉換的影響比技術驗證還大。整個流程跑一次結帳流程診斷，把讓客人中途離開的摩擦點抓出來。

如果是 B2B 客戶的請款與收款環節：企業客戶常見的狀況是下單了但月結、付款拖，發票開了錢還沒到。未付款訂單催繳信可以生出既不失禮又能收到錢的催款信文案。

最後提醒一件事：這些號碼只保證格式正確，不代表任何真實存在的公司。請留在測試環境用，不要拿去開立不實發票或做任何逃漏稅用途。