了解銀行對帳單格式:技術指南
PDF 並非資料格式,而是顯示格式。這就是為何從銀行對帳單擷取交易資料如此困難。本指南將說明銀行對帳單 PDF 的內容、可用的輸出格式(Excel、CSV、QBO、OFX、QFX、JSON),以及如何選擇正確的格式。

銀行對帳單 PDF 看似簡單:日期、說明、金額、餘額,整齊排列成欄位。但在此外觀之下,PDF 這種檔案格式(PDF)從未被設計用於儲存結構化資料,而擷取過程需要同時理解輸入格式與眾多可用的輸出格式。
本指南涵蓋了每份銀行對帳單(無論哪家銀行)都會出現的 12 個部分、銀行對帳單 PDF 的技術實情、跨銀行版面配置的差異、您將遇到的所有輸出格式(Excel、CSV、QBO、OFX、QFX、QIF、JSON)、國際格式設定的差異,以及規範金融資料交換的行業標準。
銀行對帳單的結構
每份銀行對帳單——無論是 Chase、Bank of America、Wells Fargo、HSBC、Deutsche Bank,或是任何其他銀行——都由相同的 12 個部分組成。標籤可能不同(「減項」對「提款」),欄位排列方式可能各異,但底層結構是一致的。一旦您能識別這些部分,每份對帳單看起來都會很熟悉。

