完全ガイド
ブラジルNF-e抽出

ブラジルのNF-eからのデータ抽出は、通常の請求書からのデータ抽出とは根本的に異なります。PDF形式の標準的な請求書では、視覚的なレイアウトからフィールドを読み取るためにOCRやAIベースの文書理解が必要です。一方、NF-eはXMLファイルとして届きます。これは設計上機械可読であり、商品が倉庫から出荷される前に、ブラジルの州税務当局であるSEFAZによって400以上の自動ルールに照らして構造が検証されています。

課題はデータの入手可能性ではなく、データの複雑さです。欧州のPeppol BIS請求書は約100のXML要素を使用します。レイアウトバージョン4.0のNF-eは、複数のネストレベルにまたがる500以上の構造化要素グループを持ち、明細項目ごとに4つの個別の税計算ブランチがあり、それぞれが独自の税状況コード、課税標準計算、税率、およびクレジットルールを使用します。データは完全ですが、正しく抽出するには、各フィールドの意味と他のフィールドとの関連性を理解する必要があります。

このガイドは実用的なリファレンスとして設計されています。初めてNF-e抽出ワークフローを設定する場合は、セクション2のステップバイステップのワークフローから始めてください。すでに抽出パイプラインが稼働しており、特定のICMS税率を検証したり、CFOPコードを調べたりする必要がある場合は、セクション3から6のリファレンステーブルにジャンプしてください。各セクションは独立して使用できますが、完全な価値は全体像にあります。つまり、どのフィールドを抽出するか、それらが正しいことを確認する方法、そしてキャンセルイベントや contingency インジケーターが付いたNF-eが届いた場合の対処法を知ることです。

NF-e抽出が通常の請求書抽出と異なる点

NF-e抽出の仕組みと、標準的な請求書抽出アプローチ（PDFをアップロードし、列を定義し、データを取得する）が問題の一部しか解決しない理由を、3つの構造的な違いが定義しています。

1. ソースはXMLであり、視覚的な文書ではない。 通常の請求書抽出は読み取りの問題です。AIまたはOCRシステムは、ページ上のテキストの位置を特定し、どの文字列が請求書番号かを認識し、正しい列にマッピングする必要があります。NF-e抽出は解析とマッピングの問題です。データはすでに機械可読なタグに含まれていますが、XML構造はポルトガル語のタグ名（発行者は<emit>、受取人は<dest>、税金は<imposto>）を使用し、税制によって異なる深くネストされた階層を持ちます。抽出の課題は「データを見つけること」から「正しいXMLパスを各出力列にマッピングすること」に移ります。

2. 税構造は多次元である。 単一のNF-e明細項目には、最大4つの独立した税計算（ICMS（州レベル、CSTコードに応じて10以上のバリエーションあり）、IPI（連邦物品税、製品依存）、PIS、COFINS（連邦社会貢献））が含まれます。各税には、独自の計算基準、税率、CST（税状況コード）、およびクレジット適格性ルールがあります。1つの税率が明細全体に適用されるEUのVAT請求書とは異なり、NF-e明細項目には個別の<ICMS>、<IPI>、<PIS>、<COFINS>サブグループが含まれ、それぞれ異なる課税標準を持つ可能性があります。合計のみを抽出すると、各税額控除が正しく計算されたかどうかを判断する詳細を見逃します。

3. 抽出ワークフローは発行後のイベントを考慮する必要がある。 NF-eは24時間以内に取消しできます。特定のフィールドを修正するCarta de Correção（CC-e）を受け取ることができます。SEFAZに到達できなかった場合、代替モードで発行されることがあります。受取人側ではmanifestação do destinatárioと呼ばれるイベントが発生します。これは、買い手が受領を確認し、取引を承認するか、拒否する法的義務です。完全な抽出パイプラインは、初期XMLを抽出して完了とするだけでなく、これらのイベント駆動型の変更を処理する必要があります。取消しと代替ルールがAPワークフローにどのように影響するかについては、NF-e処理の複雑さの分析をご覧ください。

