ドイツ銀行の取引明細書を
Excelに変換する方法

ドイツ銀行の口座取引明細書フォーマットを理解する

ドイツ銀行の口座取引明細書（Kontoauszug）は、一見すると他の銀行取引明細書と同様に、日付と金額が記載された取引のリストです。しかし、表面的な類似性の背後には、データをExcelに取り込もうとする際に重要となる、いくつかの癖が隠れています。

明細書のレイアウトは4つの列で構成されています。ブーフングスターク（記帳日）列、ヴェルトシュテルング（起算日）列、フェアヴェンドゥングスツヴェック（取引目的）列、そしてウムザッツ（取引金額）列です。各ページには、ザルド（残高）と、毎月の発行ごとに連番で増加する口座取引明細書番号（Kontoauszug Nr.）が記載されています。

金額列はドイツ語の10進数表記を使用しており、小数点の区切りにはカンマが使われます（1,234.56ではなく1.234,56）。日付はDD.MM.YYYY形式で表示されます。これらの違いは両方とも、データを英語ロケールのExcelワークブックに直接貼り付ける際に問題を引き起こします。さらに微妙な点として、2つの日付列は異なる目的を持っています。ブーフングスタークは銀行が取引を処理した日付であり、ヴェルトシュテルング（起算日）は利息の計算が開始される日付を決定します。キャッシュフロー分析や照合の際には、両方の日付が重要です。

取引の説明には、ドイツの決済システムに固有のタイプコードが含まれています。SEPAベーシスラストシュリフト（SEPA基本口座引落、通常は事業者が消費者から徴収する際に使用）、SEPAフィルメンラストシュリフト（SEPA企業間口座引落）、グートシュリフト（入金）、ラストシュリフト（口座引落）、カルテンツァールング（カード支払い）、ダウアーアウフトラーク（自動振込）などです。それぞれが異なる支払いメカニズムを表しており、ドイツの簿記（Buchhaltung）において適切な勘定科目を割り当てるためには、これらを区別することが重要です。

明細書には、取引詳細内に受取人/支払義務者（Begünstigter/Zahlungspflichtiger）の行、双方のIBANとBIC、場合によっては取引経路を示すInfoコード（支払いがDBオンラインバンキングまたはDBモバイルアプリのどちらから開始されたか）も含まれます。複数通貨の口座の場合、金額と並んでヴェールング（通貨）列が別途表示されます。

ドイツ銀行は、2010年の買収以降、ポストバンクの口座も扱っており、これらの明細書は列の位置やヘッダーのスタイルが若干異なるレガシーフォーマットを使用しています。db-cashやmaxblueからの投資口座明細書では、証券コード、株数、価格、取引所手数料のための追加列が導入され、標準的な取引フォーマットを超えたものになっています。

ドイツ銀行の口座取引明細書に手作業が不向きな理由

一見すると、PDFから値を手動でExcelにコピーするのが簡単な方法に思えます。しかし、ドイツ銀行のPDFには、特に3つの落とし穴があります。

第一に、日付形式の問題です。 Excelの自動認識機能は、ワークブックのロケールが英語に設定されている場合、05.03.2025を3月5日ではなく5月3日として解釈します。1年分の取引明細書を処理し、照合時に初めて日付の誤りに気づいた場合、すべての日付列を修正する必要があります。集中力のある人でも、12ヶ月分の取引を手動で再フォーマットするには30～60分かかります。

第二に、小数点表記の問題です。 1.234,56を英語ロケールのExcelセルに貼り付けると、ソフトウェアはピリオドを小数点と解釈し、1.234として認識して、端数のセント部分を完全に切り捨てます。合計で€4,812.83になるはずの少額SEPA引き落としのバッチが、数十行にわたって丸め誤差が累積し、€4,776になってしまいます。これを防ぐには、すべての金額列を元のPDFと照合する必要があり、まさに避けたかった作業が発生します。

第三に、GoBDへの準拠の問題です。 ドイツの税法では、企業は元の形式の銀行取引明細書を§147 AO（租税基本法）に基づき10年間保管し、監査時に機械可読形式で利用できるようにすることが義務付けられています。手動で入力したExcelシートは、原本とはみなされません。GoBD（電子形式による帳簿、記録、書類の適正な管理と保存に関する原則）のフレームワークは、デジタル記録の不変性、トレーサビリティ、完全性を明確に要求しています。そのため、たとえコピー＆ペーストの作業を注意深く行ったとしても、監査目的では元のPDFが必要となり、作業量が減るどころか倍増してしまいます。

