ドイツ税関申告でよくある5つの
データミス — 遅延と監査を招く原因

以下は、Zollanmeldungに特有の5つのデータエラーです。これらのエラーは、ドイツの税関申告書に、間違った値が入力されたスプレッドシートのセルをはるかに超える法的・金銭的な影響を及ぼすフィールドが存在するために発生します。各エラーは実際の現場で見られる形で説明され、手動データ入力のワークフローにおける根本原因が特定され、そして、提出後の修正ではなく、データ取得時点でエラーを防止する修正方法とともに提示されます。

エラー1：誤ったHSコード分類 — 1桁の違いが関税率を変える

実際の様子。ベトナムからドイツに綿のズボンを輸入する業者が、商品をZolltarifnummer 6204.62.31.00.9に分類したとします。正しいコードは6204.62.39.00.9 — 9桁目のTARIC細分類において、デニム製ズボン（31）とその他の綿織物製ズボン（39）を区別する1桁の違いです。この業者は6ヶ月間に120件の申告を誤ったコードで行いました。両方のコードの関税率は12%であるため、支払われた関税は正しいものです。しかし、正しくないのは、商品がドイツの外国貿易統計において誤った統計項目で追跡されていること、業者が保有する拘束関税情報（verbindliche Zolltarifauskunft、BTI）が異なるコードに適用されること、そして、EUがデニムズボンに特にセーフガード措置やアンチダンピング関税を課した場合（EUが繊維製品のセーフガード監視を積極的に行っていることを考えると現実的な可能性です）、実際の商品がデニムではないにもかかわらず、業者がデニムのコードで申告したために、業者の申告がその措置の対象に含まれてしまうことです。

実際に起こったこと。ドイツのZolltarifnummerは、4つの階層から構築される11桁の分類です。最初の6桁は世界税関機構（WCO）が管理する国際的なHSコード、7～8桁目はEUの統合関税分類（KN）、9～10桁目はEUのTARIC（統合関税率）で貿易防衛措置や関税停止をコード化し、11桁目は付加価値税率や国内規制に関するドイツの国内コードです。ドイツへの輸入の場合、ATLASの下では完全な11桁のコードが必須です。輸出の場合は、8桁のKNコードで十分です。この違いが重要なのは、9～10桁目のTARICレベルのエラーが、基礎となる関税率が同一に見えても、全く異なる貿易措置（アンチダンピング関税、相殺関税、割当制限、関税停止）を引き起こす可能性があるからです。

ドイツ連邦財務省（Bundesfinanzministerium）は、ハンブルク港とフランクフルト港における税関手続きの遅延の約68%がHSコードの誤分類に起因すると報告しています。関税コードの1桁の誤りは、誤った関税率のリスクだけでなく、ATLASによる却下サイクルを引き起こす可能性があります。ATLASは、関税コードをEZTオンラインデータベースとリアルタイムで検証します。コードが有効なエントリと一致しない場合、または他の申告データ要素と矛盾する場合、ATLASは申告を却下します。貨物は未通関のままとなります。ターミナル保管料（Lagergeld）が発生し始めます — ハンブルクのコンテナターミナルでは、無料保管期間後、TEUあたり1日約10～15ユーロです。輸入業者の配送スケジュールは遅れます。売り手の支払条件が違反される可能性があります。ATLASによる却下後まで発見されなかった場合、1件の申告における1桁の関税コードの誤りは、修正サイクルだけでなく、関税コード自体からは全く予見できない一連の業務遅延を引き起こすことになります。

このエラーには監査証跡上の結果も伴います。UCC第33条に基づき、税関当局は申告受理後最大3年間にわたり事後監査（Zollprüfung）を実施することができます。監査の結果、輸入業者が一貫して誤った関税番号を使用していたことが判明した場合、たまたま納付した関税額が正しかったとしても、「問題なし」とはなりません。これは分類ガバナンスの失敗です。税関当局は、影響を受けるすべての申告の再分類、3年間の遡及期間全体にわたる関税の再計算、そして、正しい分類でより高い関税率が適用される場合には、ドイツ租税通則法（Abgabenordnung）に基づく遡及的な関税の支払いと延滞金（Säumniszuschlag）を要求する可能性があります。

