50件のブラジルNF-e XMLを1つのスプレッドシートに：手動税務調整不要のマルチサプライヤ一括処理

サンパウロの仕入先からのNF-e 1件の処理には3分かかります。XMLはクリーンで、フィールドは明確、ICMS税率は州内取引の18%と想定通りです。問題は、7つのブラジル州にまたがる14社の仕入先から50件のNF-e XMLが届いたときに始まります。パラナ州の仕入先3は州内出荷に19.5%のICMSを適用しますが、サンパウロの貴社への出荷には12%です。ペルナンブコ州の仕入先8は20.5%を請求しますが、NCM 8471.30に分類される品目は軽減税率が適用されます。仕入先11はXMLではなくDANFE PDFを送ってきました。そして、どこかのバッチで、仕入先2が会計年度開始時に番号をリセットしたため、2つの異なるNF-e文書が同じインボイス番号を共有しています。 1件のNF-eを抽出するのは簡単です。しかし、50件を抽出し、すべての行の税務処理が検証可能な、クリーンで監査可能な買掛金スプレッドシートを作成するのは、まったく別の問題です。

50件のNF-e XMLが届いたとき — バッチ処理は「単一処理の50回繰り返し」ではない

ブラジルのNF-e処理には特異な点がある。それは、元データがすでに構造化されていることだ。米国や欧州のベンダーからの紙の請求書がデジタル化にOCRを必要とするのとは異なり、NF-eはすべて、SEFAZの400以上のルールに照らして検証され、ICP-Brasil証明書でデジタル署名されたXMLファイルとして届く。単一のNF-e XMLのデータ品質はほぼ完璧だ。ブラジルのAPにおけるバッチ問題は、データ取得の精度ではなく、サプライヤー間のデータの一貫性である。

14社のサプライヤーから50件のNF-e XMLを1つのバッチで処理する場合、単一請求書処理では決して表面化しない4つの構造的問題が発生する。

ICMS税率の断片化。ブラジルのICMSは州レベルのVATであり、税率はサプライヤーの州、自社の州、取引の方向（州内か州間か）、場合によってはNCM製品分類によって異なる。7つの州のサプライヤーからの50件のNF-e XMLのバッチには、17％、18％、19％、19.5％、20％、20.5％の州内税率に加え、発地と着地の組み合わせに応じて4％、7％、12％の州間税率が含まれる可能性がある。スプレッドシートの「ICMS金額」列は、税率、該当する州、取引が州内か州間かを把握していなければ無意味である。なぜなら、同じR$1,000のICMS課税額でも、17％の税率でR$5,882の課税ベースを意味する場合もあれば、12％の税率でR$8,333の課税ベースを意味する場合もあるからだ。貴社のERPの税モジュールには、この区別が必要である。

CFOPの不整合。 NF-eの明細行には必ず4桁のCFOP（Código Fiscal de Operações e Prestações）コードが付与され、取引の税務上の性質を分類します。例えば、同一州内での工業化目的の仕入は1.101、州をまたぐ転売目的の仕入は2.102、輸入は3.101です。先頭の数字は、取引が州内（1）、州間（2）、国際輸入（3）のいずれかを示します。サプライヤーAがサンパウロからサンパウロの倉庫への出荷にCFOP 1.101を使用し、サプライヤーBがミナスジェライス州からの州間出荷にCFOP 2.102を使用するのは、正しく意図された使い方です。しかし、サプライヤーCがリオデジャネイロ発の出荷（州間取引）にCFOP 1.101を使用した場合、CFOPがXMLの<ide>および<emit>ブロック内の州データと矛盾します。この不一致は、サプライチェーン全体でCFOPコードを相互参照する連邦デジタル簿記システムSPED EFD（Escrituração Fiscal Digital）において、監査フラグを発生させます。50件の請求書バッチでは、3～5件の不一致が一般的であり、手動で発見するには各XMLのCFOPを発着地の州ペアと照合する必要があります。

