ブラジルNF-e（ノタ・フィスカル）
XMLからExcelへのデータ抽出

DANFEの罠：なぜ多くの国際APチームが誤った書類を処理しているのか

ブラジルのサプライヤーから出荷が到着すると、運転手はバーコードと右上に44桁の番号が印刷された書類を手渡します。これがDANFE（Documento Auxiliar da Nota Fiscal Eletrônica、電子インボイス補助書類）であり、その名称にある「補助」という言葉は飾りではありません。DANFEはただ一つの目的、つまり高速道路の検問所で税務当局がバーコードをスキャンして貨物を確認できるよう、物理的な商品に同行するために存在します。完全なインボイスとして設計されたものでは決してありません。

しかし、ブラジルからの商品を受け取る大多数の国際APチームにとって、DANFEがインボイスとして扱われています。スキャン、OCR、または手動でERPに入力されます。44桁のアクセスキーは、忠実に44桁すべてが「インボイス番号」フィールドにコピーされます。そしてAP担当者は次の書類に移ります。すべてのベンダー、すべての出荷について、完全なインボイスがすでに機械可読なXML形式で存在していることに気づかずに。このXMLは、ブラジル政府が売り手に対し、ICP-Brasil証明書でデジタル署名し、商品が合法的に倉庫を出る前にSEFAZ（州税務当局）に提出することを義務付けているものです。

データ損失の規模は軽微ではありません。DANFEには、ベンダー名、買い手名、日付、数量と単価を含む明細行、合計金額という要約情報のみが印刷されます。一方、NF-e XMLは、SEFAZが承認時に実行する400以上の自動検証ルールに準拠し、現在のレイアウトバージョン4.0（Nota Técnica 2016/002で定義）では500以上の構造化タグを含んでいます。両者の違いは、レシートと取引の完全な税務記録との違いです。後者は、仕入税額控除、税関調整、そして今後5年間の監査証跡を決定します。

DANFEとXMLの区別は、些細な技術的違いではありません。ブラジルのベンダーインボイスを扱うすべてのAP部門にとって最も重要な概念であり、直接的な財務的影響を伴います。つまり、チームがDANFEからデータを入力している場合、すでに構造化され機械可読な形式で存在する情報の一部を手動で再入力しているだけでなく、すべての取引でICMS、IPI、PIS、COFINSの正しい金額を回収しているかどうかを決定する税務詳細を見逃していることになります。

NF-e XMLの中身 — なぜAPにとって重要なのか

NF-e XMLは、単なる山括弧で書かれた請求書ではありません。売り手の電子署名が付与され、SEFAZの400以上のルールに照らして検証済みの、法的に有効な税務文書です。また、ブラジル国外の電子請求書標準を超える粒度で税データを保持しています。比較すると、欧州のPeppol BIS標準は約100の要素を使用しますが、NF-eはその5倍の要素を持ち、すべてが機械可読です。

抽出ワークフローを設計する前に、何を抽出するのかを理解する必要があります。以下は、すべてのNF-e XMLに含まれる主要な要素グループと、それぞれが買掛金管理にとって重要な理由です。

44桁のアクセスキー（chave de acesso）はNF-eの共通識別子です。発行者の州（最初の2桁、IBGEコードに準拠 — サンパウロは35、リオデジャネイロは33、ミナスジェライスは31）、発行年月（次の4桁）、発行者のCNPJ（次の14桁）、書類モデル（2桁）、シリーズ（3桁）、連番（9桁）、発行タイプ（1桁）、ランダムな衝突回避コード（8桁）、モジュロ11チェックデジット（1桁）をエンコードしています。すべてのNF-e XMLは、このキーを<infNFe Id="NFe...>属性に保持しており、SEFAZに直接照会して真正性の確認、取消しの有無の確認、またはベンダーがDANFEのみを送信した場合の完全なXMLのダウンロードに使用できます。

NF-e XML抽出ワークフローの設定