エラー2：Zollwertの計算ミス — 誤ったインコタームが税関評価額の過少申告を招くケース

どのようなケースか。ドイツの輸入業者が台湾のサプライヤーから機械を購入します。商業送り状（Handelsrechnung）には85,000ユーロ — FOB高雄価格 — と記載されています。輸入業者はこの85,000ユーロをATLAS申告のZollwertとして入力します。正しい税関評価額は92,400ユーロ — CIFハンブルク価格、すなわちFOB価格に海上運賃（5,200ユーロ）と海上保険料（2,200ユーロ）を加えた金額です。申告は税関評価額を7,400ユーロ過少に計上しています。影響を受ける各申告における関税の過少納付額は、関税率に7,400ユーロを乗じた金額 — 機械の場合、2.7%のMFN税率で、1申告あたり約200ユーロです。年間30件の機械貨物の場合、年間過少納付額は6,000ユーロになります。税関当局は定期的な事後監査中にこれを発見します — 1貨物あたり200ユーロでは警報が発動されないためですが、運送業者の送り状と保険証明書の両方に運賃と保険料の金額が記載されており、税関監査人は標準的な監査ファイルの一部としてこれらを要求するためです。

実際に何が起きているのか。EUへの輸入における税関評価額（Zollwert）は、UCC第70条から第74条に基づき決定されます。主要な方法は取引価格、すなわち商品に対して実際に支払われた、または支払われるべき価格に、特定の要素を調整したものです。ドイツの輸入業者にとって重要な調整点は、税関評価額がEU域境におけるCIF（運賃・保険料込み）ベースで評価されなければならないことです。サプライヤーの送り状にFOB価格 — 輸出港で船舶に積み込まれた時点の商品価値 — が記載されている場合、輸入業者はEU域境までの運賃と輸送中の保険料を追加しなければなりません。送り状にEXW（工場渡し）価格が記載されている場合、輸入業者は工場出荷時点からEU域境までのすべての運送費、保険料、および取扱費用を追加しなければなりません。

これは特殊なルールではありません。ドイツの輸入実務において最も一般的な関税評価額の誤りです。なぜなら、サプライヤーのインボイスと関税評価額は、設計上異なる数値だからです。インボイスは買い手が売り手に支払った金額を示し、関税評価額は商品をEU域境に持ち込むための費用を示します。ドイツ法では、関税の過少納付を招く誤った関税評価額の申告は、租税通則法（Abgabenordnung）第370条に基づく税金の過少申告として扱われます。この誤りが過失とみなされた場合（これは、定期的に輸入を行う企業が文書化された関税評価手順を欠いている場合の標準的な判断です）、輸入者は事後的な関税と利息だけでなく、過少納付した関税額と同額までの罰金に直面します。税関申告を税関ブローカーが行った場合でも、誤った関税評価額の申告に対する責任は輸入者に残ります。UCC第77条(3)に基づき、輸入者が関税債務者であり、申告された価額の正確性について最終的な責任を負います。

エラー3: 原産国（Ursprungsland）の誤り — 原産地欄に誤った国が記載され、特恵関税が失効するケース

状況。 ドイツの輸入業者がベトナムのメーカーから家具を調達しています。ベトナムとEUは自由貿易協定（EVFTA、2020年8月発効）を締結しており、ほとんどの家具カテゴリーの関税を撤廃しています。特恵税率を適用するには、申告書に原産国（Ursprungsland）としてベトナムを記載し、有効なEUR.1移動証明書またはインボイス上の原産地申告書を添付する必要があります。輸入業者の購買管理担当者が、月次輸入レポート用の内部スプレッドシートに申告データを入力する際、商業インボイスの上部に「出荷地：ホーチミン市港」と表示され、商品説明に「製造国：ベトナム」と記載されているのを確認します。担当者は原産国（Ursprungsland）欄に「VN」と入力します。しかし、担当者が気づかないのは（商業インボイスのどこにも記載されていないため）、家具のフレームはベトナムで製造されていますが、製品の工場出荷価格の45%を占める張り地の生地が中国から輸入されており、EVFTAの家具に関する特定の原産地規則を満たしていないことです。この商品は原産地規則のテストに合格しないため、特恵税率の対象とはなりません。特恵を主張する申告は誤りです。税関当局が原産地を検証した場合（原産地検証はFTA事後監査の標準的な一部です）、特恵関税率は取り消され、MFN（最恵国）関税が事後的に支払われることになり、輸入者は過去数年にわたる申告分の関税回復に直面する可能性があります。