AI抽出が従来と異なる点

AI抽出は、従来のOCRによる位置ベースのアプローチを、意味理解に置き換えます。「座標(120, 340)のテキストを見つけて『取引日』とラベル付けする」という方法ではなく、視覚言語モデルが人間と同じように書類を読み取ります。つまり、文脈、列ヘッダー、空間的な関係性に基づいて、各テキストが何を意味するかを識別します。

具体的にドイツ銀行の取引明細書の場合、AIは標準的な4列レイアウト、ポストバンクのレガシー形式、maxblueの投資信託フォーマットのいずれに対しても、事前定義されたテンプレートを必要としません。ヘッダーラベルを認識してBuchungstag（ブーフングスターク）列を特定し、その隣のWertstellung（ヴェルトシュテルング）列を読み取り、たとえ明細書で列ヘッダーが省略されていても両者を区別します。出力したい列（Buchungstag、Wertstellung、Verwendungszweck、Umsatz、Saldo）を定義するだけで、AIはレイアウトのバリエーションに関係なく、すべてのページで対応する値を特定します。

これは、テンプレートベースのツール（Docparser、Parseur、ABBYYなど）とは根本的に異なります。それらのツールでは、レイアウトごとに各フィールドの領域を定義する必要があります。ドイツ銀行が明細書のデザインを変更した場合（オンラインバンキングのインターフェース更新時に定期的に行われます）、テンプレートベースのツールは誰かが領域を更新するまで機能しなくなります。一方、意味ベースの抽出エンジンは、位置ではなく意味で読み取るため、新しいレイアウトに自動的に適応します。

同じ原理は数値形式の処理にも当てはまります。AIは、元のPDFが小数点区切りとしてカンマとピリオドのどちらを使用しているかに関係なく、一貫した機械可読形式（標準的な小数点表記）で金額を出力します。日付は内部的にISO形式（YYYY-MM-DD）に変換され、その後お好みの形式で表示されます。DD.MM.YYYY形式と日付の混同問題は、抽出レイヤーで解決されるため、Excelでの後処理修正が不要になります。

ドイツ銀行の取引明細書を4ステップで変換する方法

ここでは、ドイツ銀行の口座取引明細書（Kontoauszug）PDFをダウンロードからエクスポートまで、構造化されたExcelテーブルに変換する実践的なワークフローを紹介します。

ご自身のドイツ銀行口座取引明細書（Kontoauszug）で直接お試しください。ゲストデモは登録不要でご利用いただけ、処理後ファイルが保存されることはありません。

スプレッドシートにおけるブーフングスターク（記帳日）とヴェルトシュテルング（起算日）の扱い方

ドイツの銀行取引明細書に特有の二重日付形式は、初めて使う方をしばしば混乱させます。ブーフングスターク（記帳日）は、銀行が口座に入金または引き落としを行った日付です。ヴェルトシュテルング（起算日）は、資金が実際に利用可能になったり、利息が発生し始める日付です。SEPAの口座引落の場合、これら二つの日付は通常同じです。しかし、小切手、海外送金、週末をまたいで処理された取引では、1～3営業日異なることがあります。

スプレッドシートに両方の日付がある場合、ブーフングスタークで並べ替えると、銀行が明細書で使用する時系列順になり、元のPDFとページごとに照合するのに便利です。ヴェルトシュテルングで並べ替えると、実際のキャッシュフローのタイミングがわかり、利息計算や資金ポジション分析に役立ちます。両方の列を保持しておけば、どちらかを選ぶ必要はありません。多くのドイツの経理チームは、DATEVへのインポート（ベレークダートゥム（証憑日付）フィールドにマッピング）にはヴェルトシュテルングを、内部照合にはブーフングスタークを使用しています。

抽出されたスプレッドシートでは、両方の日付が一貫した機械可読形式（ISO形式（2025-03-05）またはDD.MM.YYYY形式。地域の設定によります）で表示される必要があります。重要なのは、抽出ツールが変換を処理してくれるため、日付をExcelに貼り付けて月と日が入れ替わってしまう心配がないことです。