請求書番号のみでは重複検出に失敗する。 ほとんどのAPシステムでは、仕入先＋請求書番号で重複検出を行う。しかし、ブラジルのNF-eでは、請求書番号（número da nota）は単一の仕入先のシリーズ内でのみ一意であるため、このロジックは機能しない。仕入先Aがシリーズ001でNF-e #1523を発行し、仕入先Bもシリーズ001でNF-e #1523を発行する可能性がある。同じ仕入先でも、異なるシリーズで同一の請求書番号を発行することがある。グローバルに一意な識別子は44桁のchave de acessoだが、ほとんどのバッチ抽出ツールはこれを抽出しないか、重複排除キーとしての役割を理解せずに抽出する。chave de acessoがないと、異なる仕入先からの同一請求書番号の2つの異なる請求書が重複としてフラグされ、1つが抑制される。さらに悪いことに、修正されたchave de acesso（CCe訂正イベントを示す）で再送信された請求書が、差し替えとして認識されない。

混合フォーマットのソース。 50件のブラジル仕入先請求書のバッチでは、50件のクリーンなXMLが得られることは稀だ。一部の仕入先（通常は中小メーカーや農業生産者）は、印刷されたDANFEのみをPDFまたはスキャンで送付する。XMLを送付するが、手書き注釈が入ったスキャンDANFEを添付する仕入先もいる。中規模の産業仕入先は、主要なNF-eのXMLを送付するが、運送CT-e（Conhecimento de Transporte Eletrônico）はPDFで送付する場合がある。バッチ処理ワークフローは、これらすべてを1回のパスで処理し、XMLから構造化データを抽出（利用可能な場合）、XMLがない場合はビジュアルドキュメントを読み取り、すべてを一貫した列に統合する必要がある。

これらの4つの問題は、1件の請求書では発生しない。50件になると、4つすべてが同時に発生する。これらを解決することが、バッチ処理ワークフローを「単一抽出を50回繰り返す」ことから差別化するポイントである。

7州にわたるICMS税率マトリックス — なぜ1つの「税」列では機能しないのか

2024年、ブラジルのICMS内部税率は大きく変動しました。これは、2029年から2033年にかけてICMSを新税IBS（Imposto sobre Bens e Serviços）に置き換える税制改革を見越した動きでもあります。昨年、ブラジルの11州が標準ICMS税率を変更しました。

州 (UF)	前回の税率	2024～2026年の税率	発効日
ペルナンブーコ州	18%	20.5%	2024年1月
セアラー州	18%	20%	2024年1月
パライバ州	18%	20%	2024年1月
バイーア州	19%	20.5%	2024年2月
マラニョン州	20%	22%	2024年2月
パラナ州	19%	19.5%	2024年3月
ゴイアス州	17%	19%	2024年4月
ロンドニア州	17.5%	19.5%	2024年1月
連邦直轄区	18%	20%	2024年1月
エスピリトサント州	17%	19.5%	2024年4月
リオグランデドノルテ州	20%	18%	2024年1月

出典：Vertex Inc.、各州立法（Leis Estaduais）。サンパウロ州は18%、ミナスジェライス州は18%、リオデジャネイロ州は20%（同期間中、22%への引き上げ案は議会で審議中）。

バッチ処理における実際の影響：仕入先がブラジル国内の2州以上にまたがる場合、バッチスプレッドシートではICMSを「税率×州×取引タイプ」レベルで管理する必要があります。すべてのICMS値を合計する単一の列では不十分です。ペルナンブーコ州（州内20.5%）の仕入先からのNF-eと、サンパウロ州（州内18%）の仕入先からのNF-eでは、ICMS金額欄に同じ値が表示されていても、ERP上でのICMS処理が異なります。

州間税率は、ブラジル税法に基づき、第二の側面を加えます。

発地地域	着地地域	州間税率
南部・南東部（SP、RJ、MG、PR、SC、RS、ES）	南部・南東部	12%
北部・北東部・中西部	全ブラジル州	12%
南部・南東部	北部・北東部・中西部（ES含む）	7%
全州 — 外国含有率40%超の輸入品	全州	4%

これらの州間税率区分と上記11の州レベルの税率変更を組み合わせると、7州の仕入先からのNF-e XMLのバッチには、5種類もの異なるICMS税率が含まれる可能性があります。それぞれを特定し、種類ごとに分類し、ERPの正しい税勘定に転記する必要があります。ICMSを単一の数値として抽出し、XMLから税率、発地州、取引種類を取得しないツールは、節約する以上に調整作業を増やすスプレッドシートを生成します。

