了解銀行對帳單格式：技術指南

銀行對帳單 PDF 看起來很簡單：日期、說明、金額、餘額整齊地排列在欄位中。但在這外觀背後，卻是一種從未被設計用於儲存結構化資料的文件格式（PDF），其轉換過程需要了解輸入格式以及眾多可用的輸出格式。

本指南涵蓋了銀行對帳單 PDF 的技術實況、各銀行之間的版面差異、您將遇到的所有輸出格式（Excel、CSV、QBO、OFX、QFX、QIF、JSON）、國際格式差異，以及規範金融資料交換的行業標準。

為何 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 座標。提取工具必須：

1. 解析內容流操作符
2. 解析字體編碼以將字形索引映射到 Unicode 字元
3. 使用文字矩陣 (Tm/Td) 確定每個字元的 x,y 位置
4. 從這些座標重建單詞、行和欄

一個看起來完美對齊的欄位，可能在某一行位於 x=72.0，而在下一行位於 x=72.5。提取演算法必須定義欄位邊界，並容許這些次像素的變化。

標籤化與非標籤化 PDF

標籤化 PDF 包含一個隱藏的邏輯結構樹（類似於 HTML 標籤），將內容標記為標題、段落、表格、表格行和表格單元格。這使得提取過程顯著更容易。

非標籤化 PDF 沒有結構化中繼資料 — 提取工具只會獲得原始定位資料，必須推斷一切。

大多數銀行生成的對帳單 PDF 都是非標籤化的。 銀行使用批次處理系統（Oracle BI Publisher、SAP Crystal Reports 或自訂的列印到 PDF 流程）生成對帳單。無障礙規範 (ADA/WCAG) 正在推動銀行採用標籤化 PDF，但其普及速度緩慢。大多數主要銀行的標準下載仍然是非標籤化的。

---

銀行對帳單版面差異

銀行對其 PDF 對帳單的格式沒有行業標準。相同的五項資訊 — 日期、說明、借方、貸方、餘額 — 每家銀行的排列方式都不同。

單一金額欄位（帶正負號）

Date       Description              Amount       Balance
01/15/26   DIRECT DEP PAYROLL      +3,500.00    5,200.00
01/16/26   POS PURCHASE GROCERY      -87.50     5,112.50

借方為負，貸方為正（或反之）。常見於小型銀行、信用合作社和數位銀行。解析起來更簡單，因為只有一個金額欄位需要提取。

獨立借方/貸方欄位

Date       Description              Withdrawals  Deposits   Balance
01/15/26   DIRECT DEP PAYROLL                    3,500.00   5,200.00
01/16/26   POS PURCHASE GROCERY       87.50                 5,112.50

由 Chase、Bank of America 和許多傳統銀行使用。提取工具必須識別哪個欄位包含金額，並據此確定正負號。

按交易類型分組

商業和企業帳戶通常會將交易分組：

DEPOSITS AND OTHER CREDITS
  01/15  Wire Transfer In    REF#12345          10,000.00
  01/18  Check Deposit       #4567               2,500.00
  Total Deposits                                12,500.00

CHECKS PAID
  01/16  Check #1234                               850.00
  01/17  Check #1235                             1,200.00
  Total Checks Paid                              2,050.00

ELECTRONIC TRANSACTIONS
  01/19  ACH PYMT - Vendor Corp                  3,200.00
  01/20  Online Transfer to Savings              1,000.00
  Total Electronic                               4,200.00

區段標題決定交易是借方還是貸方。摘要行（「總存款」）必須被識別並從交易資料中排除。

銀行特定特性

• Chase — 獨立的借方/貸方欄位；按「存款及增加」、「電子支付」和「費用」分組；多行描述常見於商家詳細資訊
• Bank of America — 獨立的提款/存款欄位；末尾包含「每日餘額」部分；包含帳號、對帳單週期、路由號碼等詳細標頭
• Wells Fargo — 獨立欄位；包含「每日餘額摘要」部分；將其 CSV 下載稱為「逗號分隔」
• Capital One — 消費者卡片採用簡潔的單一金額版面；標頭資訊最少
• Citi — 通常包含國際交易詳情，原始貨幣金額和匯率顯示在獨立行上

欄位排列變化

除了借方/貸方問題，欄位順序也沒有標準化：

