銀行取引明細書のフォーマットを理解する：技術ガイド

銀行取引明細書のPDFは、日付、摘要、金額、残高が整然とした列に並んでおり、シンプルに見えます。しかし、その外観の裏には、構造化データを保存するために設計されたものではないフォーマット（PDF）と、入力フォーマットと利用可能な多くの出力フォーマットの両方を理解する必要がある変換プロセスが存在します。

このガイドでは、（銀行を問わず）すべての銀行取引明細書に表示される12のセクション、銀行取引明細書PDFの技術的な実態、銀行ごとのレイアウトのバリエーション、遭遇する可能性のあるすべての出力フォーマット（Excel、CSV、QBO、OFX、QFX、QIF、JSON）、国際的なフォーマットの違い、そして金融データ交換を管理する業界標準について説明します。

銀行取引明細書の構造

チェース、バンク・オブ・アメリカ、ウェルズ・ファーゴ、HSBC、ドイツ銀行など、どの銀行の取引明細書も同じ12のセクションで構成されています。「控除」と「引き出し」のようにラベルが変わったり、列の配置が異なったりしますが、基本的な構造は一貫しています。これらのセクションを識別できるようになれば、どの明細書も familiar に見えてきます。

このインフォグラフィックをブログで利用したいですか？ こちらの埋め込みコードをコピーしてください：

主要な銀行ごとにこれらの12セクションがどのように配置されているかを詳しく解説した、銀行別の詳細については以下をご覧ください：

• チェース銀行取引明細書の説明
• バンク・オブ・アメリカ銀行取引明細書の説明
• ウェルズ・ファーゴ銀行取引明細書の説明
• シティ銀行取引明細書の説明
• キャピタル・ワン銀行取引明細書の説明

なぜPDFはデータフォーマットではないのか

PDFはPortable Document Formatの略で、ISO 32000（バージョン2.0はISO 32000-2:2020）として標準化されています。その目的はただ一つ、あらゆる画面やプリンターで文書を同一に見せることでした。これは視覚的な忠実性には優れていますが、データ抽出には非常に不向きです。

銀行取引明細書PDFの内部構造

PDFページの内部にはコンテンツストリームがあります。これはPostScript風言語で書かれた描画オペレータのシーケンスです。テキストは特定のオペレータを使用してレンダリングされます：

• BT / ET - Begin Text / End Text：テキストオブジェクトの境界
• 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

タグ付きPDFには、コンテンツをヘッダー、段落、テーブル、テーブル行、テーブルセルとしてマークする、隠された論理構造ツリー（HTMLタグに似ています）が含まれています。これにより、抽出が大幅に容易になります。

タグなしPDFには構造メタデータがありません。抽出ツールは生の配置データのみを取得し、すべてを推測する必要があります。

ほとんどの銀行が生成する明細書PDFはタグなしです。 銀行はバッチ処理システム（Oracle BI Publisher、SAP Crystal Reports、またはカスタムの印刷-PDFパイプライン）を使用して明細書を生成します。アクセシビリティ規制（ADA/WCAG）は銀行にタグ付きPDFへの移行を促していますが、普及は遅れています。ほとんどの大手銀行からの標準ダウンロードはタグなしのままです。

銀行取引明細書のレイアウトバリエーション

銀行がPDF明細書をフォーマットする方法に業界標準はありません。日付、摘要、借方、貸方、残高という同じ5つの情報が、銀行ごとに異なる配置で表示されます。

単一金額列（符号付き）

日付 摘要 金額 残高
01/15/26 給与振込 +3,500.00 5,200.00
01/16/26 POS購入 食料品 -87.50 5,112.50

借方はマイナス、貸方はプラス（またはその逆）です。小規模銀行、信用組合、デジタルバンクでよく見られます。抽出する金額列が1つしかないため、解析が容易です。

別々の借方/貸方列

日付 摘要 引き出し 預け入れ 残高
01/15/26 給与振込 3,500.00 5,200.00
01/16/26 POS購入 食料品 87.50 5,112.50

チェース、バンク・オブ・アメリカ、多くの伝統的な銀行で使用されています。抽出ツールは、どの列に金額が含まれているかを特定し、それに応じて符号を決定する必要があります。

取引タイプ別グループ化

ビジネスおよび法人口座では、取引がグループ化されることがよくあります：

預け入れおよびその他の貸方 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支払 - ベンダー社 3,200.00 01/20  オンライン普通預金口座への振替 1,000.00 電子取引合計 4,200.00