NF-e XMLの構造から直接データを抽出する（DANFEのOCRではない）ことで、大量処理において真価が発揮されます。XMLの<imposto>ブロックには、ICMS、IPI、PIS、COFINSそれぞれの要素グループが含まれており、各行明細レベルで課税ベース（vBC）、税率（pICMS、pIPIなど）、金額（vICMS、vIPIなど）が定義されています。これらの構造化フィールドを「ICMS課税ベース」「ICMS税率（%）」「ICMS金額」「IPI金額」「PIS金額」「COFINS金額」としてスプレッドシートの各列にマッピングする列名ベースの抽出により、すべての税額を税率と課税ベースに遡って確認できる表が生成され、手動での再計算は不要です。NF-e XMLの構造とフィールドマッピングの詳細については、NF-e XML抽出ガイド（完全版）をご参照ください。

サプライヤー間のCFOPコード整合性 — バッチ処理で誰もチェックしない監査フラグ

CFOPコードは、すべてのNF-e明細行に埋め込まれた4桁の会計操作区分です。ブラジル税務当局によって定義されたCFOPコードは500以上あり、先頭の桁で分類されます。

先頭桁	意味	例（購入）
1	州内取引（同一州）	1.101 – 工業化のための購入
2	州間取引（異なる州）	2.102 – 再販のための州間購入
3	国際輸入	3.101 – 工業化のための輸入
5	州内販売（売上）	5.101 – 自社生産品の販売
6	州間販売（売上）	6.102 – 第三者の商品の州間販売
7	輸出	7.101 – 自社生産品の輸出

1枚のNF-eの中であれば、CFOPの不一致は簡単に見つかります。供給元がミナスジェライス州で、自社がサンパウロ州にある場合、すべてのCFOPコードは2（州間の入庫）で始まるべきです。明細にCFOP 1.101（州内）が表示されていれば、データエラーです。しかし、複数の供給元からの50枚の請求書という規模になると、この種の検証は不可欠であり、かつ簡単ではありません。供給元が自社の地元顧客への出荷には正しくCFOP 1.101を使用していても、州をまたいで自社に出荷する際には2.101を使用すべきです。供給元のERPが誤ったCFOPを自動入力した場合、SPED EFDが検出する監査上のリスクを自社が引き継ぐことになります。なぜなら、デジタル帳簿システムはすべての取引について、買い手側と売り手側のCFOP記録を相互参照するからです。自社の入庫CFOP記録と供給元の対応する出庫記録との間に不一致があると、自動的に監査フラグが生成されます。

バッチCFOP検証とは、バッチ内のすべての明細について、以下の3つの関係をチェックすることを意味します。

第一桁と州ペアの一致。 CFOPの第一桁は、仕入先と買手が同一州（1/5）か異なる州（2/6）かと一致しなければなりません。<emit>ブロックと<dest>ブロックの両方からIBGE州コード（35（SP）、33（RJ）、31（MG）、41（PR）など）を抽出し、同一州/異州の判定に基づいてCFOPの接頭辞を検証します。
類似取引におけるCFOPサフィックスの一貫性。 仕入先Aが同一製品に対してCFOP 2.102（州間の再販目的購入）を使用し、仕入先BがCFOP 2.101（州間の工業化目的購入）を使用している場合、少なくとも一方は誤りです。CFOPのサフィックスは取引の実際の事業目的を反映しなければなりません。
CFOPとNCMの矛盾の禁止。 CFOPは取引の性質を、NCMは製品分類をコード化します。工業用投入材を示すCFOPと完成消費財のNCMが組み合わされている場合は要注意です。これはCFOPかNCMのいずれかが誤りであり、両方が税務処理に影響することを意味します。

50件のNF-e明細行（各行に2～15明細、それぞれ独自のCFOPを持つ）を手動でCFOP検証すると、半日かかりエラー率も高くなります。CFOP、NCM、仕入先州、買手州を別々の列に抽出する一括抽出を行えば、単純な条件チェック（emitの州 ≠ destの州かつ CFOP接頭辞 ≠ 2 の場合、その行にフラグを立てる）を実行できます。この1つのルールで、複数仕入先バッチにおけるCFOPエラーの80%を捕捉できます。