想在您的部落格上使用此資訊圖表? 複製此嵌入程式碼:
若要深入了解各家銀行如何具體佈局這 12 個部分,請參閱:
為何 PDF 不是資料格式
PDF 是「可攜式文件格式」(Portable Document Format)的縮寫,標準化為 ISO 32000(2.0 版本成為 ISO 32000-2:2020)。它僅為一個目的而設計:讓文件在各種螢幕和印表機上看起來完全相同。這對於視覺保真度來說很棒,但對於資料擷取來說卻很糟糕。
銀行對帳單 PDF 內部實際包含什麼
每個 PDF 頁面內部都有一個「內容串流」(content stream)—— 一系列類似 PostScript 的繪圖指令。文字是使用特定的指令來呈現的:
- BT / ET - 開始文字 / 結束文字:文字物件的邊界
- Tf - 設定字型和大小
- Td / Tm - 移動文字位置或設定完整的文字轉換矩陣
- Tj - 顯示文字字串
- TJ - 顯示帶有獨立字形定位(字距調整)的文字
關鍵洞察:PDF 規格中沒有「表格」、「列」或「欄」的概念。 那些看起來像格式整齊的交易表格,實際上是放置在頁面上特定 x,y 座標的數十個文字片段。擷取工具必須:
- 解析內容串流指令
- 解析字型編碼,將字形索引對應到 Unicode 字元
- 使用文字矩陣(Tm/Td)來確定每個字元的 x,y 位置
- 從這些座標重建單字、行和欄
一個看起來完美對齊的欄位,在一行中可能位於 x=72.0,下一行則為 x=72.5。擷取演算法必須定義欄位邊界,並容忍這些次像素的變化。
已標記 (Tagged) 與未標記 (Untagged) 的 PDF
已標記的 PDF 包含一個隱藏的邏輯結構樹(類似 HTML 標籤),將內容標記為標題、段落、表格、表格列和表格儲存格。這使得擷取工作顯著更容易。
未標記的 PDF 沒有結構性中繼資料——擷取工具只能獲得原始定位資料,必須自行推斷一切。
大多數銀行產生的對帳單 PDF 都是未標記的。 銀行使用批次處理系統(Oracle BI Publisher、SAP Crystal Reports 或自訂的列印到 PDF 管道)來產生對帳單。無障礙法規(ADA/WCAG)正推動銀行採用已標記的 PDF,但普及速度緩慢。大多數主要銀行的標準下載仍然是未標記的。
銀行對帳單版面配置差異
銀行 PDF 對帳單的格式沒有行業標準。相同的五項資訊——日期、說明、借方、貸方、餘額——在每家銀行之間的排列方式都不同。
單一金額欄位(已標示正負)
日期 說明 金額 餘額
01/15/26 DIRECT DEP PAYROLL +3,500.00 5,200.00
01/16/26 POS PURCHASE GROCERY -87.50 5,112.50借方為負數,貸方為正數(反之亦然)。小型銀行、信用合作社和數位銀行常見。解析較簡單,因為只有一個金額欄位需要擷取。
分開的借方/貸方欄位
日期 說明 提款 存款 餘額
01/15/26 DIRECT DEP PAYROLL 3,500.00 5,200.00
01/16/26 POS PURCHASE GROCERY 87.50 5,112.50Chase、Bank of America 和許多傳統銀行使用。擷取工具必須識別哪個欄位包含金額,並據此判斷正負號。
按交易類型分組
商業和企業帳戶經常按交易類型分組:
存款和其他貸項 01/15 電匯入 REF#12345 10,000.00 01/18 支票存款 #4567 2,500.00 存款總計 12,500.00
已付款支票 01/16 支票 #1234 850.00 01/17 支票 #1235 1,200.00 支票總計 2,050.00
電子交易 01/19 ACH PYMT - Vendor Corp 3,200.00 01/20 線上轉帳至儲蓄帳戶 1,000.00 電子交易總計 4,200.00區段標題決定了交易是借方還是貸方。必須識別摘要行(「存款總計」)並將其排除在交易資料之外。
特定銀行特性
- Chase - 分開的借方/貸方欄位;按「存款和加項」、「電子付款」和「費用」分組;商家詳細資訊常見多行說明
- Bank of America - 分開的提款/存款欄位;包含結尾的「每日餘額」部分;標頭包含帳戶號碼、對帳單週期、路由號碼等詳細資訊
- Wells Fargo - 分開的欄位;包含「每日餘額摘要」部分;將其 CSV 下載稱為「逗號分隔」
- Capital One - 消費者卡片採用簡潔的單一金額版面配置;標頭資訊最少
- Citi - 常在單獨的行上包含國際交易詳細資訊,以及原始貨幣金額和匯率
欄位排列順序差異
除了借貸問題外,欄位順序也沒有標準化:
- 欄位順序:日期-說明-金額-餘額 或 日期-金額-說明-餘額
- 支票號碼:商業帳戶中存在,個人帳戶中不存在
- 參考號碼:商業對帳單中常見,個人對帳單中罕見
- 滾動餘額:每筆交易(最常見)vs. 每日小計 vs. 完全不存在
數位 PDF 與掃描 PDF
影響轉換準確度的最重要因素是您的 PDF 是數位還是掃描的。
數位(原生)PDF
當您從銀行的系統下載對帳單時,由系統程式化生成。文字以內容串流指令和字型編碼的形式儲存。
- 準確度:文字擷取 99% 以上——沒有辨識錯誤
- 速度:每頁毫秒
- 隱私:完全可在您的瀏覽器中處理——檔案不會離開您的裝置
- 檔案大小:每頁通常 50KB–500KB
- 如何識別:您可以選取並反白顯示個別單字
掃描 PDF
紙本對帳單的影像——透過掃描或拍攝實體文件產生。內容以點陣影像(JPEG、JPEG2000、CCITT 或 Flate 壓縮)的形式儲存。
- 準確度:專業 OCR 準確率 95–99%;通用 OCR 準確率 65–70%
- 速度:每頁數秒(需要影像處理)
- 隱私:通常需要伺服器端處理(檔案必須上傳才能進行 OCR)
- 檔案大小:每頁 200KB–2MB+
- 如何識別:您無法選取任何文字;放大到 400% 會顯示像素化
為何掃描準確率對金融資料更重要
97% 的字元準確率聽起來很棒,直到應用於金融資料。在一份有 1,000 個字元的對帳單中,這意味著有 30 個字元被誤讀。單一誤讀的數字會改變交易金額:「$1,234.56」變成「$1,234.86」或「$7,234.56」。進階 OCR 可達到近 99% 的準確率,但剩餘的錯誤不成比例地落在看起來相似的字元上:0/O、1/l/I、5/S、8/B、6/G,以及關鍵的逗號/句點。
務必優先選擇數位下載。 請從銀行網站下載對帳單,而非掃描紙本。這樣可以完全消除 OCR 錯誤。
輸出格式:深入解析

