ドイツ税関申告書データを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通の税関申告書（ツォルアンメルドゥング）PDFを受け取ります。各申告書には、最低でも11桁の関税番号（6桁の国際HSコードを、EUの複合命名法（KN）で8桁、TARICで10桁、国内レベルで11桁に拡張したドイツ固有の番号）、ユーロ建ての関税評価額、原産国、EORI番号が含まれています。ATLASのポジションレベル画面（Positionsdaten）での完全な輸入申告には、自重（Eigenmasse、kg単位）、荷物数（Anzahl der Packstücke）、品目価格（Artikelpreis）、通関手続コード（Zollverfahrenscode、貨物がどの手続きで申告され、どの手続きから来たかを示す4桁のフィールド）が追加されます。

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

照合ギャップは時間だけの問題ではありません。3つの構造的な問題が量とともに悪化します：

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

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

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

Zollanmeldungの項目を1つのExcelスプレッドシートに抽出する方法

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

抽出した税関申告書（ツォルアンメルドゥング）データでできること

スプレッドシートは目的地ではありません。次の3つのワークフローを可能にする層です。これらは毎月の輸入レポートが依存するワークフローであり、すべて同じ抽出データセットから始まります。

仕入先請求書の照合。抽出した税関申告書（ツォルアンメルドゥング）データの最も直接的な用途は、仕入先の商業送り状（Handelsrechnung）との照合です。送り状にはFOB価格が記載され、税関申告書にはEU国境までの運送料と保険料を含むCIF関税評価額（Zollwert）が記載されています。この2つの値の差により、申告された関税評価額が基礎となる取引と整合しているかが判断できます。税関申告書データが請求書データの隣のスプレッドシートにあれば、このチェックは並べての列比較で済みます。スプレッドシートがなければ、30件のPDFと30件の仕入先請求書を、1件ずつ手作業で照合することになり、通常は月末にフォワーダーの請求書と輸入付加価値税明細書が同時に届く時期に行うことになります。

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

EORIおよび通関手続コードの監査証跡。すべての税関申告書には、輸入者のEORI番号（EU税関参加者の一意の識別子で、DEに続く15桁の形式）が記載されており、2009年7月1日付で規則（EG）第312/2009号に基づき、旧ドイツ税関番号に代わり主要な参加者識別子となっています。すべての申告のEORI（輸入者、申告者、代理人）を含むスプレッドシートは、通関業者（Zollvertreter）が集計形式で提供できない監査証跡を作成します。EORIでフィルタリングしてどの事業体がどの貨物を申告したかを確認し、通関手続コード（4桁）でフィルタリングして標準申告（「40」で始まる通関手続コード）で輸入されたものと、委託加工（「51」で始まるコード）で輸入されたものを確認できます。このデータは常に申告書に存在していました。スプレッドシートに載せることで監査可能になるのです。

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

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

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

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

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

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