44桁のアクセスキー — ほとんどのバッチツールが無視する、ブラジル標準の重複排除キー

chave de acesso は、ブラジルで発行されるすべての NF-e を一意に識別する 44 桁の文字列で、永久に有効です。単なる参照番号ではなく、発行州（最初の 2 桁、IBGE コード準拠）、発行年月（次の 4 桁）、発行者の CNPJ（次の 14 桁）、文書モデル（2 桁）、シリーズ（3 桁）、連番（9 桁）、発行タイプ（1 桁）、ランダム衝突防止コード（8 桁）、モジュロ 11 チェックデジット（1 桁）をエンコードした構造化識別子です。すべての NF-e XML は、このキーを <infNFe Id="NFe[chave]"> 属性と <chNFe> 要素に保持します。これは、世界中のどの税システムでも、グローバルに一意な請求書識別子に最も近いものです。

しかし、ほとんどのバッチツールは「請求書番号」列を抽出して終わりにしています。ブラジルでは、その列だけでは不十分です：

サプライヤー A がシリーズ 001 で NF-e #1523 を、シリーズ 002 で NF-e #1523 を発行する場合 — 同じ請求書番号でも、まったく異なる 2 つの税務文書であり、シリーズと chave de acesso でのみ区別可能です。
サプライヤー B が自社のシリーズ 001 で NF-e #1523 を発行する場合 — サプライヤー A と同じ請求書番号でも、異なるサプライヤー、異なる取引であり、単純なベンダー＋請求書番号の重複チェックでは、一方が重複として抑制されます。
SEFAZ の取消・訂正システムは chave de acesso に依存しています。サプライヤーが元の NF-e の誤記を修正するために Carta de Correção (CCe) を発行した場合、元の chave de acesso は有効のままですが、その chave に紐づくイベント履歴に訂正が記録されます。chave を追跡しないバッチツールは、原本と訂正版を区別できません。

50 件の NF-e XML のバッチでは、chave de acesso を独自の列として抽出します。次に、3 つのチェックを実装します：

バッチ内での一意性。 同一の chave de acesso を持つ行が2つ以上あってはなりません。もし存在する場合、同じNF-eが2回アップロードされたことを意味します。重複行を抑制し、その発生をフラグ付けしてください。
仕入先 × シリーズ内でのインボイス番号の一意性。 CNPJ + シリーズ + インボイス番号でグループ化します。同じ組み合わせが異なる chave de acesso で2回出現した場合、そのうちの1つは訂正版である可能性が高いです。発行タイムスタンプがより新しい chave が優先されます。
高額インボイスのSEFAZ検証。 重要性の基準額を超えるインボイスについては、chave de acesso を使用してSEFAZの公開照会ポータル、またはTF FiscalのNF-e検索のようなサードパーティAPIに問い合わせ、承認ステータス（Autorizada/Cancelada/Denegada）を確認してください。バッチ内に取消済みのNF-eがある場合、仕入先が再発行したことを意味します。その場合は、差し替え後の chave が必要です。

44桁の数字は、ブラジル以外の買掛金担当者には気が遠くなるように感じられます。しかし、これらは世界のどの電子請求書制度においても、最も信頼性の高い重複排除キーです。バッチ処理でこれを使用しないのは、社会保障番号があるのに、人の識別を名前だけで行うようなものです。

手入力をやめよう — AIに読み取らせるだけ

画像やPDFをアップロード — 10秒で構造化データに

今すぐ試す →

登録不要 · カード不要 · 10秒で結果

XML + DANFE 混在バッチ — 一部の仕入先が完全なインボイスを送信し、他の仕入先は紙のみを送信する場合

大規模なブラジルの仕入先、特にSAP、TOTVS Protheus、Oracleを稼働させている産業メーカーや流通業者は、NF-e XMLを日常的に送信します。これはERPで生成され、ICP-Brasil証明書で署名され、SEFAZに自動送信されます。DANFEと一緒に買い手に送信するのはワンクリック操作です。