セクションヘッダーが、取引が借方か貸方かを決定します。「預け入れ合計」のようなサマリー行は、取引データから除外する必要があります。

銀行固有の特徴

• チェース - 別々の借方/貸方列。 "DEPOSITS AND ADDITIONS"、"ELECTRONIC PAYMENTS"、"FEES" でグループ化。複数行の摘要がよくある（販売店詳細用）。
• バンク・オブ・アメリカ - 別々の引き出し/預け入れ列。 "Daily Balance" セクションを末尾に含む。口座番号、明細期間、ルーティング番号を含む広範なヘッダー。
• ウェルズ・ファーゴ - 別々の列。 "DAILY BALANCE SUMMARY" セクションを含む。CSVダウンロードを「Comma Delimited」と呼ぶ。
• キャピタル・ワン - 個人カード向けにクリーンな単一金額レイアウト。最小限のヘッダー情報。
• シティ - 国際取引の詳細を、元の通貨金額と換算レートとともに別々の行に含めることが多い。

列配置のバリエーション

借方/貸方の問題を超えて、列の順序も標準化されていません：

• 列の順序：日付-摘要-金額-残高 vs. 日付-金額-摘要-残高
• 小切手番号：法人口座には存在するが、個人口座にはない。
• 参照番号：法人明細書で一般的、個人明細書ではまれ。
• 実行残高：取引ごと（最も一般的） vs. 日次小計 vs. 全くなし。

デジタルPDFとスキャン済みPDF

変換精度の最も重要な要因は、PDFがデジタルかスキャン済みかです。

デジタル（ネイティブ）PDF

銀行のシステムが明細書をダウンロードする際にプログラムで作成します。テキストは、フォントエンコーディングを持つコンテンツストリームオペレータとして保存されます。

• 精度：テキスト抽出で99%以上 - 認識エラーなし。
• 速度：1ページあたりミリ秒単位。
• プライバシー：完全にブラウザ内で処理可能 - ファイルがデバイスから離れることはありません。
• ファイルサイズ：通常、1ページあたり50KB～500KB。
• 識別方法：個々の単語を選択してハイライトできます。

スキャン済みPDF

物理的な文書をスキャンまたは写真撮影して作成された紙の明細書の画像。コンテンツはラスター化された画像（JPEG、JPEG2000、CCITT、またはFlate圧縮）として保存されます。

• 精度：プロフェッショナルOCRで95～99％、汎用OCRで65～70％。
• 速度：1ページあたり数秒（画像処理が必要）。
• プライバシー：通常、サーバーサイド処理が必要（OCRのためにファイルをアップロードする必要がある）。
• ファイルサイズ：1ページあたり200KB～2MB以上。
• 識別方法：テキストを選択できません。400％にズームするとピクセル化が見えます。

なぜスキャン済み精度が金融データでより重要なのか

文字精度97％という率は素晴らしいように聞こえますが、金融データに適用するとそうではありません。1,000文字の金額がある明細書では、30文字が誤読されます。1文字でも誤読されると、取引金額が変わります。「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（Comma-Separated Values）

標準：RFC 4180 (2005) - "Common Format and MIME Type for Comma-Separated Values."（カンマ区切り値の共通フォーマットと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 Web Connect）

概要：QuickBooks（デスクトップ版とオンライン版の両方）のインポートフォーマット。QBOファイルは、QuickBooks固有の拡張機能を持つOFX仕様に基づいています。

重要な注意：".QBO" は "QuickBooks Online" を意味するのではなく、QuickBooks Web Connectフォーマットの略であり、QuickBooks DesktopとQuickBooks Onlineの両方で機能します。

トランザクションごとの必須フィールド：

• 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によって作成。1997年2月にバージョン1.0がリリースされました。

バージョンの進化：

• 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以上の会員組織と7600万の個人口座を擁しています。

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用に開発したレガシーなプレーンテキストフォーマット。タグと値のペアで、1行に1つ。単一文字タグを使用：Dは日付、Tは金額、Pは受取人、Lはカテゴリ、Mはメモ、Nは小切手番号、^はレコード終了。

置き換えられた理由：QIFには重複検出メカニズム（FITID相当なし）、口座識別フィールドなし、銀行ルーティング情報なし、残高データなし、実装間で一貫性のない日付フォーマットといった欠点があります。

依然として関連性がある：一部の会計ソフトウェア（Xero、Sage、GnuCash）は依然としてQIFインポートを受け入れています。レガシーシステムの移行に役立ちます。