NF-e XMLデータをExcelスプレッドシートに取り込むには、3つの異なるアプローチがあり、それぞれコストと複雑性の点で大きく異なります。どれが適しているかは、ボリューム、ERPのセットアップ、およびブラジル子会社がすでにローカライゼーションモジュールを実行しているかどうかによって異なります。

方法1：ERPインポートモジュール（SAP TDF、Oracle EBS Brazil、Dynamics 365 Finance）

会社がSAP、Oracle EBS、またはMicrosoft Dynamics 365をブラジルローカライゼーションモジュールを有効にして運用している場合、ERP自体がNF-e XMLファイルを直接インポートできます。SAPのTDF（Nota Fiscalモジュール）は、トランザクションJ1BNFEを通じて受信NF-e XMLを処理し、各XML要素を対応するSAPテーブルにマッピングします。Oracle EBS Brazilローカライゼーション（12.2.6+で利用可能）は、インポートにXML Generator SEFAZプログラム（P76B601）を使用します。Dynamics 365 Financeは、[買掛金管理] > [ブラジルローカライゼーション] > [NF-e XMLのインポート] の下に専用のインポートワークフローを提供します。

これはゴールドスタンダードです — SEFAZに対してリアルタイムで検証し、正しい税勘定に転記し、スリーウェイマッチングを自動的に処理します。ただし、価格も伴います。SAPおよびOracle Brazilローカライゼーションモジュールは別途ライセンス費用がかかり、ブラジル中堅企業で支配的なERP（最新のFundação Getúlio Vargas（FGV）調査によると33%の市場シェア）であるTOTVSは、完全にブラジルに特化しており、国外では一般的ではありません。グローバルAPチームがブラジルのERPローカライゼーションを持っていない場合、このアプローチは利用できません。

方法2：XMLからExcelへの変換

最も単純なレベルでは、NF-e XMLはXMLファイルであり、どのXMLファイルもスプレッドシート形式に変換できます。Microsoft Excelの組み込みXMLインポート（データ > データの取得 > ファイルから > XMLから）、オンラインコンバーター、またはxml.etree.ElementTreeなどのライブラリを使用したPythonスクリプトなどのツールを使用して、XML構造を行と列にフラット化できます。

汎用的なXML変換の課題は、NF-eスキーマの深さにあります。単一のNF-e XMLは、明細データを<det>要素内にネストし、各要素には独自の<imposto>サブツリーがあり、ICMS、IPI、PIS、COFINSグループが分かれています。単純なXMLからCSVへの変換では、これが数百の列を持つ単一の行にフラット化され、多くは同じ名前になります（すべての明細にvProdフィールドがあり、すべての税グループにvBCフィールドがあります）。出力は技術的には「Excel内」にありますが、大幅なクリーンアップなしでは使用できません。

Pythonのxml.etreeまたはlxmlを明示的なXPathクエリとともに使用すると、正確な制御が可能になります。必要な要素を正確に抽出し、名前付き列にマッピングできます。これは、開発リソースが利用可能な場合にうまく機能しますが、NF-eスキーマが更新されるたびに壊れるXPathマッピングを維持する必要があります。2026年の税制改革により、スキーマに新しいCBS/IBS要素グループが追加されるため（下記参照）、これらのマッピングを更新する必要があります。

方法3：AIを活用した文書抽出

3つ目のアプローチは、ERPのローカライズコストとXPathスクリプトの脆弱性の両方を回避するもので、AIベースの文書抽出です。XMLを直接解析する代わりに、DANFE（またはベンダーのシステムによってPDFとしてレンダリングされたNF-e XML）を抽出ツールにアップロードし、出力テーブルに含めたい列（「CNPJ」、「請求書番号」、「ICMS課税標準」、「ICMS金額」、「NCMコード」、「CFOP」）を指定すると、AIが文書を読み取って各値をページ上のどこにあっても特定します。

