複数都市のNFS-eを1つのスプレッドシートに：
自治体テンプレート不要の一括処理

NFS-eのバッチ処理が単一文書抽出と異なる問題である理由

単一NFS-e抽出ガイドをお読みになった方は、核となる仕組みをご存じでしょう。セマンティック抽出は、各フィールドの意味を理解することでNFS-eを読み取ります。「Prestador」というラベルの隣にある14桁のサービス提供者CNPJ、ISSセクションの下にあるISS課税標準額、市庁が印刷した場所にあるISS税率を特定します。文書1件につき、列定義が1セット、出力行が1行です。市区町村ごとの差異の問題は、文書レベルで解決されます。

バッチ処理では、単一文書抽出では表面化しない別の種類の課題が生じます。サンパウロ（ITコンサルティングでISS 5%）、リオデジャネイロ（同じサービスでISS 5%）、ベロオリゾンテ（ISS 3%）、クリチバ（ISS 4%）、その他6つの市区町村のサービス提供者からのNFS-e 30件を1つの処理キューに入れると、単一文書では決して起こらない3つのことが発生します。

第一に、市区町村間のISS税率検証が必要になります。単一のNFS-eでISS 3%は、単独では問題なく見えます。しかし、同じサービスコード（項目1.01 — システムの分析と開発）が、同じバッチ内でサンパウロから5%、リオから5%、ベロオリゾンテから3%で出現しているのを見ると、ベロオリゾンテの税率がすぐに目立ちます。ベロオリゾンテは独自の税率を設定しているため、正しいかもしれません。あるいは、サービス提供者が誤った市区町村税率を適用した可能性もあります。バッチレベルのビューだけが、これを発見する唯一の方法です。

第二に、源泉徴収ISSの追跡がバッチ規模のコンプライアンス業務になります。NFS-eに「源泉徴収ISS = あり」と記載されている場合、ISSを納付する義務はサービス提供者からサービス受領者であるあなたに移ります。発生のたびに、それぞれの納期限と納付システムを持つ関連市庁への個別の支払いが必要になります。複数の市区町村からの10件の文書にわたって、どの請求書がこの義務を発生させ、どの請求書が発生させないかを追跡することは、手動のチェックリストでは管理できません。

第三に、データ自体が集計時に価値を持ちます。サービス提供者別のISS合計、市区町村別のサービス支出、源泉徴収された税とサービス提供者が支払った税の比率 — これらはどれも1件の文書からは見えません。バッチ全体が1つのスプレッドシートに入ったときにのみ現れます。

これは単一文書ワークフローを高速化することではありません。単一文書ワークフローではまったくできないことを行うことです。

複数市にまたがるNFS-e処理が標準的な請求書バッチ処理と根本的に異なる点

標準的な請求書バッチ処理（米国や欧州の50社のサプライヤーからのPDF50件）は、主に量の問題です。請求書の見た目は異なりますが、基盤となる税務ロジックは一貫しています。すなわち、全国一律のVAT、州ごとの売上税、フィールドの位置やラベルもおおむね予測可能です。

ブラジルのNFS-eバッチ処理には、標準的な請求書バッチにはない構造的な層が加わります。ISSは補完法116/2003に基づく市税であり、各市が独自の税制を運用しているため、「ISS税率」という同じ論理フィールドでも、バッチ内の文書ごとに異なる値を持つ可能性があり、その値によってその文書の税額が正しく計算されているかが決まります。

ここで、多くの文書抽出ツールが採用するテンプレートベースの抽出が構造的に機能しなくなります。テンプレートは各フィールドの矩形領域を定義します。「サービス提供者CNPJはピクセル位置（x=150、y=320）にある」という具合です。これは1つの市では機能しますが、次の市では破綻します。提供者が事業を展開する可能性のあるすべての市のテンプレートライブラリを維持することは、対象となる市が5,570あり、レイアウトを積極的に更新している市（サンパウロ市は2025年8月にNFS-eマニュアルのバージョン3.2をリリース）が増え続けている状況では現実的ではありません。

その代わりとなるのがセマンティック抽出です。フィールドがページ上のどこにあるかを定義するのではなく、「Prestadorとラベル付けされた14桁のCNPJ」のように、抽出エンジンに何を探しているかを伝え、エンジンが文書を読んでそれを見つけます。エンジンは文書の内容を理解するのであって、座標を照合するのではないため、位置は重要ではありません。同じバッチ内のサンパウロのNFS-eとポルトアレグレのNFS-eは、AIが意味を探しているため、同じ列定義で処理されます。

