ドイツの輸入データ入力問題
ATLASが埋めるはずだったギャップを、なぜ自ら生み出してしまうのか

見える3分間 — そして見えない3時間

ドイツの輸入取引に関わるすべての人が、通関業者の手数料を目にすることができます。Zollvertreter（通関業者、運送業と組み合わせた場合はZollspediteur（通関貨物取扱業者）とも呼ばれる）は、ITZBundが運用する自動通関ITプラットフォームATLASを通じて、電子的なZollanmeldung（税関申告書）を提出します。ATLASは、UZK（EU関税法、規則EU No 952/2013）に基づき、EZT-onlineデータベースと照合して関税分類を検証し、EU登録簿と照合してEORI番号を確認し、関税とEinfuhrumsatzsteuer（輸入付加価値税、標準19％／軽減7％）を計算し、承認されればSteuerbescheid（納税通知書）と18桁のMRN（マスターレファレンス番号）を発行します。通関業者の請求書が届きます。通関手続きの項目、ATLAS申告の項目。輸入業者はそれを支払います。取引は完了したように見えます。

通関業者の請求書に含まれていないもの、そして物流の請求書のどの項目にも記載されていないもの、それはATLAS受理後のプロセスです。輸入業者はZollanmeldung（税関申告書）のPDFを受け取ります。そのPDFの中には、輸入業者が自社の業務に必要とする項目が含まれています。関税見出し別の月次輸入量報告のための11桁のZolltarifnummer（関税番号）、仕入先請求書の照合（申告されたCIF関税評価額と仕入先のFOB商業送り状の比較）のためのユーロ建てのZollwert（課税価格）、四半期ごとの原産地証明書監査のためのUrsprungsland（原産国）、自由流通関税と保税倉庫における関税停止を区別する運転資金キャッシュフロー予測のためのZollverfahrenscode（通関手続コード）。これらの項目はすべて、構造化データとしてATLASに入力されました。そして、それらはすべて、フラットなPDFとして輸入業者に返されます。それらをPDFからスプレッドシートに再抽出する作業は、税関コンプライアンス活動ではありません。それは形式の変換であり、誰の職務記述書にも、どの予算にも、どの請求書にも記載されていません。

ATLASは紙の税関申告書を廃止するために設計されました。それは成功しました。しかし、ATLASが設計されていなかったこと、そして輸入業者が月末に気づくことは、自社の内部システムが読み取れる形式でデータを輸入業者に返すことです。紙の申告書はPDFの申告書に置き換えられました。再入力の手順はなくなりませんでした。それは通関業者の机から輸入業者の画面に移ったのです。

データギャップの構造：構造化された入力が非構造化された出力になる仕組み

なぜギャップが存在するのかを理解するには、データの全行程を追跡する必要があります。これはテクノロジーが失敗する話ではありません。ATLASと輸入業者のERPという、接続するように設計されたことのない2つのシステムの間で、人間がキーボードを使って橋渡しをしているという話です。

このギャップは、BAS申告がオーストラリアの中小企業にフォーム上の数字以上のコストをもたらす理由の分析で説明されているものと構造的に同じです。フォームは構造化された数値を受け付けますが、それらの数値を含む書類はPDFで届き、書類からフォームにデータを抽出する手作業が、誰も予算化していないボトルネックとなっています。税関申告と確定申告は、異なる政府フォームをまとった同じ問題です。データを組み立てる工程が申告工程を圧倒しており、「簡単にする」ことを目的としたツールのほとんどは申告側に対応する一方で、組み立て側は手作業のまま残されています。

再入力ギャップの実際のコスト — 3時間を超えて

手作業によるデータ再入力の目に見えるコストは簡単に計算できます。月40件の申告で、1件あたり4～5分、合計で約3時間のスタッフ時間です。ハンブルクやブレーマーハーフェンなどのドイツの物流ハブにおける輸入コーディネーターの中間レベルの給与で換算すると、直接人件費は月額約75～100ユーロになります。12ヶ月で約900～1,200ユーロのフォーマット変換にかかる人件費です。これは、ほとんどの輸入業者が認識する数字であり、そもそも数字を認識している場合の話です。しかし、これは実際のコストの中で最も小さい部分です。