実際に何が起きたのか。ドイツのZollanmeldungにおける原産国（Ursprungsland）は、貨物が発送された国（Versendungsland）ではありません。これは、貨物が完全に取得された国、または複数の国で生産された貨物の場合は、最後に実質的かつ経済的に正当化された加工または処理が行われた国、すなわちUCC第60条に基づく非特恵原産地規則を指します。EUの自由貿易協定に基づく減税または無税の適用可否を決定する特恵原産地については、さらに厳格なルールが適用されます。各FTAは、原産地を付与するための十分な加工を定義する製品固有の規則を定めています。輸出者は、貨物がこれらの規則を満たしていることを示す原産地証明書（EUR.1または原産地申告書）を発行します。輸入者の義務は、原産地を検証すること（これは輸出者の証明事項です）ではなく、Zollanmeldungに申告された原産地が証明書に記載された原産地と一致していること、およびその証明書が存在し、当該貨物に対して有効であることを確認することです。

このエラーは、Zollanmeldungのデータを手動で転記する担当者が、ベトナムのサプライヤーからの貨物を見て、サプライヤーが有効な原産地証明書を提供しているか確認せずに原産国として「VN」と入力した場合、あるいはさらに悪いケースとして、貨物が実際には別の国で製造されベトナムから単に発送されただけであるにもかかわらず、サプライヤーの設立国（ベトナム）が原産国として入力された場合に発生します。UCC第61条に基づき、税関当局は輸入者に原産地の証明を求めることができます。特恵申告を行った貨物について輸入者が証明書を提出できない場合、特恵は否認され、MFN税率が適用され、輸入者のコンプライアンス記録には原産地申告の誤りが蓄積され、将来の原産地申告が厳格な審査の対象となります。複数のFTAパートナー国から調達する輸入者にとって、このエラーは、本来であれば特恵が有効な場合にそれを請求する体系的な関税削減プロセスを、コンプライアンスリスクに変えてしまいます。その結果、輸入者は監査を恐れて特恵の請求自体をためらい、正当な関税削減の機会を逃すことになります。

エラー4：EORI番号の不一致 — 誤った経済事業者が輸入者として申告された場合

どのような状況か。米国親会社のドイツ子会社が、日本のサプライヤーから電子部品を輸入するケースを想定する。子会社はDE EORI番号（形式：DE + 15桁）を保有している。米国親会社も、EU VAT目的で税務代理人を通じて取得したDE EORI番号を保有している。月次の社内輸入レポートを作成するAP担当者は、商業送り状に買い手として親会社名が記載されているのを確認し、EORIフィールドに親会社のDE EORI番号を入力する。Zollanmeldungは、親会社のEORIを輸入者として提出される。税関当局が申告を処理する。輸入VAT（Einfuhrumsatzsteuer）の査定は、親会社のEORIにリンクされた税務口座に対して発行される。実際に貨物を受け取り、顧客に販売し、輸入VATを仕入税額控除する必要があるドイツ子会社には、その輸入の記録が税関口座に残らない。税関査定が異なる法人を名指ししているため、子会社のUmsatzsteuervoranmeldung（UVA）で輸入VATをVorsteuerabzug（仕入税額控除）として請求することはできない。税理士は四半期ごとのVAT調整中にこの不一致を発見する。修正には税関申告の訂正（formeller Antrag auf Berichtigung）が必要となり、処理に数週間を要する可能性があり、税関と税務署（Finanzamt）の両方の関与が必要となる場合もある。