セマンティック抽出が個々のNFS-eフィールド（CNPJ照合、LC 116サービスコード分類、ISS税額の内訳）をどのように処理するかの詳細については、単一NFS-e抽出ガイドを参照してください。バッチワークフローはそのすべてを継承し、複数文書のレイヤーを追加します。

セマンティック抽出で10都市のNFS-eを一括処理する方法

NFS-eの一括処理における抽出ワークフローは、カスタム列抽出が中心です。「提供者CNPJ」「サービスコード（LC 116）」「ISS税率」「ISS金額」「ISS源泉徴収（Retido na Fonte）」「NFS-e番号」など、出力したいフィールド名を入力するだけで、AIが各ラベルの意味を理解し、すべての書類から該当する値を特定します。これらの列名がスプレッドシートの見出しになります。一度定義すれば、バッチ内のすべての市区町村で機能します。

しかし、NFS-eの一括処理では、直接抽出以上のメリットがあります。さらに2つの列モードにより、別途スプレッドシートで作業しなくても、抽出時に複数都市間の調整が可能になります。

計算列では、抽出時に実行される検証ロジックを定義できます。NFS-eの一括処理で最も有用な計算列は、ISSの検証です。「ISS税率 × ISS課税標準 = ISS金額？」計算結果が抽出されたISS金額と一致すれば、列に「OK」と出力されます。一致しない場合は差異が出力され、データをERPにインポートする前に確認が必要な書類をバッチレベルで特定できます。1枚の書類でこのチェックを行うと30秒かかりますが、50枚の書類では計算列が自動的に処理し、抽出データと同じスプレッドシートで結果を確認できます。

推論列では、AIが書類の内容に基づいて分類やラベル付けを行います。特定のフィールドを指定せずに「市区町村（書類から抽出）」という列を追加すると、AIがNFS-eのプレフェイトゥラ（市役所）識別子を読み取り、市区町村名を自動入力します。これにより、バッチ出力に並べ替え可能な市区町村列が追加され、市区町村ごとのISS合計や税務報告が、手作業でのクロスリファレンスではなく、ピボットテーブルで簡単に作成できるようになります。

これら3つの列タイプ（直接抽出、計算、推論）は、1回のバッチ実行で連携して動作します。抽出してから検証するのではなく、抽出中に検証が行われ、その結果は同じスプレッドシートに出力されます。

ステップバイステップ：複数市区町村のNFS-eを1つのスプレッドシートに

複数のブラジル市区町村のNFS-e書類を一括処理し、1つのExcelファイルにまとめる実践的なワークフローです。この設定はバッチごとに1回行うだけで、どの市区町村の書類でも同じ列定義で処理できます。

複数市にまたがるISS照合：バッチ処理ならではの視点

NFS-eのバッチ処理で最も価値のある成果は、節約できた時間ではありません — 1枚あたり3分かかっていた処理が1ページあたり5〜10秒になるのは18倍の改善ですが、それ以上に価値があるのは、すべての文書が1つのテーブルにまとまったときだけ実現する照合ビューです。

このビューでできることのうち、単一文書処理では実現できないものをご紹介します。

市区ごとのISS合計額

出力を市区ごとにグループ化し、ISS額を合計します。これにより、各市区でのサービス購入に適用されたISSの合計額が得られます。このデータが重要な理由は2つあります。第一に、特定の市区における全サービス提供者のISS合計額が、その管轄区域に対する社内コスト配分と一致しているかどうかがわかります。第二に、これらの請求書のいずれかで源泉徴収義務者である場合、市区ごとの合計額は、市区の税納付記録と照合する必要がある数値です。Dentonsのグローバル税務ガイドは、「両方の市区がISSを主張している場合、異なる市区間の紛争は非常に一般的である」と指摘しています。バッチレベルのビューは、別の市区から問い合わせがあった場合の監査証跡となります。

源泉徴収ISSの追跡

NFS-eに「ISS Retido na Fonte = Sim」（源泉徴収されたISS）フラグが付いている場合、サービス提供者ではなく、あなたの会社がISSを提供者の市区に納付する責任を負います。これはデータ入力上のメモではなく、期限と市区ごとに異なる支払いシステムを伴う税務コンプライアンス上のアクション項目です。バッチ出力で「源泉徴収ISS」列で並べ替えると、あなたの対応が必要なすべての請求書の完全な一覧が1つのビューで得られます。30件の個別PDFを検索してフラグが付いた3件を見つける必要はありません。