ドイツの会計ソフトウェア向けデータ準備

全取引を抽出したスプレッドシートは便利です。しかし、ドイツの会計ソフトウェア用にフォーマットされたスプレッドシートがあれば、時間の節約効果はさらに大きくなります。ドイツ銀行の取引明細データの主な出力先は、DATEV、lexoffice、sevDeskの3つであり、それぞれに固有のフォーマット要件があります。

DATEVは、ドイツの税理士（Steuerberater）が使用する主要なシステムです。DATEVでは、区切り文字にカンマではなくセミコロン、小数点記号にピリオドではなくカンマ、特定の文字エンコーディング（UTF-8ではなくANSI/Windows-1252）、そして特定の列順序が求められます。勘定科目表は、ドイツの標準的な2つの会計フレームワークであるSKR03またはSKR04に従います。DATEVに直接インポートすることを目的としてCSVをエクスポートする場合、記帳された金額には正しい借方/貸方の符号規則が必要であり、事業用口座の場合は取引タイプごとに適切な税コードを割り当てる必要があります。多くの経理チームは、クリーンな標準CSVをエクスポートし、DATEVへのマッピングは税理士に任せることを好みますが、エクスポートされたCSVがセミコロンと正しいエンコーディングを使用していることを確認することで、インポート拒否のよくある原因を回避できます。

lexoffice（旧Lexware Office）は、独自の列マッピングでCSVインポートを受け付けており、取引データにIBANとBICが含まれている必要があります。sevDeskは、APIを通じた銀行取引明細の直接インポートをサポートしています。どちらのプラットフォームでも、ヴェルトシュテルング（Wertstellung）列を記帳日フィールドにマッピングし、フェアヴェンドゥングスツヴェック（Verwendungszweck、取引目的）フィールドに完全な取引説明を入力することで、インポートされた取引が銀行フィードと正しく照合されるようになります。

抽出したドイツ銀行のデータを、Buchungstag（ブーフングスターク、記帳日）、Wertstellung（ヴェルトシュテルング、起算日）、Verwendungszweck（フェアヴェンドゥングスツヴェック、取引目的）、Umsatz（ウムザッツ、取引金額）、Währung（ヴェールング、通貨）、IBANといった明示的な列名を持つクリーンなCSVとしてエクスポートすれば、ご自身または税理士が最小限の労力でこれらを対象システムのフィールドにマッピングできます。その代替手段は、12ヶ月分の取引をDATEVの入力マスクに手入力することであり、取引数によっては明細書1ページあたり15～30分の作業が発生します。

複数の取引明細書を一括処理して年末対応

ドイツの年末会計では、各事業口座の月次取引明細書（Monatsauszüge）12ヶ月分すべてを収集し、データを抽出して、年間合計を簿記（Buchhaltung）の記録と照合する必要があります。ドイツ銀行の事業口座が1つだけの企業なら12のPDF、メインの運転資金口座、VAT/キャッシュプール口座、給与口座を持つGmbHなら、毎年12月には36ものPDFを処理することになります。

これらを1つずつアップロードして個別にエクスポートするのは、手作業による入力を二重に行うようなものです。バッチファーストのアプローチでは、すべてのPDFを1回のセッションでアップロードし、ツールがそれらをまとめて処理し、すべてのページを1つの出力テーブルに結合します。各ページの終わりの残高（Saldo）は、次のページの開始残高と一致するはずです。出力全体で残高（Saldo）が一貫していれば、各数値を元のソースと照合しなくても、抽出の正確性が確認できます。

税理士（Steuerberater）への年末引き継ぎでは、マージされたExcelファイルに口座取引明細書番号（Kontoauszug Nr.）の列を含め、各取引が元の月次明細書ページにトレース可能であるようにします。このトレーサビリティは、監査対応可能なデジタル記録に対するGoBD要件を直接サポートします。もし税務署（Finanzamt）が3月の特定の取引について裏付け書類を要求した場合、スプレッドシートから口座取引明細書番号（Kontoauszug Nr.）を特定し、元のPDFを取得すれば、監査証跡は1分以内に完了します。

デジタル銀行取引明細書でGoBD準拠を維持する