実際に何が起きているのか。EORI番号（Economic Operators' Registration and Identification Number）は、EU関税手続きに関与するすべての経済事業者に義務付けられた識別子であり、規則(EC) No 312/2009に基づき、2009年7月1日から有効となっている。これは旧ドイツ税関番号（Zollnummer）に代わるものである。DE EORI番号は連邦税関総局（Generalzolldirektion、GZD）によって割り当てられ、すべての申告においてATLASを通じて検証される。EU域内取引およびVAT目的で事業者を識別するVAT番号（Umsatzsteuer-Identifikationsnummer、DE + 9桁）とは異なり、EORI番号は特に関税業務のために事業者を識別する。この2つの番号は異なる機能を果たし、異なる管理システム（一方は関税と輸入VAT、他方は国内VAT義務）にリンクしている。

不一致エラーは、主に3つのシナリオで発生する。(1) 複数法人からなる企業グループにおいて、商業送り状上の購入エンティティと、実際に貨物を受け取り輸入VATを請求する輸入エンティティが異なる場合 — 担当者が支払い者のEORIを入力し、輸入者のEORIを入力しない。(2) 間接代理人（indirekter Vertreter）として申告するフォワーダーが、自己のEORIを申告者として使用するものの、荷受人フィールドに輸入者のEORIを正しく特定しない場合 — UCC第18条に基づき、間接代理人は誰の税関申告を行っているかを明示しなければならず、荷受人のEORIが誤っていると、その貨物について輸入者が税関記録から除外される。(3) 企業が複数のEU加盟国で複数のEORI番号を保有している場合（ドイツ子会社がDE EORI、オランダ子会社がNL EORI） — 担当者が申告ソフトウェアのドロップダウンから誤ったEORIを選択する。これは、貨物がロッテルダム経由でルーティングされているものの、輸入者はドイツのエンティティである場合に発生する。

EORIの不一致がもたらす財務的影響は、訂正手数料だけではありません。それは、輸入付加価値税（VAT）の控除がブロックされることです。ドイツの輸入業者が、税関評価が誤ったEORIに対して発行されたために、輸入VATを仕入税額控除として控除できない場合、国境で支払われたVATは通過項目ではなくコストとなり、標準税率19％で課税価格10万ユーロの場合、申告が訂正されるまで、1万9000ユーロが誤った税務口座に留まることになります。UCC第173条は、誤ったデータが誠実に提供された場合の事後修正を規定していますが、修正は自動的ではなく、税関当局への正式な申請、裏付け書類、および処理時間が必要であり、その間、ブロックされたVATは回収されないままとなります。

エラー5：Zollverfahrenscodeの誤り — 手続きコードの誤りが即時の関税支払いを引き起こすケース

どのような状況か。スイスからドイツに産業用部品を輸入するケースを想定します。この貨物はハンブルクの保税倉庫（Zolllager）に保管され、在庫として保持された後、顧客の注文に応じてバッチごとに引き出される予定でした。保税倉庫に該当する税関手続きコードはZollverfahrenscode 7100です。月次の輸入サマリーを入力する経理担当者は、出荷明細を確認し、デフォルトの手続きコードである4000（自由流通用リリース）を選択しました。これは、この輸入業者の他の出荷で使用されているコードであり、担当者は今回の出荷が保税倉庫への搬入として手配されていることを認識していませんでした。申告は手続きコード4000で提出され、ATLASは通常通り処理しました。関税は全税関価格に基づいて計算され、輸入業者の延払い口座（Aufschubkonto）に即座に請求されました。輸入業者は、倉庫から貨物が引き出されるたびに関税を段階的に支払うことを想定していました。しかし、実際には全貨物分の関税（約14,000ユーロ）が一度の支払いサイクルで引き落とされ、計画外の運転資金の流出が発生しました。このことは、Aufschubkontoの明細が届いた際に財務チームによって発見されました。

実際に何が起きたのか。ドイツの税関申告におけるZollverfahrenscodeは4桁のコードで、貨物がどの税関手続きに該当するかを指定します。このコードは2つの部分で構成されています。申請された手続き（das beantragte Verfahren）を示す2桁のコードと、先行する手続き（das vorhergehende Verfahren）を示す2桁のコードです。ドイツの輸入業者にとって最も一般的なコードは以下の通りです。