ISS源泉徴収に関する法的枠組みは、ブラジルの最高裁判所で審理されてきました。2020年、STF（連邦最高裁判所）はRE 1167509で、サービス提供者がその市区に登録されていない場合、市区はサービス受領者にISS源泉徴収義務を課すことはできないと判決を下し、サンパウロのCPOM（他市サービス提供者登録）登録要件を覆しました。しかし、連邦法によって確立された源泉徴収義務（サービス種別と市区の組み合わせが正当な源泉徴収を引き起こす場合）は引き続き有効です。どの請求書に有効な源泉徴収義務が付いているかを把握するには、バッチ全体を確認する必要があります。

ISS税率のばらつき検出

補完法116/2003は、ISS税率を自治体・サービス種別ごとに2%〜5%と定めています。しかし、自治体は企業を誘致するために税率で競争します — UNDPのブラジル税制に関する診断レビューは「ICMSおよびISS税優遇措置をめぐる略奪的な競争」に言及しています。サービス提供者がサンパウロで5%課税されるサービスコードに2%の税率を適用する場合があります。これは、その提供者が企業誘致のために税率を引き下げた自治体に登録されているためです。その税率が有効かどうかは、経理チームが判断する税務上の決定事項です。しかし、それを発見するにはバッチ全体を見る必要があります。2%の単一の文書は正常に見えます。同じサービスコードで5%の文書が10件、2%が1件 — これは調査に値するばらつきです。

全国NFS-e標準がバッチ処理に与える影響

SNNFS-e（全国NFS-eシステム）は、自治体間のサービス請求書形式を統一するブラジルの取り組みです。2025年8月時点で1,463の自治体が参加しています — ただし、採用は任意であり、サンパウロなどの主要都市は独自システムを維持することを公に表明しています。その結果、ハイブリッドな状況が生じています：一部のサービス提供者は全国XML標準でNFS-eを発行し、他の提供者は自治体独自のシステムで発行しており、どちらになるかを制御することはできません。

バッチ処理の観点から見ると、このハイブリッドな状況はレイアウト非依存の抽出の価値を強化します。テンプレートベースのツールは、標準化前の自治体レイアウトとSNNFS-e標準の両方のテンプレートを必要とし、さらに自治体が一方から他方へ移行する際の更新パスも必要です。セマンティック抽出は、どの標準で生成されたかに関係なく、文書に記載されている内容を読み取ります。全国標準のNFS-eとサンパウロ独自形式のNFS-eが同じバッチに含まれ、同じ列を定義し、同じ出力を生成します。標準化プロセスは文書の内容を変更するものであり、抽出アプローチを変更するものではありません。

2026年の税制改革 — 2033年までにISSをIBS（物品サービス税）へ段階的に置き換えるもの — がさらに別の層を追加します。移行期間中、NFS-e文書には従来のISSフィールドと新しいIBS/CBSフィールドの両方が含まれる場合があります。抽出アプローチは、既存のISS列に加えて「IBS額」「CBS額」という新しい列名を追加することで適応します。テンプレートの再設計は不要です。

組織がブラジルの物品請求書も処理している場合、NF-e XML抽出ワークフローはNF-e抽出ガイドで説明されています。列定義が十分に広範であれば、2つの文書タイプは同じバッチに共存できます。ただし、NFS-e固有のフィールド（補完法116コードなど）はNF-e文書では空白になります — これは想定どおりであり、エラーは発生しません。

FAQ：NFS-e一括処理

異なる都市の事業者からのNFS-eをまとめて一括処理できますか？

はい — これが主なユースケースです。セマンティック抽出は、各文書の内容を理解して個別に読み取るため、特定の都市のレイアウトに依存しません。サンパウロ（ISS 5%）、ベロオリゾンテ（ISS 3%）、クリチバ（ISS 4%）のNFS-eが同じバッチにあっても、同じ列定義で処理されます。AIは、各文書のページ上の位置に関係なく、CNPJ do Prestador、ISS base de cálculo、その他のフィールドを特定します。

一括出力では「ISS Retido na Fonte」はどのように扱われますか？

