ドイツの輸入データ入力問題
ATLASが埋めるはずだったギャップを、なぜ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件の申告、各4〜5分で、およそ3時間のスタッフ時間に相当します。ハンブルクやブレーマーハーフェンといったドイツの物流拠点での中堅輸入コーディネーターの給与を考えると、直接人件費は月あたり約€75〜100です。12か月に換算すると、フォーマット変換にかかる人件費は年間およそ€900〜1,200になります。これが、ほとんどの輸入業者が認識する数字です（認識している場合の話ですが）。そして、これは実際のコストの中で最も小さい部分でもあります。

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

照合遅延のコスト。Zollanmeldung（税関申告書）のデータをスプレッドシートに抽出する目的は、スプレッドシート自体ではありません。サプライヤーのHandelsrechnung（商業送り状）との照合が目的です。サプライヤーの商業送り状にはFOB深圳価格 — €12,000と記載されています。Zollanmeldung（税関申告書）はZollwert（課税価格）€13,200 — 運賃と保険料を加えたCIFハンブルク価格を申告します。€1,200の差額は正しいものです。しかし、輸入コーディネーターが月末までZollwert（課税価格）の抽出を先延ばしにしている場合 — データ入力のバックログが3週間分たまっているため — その€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つのエクスポートの間のギャップは、手動によるフィールド選択、フォーマット設定、補足データ入力のもう1ラウンドです。

ドイツの税関環境に特有のさらなる複雑さとして、間接代理人（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データ再入力問題