転記ミスによるコスト。 11桁のZolltarifnummer（関税番号） — 例えば、女性用綿パンツの6204.62.31.00.9 — は11回のキーストロークです。データ入力の転記ミス率が約500キーストロークに1回とすると、400フィールドの転記（40件の申告×10フィールド、そのうち約半数が数値コード）のうち、月に1フィールドが誤入力されることになります。Zolltarifnummerの1桁の誤り — 「2」であるべきところが「3」になる — だけで、商品が全く異なる関税区分に分類され、異なる関税率が適用される可能性があります。ATLASが通関時に正しいコードを検証していた場合、その誤りは輸入業者の内部スプレッドシートにのみ存在します。しかし、これが危険な理由は2つあります。月次の輸入量レポート、四半期の関税予測、そしてキャッシュフロー予測に影響を与えること、そしてZollprüfung（税関監査）の際に通関業者のデータと照合された場合、輸入業者の記録と税関申告データの不一致が、たとえ単なる事務的な誤りであっても、輸入業者の内部統制に関する疑問を引き起こす可能性があることです。

調整の遅延によるコスト。 Zollanmeldung（税関申告書）のデータをスプレッドシートに抽出する目的は、スプレッドシート自体ではありません。目的は、仕入先のHandelsrechnung（商業送り状）との照合です。仕入先の商業送り状にはFOB深圳価格12,000ユーロと記載されています。Zollanmeldungでは、運賃と保険料を加えたCIFハンブルク価格13,200ユーロのZollwert（課税価格）が申告されています。差額の1,200ユーロは正しいものです。しかし、輸入コーディネーターがデータ入力のバックログが3週間分蓄積しているため、月末にしかZollwertを抽出しない場合、その1,200ユーロの差額が正当であることを確認する調整は、貨物が通関してから3週間後に行われます。もしZollwertが誤って入力されていた場合 — 例えば運賃が二重計上され、13,200ユーロではなく13,800ユーロで申告されていた場合 — その不一致は3週間もの間発見されず、その間に税関から利息付きのNacherhebungsbescheid（追徴課税通知）が発行される可能性があります。

決して発生しないクロス申告分析コスト。 Zollanmeldung（税関申告書）のデータが40の別々のPDFに分散している場合、誰もそのデータに対して分析的な質問をしません。「前四半期の繊維輸入における、1キログラムあたりの平均申告課税価格はいくらか？」という質問には、120のPDF（3ヶ月×40申告）からZollwert（課税価格）とEigenmasse（自重）を抽出し、割り算する必要があります。抽出自体に分析に使うはずの時間が消費されてしまうため、誰もそんなことはしません。ここでのコストは明細項目として現れるものではなく、失われた知見です。輸入業者は毎月関税を支払い、Aufschubkonto（延納口座）の明細から支払総額を把握しています。しかし、データがPDFに散在しているため、どの関税見出し、どの原産国、どの通関手続きがその総額を押し上げているのかを輸入業者は知ることができません。これは、50件のバッチ処理されたZollanmeldungから関税サマリーを構築する分析で詳述されている、バッチ処理が解き放つものと同じ洞察です。ただし、それはデータがまずスプレッドシートに届いて初めて実現します。

ATLAS申告ソフトウェアがギャップを埋めない理由

ここで当然の疑問が生じます。輸入業者がDAKOSY、AEB Import Filing、MIC-CUST、DeclariumのようなATLAS対応申告ソフトウェアを使用している場合、そのソフトウェアは申告データを既に捕捉しているのではないか？ 答えは「はい」です。ただし、その特定のソフトウェアを介して提出された申告に限ります。その限界は能力ではなく、範囲にあります。

アジアからの海上貨物輸入にDAKOSYを使用しているドイツの輸入業者は、航空貨物の申告をATLAS Internet-Zollanmeldung（IZA）経由で直接行い、特定の貨物は自社のLISやMIC-CUSTを使用する貨物運送業者を通じて行う場合があります。各申告チャネルは、それぞれ独自の申告記録を生成します。DAKOSYのレポートは海上貨物の申告をカバーします。IZAの申告はPDFを生成します。運送業者の申告は、運送業者のシステムからPDFとして届きます。月末に統合された全申告のビューを必要とする輸入業者は、3つのデータソース（うち2つはPDF、1つはソフトウェアレポート）を持っていますが、これらは統合されるように設計されたことは一度もありません。