小規模な供給元（農業協同組合、地域のサービス事業者、一部の建設資材サプライヤーなど）は、XML伝送を管理するERP基盤を持たない場合があります。彼らはDANFEを印刷し、トラック運転手に手渡すだけで、買い手が目にする書類はそれだけです。請求書は実在し、SEFAZによる承認（承認プロトコルはDANFEに印刷されています）も得られていますが、受け取り側の買掛金部門が手にするのは、紙の書類をスキャンしたPDFか写真だけです。

XMLのみ、またはPDFのみを処理するバッチ買掛金ワークフローでは、買掛金チームは毎月の請求書受付を、構造化XML用とスキャンDANFE用の2つの別々の処理パイプラインに分割し、その出力を手動で統合して1つの総勘定元帳エントリにする必要があります。この断片化によるコストは現実的です。別々のアップロードセッション、別々のレビューパス、そして最後に、同じ供給元からの請求書（一部はXML、一部はPDF）がすべて同じ買掛金バッチに収まるようにするための照合ステップが必要になります。

カスタム列抽出 — ImageToTable.aiのアプローチは、テンプレートの座標ではなくフィールドの意味に基づいてデータを抽出するもので、両方のソースを1回のバッチアップロードで処理します。列名を一度定義するだけです。「Chave de Acesso」「Supplier CNPJ」「Supplier Name」「NF-e Number」「Series」「Issue Date」「CFOP」「NCM」「Line Item Description」「Quantity」「Unit Price」「Line Total」「ICMS Base」「ICMS Rate」「ICMS Amount」「IPI Amount」「PIS Amount」「COFINS Amount」「Total NF-e Value」。AIは、フィールドが機械可読であるXMLファイルから構造化データを読み取り、スキャンされたDANFE PDFからは、レイアウトに関係なく各ラベルの視覚的な意味を理解して同じフィールドを抽出します。両方のソースは、同じ列を持つ同じスプレッドシートに、1回のバッチで統合されます。

実用的な利点は速度だけではありません。一貫性です。XMLファイルのchave de acesso列は、<chNFe>要素から直接抽出されます。DANFEスキャンからの同じ列は、印刷文書の右上隅にある44桁のバーコード領域から読み取られます。両方のエントリが同じ列に格納されるため、前述の重複排除ロジックが適用可能になります。統一されたバッチワークフローがなければ、XMLバッチのchave de acessoとスキャンされたDANFEバッチのchave de acessoは別々のスプレッドシートに格納され、それらの間の重複検出は手動で行われます。

2026～2033年の税制改革移行期間 — 単一バッチでの二重コンプライアンス

ブラジルの消費税改革は、2023年12月の憲法修正第132号により制定され、2025年1月の補完法第214号により規制され、8年間の移行期間をかけて国の間接税制度全体を再構築しています。2033年までに、5つの既存税（PIS、COFINS、IPI、ICMS、ISS）は、連邦CBS（Contribuição sobre Bens e Serviços）と州・市町村IBS（Imposto sobre Bens e Serviços）からなる二重VAT制度と、健康および環境に有害な商品に対する選択税（IS）に置き換えられます。移行は2026年1月1日に開始されました。

ブラジルのNF-eバッチを処理するAPチームにとって、当面の運用上の懸念はXMLスキーマにおける二重コンプライアンスです。移行期間中、NF-e XMLは既存の税フィールド（ICMS、IPI、PIS、COFINS）と新しい税フィールド（CBS、IBS）を同時に保持することになります。つまり、すでに500以上のフィールドを持つ複雑なNF-e XMLは、さらに大きくなろうとしています。以下は、バッチ抽出設計に影響を与えるタイムラインです。

年	旧税制の状況	新税制の状況	一括抽出への影響
2026	ICMS、PIS、COFINS、IPI すべて有効	CBS 0.9% + IBS 0.1% テスト税率（PIS/COFINSから控除可能、純負担増なし）	NF-e XMLスキーマに、従来の税項目に加えてCBS/IBSフィールドが追加。テスト税率が純税負担を変えなくても、抽出では両方を解析する必要あり。
2027	PIS、COFINS廃止。ICMS、IPIは存続。	CBSが本税率で完全施行	NF-e XMLからPIS/COFINSグループが削除され、ICMS/IPIは残り、CBSが追加。一部の供給元では年度途中で列定義が変更。
2029–2032	ICMS税率が年10%ずつ低下（2029年90%→2032年60%）。ISSとIPIも段階的に縮小。	IBS税率が比例的に上昇（2029年10%→2032年40%）	ICMS税率の列値は年々減少。IBS列値は増加。年度をまたぐ比較には、税率の年タグ付けが必要。
2033	ICMS、ISS、IPI廃止	CBS + IBS 完全運用	NF-e XMLにはCBS + IBS税グループのみ。完全移行だが、監査用の過去データは旧構造を保持。