このアプローチは、カスタム列抽出と呼ばれることもあり、テンプレートベースのOCRとは異なる動作をします。従来のOCRでは、サプライヤーごとの請求書レイアウトのテンプレートを定義し、「請求書番号は常に座標(x,y)にある」ことをシステムに伝える必要があります。レイアウトが変更されると、テンプレートは機能しなくなります。一方、列ベースの抽出は意味理解によって機能します。必要なフィールドに名前を付けると、AIはフィールドが何を意味するかを理解することで、文書内のどこからでも対応する値を見つけます。これは、ブラジルのサプライヤーのDANFEレイアウトが大きく異なるため、NF-e処理に特に関連性があります。標準化された視覚的テンプレートはなく、その下にある標準化されたXMLスキーマのみが存在します。

正直なところ、制限は、機械可読なXMLではなく、DANFEの視覚的レイアウトから抽出していることです。取得できるのはDANFEに表示されるデータの10％であり、XML内の500以上のフィールドではありません。多くの買掛金（AP）ユースケース（ヘッダーデータ、明細、合計）では、これで十分であり、手動入力よりもはるかに高速です。ただし、XMLにのみ存在する完全なPIS/COFINSの明細ごとの計算、CFOPコード、またはCST税状況コードが必要な場合、DANFEからのAI抽出では、ページに印刷されていないデータを復元できません。

NF-eフィールドをスプレッドシートにマッピング：抽出すべき項目とその理由

XML解析用のXPathクエリを書く場合でも、AI抽出用の列名を定義する場合でも、選択する列が出力の有用性を左右します。以下は、実際のXML要素パスを使用した、3つの主要なAPワークフロー（ベンダー確認、三者照合、税額控除の計上）をカバーする実用的なフィールドマッピングです。

重要な詳細：ICMS要素のパスは税区分によって異なります。NF-eスキーマはICMSの区分ごとに異なるXMLサブグループを使用します — 標準課税取引にはICMS00、免税にはICMS40、税額控除済みで税額代替のある取引にはICMS60。抽出ロジックはこの分岐構造を処理する必要があります：<ICMS>の下にどのサブグループが存在するかを確認してから、その子要素を読み取るようにしてください。

抽出データにおけるブラジル税制の複雑性への対応

データ抽出は最初のステップに過ぎません。真の作業は検証から始まります。ここで発生するエラーの多くは、税務監査の際に表面化します。ブラジルの税制は連邦、州、市町村の3つの政府レベルで運用され、税率は製品分類、発地・着地の組み合わせ、取引の法的性質によって異なります。以下は、NF-eデータ抽出ワークフローに組み込むべき検証項目です。

州ペア別ICMS税率検証

ICMS税率は一律ではありません。州間取引の場合、税率は発地州と着地州によって決まります。

州内取引の場合、税率は州によって17%から22%の範囲です。2024年時点で、ペルナンブコ州は20.5%、バイーア州は20.5%、マラニョン州は22%、リオデジャネイロ州は20%、サンパウロ州は18%、サンタカタリーナ州は17%です。これらの税率は2024年だけで11州で変更されました。バイーア州は2月7日に19%から20.5%に、マラニョン州は2月19日に20%から22%に引き上げられました。請求書を受け取るすべてのブラジル州の税率表を最新に保つことが、抽出検証ロジックには不可欠です。

CFOPコードの解釈

CFOP（Código Fiscal de Operações e Prestações）は、取引の税務上の性質を分類する4桁のコードです。SEFAZによって事前に定義されており、自由記述ではありません。先頭の桁で、これが入荷か出荷か、および商品の原産州がわかります。

受取人にとって、入荷インボイス（1xxx、2xxx、3xxx）のCFOPは、ICMSおよびIPIの税額控除が利用可能かどうか、またそのルールを決定します。CFOP 1101（州内の工業化目的の購入）は、通常、内部税率での全額ICMS控除の対象となります。CFOP 1102（州内の再販目的の購入）は、異なる扱いとなる場合があります。そしてこれはCST（Código de Situação Tributária）と相互に関連します。CSTは、品目が課税（00）、非課税（40）、税額代替（60）、または特別制度の対象となるかを指定する2桁のコードです。CFOPはこれがどの種類の取引かを示し、CSTはどのように課税されるかを示します。両方を抽出し、相互検証する必要があります。

