ブラジルのNF-e XML 50件を1つのスプレッドシートに
マルチサプライヤーのバッチ処理で手動の税務照合を排除する方法
サンパウロのサプライヤーからのNF-eを1件処理するのに3分かかります。XMLはクリーンで、フィールドは明確で、ICMS税率も州内取引の18%と想定どおりです。問題が始まるのは、7つのブラジルの州にまたがる14社のサプライヤーからNF-e XMLを50件受け取ったときです。パラナ州のサプライヤー3社は、州内出荷には19.5%のICMSを適用しますが、サンパウロへの出荷には12%を適用します。ペルナンブコ州のサプライヤー8社は20.5%を請求します — ただし、NCM 8471.30に分類される品目は軽減税率が適用されます。サプライヤー11社はXMLではなくDANFEのPDFを送ってきました。そして、バッチのどこかで、サプライヤー2社が会計年度の開始時に番号体系をリセットしたため、2つの異なるNF-e文書が同じ請求書番号を共有しています。NF-eを1件抽出するのは簡単です。しかし、50件を抽出して、各行の税務処理が検証可能なクリーンで監査可能なAPスプレッドシートを作成する — それはまったく別の問題です。
NF-e XMLが50件届いたとき — バッチ処理が「単品処理の50回繰り返し」ではない理由
ブラジルのNF-e処理には、他に類を見ない特徴があります。それは、ソースデータがすでに構造化されていることです。米国や欧州のベンダーからの紙の請求書はOCRによるデジタル化が必要ですが、NF-eはすべて、SEFAZの400以上のルールに照合して検証され、ICP-Brasil証明書でデジタル署名されたXMLファイルとして届きます。単一のNF-e XMLのデータ品質はほぼ完璧です。ブラジルのAPにおけるバッチ処理の問題は、データ取得の精度ではなく、サプライヤー間のデータの一貫性です。
14社のサプライヤーから50件のNF-e XMLを1つのバッチで処理する場合、単一請求書の処理では決して表面化しない4つの構造的な問題が発生します。
ICMS税率の断片化。ブラジルのICMSは州レベルの付加価値税であり、税率はサプライヤーの州、自社の州、取引の方向（州内か州間か）、場合によってはNCM製品分類によって異なります。7つの州のサプライヤーからの50件のNF-e XMLのバッチには、17%、18%、19%、19.5%、20%、20.5%の州内税率に加え、発地と着地の組み合わせに応じて4%、7%、12%の州間税率が含まれる可能性があります。スプレッドシートの「ICMS金額」列は、税率、該当する州、取引が州内か州間かを把握していなければ意味がありません。同じR$1,000のICMS課税額でも、R$5,882の課税標準に対する17%の税率か、R$8,333の課税標準に対する12%の税率かを意味し得るからです。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件のバッチでは、きれいなXMLが50件そろうことはめったにありません。一部の仕入先（通常は中小メーカーや農業生産者）は、印刷された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税率マトリックス — 単一の「税」列が機能しない理由
ブラジルのICMS内部税率は、2024年に大幅に変更されました。これは、税制改革を見据えたもので、税制改革により2029年から2033年の間にICMSは最終的に新しいIBS（Imposto sobre Bens e Serviços）に置き換えられます。ブラジルの11州が昨年、標準ICMS税率を変更しました。
| 州 (UF) | 従来の税率 | 2024–2026年の税率 | 適用開始日 |
|---|---|---|---|
| Pernambuco | 18% | 20.5% | 2024年1月 |
| Ceará | 18% | 20% | 2024年1月 |
| Paraíba | 18% | 20% | 2024年1月 |
| Bahia | 19% | 20.5% | 2024年2月 |
| Maranhão | 20% | 22% | 2024年2月 |
| Paraná | 19% | 19.5% | 2024年3月 |
| Goiás | 17% | 19% | 2024年4月 |
| Rondônia | 17.5% | 19.5% | 2024年1月 |
| Distrito Federal | 18% | 20% | 2024年1月 |
| Espírito Santo | 17% | 19.5% | 2024年4月 |
| Rio Grande do Norte | 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から取得しないツールは、節約する以上に照合作業を生み出すスプレッドシートを作成していることになります。
ここで、DANFEのOCRではなく、NF-e XMLの構造から直接抽出することが、バッチ処理で効果を発揮します。XMLの<imposto>ブロックには、ICMS、IPI、PIS、COFINSの各要素グループが含まれており、それぞれ明細行レベルで課税ベース（vBC）、税率（pICMS、pIPIなど）、金額（vICMS、vIPIなど）が含まれています。これらの構造化フィールド（「ICMS Base」「ICMS Rate (%)」「ICMS Amount」「IPI Amount」「PIS Amount」「COFINS Amount」）を個別のスプレッドシート列にマッピングする列名ベースの抽出により、すべての税額が税率とベースに遡って追跡できるテーブルが生成され、手動での再計算は不要です。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 – 自社製品の輸出 |
単一の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明細に対する手動CFOP検証は、各明細に2〜15の品目があり、それぞれに独自のCFOPが含まれるため、半日かかる作業であり、エラー率も高くなります。CFOP、NCM、仕入先の州、購入先の州を別々の列に抽出するバッチ抽出により、単純な条件チェックを実行できます。発行州 ≠ 宛先州 かつ CFOPプレフィックス ≠ 2 の場合、その行にフラグを立てます。この1つのルールで、複数仕入先バッチにおけるCFOPエラーの80%を検出できます。
44桁のChave de Acesso — ブラジル標準の重複排除キーでありながら、ほとんどのバッチツールが無視するもの
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>要素に含まれています。これは、世界のどの税制システムが提供するものよりも、グローバルに一意な請求書識別子に最も近いものです。
しかし、ほとんどのAPバッチツールは「請求書番号」列を抽出して完了とします。ブラジルでは、その列だけでは不十分です：
- 仕入先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つのチェックを実装します：
- バッチ全体での一意性。 2つの行が同じ chave de acesso を共有してはなりません。共有している場合、同じ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桁は、ブラジル国外の買掛金担当者には気が遠くなるように感じられます。しかし、これは世界のどの電子請求書制度においても、最も信頼性の高い重複排除キーです。バッチ処理でこれを使用しないのは、社会保障番号を持っているのに、人の名前で人を識別しているようなものです。
XML + DANFE 混合バッチ — 一部の仕入先が完全なインボイスを送信し、他の仕入先は紙のみを送信する場合
大手のブラジル仕入先 — 特にSAP、TOTVS Protheus、またはOracleを実行している産業メーカーや販売代理店 — は、NF-e XMLを日常的に送信します。これはERPによって生成され、ICP-Brasil証明書で署名され、SEFAZに自動送信されます。DANFEと一緒に購入者に送信するのはワンクリック操作です。
小規模な仕入先 — 農業協同組合、地元のサービスプロバイダー、一部の建設資材サプライヤー — は、XML送信を管理するERPインフラストラクチャを持っていない場合があります。彼らはDANFEを印刷し、トラックの運転手に渡し、それが購入者が受け取る唯一の文書です。インボイスは本物で、SEFAZによって承認されています（承認プロトコルはDANFEに印刷されています）が、受け取る買掛金部門はスキャンされたPDFまたは紙の文書の写真しか持っていません。
XMLのみ、またはPDFのみを処理するバッチAPワークフローでは、APチームは月次のインボイス受領を2つの別々の処理パイプラインに分割する必要があります — 1つは構造化XML用、もう1つはスキャンされたDANFE用 — そして、出力を1つの総勘定元帳エントリに手動でマージする必要があります。断片化コストは現実のものです：別々のアップロードセッション、別々のレビューパス、そして最後に同じ仕入先からのすべてのインボイス（一部はXML、一部はPDF）が同じAPバッチに含まれることを確認するための照合ステップが必要です。
カスタム列抽出 — 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年の税制改革移行期 — 単一バッチでの二重コンプライアンス
ブラジルの消費税制改革 — 憲法改正132号（2023年12月）および補足法214（2025年1月）によって制定され、8年間の移行期間を経て国の間接税制度全体を再構築しています。2033年までに、5つの従来税（PIS、COFINS、IPI、ICMS、ISS）は二重VATシステムに置き換わります：連邦のCBS（Contribuição sobre Bens e Serviços）と州・市のIBS（Imposto sobre Bens e Serviços）、さらに健康・環境に有害な商品に対する選択税（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処理ワークフロー
構造上の問題を把握したところで、複数仕入先・複数州にわたるブラジルの買掛金管理の実態に対応したバッチ処理手順をご紹介します。
- 1ソースファイルを収集・正規化します。バッチ期間（通常は月次）のすべてのNF-e XML、DANFE PDF、CT-e運送書類を収集します。ファイル名を一貫した規則 —
{CNPJ}_{NF-eNumber}_{Series}_{IssueDate}.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バッチ全体を1回のセッションでアップロードします。50ファイルすべて — XML、PDF、スキャン — をアップロードエリアにドラッグします。システムはそれらをまとめて処理し、出力を1つのスプレッドシートにマージします。各行にはトレーサビリティのためソースファイル名がタグ付けされます。
- 4バッチ固有の3つの検証を実行します。（a）Chave de acessoの一意性チェック — 重複なし。（b）CFOPの先頭桁と州のペア — 州内取引のCFOP（1xxx）が州間取引に出現する不一致をフラグ付けします。（c）ICMS税率の妥当性 — 抽出された税率を期待される州税率と比較します。サンパウロのサプライヤー（州内18%、州間7〜12%）に対する20.5%のICMSは、ペルナンブコのサプライヤーの誤分類またはデータエラーのいずれかです。レビュー用にフラグを立てます。
- 5ERP転記用に税務処理別に分類します。抽出されたICMS税率と原産州の列を使用して、行を転記バッチにグループ化します：州内エントリ（税率17〜22%）、12%の州間エントリ、7%の州間エントリ、および4%のエントリ（輸入品）。各グループはERPの異なる税勘定に転記されます。同じグループ化ロジックがIPI、PIS、COFINS列にも適用されます。
このワークフローは、バッチ抽出ツールが同じアップロードセッションでXMLとビジュアル文書の両方を処理できることを前提としています — ブラジルのAPが単一形式のみを受け取ることはほとんどないためです。現在のプロセスでXML解析用とPDF OCR用に別々のワークフローが必要な場合、ステップ5のマージステップで処理時間が2倍になり、2つのパイプライン間で列マッピングの不整合が生じるリスクが発生します。
よくある質問
バッチ処理でNF-e XMLとDANFE PDFを同じアップロードで処理できますか？
はい — 抽出ツールがXML解析のみに依存せず、セマンティクスを読み取る場合に可能です。セマンティック抽出は、両方の形式に存在するデータ（CNPJ、NF-e番号、合計額、税額）についてNF-e XMLの構造化タグを読み取り、印刷文書のみが利用可能な場合はDANFEを視覚的に読み取ります。出力は一貫した列を持つ1つのスプレッドシートに統合されます。ツールがXML解析のみ、またはOCRのみを行う場合は、2つの別々のワークフローと手動での統合手順が必要になります。
2つのNF-e XMLが同じインボイス番号でも異なるアクセスキーを持つ場合はどうなりますか？
これは正当なシナリオです — 通常はCCeイベント後に再発行された修正済みNF-e、または同じ連番を持つ異なるシリーズの2つのNF-e文書です。アクセスキーはどちらの場合も一意です。バッチ検証では、重複排除のためにインボイス番号ではなくアクセスキーでグループ化し、監査目的でインボイス番号、シリーズ、キーの関係を保持する必要があります。同じCNPJ + シリーズ + インボイス番号が2つの異なるアクセスキーで表示される場合は、発行タイムスタンプを確認してください — 後のキーが前のキーに優先します。
バッチでICMS-ST（税額控除）をどのように処理しますか？
ICMS-STはNF-e XML内で独立した税グループ（合計ブロックの<ICMSTot>）として表示され、独自の課税基準、税率、金額を持ちます。これは「ICMS-ST課税基準」「ICMS-ST金額」という別々の列に抽出する必要があります — 通常のICMSと統合しないでください。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フィールドに加えて、CBSおよびIBSフィールドがテスト税率（それぞれ0.9%および0.1%）で含まれるようになります。これらのテスト税率は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をそのままアーカイブし、抽出スプレッドシートを内部照合用の独立した検索可能な記録として維持してください。