Day 25

ACH 匯款格式轉換技術

報文嚴謹性解析與實務應用


結合「ACH 轉整批匯款檔工具」解析金融標準格式


金融系統自動化作業系列課程

課程核心目標

  • 認知重要性：了解為何金融機構清算系統對報文格式要求「零容忍」。
  • 解構資料流：剖析整批匯款檔案的三段式結構（首筆、明細、尾筆）。
  • 實務工具應用：探討如何利用自動化工具，精準轉換客戶 ACH 資料，消彌人工登打的退件風險。

格式誤差的代價

微小的失誤

檔案多了一個半形空白、長度差了 1 個 Byte、或是編碼不是純 Big5...

巨大的影響

  • 清算中心整批退件 (Reject)
  • 客戶資金延遲入帳 (客訴)
  • 跨行作業手續費損失
  • 龐大的查帳與人工重送成本

報文核心架構

標準的整批匯款 TXT 文字檔，由三種層級的紀錄 (Record) 構成，每一列都有極為嚴格的「固定長度 (Fixed-length)」限制。

區別碼 (Code) 名稱 作用說明
1 首筆 (Header) 定義整批檔案的屬性，如：匯款日、批號、匯款行
2 明細 (Detail) 實際的交易內容，如：收款帳號、戶名、金額
3 尾筆 (Trailer) 檢核點 (Checksum)，包含總筆數與總金額

深度解析：首筆 (區別碼 1)

首筆決定了整批交易的命脈，格式稍有不慎，後方成千上萬筆明細都會作廢。

  • 流水號：首筆必須固定填入 '00000'。
  • 匯款日：6 碼數字，格式為國曆 yymmdd (民國年後兩碼)。
  • 匯款人姓名：長度限制 68 文字，必須為中文 BIG5 碼。
  • FILLER (空白補齊)：未使用的區塊必須以英文空白填滿，不可使用 Tab 或 Null。

核心靈魂：10 碼批號邏輯

批號 (10數字) 是系統辨識整批匯款唯一性的金鑰，格式：yymmdd + xx + nn

yymmdd

國曆年月日

xx

客戶代號 (01~99)

nn

子批號 (01~09)

限制：批號中的日期必須與「匯款日」欄位完全一致！

批號重複的防線

為何需要將後 4 碼拆分為「客戶代號」與「子批號」？

當同一匯款日 (yymmdd) 有多批匯款時，為了避免清算系統視為重複拋轉而退件：

  • 客戶代號 (xx)：由營業單位編列。例如：甲公司配 01，乙公司配 02。
  • 子批號 (nn)：由客戶自行編列。若甲公司當天發送兩批薪資，可分別編為 01 與 02。

深度解析：明細 (區別碼 2)

每一筆明細對應一筆實際的匯出款項。

欄位名稱 長度/格式限制 業務邏輯
流水號(序號) 5數字 00001 ~ nnnnn (必須嚴格連續)
解款行 7數字 3位總行 + 3位分行 + 1位檢查碼
匯款種類 2數字 91:一般入戶 / 92:公庫 / 93:同業
收款人帳號 14數字 靠右對齊，左邊補 0

明細高風險區：金額處理

匯款金額格式 (14數字)

規範：12位整數 + 2位小數 (不含小數點)

範例：匯款 $1,500 元，檔案中必須填寫 00000000150000


系統天花板限制

單筆匯出金額上限為 五仟萬元。
如果客戶單筆匯款超過此限額，系統報文將無法容納，必須在源頭拆分為多筆明細。

深度解析：尾筆 (區別碼 3)

作為檔案的句號，承擔了資料完整性的「雜湊檢核 (Hash Check)」責任。

  • 流水號：尾筆固定填入 '99999'。
  • 總筆數 (4數字)：必須與檔案中的明細 (區別碼 2) 的實體列數完全吻合。
  • 總金額 (14數字)：所有明細匯款金額的精確加總。差 1 塊錢都會導致整批 Reject。
  • 結尾 FILLER：137文字的英文空白，補足單列固定長度規範。

實務痛點：為何需要轉換工具？

客戶端（如企業財會系統）產出的 ACH (Automated Clearing House) 檔案，往往與金融機構的「標準整批匯款格式」有落差：

  • 檔案名稱與內部批號規則不符。
  • 解款行代號未補齊 7 碼檢查碼。
  • 中文姓名編碼混雜 UTF-8 與 Big5，產生亂碼。
  • 空白補位使用 Tab 鍵而非 Space。

自動化解方：格式轉換工具

透過 Excel VBA 或系統轉檔工具，實作資料清洗與正規化。

  1. 自動讀取來源：匯入客戶原始 ACH 檔案。
  2. 參數介面介入：要求作業人員輸入對應的「客戶批號 4 碼 (xxnn)」、「匯款人姓名」與「匯款日期」。
  3. 邏輯重組：工具依據輸入參數，自動編譯出符合 yymmddxxnn 的完美批號。
  4. 產出標準檔：自動補 0、補空白，計算總筆數與總金額。

進階功能：解款行資料補齊

最常發生退件的原因之一，在於客戶提供的「受益人帳戶銀行 (解款行)」代碼錯誤或因裁撤分行而失效。

  • 自動補齊機制：工具內建對照表，自動檢查 3位總行 + 3位分行。
  • 檢查碼計算：依據特定演算法補上第 7 碼檢查碼。
  • 裁撤分行映射：若遇到已裁撤併入的分行，工具能透過 裁撤分行對應頁籤 自動轉換為存續分行代碼，免除人工逐筆核對的災難。

報文查驗點 Check-list

檢驗項目 標準要求 失敗後果
檔案名稱 mmdd批號.TXT 系統無法抓取檔案
編碼格式 純 BIG5 (中文) 系統解析成亂碼，退匯
金額長度 12位整數+2位隱含小數 金額暴增百倍，引發災難
資料對齊 數值靠右補0 / 文字靠左補空白 欄位偏移，整批作廢

標準操作流程 (SOP)

Step 1: 匯入與設定

開啟轉換工具，匯入 ACH 原始檔。輸入指定的 4 碼客戶批號與匯款日期。

Step 2: 檢核與修正

檢查工作頁「來源資料」。若解款行或戶名有異常，利用工具內建功能進行修正。

Step 3: 轉換與產出

點選「產生匯款檔案」，於「轉換後資料」確認格式無誤後，上傳至主機系統。

總結與展望

  • 規範即是法律：金融報文沒有容錯空間，了解首筆、明細、尾筆的結構是基礎功。
  • 自動化取代人工：依賴人眼檢查 TXT 檔是不切實際的，必須仰賴轉換工具的強型別約束。
  • 持續優化字典檔：解款行清單、裁撤分行對照表需定期維護，才能讓工具發揮最大效益。

感謝聆聽！落實格式標準，守護交易安全。