轉換銀行對帳單時,您需要選擇一種輸出格式。每種格式都有不同的優點、限制和理想用途。
Excel (.xlsx)
標準:Office Open XML (OOXML),標準化為 ECMA-376 和 ISO/IEC 29500。
這是什麼:.xlsx 檔案實際上是一個 ZIP 壓縮檔,包含 XML 檔案——工作簿結構、儲存格資料、樣式和共用字串。這就是為何它能儲存資料類型(日期作為日期,數字作為數字)、格式設定、公式和多個工作表。
為何在銀行對帳單中如此受歡迎:
- 日期仍是日期(可排序、篩選)
- 數字仍是數字(可加總、格式化)
- 用於對帳的公式(SUM、VLOOKUP)
- 用於支出分類的樞紐分析表
- 用於標示差異的條件式格式設定
- 與需要可讀試算表的客戶共用
限制:
- 最多 1,048,576 列(對銀行對帳單而言很少相關)
- 大多數會計軟體無法直接匯入(請改用 QBO/OFX)
- 需要 Excel、Google Sheets 或 LibreOffice Calc 才能開啟
最適合:手動審閱、自訂分析、對帳、歸檔、客戶報告。
CSV(逗號分隔值)
標準:RFC 4180 (2005) —「逗號分隔值的通用格式和 MIME 類型」。
核心規則:
- 記錄以 CRLF(換行符 + 換行)分隔
- 欄位以逗號分隔
- 包含逗號、引號或換行的欄位必須用雙引號括起來
- 欄位內的雙引號透過加倍來逸出
實際中的分隔符號差異:
- 逗號 (
,) - 標準,在美國/英國使用 - 分號 (
;) - 在逗號是小數分隔符號的國家使用(法國、德國、義大利、西班牙、巴西) - 定位字元 (
\t) - TSV 格式,避免分隔符號衝突
編碼問題:
- 建議使用 UTF-8 以實現互通性
- UTF-8 BOM(位元組順序標記):標準不要求,但Windows 上的 Excel 需要它才能正確顯示非 ASCII 字元(帶音標的字母、貨幣符號)。沒有 BOM,Excel 可能會將 UTF-8 解譯為 Windows-1252,導致字元損壞。
- 在歐洲地區設定下,Excel 使用分號而非逗號作為欄位分隔符號
限制:
- 沒有資料類型——一切都是文字(開頭為零的數字會損壞,長帳號會變成科學記號)
- 不支援多工作表
- 沒有格式設定或公式
- 沒有中繼資料(沒有帳戶資訊,沒有重複偵測 ID)
最適合:最大程度的相容性——幾乎所有會計程式、資料庫和試算表都能匯入 CSV。在 QBO/OFX 無法使用時的通用備案。
QBO(QuickBooks 網路連線)
這是什麼:QuickBooks(桌面版和線上版)的匯入格式。QBO 檔案基於 OFX 規格,並包含 QuickBooks 特有的擴充功能。
重要澄清:".QBO" 並非「QuickBooks Online」的縮寫——它代表 QuickBooks 網路連線格式,適用於 QuickBooks 桌面版和 QuickBooks 線上版。
每筆交易所需的欄位:
TRNTYPE- 交易類型(DEBIT、CREDIT、CHECK、DEP、DIRECTDEP、DIRECTDEBIT、ATM、POS、XFER、PAYMENT、FEE、SRVCHG、INT、OTHER)DTPOSTED- 日期,格式為 YYYYMMDDTRNAMT- 金額(借方為負數)FITID- 金融機構交易 IDNAME- 支付對象/說明
FITID 的重要性:QuickBooks 會追蹤每個帳戶曾經匯入的每個 FITID。如果再次匯入具有相同 FITID 的交易,QuickBooks 會默默跳過它——防止使用者在重新匯入重疊的對帳單週期時產生重複項目。這種自動重複偵測是 QBO 相較於 CSV 的最大優勢。
額外資料:QBO 還包含帳戶 ID、銀行 ID(路由號碼)、貨幣、支票號碼、備註和期末餘額——這是 QuickBooks 所有匯入格式中最豐富的資料集。
最適合:QuickBooks 使用者(桌面版和線上版)。提供最豐富的匯入體驗,具有自動重複偵測和交易類型分類功能。
OFX(開放金融交換)
歷史:由 Microsoft、Intuit 和 CheckFree 創建。1.0 版本於 1997 年 2 月發布。
版本演進:
- OFX 1.0–1.6 (1997–1999):基於 SGML 的語法(不需要結束標籤)
- OFX 2.0+ (2000–至今):基於 XML(有正確的結束標籤,格式正確的 XML)
許多銀行仍生產 OFX 1.x(SGML)以實現最大程度的相容性。
目前管理機構:2019 年,OFX 聯盟合併到金融資料交換 (FDX) 聯盟,該聯盟現負責管理規格。FDX 擁有超過 200 個會員組織和 7,600 萬個客戶帳戶。
為何 OFX 是通用標準:OFX 與您透過銀行串流將銀行帳戶直接連接到會計軟體時使用的格式相同——檔案匯入也使用相同的格式。
最適合 Xero 使用者:Xero 可自動匯入 OFX 檔案,無需手動對應欄位。上傳檔案後,交易會立即出現,包含正確的日期、金額和說明。也適用於 Wave、Sage、FreshBooks 和大多數會計軟體。
QFX(Quicken 金融交換)
這是什麼:Intuit 的 OFX 專有變體,僅用於 Quicken。QFX 檔案是標準的 OFX 檔案,但包含額外的專有欄位。
關鍵專有欄位:INTU.BID - Quicken 銀行識別碼。此數字 ID 對應到 Quicken 內部資料庫中的銀行。沒有它,Quicken 將拒絕匯入檔案。
與標準 OFX 的差異:
- 在標頭中需要 INTU.BID
- 可能包含其他以 INTU.* 為字首的欄位
- 金融機構需向 Intuit 支付授權費才能提供 QFX 下載
- Quicken 不會匯入沒有 INTU.BID 欄位的標準 OFX 檔案
最適合:Quicken 個人理財軟體使用者。必需格式——沒有其他替代方案可用。
QIF(Quicken 互通格式)
這是什麼:Intuit 為 Quicken 開發的舊版純文字格式。標籤-值對,每行一個,使用單一字元標籤:D 代表日期,T 代表金額,P 代表支付對象,L 代表類別,M 代表備註,N 代表支票號碼,^ 代表記錄結束。
為何被取代:QIF 缺乏重複偵測機制(沒有 FITID 等效項),沒有帳戶識別欄位,沒有銀行路由資訊,沒有餘額資料,且不同實作之間的日期格式不一致。
仍具相關性:某些會計軟體(Xero、Sage、GnuCash)仍接受 QIF 匯入。適用於舊系統遷移。
JSON(JavaScript 物件表示法)
目前狀態:JSON 尚未成為銀行對帳單檔案的標準,但正日益用於:
- 開放銀行 API(英國開放銀行標準、PSD2 Berlin Group)
- FDX API(金融資料交換——OFX 的後繼者,擁有 200+ 個會員組織)
- Plaid、Yodlee、MX 等資料聚合器 API
- 開發者和自動化工作流程
日益普及:開放銀行法規(歐洲的 PSD2、美國的 CFPB 第 1033 條)正在加速 JSON API 的採用。FDX API 使用 JSON/REST 和 OAuth 2.0,代表了金融資料交換的未來方向。
最適合:開發自動化工作流程、金融科技整合、自訂儀表板和開放銀行 API 整合的開發人員。
格式比較一覽
| 格式 | 資料類型 | 重複偵測 | 帳戶資訊 | 會計軟體支援 | 最適合 |
|---|---|---|---|---|---|
| Excel | 是 | 否 | 否 | 有限 | 手動審閱、分析 |
| CSV | 否 | 否 | 否 | 通用 | 最大程度相容性 |
| QBO | 是 | 是 (FITID) | 是 | QuickBooks | QuickBooks 使用者 |
| OFX | 是 | 是 (FITID) | 是 | 大多數軟體 | Xero、Wave、Sage |
| QFX | 是 | 是 (FITID) | 是 | 僅限 Quicken | Quicken 使用者 |
| QIF | 部分 | 否 | 否 | 部分舊版 | 舊版遷移 |
| JSON | 是 | 自訂 | 是 | 基於 API | 開發者、自動化 |
會計軟體相容性
您的會計軟體接受哪種格式?
| 軟體 | QBO | OFX | QFX | QIF | CSV | 最佳選擇 |
|---|---|---|---|---|---|---|
| QuickBooks Online | 是 | 是 | 是 | 否 | 是 | QBO |
| QuickBooks Desktop | 是 | 是 | 是 | 否 | 是 | QBO |
| Quicken | 否 | 否 | 是 | 是 | 否 | QFX |
| Xero | 是 | 是 | 是 | 是 | 是 | OFX |
| Sage | 否 | 是 | 否 | 是 | 是 | OFX |
| Wave | 否 | 是 | 是 | 否 | 是 | OFX |
| FreshBooks | 否 | 否 | 否 | 否 | 是 | CSV |
| Zoho Books | 否 | 是 | 否 | 是 | 是 | OFX |
| GnuCash | 否 | 是 | 否 | 是 | 是 | OFX |
經驗法則:如果您的軟體支援,請使用 QBO 搭配 QuickBooks,QFX 搭配 Quicken,OFX 搭配其他所有軟體,並將 CSV 作為通用備案。
國際格式差異
如果您處理國際銀行對帳單,您會遇到讓大多數轉換工具出錯的格式差異。
日期格式
| 地區 | 格式 | 範例 | 備註 | |---|---|---|---|| | 美國 | MM/DD/YYYY | 03/15/2026 | 月份在前 | | 歐洲、拉丁美洲 | DD/MM/YYYY | 15/03/2026 | 日期在前 | | 德國 | DD.MM.YYYY | 15.03.2026 | 句點分隔符 | | 日本 | YYYY年MM月DD日 | 2026年03月01日 | 年份在前,附帶日文漢字 | | 中國 | YYYY年MM月DD日 | 2026年3月1日 | 與日本類似 | | ISO 8601 | YYYY-MM-DD | 2026-03-15 | 歧義消除的國際標準 |
歧義問題:「03/04/2026」在美國是 3 月 4 日,在歐洲是 4 月 3 日。當對帳單中的所有日期日值小於或等於 12 時,在不知道來源國家的情況下,無法透過演算法確定正確的格式。轉換工具必須掃描對帳單中的所有日期,尋找大於 12 的值來確定格式。
數字格式
| 地區 | 一千零五十元五十分 | 備註 | |---|---|---|| | 美國、英國、澳洲、日本 | 1,000.50 | 逗號用於千位分隔,句點用於小數分隔 | | 德國、法國、西班牙、巴西、義大利 | 1.000,50 | 句點用於千位分隔,逗號用於小數分隔 | | 瑞士 | 1'000.50 | 撇號用於千位分隔 | | 印度 | 1,00,000.50 | Lakh 分組系統 | | 斯堪地那維亞 | 1 000,50 | 空格用於千位分隔,逗號用於小數分隔 |
來自歐洲銀行的「10.000,45」意味著一萬零四十五分——而不是十點零零零四五。弄錯這一點會產生 10,000 倍的錯誤。
貨幣符號位置
- 美國/英國:符號在金額前:$1,234.56 / £1,234.56
- 法國、德國、西班牙:符號在金額後:1.234,56 €
- 愛爾蘭、荷蘭:符號在金額前:€1,234.56
- 日本:符號在金額前:¥123,456
字元編碼
- UTF-8 - 通用標準,支援所有腳本
- GBK/GB2312 - 簡體中文(中國銀行使用)
- Shift_JIS - 日文(日本銀行使用)
- Big5 - 繁體中文(台灣、香港)
- EUC-KR - 韓文
- ISO 8859-1 - 西歐語言
- Windows-1252 - 西歐語言(舊版)
- Windows-1256 - 阿拉伯文
在沒有正確編碼偵測的情況下,在美國系統上開啟中國或日本銀行對帳單會產生亂碼。PDFSub 可處理超過 130 種語言,自動偵測日期格式、數字格式和字元編碼——包括從右至左的阿拉伯文和希伯來文、CJK 字元以及所有歐洲字元集。
常見銀行對帳單元素
交易日期 vs. 過帳日期 vs. 生效日期
銀行對帳單可能包含單筆交易的多個日期:
- 交易日期 - 實際發生購買或轉帳的日期
- 過帳日期 - 銀行處理並記錄的日期(通常是信用卡購買後 1-3 個工作日)
- 生效日期 - 資金實際可用的日期(影響利息計算,國際銀行常見)
大多數消費者對帳單僅顯示過帳日期。商業對帳單通常同時包含交易日期和過帳日期。
借方/貸方表示法
銀行對借方和貸方的表示方式不同:
- 標示金額:借方為 -87.50,貸方為 +3,500.00
- 獨立欄位:「提款」和「存款」
- 縮寫:「DR」代表借方,「CR」代表貸方(英國/大英國協常見)
- 括號:(87.50) 代表借方(會計慣例)
滾動餘額
- 每筆交易餘額 - 每筆交易後更新(美國消費者對帳單最常見)
- 僅每日餘額 - 每日結束時顯示的餘額(商業對帳單常見)
- 無滾動餘額 - 僅期初和期末餘額(部分國際對帳單)
滾動餘額對於驗證很有價值:您可以驗證每筆交易是否正確地將餘額從一行移至下一行。
標準標頭資訊
大多數銀行對帳單包含:帳戶持有人姓名、帳戶號碼(通常部分遮蔽)、對帳單週期、期初和期末餘額、總存款和提款額,以及銀行路由/排序代碼/SWIFT BIC。
密碼保護
銀行如何加密 PDF
銀行通常使用AES-128 或 AES-256 加密。存在兩種保護模式:
- 使用者密碼(開啟密碼):開啟檔案所需
- 擁有者密碼(權限密碼):PDF 可開啟,但編輯/複製可能受限
常見密碼模式
| 銀行 | 典型密碼 |
|---|---|
| Chase | 全部的 9 位數社會安全號碼 (SSN) |
| Bank of America | SSN 或 TIN |
| Wells Fargo | SSN 或 SSN 的最後 4 位數字 |
| Capital One | 出生日期 (MMDDYYYY) |
其他常見模式包括帳戶號碼的最後 4 位數字、客戶 ID 或會員號碼。銀行通常在您首次啟用電子對帳單時告知密碼模式。
多頁對帳單的挑戰
長對帳單(包含數百筆交易的商業帳戶)會帶來幾個擷取挑戰:
分割交易
交易說明可能從一頁底部開始,延續到下一頁頂部。轉換器必須偵測延續行並將其合併為單一交易。
重複的標頭和頁腳
大多數銀行會在每頁重複欄位標頭,加上頁碼、法律免責聲明和行銷文字。這些必須被識別並從交易資料中排除。
延續行
許多交易有多行說明:
01/15 ACH ELECTRONIC DEBIT VENDOR CORP $3,200.00 $2,000.00 REF#123456789 INVOICE 2026-001 VENDOR CORP ACCOUNTS PAYABLE第 2 和第 3 行是屬於第 1 行交易的延續行。它們通常缺少日期和金額,並在與說明欄位相同的 x 座標處縮排顯示。
餘額轉移
有些銀行會在延續頁的頂部包含「Balance Forward」或「Balance Brought Forward」行。這些是資訊性的,不是交易,必須從擷取的資料中排除。
常見交易縮寫
銀行對帳單使用因機構而異的縮寫:
| 縮寫 | 意義 |
|---|---|
| ACH | 自動清算中心(電子轉帳) |
| ATM | 自動櫃員機 |
| POS | 銷售點(簽帳金融卡) |
| EFT | 電子資金轉帳 |
| INT | 利息支付 |
| CHK / CK | 支票 |
| WD / W/D | 提款 |
| DEP | 存款 |
| DD | 直接存款 |
| OD | 透支 |
| NSF | 資金不足 |
| SRVCHG | 服務費 |
| XFER | 轉帳 |
您應該知道的行業標準
這些格式用於公司銀行和財資管理。您很少會直接遇到它們,但了解它們可以解釋為何銀行對帳單的運作方式如此。
BAI2(銀行管理協會)
用於 ERP 系統(SAP、Oracle)中的自動現金管理和銀行對帳。固定寬度的 ASCII 格式,帶有交易類型代碼(例如,165 = 預授權 ACH 貸項,455 = ACH 借項,495 = 電匯出)。最初於 1987 年發布,現由 ASC X9 維護。
SWIFT MT940 / MT942
用於全球銀行為企業客戶和財資部門提供的每日結束(MT940)和日內(MT942)銀行對帳單。SWIFT 每天處理約 4,500 萬則訊息。基於標籤的格式,使用冒號分隔的欄位標識符。
ISO 20022 (camt.053)
MT940 的現代基於 XML 的替代品。是 ISO 20022 通用金融訊息標準的一部分。比 MT940 的資料更豐富,沒有欄位長度限制,可機器解析的 XML 帶有 XSD 驗證。SWIFT 正在從 MT 訊息遷移到 ISO 20022。SEPA(單一歐元支付區)強制要求歐洲支付使用 camt 格式。
NACHA ACH
美國自動清算中心 (ACH) 交易的檔案格式。固定寬度的 ASCII,每行剛好 94 個字元。ACH 每年處理約 300 億筆交易。當您的銀行對帳單顯示「ACH CREDIT」或「ACH DEBIT」時,底層交易是在銀行之間以 NACHA 格式傳輸的。
為您的工作流程選擇正確的格式
決策指南
如果使用 QuickBooks(桌面版或線上版),請使用 QBO。您將獲得交易類型分類、透過 FITID 進行重複偵測,以及最豐富的匯入中繼資料。
如果使用 Xero、Sage、Wave 或其他支援 OFX 的軟體,請使用 OFX。Xero 可自動對應欄位,無需手動設定欄位配置。
如果使用 Quicken,請使用 QFX。這是 Quicken 唯一接受的格式。
如果需要匯入前審閱、分析或操作資料,請使用 Excel。建立樞紐分析表、執行公式或準備報告。
如果您的軟體未在上方列出,或需要最大程度的系統相容性,請使用 CSV。準備手動對應欄位。
如果您正在建置自動化工作流程、API 整合或自訂報告系統,請使用 JSON。
專業提示
- 如果您的軟體支援,請始終使用 QBO/OFX 而非 CSV——僅重複偵測功能即可避免數小時的清理工作
- 將原始 PDF 與轉換後的檔案一起保留——這是您的審計軌跡和來源文件
- 每次匯入後進行驗證——抽查期初/期末餘額和幾筆隨機交易
- 根據軟體選擇格式——為您的會計平台使用原生格式可避免手動欄位對應並啟用自動功能
免費試用
準備好轉換您的第一份對帳單了嗎?立即上傳 PDF——PDFSub 可轉換為 Excel、CSV、QBO、OFX、QFX 和 JSON。數位對帳單完全在您的瀏覽器中處理,以確保最大程度的隱私。開始 7 天免費試用,即可完整存取所有格式。