NCM分類とその下流への影響

NCM（メルコスール共通命名法）は、国際的なHSコードにメルコスール固有の2桁を追加した8桁のコードです。すべての明細行に表示され、その製品のIPI税率（連邦歳入庁が更新する400ページ以上のPDFであるTIPI表に掲載）、輸入関税率、そして重要なことに、標準的な税計算を上書きする税制上の優遇措置（軽減税率、みなし控除、または免除）の対象となるかどうかを決定します。

税制優遇措置の対象となるNCMコードは、請求書に表示されている標準のICMSまたはIPI税率が、実際に控除として計上すべき金額ではない可能性があることを意味します。抽出ワークフローでは、NCMが既知の優遇カテゴリに一致する明細行にフラグを立て、税務チームが総額の税率が正しいと単純に想定するのではなく、控除計算を検証できるようにする必要があります。

2026年の税制改革と抽出ワークフローへの影響

ブラジルの税制改革は、憲法改正第132/2023号により制定され、補完法第214/2025号により規制されており、国の間接税制度を根本的に再構築しています。5つの既存税（PIS、COFINS、ICMS、ISS、IPI）は、連邦レベルのCBS（財・サービス貢献）、州・市町村レベルのIBS（財・サービス税）、および健康や環境に有害とみなされる財に対する選択税（IS）からなる二重VATモデルに段階的に置き換えられています。

移行スケジュールは以下の通りです。

APチームにとって当面の運用上の懸念は、2026年から2033年までのデュアルスキーマ期間です。この期間中、NF-e XMLファイルには従来の税要素グループと新しい税要素グループが同時に含まれます。2026年以前のスキーマにハードコードされたフィールドマッピング（vICMS、vPIS、vCOFINSのみを読み取る）を使用する抽出ワークフローでは、新しいCBS/IBSフィールドが黙って無視されます。これは将来の問題ではなく、今始まっています。2026年8月1日以降、CBS/IBSフィールドなしで提出されたNF-e XMLはSEFAZによって拒否されます。スキーマ変更は必須であり、オプションではありません。

XML解析スクリプトを作成している場合は、スキーマ分岐を計画してください。ドキュメントに存在する税グループを検出し、存在するものを抽出し、一貫した出力列セットに正規化します。DANFEからAIベースの抽出を使用している場合は、CBS/IBSフィールドが印刷表現に表示され始めたときに認識されるかどうかをプロバイダーに確認してください。

よくある質問

DANFEだけで完全なXMLデータを取得できますか？

いいえ。DANFEは印刷された要約であり、XML内のデータの90％以上が省略されています。これは輸送中の物理的な検査用に設計されたものであり、財務処理用ではありません。完全な税内訳、CFOPコード、NCM分類、CST税状況コード、輸送詳細はXMLにのみ存在します。ベンダーがDANFEのみを送信した場合は、XMLを依頼してください。法的に提供が義務付けられており、DANFEに印刷された44桁のアクセスキーを使用してSEFAZから取得することもできます。

特定の請求書にどのICMS税率が適用されるかを知るにはどうすればよいですか？

NF-eのICMS税率は、発行元の州（<emit>内の発行者の州登録から抽出）、宛先の州（<dest>内のエンティティの州）、および商品に40％を超える輸入含有量があるかどうか（州の組み合わせに関係なく4％の税率が適用される）によって決定されます。XML自体には、売り手が適用した税率がpICMSに含まれていますが、売り手が正しく適用したと想定するのではなく、正しい税率表に対して検証する必要があります。税率の誤りは一般的な監査指摘事項です。

AIはCFOPコードを自動的に正しく解釈できますか？