これらの3つの違いは、NF-e抽出が「ポルトガル語のフィールド名を持つ請求書抽出」ではないことを意味します。これは独自のカテゴリであり、文書OCRよりもEDI解析に近いですが、ほとんどのEDI標準を桁違いに超える税の複雑さを持っています。独自の構造的な複雑さを持つもう一つの主要なラテンアメリカの電子請求書システムについては、メキシコCFDI抽出の完全ガイドをご覧ください。

NF-eデータ抽出の完全ワークフロー：ステップバイステップ

手動、スクリプトベース、AI駆動を問わず、エンドツーエンドのNF-eデータ抽出ワークフローは同じ論理的な流れに従います。各ステップで生成された出力が次のステップへの入力となります。

NF-e XMLフィールドマッピングリファレンス

以下の表は、NF-e XMLの必須パスをスプレッドシートの列にマッピングしたものです。フィールドは重要度に応じて分類されています。必須（基本処理に必要）、重要（税務検証やクレジット回収に必要）、特定用途（通関やSPED申告など特定のシナリオで必要）です。すべてのパスは標準のNF-e XML名前空間を基準としています。

ヘッダーフィールド（請求書1件につき1行）

明細フィールド（商品行ごとに1行）

<infNFe>内の各<det>要素は1つの商品行を表します。nItem属性に行番号（1始まり）が格納されます。以下のフィールドは<det>ごとに繰り返されます。

ICMSサブグループに関する重要な注意点：<imposto>内のICMS XMLパスはCSTコードによって異なります。通常課税のICMSは<ICMS00>サブグループを使用します。その他のCSTコードでは、<ICMS10>（課税+ST）、<ICMS20>（課税ベース減額）、<ICMS30>（通常ICMS免除のST）、<ICMS40>（免除）、<ICMS51>（繰延）、<ICMS60>（既徴収）、<ICMS90>（その他）、<ICMSPart>（DIFAL — 州間税率差額）、<ICMSST>（税額代替）などがあります。抽出マッピングでは、<ICMS00>だけでなく、これらすべてのバリエーションを処理する必要があります。

税額検証：抽出された数値を確認する方法

NF-e XMLには仕入先自身の税計算が含まれており、誤っている可能性があります。SEFAZはXML構造の完全性と基本的な計算の整合性を検証しますが、発地・着地の組み合わせに正しいICMS税率が使用されているか、NCMコードの公式TIPI税率とIPI税率が一致しているかは確認しません。これらは買い手側の責任であり、ブラジルのAPで還付可能な過払いの最も一般的な原因です。

州ペア別ICMS州間税率検証

州間取引のICMS税率は、発地州（仕入先の出荷元）と着地州（自社の所在地）によって異なります。以下の表を使用して、NF-eのICMS税率が州ペアの正しい税率と一致するか検証してください：

NF-eのICMS税率が発地・着地ペア（<emit>/<enderEmit>/<cUF> から <dest>/<enderDest>/<cUF>）の期待税率と一致しない場合は、文書をレビュー対象としてフラグを立ててください。税率の不一致はブラジルの仕入先請求書で最も一般的なエラーの一つであり、誤った税額控除計算につながる可能性があります。

CSTコード：税状況コードがすべてを変える

CST（Código da Situação Tributária）は3桁のコードで、税率だけでなく税の適用方法を示します。NF-e上のICMS、IPI、PIS、COFINSの計算にはすべて独自のCSTが付与されます。CSTの最初の桁は税制度の起源を示します（0=国内、1=外国、2=国内成分を含む外国 — 税によって異なります）。ICMSの場合、CSTは課税、免税、繰延、代替（ST）、または特別制度による徴収のいずれかを決定します。3桁のICMS CSTコードは以下の論理に従います：