JSON（JavaScript Object Notation）

現在の状況：JSONはまだ銀行取引明細書ファイルの標準ではありませんが、以下でますます使用されています：

• オープンバンキングAPI（英国オープンバンキング標準、PSD2ベルリングループ）。
• FDX API（Financial Data Exchange - OFXの後継、200以上の会員組織）。
• Plaid、Yodlee、MXなどのデータアグリゲーターAPI。
• 開発者および自動化ワークフロー。

採用の拡大：オープンバンキング規制（欧州のPSD2、米国のCFPBセクション1033）は、JSON APIの採用を加速させています。FDX APIはJSON/RESTとOAuth 2.0を使用しており、金融データ交換の将来の方向性を示しています。

最適な用途：自動化ワークフロー、フィンテック統合、カスタムダッシュボード、オープンバンキングAPI統合を構築する開発者。

フォーマット比較（一目でわかる）

会計ソフトウェアとの互換性

お使いの会計ソフトウェアはどのフォーマットを受け入れますか？

経験則：QuickBooksにはQBO、QuickenにはQFX、その他にはOFXを使用し、CSVを普遍的なフォールバックとして使用します。

国際的なフォーマットの違い

海外の銀行取引明細書を扱う場合、ほとんどの変換ツールがつまずくフォーマットの違いに遭遇します。

日付フォーマット

曖昧さの問題：「03/04/2026」は米国では3月4日ですが、ヨーロッパでは4月3日です。明細書中のすべての日付の日の値が12以下の場合、原産国を知らずに正しいフォーマットを判断するアルゴリズム的な方法はありません。変換ツールは、フォーマットを決定するために、明細書中のすべての日付をスキャンし、12を超える値を探す必要があります。

数値フォーマット

ヨーロッパの銀行からの「10.000,45」は、1万45セントを意味します - 10点00045ではありません。これを間違えると、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つの取引に対して複数の日付が含まれる場合があります：

• 取引日 - 実際には購入または送金が発生した日。
• 記帳日 - 銀行が処理して記録した日（通常、クレジットカード購入の場合は1～3営業日後）。
• 値日（バリューデート） - 資金が実際に利用可能になった日（利息計算に影響、国際銀行業務で一般的）。

ほとんどの個人向け明細書には、記帳日のみが表示されます。法人向け明細書には、取引日と記帳日の両方が含まれることがよくあります。

借方/貸方の表現

銀行は借方と貸方を異なる方法で表現します：

• 符号付き金額：借方は-87.50、貸方は+3,500.00。
• 別々の列：「引き出し」と「預け入れ」。
• 略語：「DR」（Debit）または「CR」（Credit）（英国/連邦諸国で一般的）。
• 括弧：（87.50）（借方、会計上の慣習）。

実行残高

• 取引ごとの残高 - 各取引後に更新（米国個人向け明細書で最も一般的）。
• 日次残高のみ - 各日の終わりに表示される残高（法人明細書で一般的）。
• 実行残高なし - 開始残高と終了残高のみ（一部の国際明細書）。

実行残高は検証に役立ちます。各取引が次の行に正しく残高を移動させていることを確認できます。

標準ヘッダー情報

ほとんどの銀行取引明細書には、口座名義人、口座番号（しばしば部分的にマスクされている）、明細期間、開始残高と終了残高、預け入れと引き出しの合計、銀行のルーティングコード/ソートコード/SWIFT BICが含まれます。

パスワード保護

銀行がPDFを暗号化する方法

銀行は通常、AES-128またはAES-256暗号化を使用します。2つの保護モードがあります：

• ユーザーパスワード（オープンパスワード）：ファイルを開くために必要。
• オーナーパスワード（権限パスワード）：PDFは開けますが、編集/コピーが制限される場合があります。

一般的なパスワードパターン

その他の一般的なパターンには、口座番号の下4桁、顧客ID、または会員番号などがあります。銀行は通常、電子明細書の利用を開始した際にパスワードパターンを通知します。

複数ページ明細書の課題

長い明細書（数百件の取引がある法人口座など）は、いくつかの抽出上の課題を生じさせます：

取引の分割

取引の摘要が、あるページの末尾で始まり次のページの先頭で続くことがあります。コンバーターは、継続行を検出し、それらを単一の取引にマージする必要があります。

ヘッダーとフッターの繰り返し

ほとんどの銀行は、各ページに列ヘッダーを繰り返し表示し、さらにページ番号、法的免責事項、マーケティングテキストも表示します。これらは特定され、取引データから除外する必要があります。