• 欄位順序：日期-說明-金額-餘額 與 日期-金額-說明-餘額
• 支票號碼：商業帳戶中存在，個人帳戶中不存在
• 參考號碼：商業對帳單中常見，個人對帳單中罕見
• 累計餘額：每筆交易後更新（最常見）與每日小計與完全不存在

---

數位 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（回車 + 換行）分隔
• 欄位以逗號分隔
• 包含逗號、引號或換行的欄位必須用雙引號括起來
• 欄位內的雙引號透過重複來轉義

實際應用中的分隔符變化：

• 逗號 (,) — 標準，用於美國/英國
• 分號 (;) — 用於逗號作為小數點分隔符的國家（法國、德國、義大利、西班牙、巴西）
• Tab 鍵 (\t) — TSV 格式，避免分隔符衝突

編碼問題：

• 建議使用 UTF-8 以實現互通性
• UTF-8 BOM (位元組順序標記)：標準不要求，但 Windows 上的 Excel 需要它才能正確顯示非 ASCII 字元（重音字母、貨幣符號）。如果沒有 BOM，Excel 可能會將 UTF-8 解釋為 Windows-1252，導致字元損壞。
• 在歐洲地區設定中，Excel 使用分號而不是逗號作為欄位分隔符

限制：

• 無資料類型 — 一切皆為文字（帶前導零的數字會損壞，長帳號會變成科學記號）
• 不支援多工作表
• 無格式或公式
• 無中繼資料（無帳戶資訊，無重複偵測 ID）

最適用於： 最大相容性 — 幾乎所有會計程式、資料庫和試算表都可以匯入 CSV。當 QBO/OFX 不可用時的通用備用方案。

QBO (QuickBooks Web Connect)

內容： QuickBooks（桌面版和線上版）的匯入格式。QBO 檔案基於 OFX 規範，並帶有 QuickBooks 特定的擴展。

重要澄清： 「.QBO」不代表「QuickBooks Online」 — 它代表 QuickBooks Web Connect 格式，適用於 QuickBooks 桌面版和 QuickBooks 線上版。

每筆交易的必填欄位：

• TRNTYPE — 交易類型 (DEBIT, CREDIT, CHECK, DEP, DIRECTDEP, DIRECTDEBIT, ATM, POS, XFER, PAYMENT, FEE, SRVCHG, INT, OTHER)
• DTPOSTED — 日期，格式為 YYYYMMDD
• TRNAMT — 金額（借方為負）
• FITID — 金融機構交易 ID
• NAME — 收款人/說明

為何 FITID 很重要： QuickBooks 會追蹤每個帳戶中匯入過的每個 FITID。如果具有相同 FITID 的交易再次匯入，QuickBooks 會靜默跳過它 — 防止使用者重新匯入重疊的對帳單週期時產生重複條目。這種自動重複偵測是 QBO 相對於 CSV 的最大優勢。

額外資料： QBO 還包含帳戶 ID、銀行 ID（路由號碼）、貨幣、支票號碼、備註和期末餘額 — 這是 QuickBooks 任何匯入格式中最豐富的資料集。

最適用於： QuickBooks 使用者（桌面版和線上版）。提供最豐富的匯入體驗，具有自動重複偵測和交易類型分類功能。

OFX (Open Financial Exchange)

歷史： 由 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 聯盟併入 Financial Data Exchange (FDX) 聯盟，該聯盟現在管理該規範。FDX 擁有超過 200 個成員組織和 7,600 萬個消費者帳戶。

為何 OFX 是通用標準： OFX 是當您透過銀行饋送將銀行帳戶直接連接到會計軟體時使用的相同格式 — 相同的格式也適用於檔案匯入。

最適用於 Xero 使用者： Xero 會自動匯入 OFX 檔案，無需手動欄位映射。上傳檔案後，交易會立即顯示，並帶有正確的日期、金額和說明。也適用於 Wave、Sage、FreshBooks 和大多數會計軟體。

QFX (Quicken Financial Exchange)

內容： Intuit 專有的 OFX 變體，專門與 Quicken 搭配使用。QFX 檔案是帶有額外專有欄位的標準 OFX 檔案。

關鍵專有欄位： INTU.BID — Quicken 銀行識別碼。此數字 ID 映射到 Quicken 內部資料庫中的一家銀行。如果沒有它，Quicken 將拒絕匯入檔案。