抽出ワークフローでは、税額とともにCSTコードを常に取得してください。「ゼロICMS」でもCST 40（免税）とCST 00（エラー）では状況がまったく異なります。CSTは、ゼロが正当な税務処理なのか、調査が必要なデータ欠落なのかを判断します。

IPI、PIS、COFINSの検証

IPIの確認: IPI税率は製品のNCMコードによって決まります。ブラジルはTIPI（IPI適用税率表）を公開しており、すべてのNCMコードにIPI税率をマッピングした包括的な税率表です。TIPIの全データを社内で維持することはできませんが（数千のエントリが含まれ、Receita Federalによって定期的に更新されます）、高額な明細項目をスポットチェックできます。NCMを抽出し、そのTIPI税率範囲を確認し、pIPIフィールドが期待範囲内にあることを確認します。IPIのCSTコードも重要です。CST 50はIPI非課税、00は課税を意味します。

PISおよびCOFINSの確認: これらの連邦負担金は、累積方式または非累積方式のいずれかで適用されます。方式はサプライヤーの税区分によって決まり、税率と買い手であるあなたが利用できるクレジットの両方を左右します。

NF-eのPIS税率が1.65%、COFINSが7.6%の場合、サプライヤーは非累積方式であり、PIS/COFINSの仕入税額控除を請求できます。税率が0.65%と3.0%の場合は、クレジットは利用できません。サプライヤーのCST（通常、01 = 非累積方式、02 = 累積方式）が方式を確定します。これらの税率を抽出して検証することは、回収可能な税額に直接影響します。

ICMS税額代替納付（ICMS-ST）：見逃せないメカニズム

ICMS-ST（Substituição Tributária）は、税務当局がサプライチェーン全体のICMS徴収責任を最初のリンク（通常は製造業者または輸入業者）に割り当てるメカニズムです。チェーン内の各買い手（製造業者→卸売業者→小売業者）がそれぞれのマージンに対してICMSを支払う代わりに、製造業者がチェーンの開始時点で消費者への推定最終販売価格に基づいてICMSを徴収します。この納税者の「代替」により、税の徴収ポイントが上流に移ります。

NF-e文書を処理するAPチームにとって、ICMS-STは2つのシナリオで発生します：

シナリオ1 — 自社がチェーンの中間（代替納付された側から購入）。 すでに製造業者からST適用で購入した卸売業者から商品を購入します。NF-eには通常のICMS（CST 00、通常課税）と別個のICMS-ST額（CST 10、<ICMS10>または<ICMSST>内）が記載されます。抽出では両方を取得する必要があります。通常のICMSは仕入税額控除、ICMS-STは控除対象外で、上流サプライヤーがSEFAZに既に納付したコスト込みの金額です。還付は受けられません。

シナリオ2 — 自社が最終リンク（小売業者または直接消費者）。 ST代替納付されたサプライヤーから購入します。NF-eには単一のICMS-ST額（CST 30 — 通常ICMSは免除、STが適用）が記載されます。チェーン全体のICMSコストがこの1つの金額に含まれています。抽出ではSTフィールドのみを取得し、通常のICMS控除は利用できません。

抽出ワークフローでこれら2つのシナリオを区別するには、CSTコードを確認します。CST 10 = 通常ICMS + ST（部分的な控除あり）、CST 30 = STのみ（通常ICMSの控除なし）。ICMS-STのXMLパスは別のサブグループを使用します：ST額は<imposto>/<ICMS>/<ICMSST>/<vICMSST>、ST計算ベースは<vBCST>。これらを通常のICMSとは別の列として抽出し、決して単一の「ICMS合計」フィールドに合計しないでください。一部のAPチームは通常ICMSとSTを合計して複合額を計上しますが、これによりICMS控除ポジションが過大表示され、監査で指摘されます。

CFOPとNCM：コンプライアンスを左右する分類コードの抽出

