ドイツ税関申告書データをExcelに抽出する方法
再入力不要で実現

Zollanmeldung（税関申告書）のデータはどこから来て、どこで詰まるのか

EU域外からドイツに輸入されるすべての貨物には、税関申告（Zollanmeldung、別名EinheitspapierまたはSAD＝単一行政文書）が必要です。この申告書は、貨物を関税手続に割り当て、11桁の関税番号（Zolltarifnummer）で分類し、価格、原産地、正味重量を申告するものです。申告は、ATLAS（ITZBundが運営するドイツの国家関税ITプラットフォーム）を通じて電子的に行われ、法的根拠は欧州連合関税法典（UZK）第158条～第163条です。ATLASは18桁のマスターリファレンス番号（MRN）を発行し、関税率表に照らして申告を検証し、承認されれば貨物を自由流通に解放します。

申告書自体は構造化データです。ATLASはそれを構造化データとして取り込みます。問題はその後の処理です。通関業者は、記録用にZollanmeldungのPDFコピーを送ってきます。同じデータがフラットな文書としてレンダリングされているのです。複数の通関業者や輸入拠点を利用している場合、各業者は独自の形式で申告書を送ります。ある業者は独自のPDFレイアウト、別の業者はスキャンした紙のフォーム、さらに別の業者はATLASのインターネット税関申告（IZA）の印刷物という具合です。すべての申告書でフィールドは同じです。関税番号、原産国、貨物価格、発送国/仕向国、通関手続コード、EORI番号、自重。しかし、それらはページごとに異なる位置にあり、スプレッドシートにきれいにコピー＆ペーストできるものは一つもありません。

ATLASとスプレッドシートの間にあるギャップ、それが両者の間に挟まったPDFです。システムは表示できても読み取れない文書です。ZollanmeldungのPDFからExcelに手入力するすべてのフィールドは、ATLASがすでに構造化された形で保持しているものです。手動入力は情報を追加しているのではなく、申告書1件ごとに形式を変換しているにすぎません。

なぜ手動入力が照合ギャップを生むのか

3つの製品カテゴリーにわたって月間30件の輸入貨物を管理するドイツの輸入マネージャーは、通関業者から約30通のZollanmeldung（税関申告書）PDFを受け取ります。各申告書には最低でも11桁のZolltarifnummer（関税番号）（6桁の国際HSコードを、EU複合命名法で8桁、TARICで10桁、国内レベルで11桁に拡張したドイツ固有のコード）、ユーロ建ての関税評価額、原産国、EORI番号が含まれています。ATLASのポジションレベル画面（Positionsdaten）における完全な輸入申告では、さらに正味重量（Eigenmasse、kg単位）、包装数（Anzahl der Packstücke）、品目価格（Artikelpreis）、通関手続コード（Zollverfahrenscode、4桁のコードで、貨物がどの手続きで輸入され、どの手続きから来たかを示す）が追加されます。

これらの項目を30件の申告書から手動で抽出して1つのスプレッドシートにまとめ、月次報告書を作成するには、1件あたり約4～5分かかります。各PDFから該当フィールドを探し、値を入力し、11桁のZolltarifnummer（10桁のTARICや8桁のKNではなく、ドイツ税関が実際に輸入関税計算に使用する完全な11桁のCodenummer）を正しく入力したか確認する作業です。30件の場合、分析を1行も始める前に2.5時間のデータ入力が必要になります。

照合ギャップは時間だけの問題ではありません。それは3つの構造的な問題であり、取扱量が増えるにつれて悪化します。

第一に、HSコードの転記ミス。 Zolltarifnummerは「6204.62.31.00.0」のような形式で、5つの数字グループからなる合計11桁です。PDFからExcelに打ち直す際、通常のタイピング条件下では約500キーストロークに1回の割合で転記ミスが発生します。11桁の関税コードは11キーストロークです。30件の申告書に平均3つの関税ラインがある場合、約990キーストロークとなり、スプレッドシート内の約2つの関税コードが誤っていることになります。このエラーは、税関監査や関税再計算で発覚するまで見えません。

第二に、照合の遅延。 Zollanmeldungデータを抽出する目的は、サプライヤーの商業送り状（Handelsrechnung）と照合することです。送り状にはFOB深圳で12,000ユーロと記載されています。Zollanmeldungでは、運賃調整後のCIFハンブルク価格である12,800ユーロの関税評価額が申告されています。輸入マネージャーが貨物到着の1週間後に関税データを入力した場合、送り状と申告書の差異は1週間遅れて発見されます。ATLASへの提出とスプレッドシートの利用可能性の間に体系的なデータギャップがあるため、差異は累積します。30件の貨物、30件の潜在的な調整が、貨物が通関した時点ではなく月末に一括で発見されるのです。

第三に、申告書間の比較が不可能。 Zollanmeldungデータが30通の個別PDFに分散している場合、「今月の輸入品のうち、関税番号6204を使用したのはどれか？」という質問に答えるには、30の文書を開いてそれぞれをスキャンする必要があります。「第3四半期にハンブルクに輸入した繊維製品の、1キログラムあたりの平均申告関税評価額はいくらか？」という質問には、まずすべてのデータを抽出する必要がありますが、抽出自体がボトルネックであるため誰も実行しません。データは存在します。単に、質問をサポートできる形式になっていないだけです。これは、GST報告のためのAU BASデータ準備における抽出ボトルネックと構造的に同じです。文書には答えが含まれていますが、ファイル全体に散在しており、比較にはまず抽出が必要なのです。

Zollanmeldung（税関申告書）のフィールドを1つのExcelスプレッドシートに抽出する方法

