ドイツの商業送り状（Handelsrechnung）輸出データを抽出する方法
：税関・会計向け
ドイツの輸出商業送り状（Handelsrechnung）には、国内の請求書（Rechnung）にはない約12の項目があります。輸出業者のEORI番号、品目ごとの11桁の関税番号（Zolltarifnummer）、品目ごとの原産地（Ursprungsland）、該当するインコタームズ、正味重量と総重量、そして輸出確認書（Ausfuhrbestätigung）のセクションです。これらの項目はすべて、輸出部門によって送り状テンプレートに入力されています。そして、それらはすべて、少なくとも他の2つのシステム、つまり税関用のATLAS輸出申告と会計用の社内ERPに再入力しなければなりません。以下で説明する抽出方法は、両方の再入力ステップを1つの構造化された出力に置き換えます。Handelsrechnungごとに1行、列は一度定義すればよく、すべての項目がPDFから取得されます。
重要ポイント
- ドイツのHandelsrechnungには、国内のRechnungにはない約12の税関専用項目（EORI番号、品目ごとの11桁HSコード、原産国、インコタームズ、正味重量と総重量）が含まれており、それぞれをPDFからATLASとERPに再入力する必要があります。
- 月間30件の出荷がある輸出業者は、毎月約240の税関項目をPDFからスプレッドシートに転記しています。そのすべてのキー入力が、税関の確認内容と会計帳簿の間に不一致を生む可能性があり、税務署は監査中にこの差異をクロスチェックします。
- 抽出列を一度定義し、再入力する代わりにPDFをアップロードすれば、ATLAS輸出申告とERP会計入力の両方のパイプラインが1つの構造化されたスプレッドシートからデータを取得するため、転記のギャップを根本から解消できます。
Handelsrechnungと国内のRechnungの違い
ドイツのすべての事業者は請求書を発行します。国内のRechnung（売上請求書）には、§14 UStGに基づき、供給者の氏名と住所、請求書の発行日と番号、顧客の氏名と住所、商品またはサービスの数量と説明、正味金額、付加価値税率と金額、総額（税込）を含める必要があります。これらは、売掛金システム、付加価値税予備申告（Umsatzsteuervoranmeldung）、および年度末の財務諸表に反映される項目です。これらは、DATEV、Lexware、SAPといったドイツの会計ソフトウェアが取り込むように設計されている項目です。
Handelsrechnungには、これらの項目がすべて含まれます。しかし、それに加えて、商品が税関の国境を越えるという唯一の理由で存在する追加の項目セットも含まれます。これらは、仕向国の税関当局が関税を評価し、原産地を確認し、申告価格を検証するために必要とする項目です。欧州連合関税法典（UCC、規則(EU) No 952/2013）に基づき、EUから非EU諸国に輸出される商品に添付される商業送り状には、以下を含める必要があります。
| 項目（ドイツ語） | 英語説明 | 税関で必要な理由 |
|---|---|---|
| EORI番号 | 経済事業者登録識別番号 — 形式：DE + 15桁 | EU税関システムで輸出業者を識別します。すべての税関申告にはUCC第9条に基づき必須です。これがないと、ATLASが輸出申告を拒否します。 |
| 関税番号（HSコード） | 品目ごとの11桁のドイツ関税コード — 最初の6桁＝国際HS、7～8桁＝EU統合関税分類、9～10桁＝TARIC、11桁＝ドイツ国内コード | 輸出管理区分、輸出制限の有無、そして輸入者にとっては仕向地での輸入関税率を決定します。インボイス単位ではなく、品目ごとに必要です。 |
| 原産地 | 品目ごとの原産国 — 物品が完全に取得されたか、最後の実質的な加工が行われた国（UCC第60条） | 仕向地での特恵関税の適用可否を決定します。1つの貨物に複数の原産地の物品が含まれる可能性があるため、品目ごとに記載が必要です。 |
| 取引条件（インコタームズ） | インコタームズ2020の条項 — 例：EXW シュトゥットガルト、FOB ハンブルク、CIF ニューヨーク、DDP 東京 | 各輸送区間において、運送費、保険、税関リスクを誰が負担するかを定義します。申告された税関価格に何が含まれるか（運送費＋保険の有無）を決定します。 |
| 正味重量 / 総重量 | 品目または貨物ごとの正味重量（商品のみ）と総重量（商品＋包装）をキログラムで表示 | 運送書類（CMR、AWB、B/L）および税関評価に必要です。総重量は運送料金と取扱要件を決定します。 |
| 輸出確認書 | 輸出確認セクション — 通常、税関印またはATLASの電子出口確認通知（Ausgangsvermerk）用の予約領域 | 物品が物理的にEU関税領域を離れたことの証明です。§4 Nr. 1a UStGに基づくVATゼロ税率適用に必要です。これがないと、輸出業者はUVAでの免税を立証できません。 |
これらの項目はすべて、輸出部門が商業送り状（Handelsrechnung）のテンプレートに入力します。同じ項目がATLASの輸出申告書にも記載される必要があり、輸出部門または通関業者がそこで再入力します。さらに経理部門は、そのサブセット（インボイス番号、合計金額、輸出元帳用のEORI番号）を社内ERPに3度目の再入力が必要です。商業送り状（Handelsrechnung）は一度作成されます。そのデータは3回入力されるのです。
二重パイプライン問題：1枚の請求書、2つのシステム、接続ゼロ
毎月30件の貨物を輸出するドイツの輸出業者は、30通の商業送り状（Handelsrechnung）を作成します。それぞれの送り状は、完全に別々の2つのデータパイプラインを通過しますが、これらのパイプラインは互いに連携しません。
パイプライン1：税関（ATLAS AES）。 輸出部門または通関業者（Zollspediteur）は、商業送り状（Handelsrechnung）のデータを取得し、ATLAS AES輸出申告（Ausfuhranmeldung）に入力します。この申告には、EORI番号、品目ごとのHSコード、品目ごとの原産地、インコタームズ、関税評価額、正味重量/総重量が必要です。申告は、ATLAS互換ソフトウェア（AEB Export Filing、DAKOSY GE、MIC-CUST、SAP GTSなど）または通関業者の自社システムを通じて提出されます。ATLASがこれを処理し、リスク分析を実施し、承認されると、18桁の移動参照番号（MRN）が付された輸出同伴書類（EAD、Ausfuhrbegleitdokument）を発行します。商品がEUを離れると、輸出者は輸出確認書（Ausgangsvermerk）を受け取ります。これは商品が物理的に輸出された証拠であり、VATゼロ税率の適用を裏付けるものです。
パイプライン2：会計（ERP）。 経理部門は、同じ商業送り状（Handelsrechnung）を受け取ります。通常は、輸出部門または文書管理システムからPDFとして届きます。経理担当者は、輸出販売を計上する必要があります。請求書番号、請求書日付、顧客名、合計金額、コスト配分のためのインコタームズ（運賃と保険料は商品価値とは異なる勘定科目に計上されます）、および輸出元帳（Ausfuhrbuch）のためのEORI番号です。付加価値税申告（Umsatzsteuervoranmeldung、UVA）のためには、経理担当者は各商業送り状（Handelsrechnung）をその輸出確認書（Ausgangsvermerk）と照合し、§4 Nr. 1a UStGに基づく非課税輸出収益を裏付ける必要があります。イントラスタット報告（EU域内貿易統計、外国貿易統計法（Außenhandelsstatistikgesetz）に基づき義務付け）のためには、経理担当者はHSコード、仕向国、および商品コードごとの統計価額を必要とします。
ギャップ。 パイプライン1は、輸出部門からデータを受け取ります。輸出部門は、ATLASソフトウェアに直接入力するか、通関業者にメールで送信します。パイプライン2は、商業送り状（Handelsrechnung）のPDFからデータを受け取ります。これは、フラットな文書として経理の受信箱に届きます。つまり、すべてのフィールドは見えますが、構造化されていません。経理担当者はPDFを開き、請求書番号、日付、合計金額、EORI番号、インコタームズ、HSコードをERPに再入力します。毎月30通の商業送り状（Handelsrechnung）があり、それぞれに約8つの税関関連フィールドがある場合、毎月240ものフィールドがPDFからスプレッドシートに手動で転記されることになります。すべてのキーストロークが転記ミスの可能性をはらんでいます。すべてのエラーは連鎖します。会計元帳でHSコードを誤って入力すると、ATLASに提出されたHSコードと一致せず、税関調査（Zollprüfung）や付加価値税特別調査（Umsatzsteuer-Sonderprüfung）で不一致が表面化する可能性があります。
これは、ATLASが閉鎖するために設計されたデータ再入力ギャップをなぜ生み出すのかという分析で説明されているのと同じ構造的ギャップです。つまり、税関申告をデジタル化したシステムが、データを輸入者にPDFとして返し、そのギャップを埋めるために手動転記のステップがATLASの出力とERPの入力の間に入るのです。商業送り状（Handelsrechnung）は、輸出側における同じパイプラインの出発点です。データは構造化された入力として作成され、社内ではPDFとして配信され、それを必要とするすべてのシステムに再入力されます。
抽出の設定方法：列を一度定義すれば、すべてのHandelsrechnungを処理できます
解決策は、輸出部門がHandelsrechnungを作成する方法を変えることではありません。彼らはすでにデータを一度入力しています。解決策は、各下流パイプラインにデータが入る時点でPDFからそのデータを取得することです。つまり、PDFとシステムの間にある再入力のステップを排除します。
カスタム列抽出は、各ドキュメントから抽出したい内容を記述する列名のセットを定義することで機能します。AIが各PDFを読み取り、内容を意味的に理解し、値がページのどこにあるか、請求書ごとにレイアウトがどのように異なるかに関係なく、各列に一致する値を見つけ出します。列は一度定義するだけです。その後アップロードするすべてのHandelsrechnungが、同じスプレッドシート構造にデータを投入します。
ステップ1：主要な税関列を定義する
これらは、パイプライン1（ATLAS輸出申告）に必要なフィールドです。輸出チームが使用している正確なドイツ語の用語を使用して各列を定義し、AIが意味コンテキストを正しく一致させられるようにします。
| 列名 | AIが抽出する内容 |
|---|---|
Handelsrechnung Nummer (Commercial Invoice Number) | 請求書番号 — 通常、ドイツの輸出請求書では「HR-」または「EX-」が接頭辞として付き、国内のRechnung番号とは区別されます |
Handelsrechnung Datum (Invoice Date, DD.MM.YYYY) | ドイツの日付形式での請求書発行日 |
EORI-Nummer (DE + 15 digits) | 輸出者のEORI番号 — ATLAS申告を行う事業体と一致している必要があります |
Kunde (Customer Name and Address) | 海外バイヤーの完全な氏名と住所（国名を含む） |
Zolltarifnummer (11-digit Customs Tariff Code) per Position | 請求書の各明細項目に対する完全な11桁のドイツ関税番号 |
Ursprungsland (Country of Origin, ISO Code) per Position | 明細項目ごとの原産国 — 例：ドイツ原産品の場合はDE、中国原産品の場合はCN |
Lieferbedingungen (Incoterms 2020) | インコタームズの条項 — 例：FOB Hamburg、CIF New York、EXW Stuttgart、DDP Tokyo |
Nettogewicht pro Position (Net Weight per Line Item, in kg) | 商品明細ごとの正味重量 |
Bruttogewicht Gesamt (Total Gross Weight, in kg) | すべての梱包を含む貨物の総重量 |
ステップ2：クロスチェック用の推論列を追加する
推論列を使用すると、AIが既に読み取った情報からデータを導き出します。Handelsrechnungには暗黙的に記載されていても、税関申告書には明示的に必要な値を生成します。直接抽出列の下にこれらの列を追加してください。
| 推論列名 | AIが導き出す内容 |
|---|---|
HS章（Zolltarifnummerから導出：2桁の章番号と説明を出力、例：「84 — 機械類及び機械器具」） | 11桁のコードを人間が読めるHS章に変換します。イントラスタットの商品グループ分けや、コードの章が商品説明と一致しない誤分類の発見に役立ちます。 |
Bestimmungsland（仕向国、顧客住所から取得） | 顧客住所から仕向国を抽出します。これは商品が物理的に発送される国であり、請求先住所とは異なる場合があります。 |
ステップ3：税関価額検証用の計算列を追加する
ドイツの輸出申告でよくあるエラーは、税関価額の不一致です。Handelsrechnungに記載された価額（使用されるインコタームズに応じてEXW、FOB、CIFで記載される場合があります）が、ATLAS申告で必要な価額と異なるケースです。ATLAS輸出申告には、ドイツ国境における統計価額（通常はFOBまたはEXW価額に、ドイツの輸出港または空港までの内陸輸送費を加えたもの）が必要です。
計算列を追加して、請求書合計額と明細行の合計額の差をフラグ付けします。これは税関価額計算の前段階となります。
| 計算列名 | AIが計算する内容 |
|---|---|
請求書合計と明細行合計のチェック（Rechnungssumme マイナス Summe aller Positionen — 差が1ユーロ以内なら"OK"、1ユーロを超える場合は"CHECK"を出力） | すべての明細行の金額を合計し、請求書合計額と比較します。データがATLAS申告や会計入力に到達する前に、算術エラーを発見します。 |
Positionen Anzahl（明細行数、この請求書の総商品明細行数をカウント） | 明細行の数をカウントします。抽出ですべての行が取得されたかを確認したり、各商品コードが個別の統計エントリとなるイントラスタット報告に役立ちます。 |
ファイルは安全に処理され、保存されることはありません。
ステップ4：すべての輸出貨物のHandelsrechnungをアップロードする
当月、当四半期、または通期のHandelsrechnungのPDFをアップロードします。AIはバッチ内の各請求書を個別に処理します。異なるレイアウト（異なるテンプレート、異なる列位置、異なるインコタームズの配置）を使用する請求書も、標準テンプレートと同じ方法で処理されます。これは、AIがページ上の位置ではなく、意味的な意味に基づいてフィールドを特定するためです。
国内のRechnungとHandelsrechnungの両方を管理しているドイツの輸出業者の場合、抽出アプローチは同じバッチで両方の文書タイプを処理します。関税関連の列（EORI番号、HSコード、原産地、インコタームズ、重量）を列として定義し、これらのフィールドがない国内のRechnungについては、該当するセルは単に空になります。請求書番号、日付、顧客、合計などの共通フィールドは両方の文書タイプにわたって入力されるため、国内のRechnungか輸出用のHandelsrechnungかに関わらず、統合された1つの輸出スプレッドシートが得られます。
出力内容：商業送り状（Handelsrechnung）1件につき1行、各フィールドは所定の位置に
出力はスプレッドシート（Excel、CSV、またはGoogle Sheetsアドオン経由でGoogle Sheetsに直接）で、商業送り状（Handelsrechnung）1件につき1行が割り当てられます。列はお客様が定義したものです。各セルの値は、AIがPDFから抽出した内容です。
このスプレッドシートは、以下の2つのパイプラインに同時にデータを供給します。
ATLAS申告に必要なEORI番号、HSコード、原産地、インコタームズ、重量は、すでにスプレッドシートに含まれています。輸出部門または通関業者は、ATLASソフトウェアにスプレッドシートから直接データを入力します。各PDFを開いて再入力する必要はありません。お使いのATLASソフトウェア（AEB、DAKOSY、MIC-CUST）が一括申告のためのCSVまたはExcelインポートに対応している場合、データは申告に直接反映されます。通関業者を利用する場合は、PDFの代わりにスプレッドシートを送付します。業者は表からコピーするため、PDFから読み取るよりも高速かつ転記ミスが少なくなります。
請求書番号、日付、顧客、合計金額、EORI番号、インコタームズは、輸出台帳（Ausfuhrbuch）と付加価値税予備申告（UVA）に反映されます。HSコードの章と仕向国は、イントラスタット申告に使用されます。経理担当者は30のPDFを開いて240のフィールドを再入力する代わりに、1つのスプレッドシートを開き、値をPDFと照合してから、DATEV、Lexware、またはSAPにデータをインポートします。検証はエラーを発見します。転記はエラーを生み出します。
スプレッドシートは、商業送り状（Handelsrechnung）データの唯一の信頼できる情報源となります。EORI番号でフィルタリングして、すべての輸出申告が正しい輸出者識別子を使用していることを確認します。HSコードの章でフィルタリングして、四半期ごとのイントラスタット報告のために商品別の輸出量をグループ化します。計算列「請求書合計と明細行合計の一致チェック」を比較して、ATLAS申告に至る前に算術上の不一致を発見します。輸出申告に使用されるのと同じデータセットが会計仕訳にも使用されるため、両方のパイプラインでソースデータが一貫し、税関申告額と会計帳簿額の差異というよくある監査指摘事項を排除します。
FAQ — ドイツ語商業送り状（Handelsrechnung）データ抽出
複数の明細行があり、それぞれ異なるHSコードや原産国が記載されたHandelsrechnungにも対応できますか？
はい。各明細行は、それぞれのHSコードと原産国とともに抽出されます。出力は1請求書あたり1行の構造を維持します。明細行ごとに1行が必要な場合は、列の先頭に「per Position」というプレフィックスを付けて定義してください。AIが各商品明細を個別の抽出単位として扱います。ただし、ほとんどの輸出業務では、HSコードと原産国が主要商品で集約または代表される1請求書あたり1行で十分です。なぜなら、ATLAS申告には明細行の詳細がすでに含まれており、会計入力には請求書レベルのサマリーのみが必要だからです。
異なるインコタームズ（特に同一請求書上のEXW、FOB、CIFの値の違い）はどのように処理されますか？
AIは請求書に記載されたインコタームズ（例：FOB Hamburg、CIF New York、EXW Stuttgart）をそのまま抽出します。運送費や保険料の加算は計算しません。関税評価額（ATLAS申告に使用する額）を計算するには、インコタームズに基づいて請求書金額を調整する必要があります。EXW価格＋EU域内の内陸運送費＝統計価格、FOB価格は通常そのままATLAS輸出申告に使用できます。CIF価格には運送費と保険料が含まれており、輸出側の申告ではこれらを分離する必要があります。計算列「請求書合計と明細行合計のチェック」で請求書の計算を検証できますが、インコタームズから関税評価額への調整は手動計算ステップのままです。ただし、出荷ごとに運送費と保険料がわかっている場合は、計算列で自動化することも可能です。
これはATLAS AES輸出申告の提出を代替するものですか？
いいえ。この抽出機能はATLAS申告の入力データを作成します。申告の提出には、ATLAS対応ソフトウェア（AEB、DAKOSY、MIC-CUST、SAP GTS、または税関ブローカーのシステム）と、ドイツ税関当局（Generalzolldirektion）への有効なATLAS参加者登録が依然として必要です。この抽出機能は、Handelsrechnung PDFを読み取り、そのフィールドをATLASソフトウェアに入力する手動データ入力ステップを代替するものであり、ソフトウェア自体を代替するものではありません。税関申告から構造化データセットまでの完全なワークフローについては、ドイツ税関申告データをExcelに抽出するガイドで輸入側の同等の手順を説明しています。
このワークフローにおいて、輸出確認書（Ausfuhrbestätigung）／出口確認通知（Ausgangsvermerk）はどのように位置づけられますか？
輸出確認書（Ausfuhrbestätigung）は、商品が物理的にEU関税領域外に搬出されたことの証明です。これは、商品が提示され通関された後、ATLAS経由で出口税関から発行されます。Handelsrechnung自体の項目ではなく、輸出申告が処理された後に届く別の電子メッセージまたはスタンプです。抽出ワークフローでは、最初にHandelsrechnungデータを抽出し（ATLAS申告の入力データを作成）、申告が提出され商品が搬出された後、出口確認通知（Ausgangsvermerk）を受領します。その時点で、スプレッドシートに列（Ausgangsvermerk erhalten (Y/N)）を追加し、確認通知が届いたら各行を手動でマークすることで、会計チームがどの輸出がVATゼロ税率の裏付けとして確定し、どの輸出が未処理かを一目で把握できるようになります。
同じ列設定で、ドイツ国内の請求書（Rechnung）からもデータを抽出できますか？
はい、可能です。共通項目（請求書番号、日付、顧客名、金額）は、どの請求書形式からも取得できます。関税固有の列（EORI番号、HSコード、原産地、インコタームズ、重量）は、国内の請求書（Rechnung）の場合は空欄になります。つまり、20件の商業送り状（Handelsrechnung）と40件の国内請求書（Rechnung）が混在したバッチをアップロードし、1つの統合スプレッドシートとして出力できます。EORI番号の列で並べ替えれば、輸出用請求書と国内用請求書を簡単に分けられます。同じ原則は、ELSTER税務フォームデータの抽出にも適用できます。列を一度定義すれば、あとはソース文書からデータを取り込むだけです。こちらのドイツのELSTER税務フォームデータをExcelに抽出するガイドでは、同じ列定義のアプローチを別の文書タイプに適用しています。
Handelsrechnungには、税関申告と会計システムに必要なすべての項目がすでに含まれています。ボトルネックはデータの不足ではなく、スプレッドシートがあるべき場所にPDFがあることです。
Handelsrechnungを抽出する