CFOPコードは文書からそのまま抽出されます。4桁のコードはDANFEとXMLに表示されます。ツールがコードを解釈できるか（例：「州内購入（再販用）」と「州間購入（工業化用）」の区別）は、ツールの機能に依存します。一部のAI抽出ツールは、参照テーブルを使用してCFOPコードを説明にマッピングできます。解釈がワークフローに不可欠な場合は、ツールプロバイダーにCFOPマッピング対応を確認するか、抽出したコードをデコードするための別のExcelルックアップテーブルを維持してください。

当社にはブラジルのERPローカライゼーションがありません。それでもNF-eデータを抽出できますか？

はい。XML自体は標準形式のファイルであり、XMLファイルがあればどの企業でも解析できます。SAP TDFやOracle Brazilローカライゼーションは不要です。Pythonスクリプト、オンラインのXML-to-Excel変換ツール、またはAI抽出ツールを使用して、データをスプレッドシートに取り込むことができます。ERPローカライゼーションモジュールは統合（自動転記、SEFAZ検証、税勘定マッピング）を追加しますが、抽出には必須ではありません。

NF-e抽出はSPED報告要件をカバーしますか？

いいえ。SPED（Sistema Público de Escrituração Digital）はブラジルのデジタル簿記システムであり、州税のEFD-ICMS/IPI、PIS/COFINSのEFD-Contribuições、デジタル会計帳簿のECDなど、個別の申告が必要です。NF-e抽出は請求書データをExcelに取り込みますが、SPED準拠のファイルは生成しません。SPED申告には、抽出したデータを特定のSPEDレイアウトコードにマッピングし、政府認定ソフトウェアを通じて提出する必要があります。これは、ブラジルの会計チームまたは税務コンプライアンスプロバイダーが処理する別のワークフローです。

ベンダーがデータ抽出後にNF-eをキャンセルした場合はどうなりますか？

NF-eは、商品がまだ出荷されていない場合、発行者が認可から24時間以内にキャンセルできます。キャンセルにより、同じ44桁のアクセスキーにリンクされたイベント（キャンセルイベント）がSEFAZのシステムに作成されます。そのキーに対するクエリは、キャンセルされたステータスを返します。抽出ワークフローは、特に支払期日近くの請求書について、定期的にSEFAZに対してアクセスキーを検証し、キャンセルされた文書に対する仕訳入力を回避する必要があります。2026年の改革では、課税事象後のキャンセルには税額の66%の罰金が科せられるため、遅延キャンセルの頻度は減少するはずですが、検証は引き続き必要な管理策です。

複数のNF-e XMLファイルを一括抽出するにはどうすればよいですか？

XMLベースの方法では、XMLファイルのディレクトリをループ処理するスクリプトを使用し、各ファイルから同じXPathクエリでデータを抽出して、結果を累積スプレッドシートに追加します。DANFE PDFからのAI抽出の場合は、バッチ処理機能を利用してください。複数のDANFEファイルをまとめてアップロードし、列定義を一度指定するだけで、各ドキュメントからデータを抽出し、結果を1つのExcelファイルに統合します。この方法は混合形式にも対応します。一部のベンダーがDANFE PDFを送信し、他のベンダーがXMLを印刷したものを送信する場合でも、バッチ処理は両方から同時に抽出します。

NF-eデータ抽出の精度は手動入力と比べてどのくらいですか？

XMLベースの抽出では、対象フィールドの精度は実質100%です。これは、視覚的なレイアウトを解釈するのではなく、機械可読ファイルから構造化データを読み取るためです。DANFEからのAI抽出では、印刷テキストの精度は最大99%に達しますが、44桁のアクセスキーのような複雑なフィールド（1桁の誤りでキーが無効になる）の精度は、長い数値文字列の処理方法に依存します。手動入力に対する真の精度向上は、文字レベルの正確さだけではありません。完全性が重要です。人間がDANFEからデータを入力する場合、通常1枚の請求書あたり8～12フィールドを取得します。自動抽出では、すべてのドキュメントから指定したすべてのフィールドを取得するため、手動入力で最も一般的で見落とされがちなエラーであるデータの欠落を排除します。