「ISS Retido」フィールドは専用の列として抽出されます — 通常は「Sim」または「Não」が入ります。一括出力のスプレッドシートでこの列を並べ替えると、貴社が源泉徴収義務者となるすべての請求書の完全なリストが得られます。そこから、該当する各請求書のISS率×課税標準で納付額を計算し、各市町村の支払いシステムに振り分けます。抽出ツールはデータを提供します。税の納付自体は別のコンプライアンス手順であり、経理チームが各自治体の支払いポータルを通じて行います。

事業者がレイアウトエラーやフィールド欠落のあるNFS-eを発行した場合はどうなりますか？

抽出エンジンは文書にあるものを読み取ります。必須フィールド（例：CNPJ）が欠落しているか判読不能な場合、出力の該当セルは空白になります。これは実際には便利です。一括出力の空白セルは、どの文書について事業者へのフォローアップが必要かを即座に示します。一方、30件の文書を手動で入力すると、他の項目に紛れて1つの空白フィールドを見逃す可能性があります。一括表示により、欠落が可視化されます。

同じバッチにNFS-eと海外サービス請求書を混在できますか？

はい。列定義が「請求書番号」「事業者名」「合計金額」「税額」など両方の文書タイプをカバーしていれば、海外請求書とNFS-eは同じバッチに共存できます。「LC 116サービスコード」や「ISS率」などのNFS-e固有の列は非ブラジル文書では空白になり、「VAT番号」などの海外固有の列はNFS-e文書では空白になります。どちらの動作も想定内であり、エラーは発生しません。

抽出エンジンはNFS-e文書の2026年税制改正フィールド（IBS/CBS）に対応していますか？

はい — 市がNFS-eレイアウトをIBSまたはCBSフィールドを含むように更新した場合、バッチ定義に対応する列名（例：「IBS額」「CBS額」）を追加するだけです。抽出エンジンは、既存のISSやCNPJフィールドを特定するのと同じ方法で、文書の内容を理解してこれらの新しいフィールドを特定します。テンプレートの再設定は不要です。2033年までの移行期間中は、ISSとIBSの両方のフィールドを含むNFS-e文書を含むバッチを実行できます — 両方の列を定義すれば、各文書に存在するフィールドが出力に反映されます。

バッチ処理は、各市のAPIを直接統合する方法と比べてどうですか？

市のAPI統合には、サービス提供者が事業を展開する各都市ごとに個別の接続を構築・維持する必要があります — それぞれに独自の認証方法、スキーマ、更新スケジュールがあります。SNNFS-e（全国NFS-eシステム）の国家標準は参加する市にとってこれを簡素化しますが、サンパウロなどの主要都市は参加を拒否しています。セマンティックバッチ抽出は、すでに受け取っている文書（PDF、XML、DANFSE印刷物）を処理するため、市のシステムへのAPIアクセスは不要です。これは、NFS-e発行のためのAPI統合の代替手段ではありません。サービス受領者（tomador）として、発行者ではない場合の受領側ソリューションです。

NFS-e以外のバッチ文書抽出の詳細については、Excelへのバッチ請求書抽出が文書タイプや通貨を超えてどのように機能するかをご覧ください。

市ごとの手入力からバッチごとの照合へ

NFS-eは政府の税収を効率化するために設計されました — そして実際に効率化しています。受け取るすべてのサービス請求書は、受信箱に届く前に市の税務当局によって検証されています。CNPJはチェック済みです。ISS税率はサービスコードに対して検証済みです。請求書番号は割り当て済みです。そのデータは存在し、正確であり、ほとんどの国際的な請求書が経験しない政府の検証ステップを通過しています。

非効率性は完全に受領側にあります：都市ごとに異なる文書から検証済みフィールドを再入力し、SPED（デジタル税務簿記システム）照合のために正確である必要があるスプレッドシートに入力することです。セマンティックバッチ抽出は、入力を速くするのではなく、入力をなくすことでこのギャップを埋めます — そしてそれによって、手作業では決して生み出せない市をまたいだビューを提供します。

次にサンパウロ、リオ、ベロオリゾンテなど各地のサービス提供者からNFS-eの束を受け取ったら、それらを1つのバッチとして処理してみてください。列を一度定義し、抽出を実行します。その後、市ごとに並べ替えてISS合計を確認してください。バッチビューが個々の文書では見えなかった何かを明らかにするかどうかを確認してください。