2026年のバッチ抽出における実務上の含意：今、列定義を構築しているのであれば、ICMSやPIS/COFINSの列とともに、CBSとIBSの列も（テストレートであっても）含めておくこと。データは今日のXMLにすでに存在している。抽出にコストはかからない。2027年に移行が加速したときに、あなたのスプレッドシートにそのデータがあれば、2026年分のアーカイブされたNF-e XMLを遡って再抽出することなく、過去のバッチデータにはすでにCBSベースの報告の基盤が含まれていることになる。

「ICMS Base」「ICMS Rate」「CBS Base」「CBS Rate」などのフィールド名を意味的に読み取るバッチ抽出システムは、サプライヤーごとの再設定なしでこの移行を処理する。列定義は同じままで、AIが現在のXMLスキーマバージョンに存在する税フィールドを自動的に見つける。今後7年間にNota Técnicaの更新で新しいフィールドが追加され古いものが廃止されるにつれて、抽出ロジックは、SEFAZが新しいレイアウトバージョンを公開するたびに再構築しなければならないテンプレートではなく、到着するXMLに適応する。

月末を乗り切るバッチNF-e処理ワークフロー

構造的な問題を把握したところで、複数サプライヤー・複数州のブラジルAPの現実に合わせて設計されたバッチ処理シーケンスを紹介する。

1
ソースファイルを収集・統一します。バッチ期間（通常は月次）のNF-e XML、DANFE PDF、CT-e運送書類をすべて収集します。ファイル名を {CNPJ}_{NF-e番号}_{シリーズ}_{発行日}.xml という統一規則にリネームし、ファイル名にソースのトレーサビリティを組み込みます。元のファイル名は破棄せず、メタデータとして付加してください。
2
全サプライヤー共通の抽出列を一度定義します。必要なNF-eデータを網羅する列名を設定します：サプライヤー識別子（CNPJ、Razão Social、Inscrição Estadual）、文書識別子（Chave de Acesso、Número、Série、Data de Emissão）、明細項目（NCM、CFOP、Descrição、Quantidade、Preço Unitário、Total da Linha）、税金（Base ICMS、Alíquota ICMS、Valor ICMS、Valor IPI、Base PIS、Valor PIS、Base COFINS、Valor COFINS、Valor Total da NF-e）。2026年の移行に備え、CBSおよびIBSの列も含めてください。これらの列名は、フィールドの位置ではなく意味に基づいて抽出を行うため、全サプライヤーで機能します。これは、異なるサプライヤー形式の請求書データをExcelに一括抽出する際と同じアプローチです。
3
バッチ全体を一度にアップロードします。XML、PDF、スキャン文書など50ファイルすべてをアップロードエリアにドラッグします。システムがまとめて処理し、出力を1つのスプレッドシートに統合します。各行にはトレーサビリティのためソースファイル名がタグ付けされます。
4
3つのバッチ固有検証を実行します。 (a) アクセスキーの一意性チェック — 重複なし。(b) CFOPの先頭桁と州のペア — 州内取引用CFOP（1xxx）が州間取引で使用されている場合に不一致を検出。(c) ICMS税率の妥当性 — 抽出された税率と期待される州税率を比較。サンパウロの仕入先で20.5%のICMS（州内18%、州間7～12%）は、ペルナンブコ州の仕入先の誤分類かデータエラーです。確認用にフラグを立てます。
5
税区分ごとに仕分けてERPに転記します。 抽出されたICMS税率と原産州の列を使用して、行を転記バッチにグループ化します。州内取引（税率17～22%）、12%の州間取引、7%の州間取引、4%の取引（輸入品）です。各グループはERP内の異なる税勘定に転記されます。同じグループ化ロジックがIPI、PIS、COFINSの列にも適用されます。