NF-eの明細行には、その製品の税務処理を決定する2つのコードが必ず含まれています。これらは単なるメタデータではなく、税額計算ロジックへの入力値です。

CFOPコード一覧（先頭桁による分類）

CFOP（Código Fiscal de Operações e Prestações）は4桁のコードで、先頭桁が取引の方向と性質を示します。買い手側（購入側）のNF-e処理で最もよく見られるCFOPコードは、1xxx、2xxx、3xxxの範囲に該当します。

CFOPが抽出において重要な理由：CFOPコードは、取引に適用されるICMSルールを決定します。先頭が1（州内）のCFOPは、サプライヤー所在州の内部税率（17～22%）が適用され、州間税率は適用されません。先頭が2（州間）のCFOPは、上記の州間税率表に従う必要があります。CFOPとICMS税率に矛盾がある場合（例：CFOP 1102（州内）なのにICMS税率12%（州間税率））、請求書に構造的な不一致が存在するため修正が必要です。抽出ワークフローでこれを自動的に検出する必要があります。

NCMコード：IPIと輸入関税を左右する製品分類

NCM（Nomenclatura Comum do Mercosul）は、HSコードにメルコスール固有の2桁を追加した8桁の製品分類コードです。形式：NNNN.NN.NN（最初の6桁がHSコード）。NCMコードは以下を決定します：

• IPI税率：TIPI表でマッピング。特定の章で始まるNCMは、IPI税率が高くまたは低くなります。
• ICMS-ST適用：特定のNCMの章は、州間で必須のICMS-STプロトコル（convênios）の対象となります。
• 輸入関税（II）：国際購入時。
• 代替税率（例：CONFAZプロトコルに基づく簡易ICMS-ST計算）。

抽出時、NCMは常に先頭のゼロを保持したテキストフィールドとして取得する必要があります。数値に変換しないでください。NCM 8471.30.00（コンピュータ機器）は、数値として扱うと先頭の構造が失われます。NCMは、ワークフローに自動税率検証が含まれる場合、IPI税率を検索するための主キーとしても機能します。

抽出ワークフローにおけるNF-e特別イベントの処理

NF-eは静的な文書ではありません。法的に定義された一連のイベントを通じて、修正、取消、再発行が可能です。完全な抽出ワークフローはこれらのイベントを考慮する必要があります。なぜなら、既に抽出したデータが変更される可能性があるからです。

取消。発行者は、許可プロトコル受領から24時間以内に、商品が物理的に移動していない場合に限り、NF-eを取り消すことができます。取消イベントはSEFAZに登録され、同じアクセスキーにリンクされます。24時間経過後は取消不可となり、発行者は税務当局への特別取消申請か、クレジットノート（NF-e de devolução）の発行が必要です。抽出ワークフローでは、抽出時と支払い前にNF-eのステータスを確認することが重要です。プログラムでNF-e文書を処理する場合は、SEFAZのConsNFeDestウェブサービスに問い合わせて、購入者の受信NF-eステータスリストを確認するステータスチェック手順を含めてください。

カータ・デ・コレソン（CC-e）。サプライヤーが既に許可されたNF-eのフィールド（例：製品説明の修正、配送先住所の訂正、支払期日の更新）を修正する必要がある場合、CC-e（NF-eのアクセスキーにリンクされた電子修正書）を発行します。CC-eはXMLを置き換えるのではなく、特定のフィールドを修正します。抽出ワークフローでは、NF-e文書を処理する際に、そのアクセスキーにCC-eイベントが存在するかどうかを問い合わせる必要があります。ImageToTable.aiのバッチ処理には、抽出済み文書に対する修正イベントを確認するオプションが含まれています。サプライヤーがCC-eで支払期日を修正したのに、ワークフローが元のXMLの支払期日を使用した場合、誤ったスケジュールで支払いを行うことになります。