カスタム列抽出はワークフローを逆転させます。各Zollanmeldung（税関申告書）のPDFを開いて手作業でExcelに入力する代わりに、チームが実際に使用しているドイツ税関の正確なフィールド名を使って列を一度定義し、30件すべての申告書をアップロードエリアにドロップするだけです。エンジンが各PDFを読み取り、各フィールドの意味を理解して（画面上の位置ではなく）特定し、定義した列をヘッダーとして、1行に1申告書のデータが入った1つのスプレッドシートを生成します。出力は30件の個別抽出結果を後でマージする必要があるものではなく、その後の照合作業に適した構造で、Excel（XLSX）としてエクスポート可能な1つのファイルです。

抽出した税関申告書データでできること

スプレッドシートは最終目的地ではなく、次の3つのワークフローを可能にする基盤です。これらは月次輸入レポートに不可欠なワークフローであり、すべて同じ抽出データセットから始まります。

仕入先請求書の照合。 抽出した税関申告書データの最も直接的な使い方は、仕入先の商業送り状（Handelsrechnung）との相互参照です。送り状にはFOB価格が記載され、税関申告書にはCIFの関税評価額（Zollwert）が記載されています。この関税評価額には、EU国境までの運賃と保険料が含まれます。両者の差額は、申告された関税評価額が実際の取引と一致しているかどうかを判断する材料となります。税関申告書データをスプレッドシートにまとめ、送り状データと並べて比較すれば、この確認は横並びの列比較で完了します。スプレッドシートがなければ、30のPDFと30の仕入先請求書を1組ずつ手作業で照合することになり、月末にフォワーダーの請求書と輸入VAT明細書が同時に届くタイミングで行うことになります。

関税番号別の月次輸入サマリー。 抽出したスプレッドシートと推論されたHS章の列があれば、月次輸入サマリー（関税章別の総関税評価額、原産国別の総正味質量、通関手続コード別の申告件数）はピボットテーブルで生成できます。エクスポートしたExcelを開き、列を選択してピボットを作成すればレポートは完了です。これにより、各税関申告書PDFを開いて関税番号と貨物価格を確認し、別の報告用スプレッドシートに手入力するという手作業が不要になります。この作業は30件の申告でさらに1時間を要し、月次の財務会議の直前にいつも最後まで残っているタスクです。

EORI番号と通関手続コードの監査証跡。すべての税関申告書（ツォルアンメルドゥング）には、輸入者のEORI番号（Economic Operators' Registration and Identification number — EU関税参加者の一意識別子、形式はDE＋15桁）が記載されています。これは、2009年7月1日以降、規則(EG) No. 312/2009に基づき、従来のドイツの税関番号（Zollnummer）に代わる主要な参加者識別子として使用されています。各申告書のEORI番号（輸入者、申告者、代理人）をスプレッドシートにまとめることで、通関業者（Zollvertreter）が集約形式では提供できない監査証跡を作成できます。EORI番号でフィルタリングすれば、どの事業体がどの貨物を申告したかを確認でき、通関手続コード（Zollverfahrenscode）でフィルタリングすれば、通常通関（通関手続コードが「40」で始まるもの）と内国加工（コードが「51」で始まるもの）のどちらで輸入されたかを確認できます。このデータは常に申告書の中に存在していました。それがスプレッドシートに整理されることで、監査可能になるのです。

ドイツの公式書類から構造化フィールドを抽出するこのアプローチは、貿易コンプライアンス業務における他の文書タイプにも適用できます。列を一度定義し、PDFのバッチを処理するというパターンは、文書が税関申告書（Zollanmeldung）であれ、ELSTER税務申告書であれ、商業送り状の相互参照であれ、まったく同じです。フィールドは変わりますが、抽出メカニズムは変わりません。

単一申告書を超えて：税関データハブの構築

単一バッチの抽出は、月次報告の問題を解決します。構造的な改善は、同じ列定義（7つの税関フィールドと推論されたHSコード章）を毎月再利用するときに実現します。1月に定義した列名は、2月の申告書、3月の申告書でも再設定なしで機能します。毎月のバッチは、同じ列を持つスプレッドシートを生成します。月次ファイルを連結すれば、年度累計の税関データハブの完成です。ATLAS（自動関税・地方通関システム）を通じて提出されたすべての輸入申告書、すべての関税番号（Zolltarifnummer）、すべての申告された関税評価額、すべての原産国が、1つのソート可能でフィルタリング可能なExcelファイルに集約されます。

これは税関管理プラットフォームの代替品ではありません。ATLASへの申告書提出は、引き続き通関業者（Zollvertreter）の仕事です。これが代替するのは、業者のPDF出力と輸入者の内部システムとの間にある手動のデータブリッジ、つまり輸入管理者や物流コーディネーターがPDFを開き、関税番号を読み取り、スプレッドシートに入力するというステップです。そのステップは、フォーマット変換であり、貿易の専門知識ではありません。これをワークフローから排除することで、これまで2.5時間かけてExcelにフィールドを入力していた担当者は、抽出結果の確認に10分、そして会社のサプライチェーンに関する知識を実際に必要とする照合分析に2時間を費やすことができるようになります。

これは、ドイツのELSTER税務申告書からExcelにデータを抽出するのと同じ原理です。税務申告書はPDFとして表示された構造化データであり、それをスプレッドシートに抽出することはフォーマット変換であって、会計処理ではありません。この点において、税関申告書は税務申告書と何ら変わりません。どちらも、すべてのフィールドに定義された意味がある公式書類であり、フィールドとスプレッドシートの間にある唯一の障壁は、それを入力するというステップなのです。

よくある質問 — ドイツ税関申告書データ抽出