このワークフローは、バッチ抽出ツールが同じアップロードセッションでXMLとビジュアル文書の両方を処理できることを前提としている。ブラジルAPが1つの形式のみを受け取ることは稀だからだ。現在のプロセスでXML解析とPDF OCRに別々のワークフローが必要な場合、ステップ5のマージ工程で処理時間が2倍になり、2つのパイプライン間で列マッピングに不整合が生じるリスクが生じる。

よくある質問

バッチ処理でNF-e XMLとDANFE PDFを同じアップロードで処理できますか？

はい — 抽出ツールがXML解析のみに依存せず、セマンティックに読み取る場合に可能です。セマンティック抽出では、NF-e XMLの構造化タグから両形式に存在するデータ（CNPJ、NF-e番号、合計、税額）を読み取り、印刷文書のみが利用可能な場合はDANFEを視覚的に読み取ります。出力は一貫した列を持つ1つのスプレッドシートに統合されます。ツールがXML解析のみ、またはOCRのみを行う場合、2つの別々のワークフローと手動でのマージ手順が必要になります。

2つのNF-e XMLが同じ請求書番号でも異なるchave de acessoを持つ場合はどうなりますか？

これは正当なシナリオです — 通常、CCeイベント後に再発行された修正済みNF-e、または異なるシリーズで同じ連番を持つ2つのNF-e文書です。chave de acessoはどちらの場合も一意です。バッチ検証では、重複排除のために請求書番号ではなくchave de acessoでグループ化し、監査目的で請求書番号、シリーズ、chaveの関係を保持する必要があります。同じCNPJ + シリーズ + 請求書番号が2つの異なるchave de acessoで表示される場合は、発行タイムスタンプを確認してください — 後のchaveが前のものを無効にします。

バッチでICMS-ST（税代替）を処理するにはどうすればよいですか？

ICMS-STは、NF-e XML内で独自の基準、税率、金額を持つ別の税グループ（合計ブロックの<ICMSTot>）として表示されます。これは通常のICMSと統合せず、「ICMS-ST基準」「ICMS-ST金額」などの別の列に抽出する必要があります。ICMS-STは代替納税者によって上流で既に支払われた税金を表し、ERPではクレジット目的で通常のICMSとは異なる扱いをします。これらを1つの「ICMS」列に混在させると、利用可能なクレジットが過大表示されます。

NF-eからすべての明細ではなく、特定の明細のみを抽出できますか？

はい。抽出列を定義する際に、明細レベルで必要なフィールド（NCM、CFOP、品目、数量、単価、明細合計、明細ごとの税額）を含めてください。AIは、列定義に一致するすべてのNF-eからすべての明細を抽出します。単価なしでNCM＋数量＋CFOPのみが必要な場合は、不要な列を定義から除外してください。抽出では、指定したものだけが出力されます。

2026年の税制改革により、NF-e XMLから抽出する項目は変わりますか？

2026年には、NF-e XMLスキーマに、既存のICMS、PIS、COFINSフィールドに加えて、テスト税率（それぞれ0.9％と0.1％）でのCBSおよびIBSフィールドが含まれます。これらのテスト税率はPIS/COFINSから全額控除可能であるため、正味の税負担は変わりません。ただし、これらのフィールドはXMLに存在するため、今すぐ抽出する必要があります。2027年にCBSが完全な税率でPIS/COFINSに取って代わるときには、バッチ抽出の列定義がすでに整っているでしょう。税制改革のタイムラインは、補完法214/2025およびOECDの2025年の改革分析に規定されています。

NF-e XMLと抽出記録はどのくらいの期間保管する必要がありますか？

ブラジルの税法では、NF-e XMLおよび関連する税務文書は、取引が発生した会計年度の終了から最低5年間保管することが義務付けられています。これは、サプライヤーから受け取った元のXMLと抽出記録の両方に適用されます。監査において、DANFEはXMLの法的に十分な代替物とはなりません。スキャンしたDANFEのみを保管し、XMLを破棄した場合、SEFAZが要求する完全な税務記録を再構築することはできません。ベストプラクティス：XMLはそのままアーカイブし、抽出スプレッドシートは内部照合用の個別の検索可能な記録として維持してください。