コンティンジェンシーモード。SEFAZに接続できない場合、サプライヤーはコンティンジェンシーモードでNF-eを発行できます。発行タイプ（<ide>/<tpEmis>）はコンティンジェンシー方式を示します：2 = FS-DA（入力DANFE）、3 = EPEC（事前イベントコンティンジェンシー）、4 = DPEC（電子コンティンジェンシー）、5 = FS-IA（フォームコンティンジェンシー）、6 = SVC（SEFAZ仮想コンティンジェンシー — バックアップ認証サーバー）。コンティンジェンシーモードでは、抽出時にNF-eに完全なSEFAZ認証プロトコルが含まれていない場合があります。ワークフローでは、コンティンジェンシー発行文書にフォローアップ用のフラグを立ててください。システムが復旧したら、サプライヤーは完全なNF-eを送信するため、最終XMLを取得し、フィールドに変更があれば再抽出する必要があります。

受取人のマニフェスタサン。 これは供給者のイベントではなく、買い手の義務です。ブラジル法では、商品の買い手はSEFAZポータルで特定の期間内にイベント応答を登録する必要があります。発行から10日以内に受領を確認し、取引を承認または拒否します。このプロセスは受取人のマニフェスタサンと呼ばれ、SEFAZのDF-eプラットフォームを通じて管理されます。マニフェスタサンは抽出とは別のコンプライアンス手順ですが、抽出ワークフローでは、処理済みの各NF-eのアクセスキーをマニフェスタサン追跡システムに記録し、コンプライアンス部門が期限内に必要なイベントを提出できるようにする必要があります。マニフェスタサンを登録しない場合、SEFAZは取引が未確認とみなし、その供給者からの将来のNF-e発行がブロックされる可能性があります。

これらのイベントタイプとAP業務への影響の詳細については、NF-e処理の複雑さの分析をご覧ください。

抽出方法の比較：ボリュームに合ったアプローチ

NF-eデータを抽出する一般的な方法は4つあり、適切な方法はボリューム、技術リソース、明細レベルの税詳細が必要か、ヘッダー合計のみで十分かによって異なります。

NF-eの重要な違いは、抽出方法がDANFEとXMLの両方を処理できるかどうかです。供給者が混在（XMLを直接送信する場合と、DANFEのみを印刷して発送する場合）する場合、両方のソースを一貫して処理できる方法が必要です。ImageToTable.aiは両方をサポートしています。生のNF-e XMLファイルをDANFE PDFと一緒に同じバッチでアップロードし、単一の列テンプレートを定義して統合スプレッドシートを取得できます。このツールは、上記の可変ICMSサブグループパスも処理します。これは、スキーマの複雑さによりスクリプトチームが数十のXPathバリエーションを維持する必要がある場合に大きな利点です。複数のNF-e文書をバッチ処理する実践的な手順については、バッチNF-e処理ガイドをご覧ください。

2026年税制改革に向けた抽出ワークフローの準備

ブラジルの憲法改正132/2023および補完法214/2025により、5つの既存税を2つの新税に置き換える二重VAT制度が導入されました。NF-e抽出においては、2026年8月から2033年までの移行期間中、現在解析しているXMLスキーマに新旧両方の税フィールドが含まれることになります。以下に、抽出レベルでの変更点と必要な対応を説明します。

変更なし：XMLの全体構造（<ide>、<emit>、<det>、<total>）は変わりません。ヘッダーフィールド、明細数量、NCMコード、CFOPコードも影響を受けません。

変更点：各明細の<imposto>セクションと<total>集計グループに、新しいXML要素グループが追加されます。新しいグループには、既存のICMS、IPI、PIS、COFINSフィールドに加えて、CBS（連邦税）とIBS（州・市税）の税計算が含まれます。移行期間中は、両方のフィールドセットを抽出し、ダウンストリームシステムで利用できるようにする必要があります。

抽出ワークフロー準備のための3つの実践的ステップ：

よくある質問

NF-eフィールド抽出時にXML名前空間の処理は必要ですか？