単一のATLASソフトウェアプロバイダーがすべての申告を捕捉したとしても、捕捉されるデータはATLASのコンプライアンス項目に最適化されており、輸入業者の内部報告ニーズには最適化されていません。ソフトウェアはZolltarifnummer（関税番号、11桁）を11桁の文字列として、Zollwert（課税価格）をユーロ額として、Zollverfahrenscode（通関手続コード、4桁）を4桁の数字として保存します。これはまさにATLASが要求する項目です。しかし、ソフトウェアが通常生成しないのは、輸入業者の報告構造に一致する統合エクスポートです。つまり、申告ごとに1行で、輸入業者の財務チームが必要とする項目と、「HS章（11桁の関税コードから派生）」や「関税エクスポージャー（Zollwert×MFN税率）と、有効な原産地証明書がファイルにある場合の特恵税率との比較」のような推論項目を並べたものです。ソフトウェアはATLASが必要とするものをエクスポートします。輸入業者が必要とするのは、輸入レポートが必要とするものです。この2つのエクスポートの間のギャップは、手動による項目選択、フォーマット調整、および補足データ入力のもう一つのラウンドです。

ドイツの税関環境に特有のさらなる複雑さとして、間接代理人（indirekter Vertreter）の役割があります。運送業者が間接代理人としてZollanmeldung（税関申告書）を提出する場合、輸入者に代わって自己の名義で行動し、UZK第84条に基づき関税債務について連帯責任を負います。運送業者のATLAS申告データは運送業者のシステムに属します。輸入者がそのデータにアクセスできるかどうか（構造化されたエクスポートとしてであれ、PDFとしてであれ）は、運送業者が利用可能な形式で提供する意思と技術的能力に依存します。多くの運送業者は、標準的な納品物として申告書のPDFスキャンを送付します。ATLASに入力された構造化データは、運送業者のATLASソフトウェア内に留まります。輸入者が受け取るのは、申告書が紙で提出された場合と同じフラットなPDFです。手動での再入力工程は変わらないどころか、第三者のデータ形式の好みに依存するようになっています。

解決策：データ取得をキーボード入力より上流に移す

問題はATLASが壊れていることではありません。ATLASは設計されたとおりに機能しています。つまり、税関申告書を電子的に検証し、通関を迅速化しています。問題は、輸入者のデータパイプラインがPDFで終わってしまい、そのPDF内のデータに依存する下流のすべてのプロセスが、誰も責任を持たない手動の転記工程から始めなければならないことです。

構造的な解決策は、より優れたATLAS統合ではありません。転記工程そのものを排除することです。つまり、誰かがスプレッドシートを開いて再入力する前に、PDFからデータを取得し、それを輸入者のワークフローに取り込む時点で行うのです。カスタム列抽出により、これが可能になります。チームが使用する正確なドイツ税関用語（「Zolltarifnummer（関税番号、11桁）」、「Ursprungsland（原産国）」、「Zollwert（課税価格、EUR）」、「Zollverfahrenscode（通関手続コード、4桁）」、「EORI-Nummer（EORI番号）」）を使用してフィールド名を一度定義し、すべてのブローカー、運送業者、IZA提出チャネルからのすべてのZollanmeldung PDFをアップロードすれば、申告ごとに1行、列がヘッダーとして定義され、フィールドがPDFから取り込まれた1つのスプレッドシートを受け取ることができます。3時間の手動転記が、10分のアップロードと確認の工程になります。出力されたスプレッドシートは、月次輸入レポート、仕入先請求書の照合、四半期ごとの関税予測に直接供給されます。再入力というボトルネックを経由する必要はありません。

これは、ステップバイステップのドイツ税関申告データをExcelに抽出するガイドで詳述されている抽出アプローチとまったく同じものです。同じ列定義がすべての申告に適用され、毎月同じ出力構造が得られ、同じスプレッドシートがすべての下流プロセスに供給されます。手動データパイプラインと抽出ベースのパイプラインの違いは、速度の問題ではありません。それは、誰が形式変換を行うかという問題です。手動パイプラインでは、人が毎月それを行い、時間を費やし、転記ミスのリスクを負います。抽出ベースのパイプラインでは、データはPDFから構造化テーブルに直接ジャンプし、人は転記するのではなく確認を行います。

FAQ — ドイツ税関ATLASデータ再入力問題