銀行取引明細書に関するGoBD準拠は、3つの要件に基づきます。完全性（すべての取引が漏れなく記録されていること）、不変性（元の記録が後から変更されていないこと）、機械可読性（データが自動化された手段で検索・評価可能であること）です。手動でExcelにコピー＆ペーストする方法は、これら3つすべてに違反します。設計上不完全であり（フィールドをスキップする）、監査証跡なしで編集可能で、監査人のIDEAツールが照会できる構造化データレイヤーが欠けています。

AIによって抽出されたスプレッドシートは、元のPDFから完全な取引セットを保持します。元のPDFは不変の記録として保存され（GoBDは§147 AOに基づき10年間の保存を義務付けています）、抽出されたExcelファイルは機械可読な作業用コピーとして機能します。両方（GoBD準拠のアーカイブに保存された元のPDFと、日常業務で使用する抽出済みExcel）を保存すれば、単一のワークフローに縛られることなく、監査対応要件を満たせます。

パスワードで保護された銀行取引明細書（多くのドイツ銀行のデジタル取引明細書は暗号化されたPDFで提供されます）については、ImageToTable.aiのメール受信機能を使用すると、登録済みのメールアドレスから取引明細書を転送する際に、事前設定されたパスワードを自動的に適用できます。手動による復号化の手順は不要です。抽出されたデータはアカウントの処理キューに直接送られ、元の暗号化されたPDFはアーカイブ用に保持されます。

よくある質問

AIはパスワードで保護されたドイツ銀行のPDFを処理できますか？

はい。アカウント設定でパスワードを保存しておくと、暗号化されたPDFが届いた際に自動的に適用されます。これは直接アップロードと、メール受信機能で転送された明細書の両方で機能します。

ポストバンクの旧形式の明細書でも抽出は機能しますか？

はい。AIはポストバンク形式の明細書（標準的なドイツ銀行の明細書とは列のレイアウトが若干異なります）を、個別のテンプレートを必要とせずに読み取ります。旧形式のレイアウトのバリエーションも、現在の口座取引明細書形式と同様に処理されます。

maxblueやdb-cashの投資口座明細書はどうですか？

これらの明細書には、ヴェルトパピーアケンヌンマー（証券コード）、株数、価格、手数料の内訳など、証券固有の追加列が含まれています。抽出はこれらの形式でも機能します。出力を定義する際に関連する列名を追加するだけで済みます。

DATEV形式で直接エクスポートできますか？

このツールは標準のCSVとExcelをエクスポートします。DATEVには、区切り文字（セミコロン）、エンコーディング（ANSI/Windows-1252）、勘定科目フレームワーク（SKR03/SKR04）に関する特定の要件があります。ツールからのクリーンなCSVエクスポートを後処理してDATEV準拠のファイルにするか、インポート形式を処理する税理士に直接渡すことができます。事前設定されたDATEVプロファイルは現在利用できません。エクスポートされるデータは構造化された中間データです。

一度に何ヶ月分の明細書を処理できますか？

特に制限はありません。各明細書ページは、お客様のプランのページ枠に対してカウントされます。バッチ処理では、選択されたすべてのファイルが1つの出力テーブルにマージされ、各取引行のソース月を識別する口座取引明細書番号列が追加されます。

カンマからピリオドへの小数点変換は組み込まれていますか？

はい。AIはソースPDFからドイツ語の小数点表記（1.234,56）を読み取り、エクスポートされたExcelまたはCSVでは標準の小数点形式（1234.56）で金額を出力します。後処理や検索・置換の手順は必要ありません。

AI抽出した口座取引明細書データにGoBDはどのように適用されますか？

元のPDFは、改ざん不可の記録として10年間保存する必要があります（§147 AOに基づく）。抽出されたExcelファイルは、分析や会計ソフトへのインポートのための作業用コピーです。元のPDFが準拠したアーカイブ（改ざん不可、検索可能、機械可読）に保存されている限り、抽出レイヤー自体がコンプライアンス上の問題を引き起こすことはありません。生成された出力と併せて、必ず元のPDFを保管してください。

ゲストページでご自身のドイツ銀行取引明細書を変換できます。登録不要、ファイル保存もありません。または、無料アカウントに登録して、テンプレートの保存、バッチ処理、Google Sheetsアドオンによるワークブックへの直接抽出をご利用いただけます。