はい。NF-e XMLは<nfeProc>要素で宣言されたデフォルト名前空間（通常xmlns="http://www.portalfiscal.inf.br/nfe"）を使用します。XPathクエリでは、この名前空間を登録するか（Pythonのlxmlの場合：ns = {'nfe': 'http://www.portalfiscal.inf.br/nfe'}）、local-name()を使用して回避する必要があります。Power QueryのXMLコネクタは、ほとんどの場合名前空間を自動処理します。抽出ツールで明示的な名前空間登録が必要な場合は、正しいURIを使用してください。不一致があると、空の結果セットが静かに返されます。

明細行の税額を合計し、ヘッダーの合計と比較すべきですか？

はい。これは実装できる最も価値のある検証チェックの一つです。NF-e XMLは<total>/<ICMSTot>に税額合計を、各<det>に明細行の詳細を保持します。これらは一致する必要があります。明細行の合計とヘッダー合計の不一致は危険信号です。XML生成時に明細行が省略された、割引が不整合に適用された、またはサプライヤーのERPに設定ミスがある可能性を示します。すべての抽出バッチで、明細行の税額とヘッダー合計を照合することを標準手順にしてください。

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

いいえ。SPED（Sistema Público de Escrituração Digital）はブラジルのデジタル帳簿提出システムであり、州税向けEFD-ICMS/IPIと連邦負担金向けEFD-Contribuiçõesが含まれ、特定のSPEDレイアウトにフォーマットされ、認定ソフトウェアを通じて提出される必要があります。NF-e抽出は請求書データをスプレッドシートに取り込むものであり、SPED準拠のレコードを生成するものではありません。ただし、NF-eから抽出するデータ（明細行のICMS、PIS、COFINS、CFOP、NCM、CST）は、SPED提出に使用されるものと同じデータです。抽出ワークフローが明細行レベルで税詳細を正しく取得していれば、ブラジルの経理チームはそのデータを使用して、ソース文書からの再入力ではなく、必要なSPEDレコードを入力できます。NF-eフィールドからSPEDレイアウト位置へのマッピングは別の変換ステップであり、一部のERPローカライゼーションモジュールが自動処理します。

会社がブラジルの異なる州に複数のCNPJを持つ場合はどうなりますか？

これは大規模組織では一般的です。各CNPJ（ポルトガル語で「estabelecimento」）は税務上、独立した法人格であり、NF-eの送付先州は商品を受け取ったCNPJに対応します。複数法人組織のNF-eデータを抽出する場合、受取人CNPJ（<dest>/<CNPJ>）で抽出結果をフィルタリングし、法人ごとに個別のGLマッピングを維持してください。ICMS税率の検証も法人ごとに異なります。同じ仕入先からでも、サンパウロのCNPJに出荷された商品とバイーアのCNPJに出荷された商品では税率が異なります。ブラジルの州ごとの複雑性への対応については、手頃な価格のNF-e抽出ガイドをご参照ください。

過去の期間から抽出したデータのNCMコードが変更された場合はどうなりますか？

NCMコードはReceita Federalによって定期的に更新されます（通常は年1回ですが、Notas Técnicasによる年度途中の調整もあります）。NCMコードが変更されると、その製品分類のIPI税率も変更される可能性があります。抽出目的では、発行時にNF-eに記載されているNCMコードを取得する必要があります。これは請求書日付時点で有効なコードであり、法的に支払われるべき税金を決定します。遡及分析やSPED調整を行う場合は、現在のNCMリストではなく、元の文書に記録されたNCMを使用してください。

仕入先のNF-e XMLに要素が欠落している、または不正な形式の場合はどうなりますか？