手続コードの誤りは、ATLASの検証をすり抜けるため、特に危険です。ATLASは、コードが有効であり、かつそのコードが商品の種類や申告者の許可内容に対して利用可能であることを検証します。しかし、輸入者が異なる手続を意図していたかどうかは検証できません。輸入者が自由流通（4000）と蔵入れ（7100）の両方を許可されている場合、ATLASはどちらのコードも受け入れます。システムは形式の正しさを検証しますが、意図の正しさは検証しません。この誤りが表面化するのは、関税が引き落とされたとき、あるいはその逆で、輸入者が即時に関税を支払うことを期待していたにもかかわらず商品が蔵入手続で輸入され、関税が発生するはずの貨物について輸入者の延払口座明細に関税請求が表示されず、輸入者が認識していない関税債務が発生したときです。

誤った手続コードを修正することは、修正申告書を提出するほど簡単ではありません。誤った手続で貨物がすでに放関されている場合（誤りは通関時には見えないため、放関されているのが通常です）、手続を変更するには、誤りが誠実に行われたこと、および貨物が意図された手続に従って取り扱われたことを証明する必要があります。保税蔵置所の場合、これは貨物が物理的に倉庫に入庫され、倉庫入庫番号のもとで倉庫在庫システムに記録されたことを示すことを意味します。倉庫記録が貨物の入庫と保管を示しているにもかかわらず、税関申告が自由流通を示している場合、輸入者は2つの矛盾する法的立場に直面します。貨物は倉庫にありますが（蔵入手続が必要）、申告書は貨物が自由流通に入ったと述べています（つまり、貨物は倉庫を出て顧客に配送されるべきだった）。これらの立場を調整するには、税関への正式な申請、倉庫業者からの裏付け書類、および複数の支払サイクルに及ぶ処理時間が必要です。

共通の糸口：すべてのエラーはPDFとキーボードの間で始まる

5つの個別のエラーから一歩引いて見ると、あるパターンが浮かび上がります。そのどれもが税関申告業者のATLAS申請に起因するものではありません。また、関税率表が複雑すぎる、原産地規則が不明瞭すぎる、手続コードが多すぎるといった理由で発生するものでもありません。すべてのエラーは手動での転記作業、つまり書類から値を読み取り、システムに入力する瞬間に発生します。11桁のZolltarifnummer、CIF調整後のZollwert、確認済みのUrsprungsland、正しいEORI、意図したZollverfahrenscode — これらの値はすべて、申告が行われる前に輸入者の書類経路のどこかに存在しています。エラーは値が不明であることではありません。エラーは値が既知であるにもかかわらず再入力が必要であり、その再入力の工程が、書類に記載されている内容とシステムが記録する内容との間にギャップを生み出すことです。

これは、消費税の不一致を引き起こす5つの日本の請求書データ入力エラーの根底にあるのと同じ構造的パターンです。異なる書類、異なる税制ですが、同じメカニズムです。すなわち、あるフィールドが金銭的な影響を伴い、そのフィールドが手動で転記され、その転記ミスは後続のシステムが拒否するまで見えず、修正にはエラーを防止するためのコストよりも桁違いに高いコストがかかる、というものです。ドイツの税関申告書と日本の請求書は異なる書類ですが、異なる税法をまとった同じデータ問題です。

構造的な解決策は5つのエラーすべてで同じです。データ取得をキーボードよりも上流に移行することです。Zolltarifnummer、Zollwert、Ursprungsland、EORI-Nummer、Zollverfahrenscodeといったフィールドを一度定義し、誰かが申告書や社内報告書に入力する前に、抽出機能がそれらを元の書類から構造化されたテーブルに取り込むようにします。かつて入力を行っていた担当者は、それを検証する担当者になります。つまり、抽出されたZolltarifnummerがファイル上のBTIと一致するか、計算されたCIF価格に運賃と保険料が含まれているか、原産地フィールドに対応する証明書があるかを確認します。検証はエラーを発見します。転記はエラーを生み出します。解決策は、より良いトレーニングや、より注意深いデータ入力、あるいはダブルキー検証ではありません。それは、ワークフローから転記の工程を取り除くことです。

FAQ — ドイツ税関申告データのエラー