継続行

多くの取引には複数行の摘要があります：

01/15  ACH電子デビット ベンダー社 $3,200.00  $2,000.00 REF#123456789 INVOICE 2026-001 VENDOR CORP ACCOUNTS PAYABLE

2行目と3行目は、1行目の取引に属する継続行です。通常、日付と金額がなく、摘要列と同じx座標にインデントされて表示されます。

残高繰越

一部の銀行では、継続ページの先頭に「Balance Forward」または「Balance Brought Forward」という行が含まれています。これらは情報提供のみを目的としたもので、取引ではなく、抽出データから除外する必要があります。

一般的な取引略語

銀行取引明細書では、金融機関によって異なる略語が使用されます：

知っておくべき業界標準

これらのフォーマットは、法人銀行業務やトレジャリーマネジメントで使用されています。直接遭遇することはめったにありませんが、これらを理解することで、銀行取引明細書がどのように機能するかがわかります。

BAI2（Bank Administration Institute）

ERPシステム（SAP、Oracle）での自動キャッシュ管理と銀行照合に使用されます。トランザクションタイプコード（例：165 = 事前承認ACHクレジット、455 = ACHデビット、495 = 電信送金）を持つ固定幅ASCIIフォーマット。元々は1987年にリリースされ、現在はASC X9が維持管理しています。

SWIFT MT940 / MT942

世界中の銀行が法人顧客およびトレジャリー部門で使用する、日次末（MT940）および日中（MT942）の銀行取引明細書。SWIFTは1日あたり約4500万件のメッセージを処理します。コロン区切りのフィールド識別子を持つタグベースのフォーマットです。

ISO 20022（camt.053）

MT940の最新のXMLベースの代替フォーマット。ISO 20022ユニバーサル金融メッセージング標準の一部。MT940よりも豊富なデータ、フィールド長制限なし、XSD検証付きの機械解析可能なXML。SWIFTはMTメッセージからISO 20022への移行を進めています。SEPA（単一ユーロ決済地域）は、ヨーロッパの決済においてcamtフォーマットを義務付けています。

NACHA ACH

米国のAutomated Clearing Houseトランザクションのファイルフォーマット。固定幅ASCII、1行あたり正確に94文字。ACHは米国で年間約300億件のトランザクションを処理します。銀行取引明細書に「ACH CREDIT」または「ACH DEBIT」と表示される場合、基になるトランザクションは銀行間でNACHAフォーマットで送信されました。

ワークフローに最適なフォーマットの選択

決定ガイド

QBOを使用する場合：QuickBooks（デスクトップ版またはオンライン版）を使用している場合。トランザクションタイプ分類、FITIDによる重複検出、最も豊富なインポートメタデータを取得できます。

OFXを使用する場合：Xero、Sage、Wave、またはその他のOFX互換ソフトウェアを使用している場合。Xeroは手動での列マッピングなしでフィールドを自動マッピングします。

QFXを使用する場合：Quickenを使用している場合。Quickenが受け入れる唯一のフォーマットです。

Excelを使用する場合：インポート前にデータをレビュー、分析、または操作する必要がある場合。ピボットテーブルを作成したり、数式を実行したり、レポートを準備したりします。

CSVを使用する場合：上記のリストにないソフトウェアを使用している場合、またはシステム間の最大限の互換性が必要な場合。列を手動でマッピングする準備をしてください。

JSONを使用する場合：自動化ワークフロー、API統合、またはカスタムレポートシステムを構築している場合。

プロのヒント

• ソフトウェアがサポートしている場合は、常にCSVよりもQBO/OFXを使用してください。重複検出だけでも、何時間ものクリーンアップ作業を防ぎます。
• 元のPDFを変換済みファイルと一緒に保管してください。それが監査証跡であり、ソースドキュメントです。
• インポートごとに確認してください。開始/終了残高といくつかのランダムなトランザクションをスポットチェックしてください。
• フォーマットをソフトウェアに合わせる：会計プラットフォームのネイティブフォーマットを使用すると、手動での列マッピングが不要になり、自動機能が有効になります。

無料でお試しください

最初の明細書を変換する準備はできましたか？ 今すぐPDFをアップロード - PDFSubはExcel、CSV、QBO、OFX、QFX、JSONに変換します。デジタル明細書は、最大限のプライバシーのために完全にブラウザ内で処理されます。すべてのフォーマットにフルアクセスできる7日間の無料トライアルを開始してください。