発生し得ます。最も一般的な問題は、<cobr>（請求）グループの欠落、<enderEmit>の住所情報の不完全さ、または宣言されたCSTコードに対して期待されるスキーマバリアントに従っていないICMSサブグループです。抽出ワークフローはこれらを適切に処理する必要があります。欠落フィールドにはnullまたはプレースホルダーを返し、検証警告をログに記録します。重要でない要素の欠落では決して処理を停止しないでください。重要なフィールド（アクセスキー、CNPJ、明細行合計）については、値の欠落はそのNF-eをバッチから拒否し、明確なエラーメッセージを表示する必要があります。検証サマリーレポートは不可欠です。フィールドが欠落または異常だったすべてのNF-eをログに記録し、GLに転記する前にチームが調査できるようにしてください。

DIFAL（州間ICMS税率差）の処理方法を教えてください。

DIFAL（Diferencial de Alíquota do ICMS）は、商品が州境を越えて販売され、仕向け地の州のICMS税率が、仕向け地で支払われた州間税率よりも高い場合に適用されます。買い手は自州に対してその税率差を支払う必要があります。NF-e上では、DIFALは<imposto>/<ICMS>の下にある<ICMSPart>サブグループで表されます。このサブグループには、vBC（計算基準額）、pICMS（既に適用された州間税率）、pICMSUf（仕向け地州の内部税率）、およびvICMS（DIFAL額＝基準額に対する2つの税率の差）が含まれます。DIFAL額は別途抽出し、州固有のICMSクレジットワークフローで処理する必要があります。これは通常のICMSクレジットの一部ではありません。

運送料や保険料は商品価格とは別に抽出すべきですか？

はい。NF-e XMLは取引を商品価格（vProd）、運送料（vFrete）、保険料（vSeg）、その他費用（vOutro）に分解します。ICMSの課税基準額には、多くの場合、商品価格＋運送料＋保険料＋その他費用の合計が含まれますが、常にそうとは限りません。一部の製品では、商品価格のみにICMSが計算されます。各構成要素を個別に抽出することで、ICMS課税基準額が価格体系の理解と一致しているかを検証できます。NF-e上で運送料がICMS基準額に含まれているのに、貴社のERPモデルでは運送料がICMS基準額の対象外である場合、調整すべき項目が発生します。

AIベースの抽出ツールは、DANFE PDFだけでなく、NF-e XML全体も処理できますか？

ツールによります。ImageToTable.aiのAIベースの抽出は、同じバッチでNF-e XMLファイル（構造化データ）とDANFE PDF（ビジュアル文書）の両方を処理できます。XMLをアップロードすると、ツールは構造化要素を直接読み取り（OCR不要）、列テンプレートにマッピングします。DANFE PDFをアップロードすると、AIがビジュアルコンテンツを読み取り、表示されているフィールドを抽出します。両方に対応する単一プラットフォームの主な利点は一貫性です。「NF-eアクセスキー」「ICMS金額」「CFOPコード」用の列テンプレートを1つ定義すれば、ツールは受け取ったソース文書（XMLまたはDANFE）から自動的にデータを入力します。これにより、XMLベースの仕入先とDANFEベースの仕入先で個別のワークフローを維持する必要がなくなり、ブラジルの買掛金業務における一般的な断片化ポイントを解消します。

抽出結果をXMLと一緒に保管する必要はありますか？

ブラジルの法律では、取引が発生した会計年度の終了から5年間、元のNF-e XMLを保管することが義務付けられています。抽出結果（スプレッドシートやERPの記録）はXMLの代わりにはなりません。ただし、抽出結果を構造化して生のXMLアーカイブと併せて保管することは、内部照合や監査対応のベストプラクティスです。SEFAZ監査では、元のXML（文書の存在と適切な承認を証明するため）と会計記録（データの処理方法を示すため）の両方を提出する必要が生じるでしょう。アクセスキーを結合キーとして、元のXMLと抽出結果を自動的に関連付けて保管する抽出ワークフローを構築すれば、監査準備の時間を大幅に節約できます。コスト効率の良いコンプライアンス対応については、中小企業向けNF-e抽出ガイドをご覧ください。