與標準 OFX 的差異：

• 標頭中需要 INTU.BID
• 可能包含其他以 INTU.* 為字首的欄位
• 金融機構向 Intuit 支付授權費以提供 QFX 下載
• Quicken 將不會匯入沒有 INTU.BID 欄位的標準 OFX 檔案

最適用於： Quicken 個人理財軟體使用者。必需的格式 — 沒有其他替代方案有效。

QIF (Quicken Interchange Format)

內容： Intuit 最初為 Quicken 開發的傳統純文字格式。標籤-值對，每行一個，帶有單字元標籤：D 代表日期，T 代表金額，P 代表收款人，L 代表類別，M 代表備註，N 代表支票號碼，^ 代表記錄結束。

為何被取代： QIF 缺乏重複偵測機制（沒有 FITID 等效項），沒有帳戶識別欄位，沒有銀行路由資訊，沒有餘額資料，並且在不同實作中日期格式不一致。

仍然相關： 一些會計軟體（Xero、Sage、GnuCash）仍然接受 QIF 匯入。對於傳統系統遷移很有用。

JSON (JavaScript Object Notation)

現狀： JSON 尚未成為銀行對帳單檔案的標準，但越來越多地用於：

• 開放銀行 API（英國開放銀行標準、PSD2 柏林集團）
• FDX API（金融資料交換 — OFX 的繼承者，200 多個成員組織）
• Plaid、Yodlee、MX 和其他資料聚合器 API
• 開發人員和自動化工作流程

日益普及： 開放銀行法規（歐洲的 PSD2、美國的 CFPB 第 1033 條）正在加速 JSON API 的採用。FDX API 使用帶有 OAuth 2.0 的 JSON/REST，代表了金融資料交換的未來方向。

最適用於： 建立自動化工作流程、金融科技整合、自訂儀表板和開放銀行 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

經驗法則： QuickBooks 使用 QBO，Quicken 使用 QFX，其他所有軟體使用 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 支援 133 種語言，自動偵測日期格式、數字格式和字元編碼 — 包括從右到左的阿拉伯文和希伯來文、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

美國自動清算所交易的檔案格式。固定寬度 ASCII，每行恰好 94 個字元。ACH 在美國每年處理約 300 億筆交易。當您的銀行對帳單顯示「ACH CREDIT」或「ACH DEBIT」時，底層交易是透過 NACHA 格式在銀行之間傳輸的。

---

為您的工作流程選擇正確的格式

決策指南

如果符合以下情況，請使用 QBO： 您使用 QuickBooks（桌面版或線上版）。您可以獲得交易類型分類、透過 FITID 進行重複偵測，以及最豐富的匯入中繼資料。

如果符合以下情況，請使用 OFX： 您使用 Xero、Sage、Wave 或其他 OFX 相容軟體。Xero 無需手動欄位配置即可自動映射欄位。

如果符合以下情況，請使用 QFX： 您使用 Quicken。這是 Quicken 唯一接受的格式。

如果符合以下情況，請使用 Excel： 您需要在匯入前審閱、分析或操作資料。建立樞紐分析表、執行公式或準備報告。

如果符合以下情況，請使用 CSV： 您的軟體未列於上方，或者您需要最大程度的系統相容性。請準備手動映射欄位。

如果符合以下情況，請使用 JSON： 您正在建立自動化工作流程、API 整合或自訂報告系統。

專業提示

• 當您的軟體支援時，始終優先使用 QBO/OFX 而非 CSV — 僅重複偵測功能就能省去數小時的清理工作
• 保留原始 PDF 檔案與您轉換後的檔案一起 — 它是您的審計追蹤和原始文件
• 每次匯入後進行驗證 — 抽查期初/期末餘額和一些隨機交易
• 將格式與軟體匹配 — 為您的會計平台使用原生格式可避免手動欄位映射並啟用自動功能

---

免費試用

準備好轉換您的第一份對帳單了嗎？立即上傳 PDF — PDFSub 可轉換為 Excel、CSV、QBO、OFX、QFX 和 JSON 格式。數位對帳單完全在您的瀏覽器中處理，以實現最大隱私。立即開始 7 天免費試用，完整存取所有格式。