How to Extract NFS-e Data for Your
Brazilian Operations (2026 Guide)

Why a Brazilian Service Invoice Is Different from Every Other Invoice You Process

If you have worked with Brazilian fiscal documents before, you are likely familiar with the NF-e — the electronic goods invoice that every AP team in Brazil or dealing with Brazilian suppliers must handle. The NF-e is governed at the state level by SEFAZ (Secretaria da Fazenda Estadual), follows a single national XML schema (layout version 4.0), and carries ICMS — a state-level tax on goods circulation. It is complex, but it is one system.

A service invoice (Nota Fiscal de Serviços / NFS-e) is governed at the municipal level. The tax it carries is ISS — Imposto Sobre Serviços — and the rate, the layout, the validation workflow, and even the digital certificate requirements can all differ from one city to the next. São Paulo has its own NFS-e web service. Rio de Janeiro has a different one. Belo Horizonte has a third. And 5,567 other municipalities each have theirs.

This is not an edge case. It is the structural reality of Brazil's fiscal federalism, enshrined in Lei Complementar 116/2003, which grants each municipality the authority to set its own ISS rate (2%–5%) and administer its own service tax collection. The federal government has been working to unify this through the National NFS-e System (Sistema Nacional de NFS-e / SNNFS-e), with over 1,280 municipalities signed on as of early 2026. But adoption is voluntary, and many major cities still run their own systems.

For the team receiving these documents — the AP clerk opening a PDF from a Brazilian marketing agency or an IT consultant — the practical consequence is this: no two NFS-e documents look the same. A service invoice issued in São Paulo places the ISS base de cálculo (taxable base) in a different position than one issued in Porto Alegre. The CNPJ do prestador (service provider's corporate tax ID) might be in the header on one document and in a sidebar on another. A template that works for São Paulo will break for Campinas.

This is why template-based OCR — the approach most document extraction tools use — fails systematically on NFS-e. Templates match coordinates. Municipalities change coordinates. For a closer look at how Brazil's other major electronic invoice type works, see our NF-e XML extraction guide, which covers the state-level goods invoice.

What a Brazilian Service Invoice (NFS-e) Actually Contains

Before you can extract data from a service invoice (Nota Fiscal de Serviços / NFS-e), you need to know what is on it — and, crucially, what each field means for your accounting. An NFS-e is not just a bill. It is a fiscal document with legally mandated fields whose values determine your tax obligations, your vendor master matching, and your audit trail.

Here are the key fields on a typical NFS-e and why each matters on the receiving side:

The LC 116 service code list contains 40 main categories, each with sub-items covering everything from IT services (category 1) to legal services (item 17.14), engineering (category 7), and healthcare (category 4). The full list is publicly available in the annex to Lei Complementar 116/2003. Every NFS-e you receive carries one of these codes, and that code directly determines the ISS rate your provider should have applied.

None of these fields are optional. The municipality that validates the NFS-e checks every one of them before authorizing the document. This means the data you need for accurate AP processing already exists — it was verified by a government tax authority before the invoice reached your inbox. The question is whether you can get it out of the document and into your spreadsheet without retyping it.

What Manual NFS-e Entry Costs Your Finance Team

The standard assumption is that manually entering invoice data is slow. It is — the average single-page document takes about 3 minutes to key into a spreadsheet. But with NFS-e specifically, slowness is not the most expensive problem. The most expensive problem is error propagation through your tax records.

A mistyped CNPJ — one wrong digit in a 14-digit string — means your vendor master reconciliation fails, and you cannot claim the ISS credit if your entity is the withholding agent. A wrong ISS rate copied into your ERP (2% entered as 5%) means your tax accrual is off for the entire reporting period, potentially flagged during a municipal audit. A missed "ISS Retido na Fonte = Sim" flag means you fail to remit ISS that you — not the provider — are legally responsible for paying to the prefeitura.

These are not hypothetical risks. Brazilian tax authorities conduct electronic cross-matching between NFS-e issuers and recipients. If your provider reported receiving R$50,000 from your CNPJ and your SPED records show R$48,000 because two invoices were mistyped, the mismatch triggers an automatic notification — and then a formal inquiry.

Multiply this across even a modest volume. A mid-sized company with 10 Brazilian service providers — an IT consultancy, a marketing agency, a legal firm, an accounting office, a facilities management company, and a handful of freelancers — might receive 30 to 50 NFS-e documents per month. At 3 minutes per document, that is roughly 2.5 hours of manual keying. But the real cost is not the 2.5 hours. It is the correction cycle: the reconciliation spreadsheet that does not balance, the call to the provider asking for a duplicate, the amended tax filing, the accounting fee to sort out the discrepancy.

This is where the phrase "document extraction" becomes concrete. It is not about saving typing time. It is about eliminating the gap between what the municipality validated and what your ERP received.

How AI Extraction Handles Municipal Variation — Without Per-City Templates

The core technical challenge with NFS-e extraction is not that the documents are hard to read. A service invoice (Nota Fiscal de Serviços / NFS-e) from any Brazilian city is a clearly printed, mostly machine-generated document. The challenge is that the same field appears in a different position, with different labels, on documents from different cities.

Traditional template-based OCR solves this by defining a rectangular zone for each field: "CNPJ do Prestador is at coordinates (x=150, y=320, w=200, h=30)." This works perfectly — for one municipality. It breaks for the next. Maintaining a template library for 5,570 cities is not practical. Even maintaining one for the 20 cities your providers happen to be in means 20 templates that break when the prefeitura releases a layout update (which São Paulo did as recently as August 2025 with version 3.2 of its NFS-e manual).

The alternative is semantic extraction: instead of searching for a field by its position, you search for it by what it means. You tell the extraction engine "I need the CNPJ of the service provider," and the engine reads the document, understands that a 14-digit number labeled "CNPJ" next to "Prestador" is the provider's tax ID — regardless of where it sits on the page.

This is fundamentally different from OCR. OCR converts pixels to characters. Semantic extraction — powered by vision language models — reads a document more like a person reads it: understanding labels, context, and document structure. When the São Paulo layout puts "Prestador de Serviços" in the top-left and Porto Alegre puts it in a centered header, a semantic engine does not care. It is not looking for a position. It is looking for a meaning.

The extraction approach uses Custom Column Extraction: you type the field names you want into your output — "Provider CNPJ," "Service Code (LC 116)," "ISS Amount," "NFS-e Number" — and the AI locates each value on the document by understanding what the label means, not where it sits. These column names become the headers of your final Excel spreadsheet, so the output is ready to upload into your ERP or accounting system without reformatting.

Step-by-Step: Extract NFS-e Data into Excel

Here is the practical workflow for extracting data from your received NFS-e documents into a structured spreadsheet. The process works whether you have the PDF/DANFSE (the printed auxiliary document for services) or the underlying XML file.

Handling ISS Withholding, Multiple Service Codes, and Batch Scenarios

Most NFS-e extraction is straightforward — a single provider, a single service, standard fields. But real finance workflows encounter edge cases that matter. Here are three that trip up manual processes:

ISS Retained at Source (ISS Retido na Fonte)

When an NFS-e is marked "ISS Retido na Fonte = Sim," the obligation to remit ISS to the municipality shifts from the service provider to the service taker — that is, to you. This is not a data entry note. It is a tax compliance action item. Your finance team must: (1) identify these invoices in the extraction output, (2) calculate the ISS amount to remit (the rate × base shown on the invoice), and (3) issue the payment to the correct municipality's prefeitura within the deadline.

Missing this step means the ISS was never paid to anyone — the provider did not pay it (because they declared it withheld), and you did not pay it (because you missed the flag). Both parties are exposed. An extraction workflow that flags these documents automatically — by extracting the "ISS Retido" field as a yes/no column — turns a compliance risk into a sortable spreadsheet column.

Multiple Service Codes on One Invoice

A single NFS-e can contain multiple line items, each with its own LC 116 service code and its own ISS rate. An IT consulting firm might bill separately for "Análise e desenvolvimento de sistemas" (code 1.01, ISS 5% in São Paulo) and "Suporte técnico" (code 1.07, potentially a different rate). If you extract only the invoice-level ISS total, you lose the per-line classification that determines whether each line was taxed correctly. Define your columns to extract line-item-level service codes and ISS amounts, not just the document total.

Batch Processing Across Multiple Service Providers

When you receive NFS-e documents from five different providers in five different cities, the batch processing advantage compounds. Instead of opening each PDF individually and copying fields into separate spreadsheet rows, you upload all of them together. The extraction engine processes them in parallel — a single page takes 5 to 10 seconds — and produces one consolidated spreadsheet with all providers' data in the same columns. This is the practical answer to the municipal fragmentation problem: the AI handles the layout differences per document automatically, and your team handles one output file.

For volume scenarios — 50, 100, or more NFS-e documents per month — batch invoice extraction to Excel eliminates the per-document setup that makes manual processing scale linearly with document count.

The 2026 Tax Reform: What Changes for NFS-e Extraction

Brazil is in the middle of a tax reform that will eventually replace ISS and ICMS with a unified IBS (Imposto sobre Bens e Serviços) and replace PIS/COFINS with CBS (Contribuição sobre Bens e Serviços). The transition is gradual — through 2033 — but NFS-e layouts are already updating. São Paulo published version 3.2 of its NFS-e manual in August 2025, introducing fields for the new tax structure. Other municipalities will follow.

From a data extraction perspective, this means two things. First, fields you extract today (ISS base, ISS rate, ISS amount) will eventually be supplemented or replaced by IBS/CBS fields on future NFS-e documents. Second, during the transition period, you may receive invoices that carry both legacy ISS fields and new IBS fields — and you will need to extract both for reconciliation.

The extraction approach described above handles this naturally. Because it does not depend on fixed field positions or hard-coded templates, new fields on an updated NFS-e layout are extracted the same way as existing ones: you add the column name (e.g., "IBS Amount"), and the AI locates it on the document. No template reconfiguration required.

For a practical guide to extracting tax data from Brazilian goods invoices — which carry ICMS, IPI, PIS, and COFINS and are governed by a different regulatory framework — see our NF-e XML extraction guide. If you also process Brazilian payroll documents, our holerite (payslip) extraction guide covers that workflow.

FAQ: Brazilian NFS-e Service Invoice Extraction

Can I extract data from an NFS-e PDF if I don't have the XML?

Yes. The PDF/DANFSE contains all mandatory fiscal fields required by the municipality for validation. Unlike the NF-e DANFE — which omits roughly 90% of the underlying XML data — the NFS-e printed document is more self-contained because municipalities do not share a single standard for what goes in the XML versus what appears on the printed auxiliary document. The full set of fields listed in the anatomy table above (CNPJ prestador/tomador, LC 116 code, ISS breakdown, NFS-e number, RPS number) are typically present on the PDF. However, if you have access to the XML, use it — it guarantees 100% field coverage and eliminates OCR-related accuracy variance.

Does the extraction work with NFS-e documents from any Brazilian city?

Semantic extraction reads fields by understanding document content, not by matching a specific city's layout. It works on an NFS-e from São Paulo, Rio de Janeiro, Belo Horizonte, Porto Alegre, or any other municipality without requiring a per-city template. However, extraction accuracy on handwritten NFS-e documents — which are rare (almost all NFS-e are machine-generated) — will be lower than on printed or digital documents. Handwriting recognition works, but it is inherently less accurate than reading printed text.

What about ISS withheld at source — how do I handle the tax remittance obligation?

Extract the "ISS Retido na Fonte" field as a dedicated column. Any invoice where this field equals "Sim" (or "Yes") should be routed to your tax compliance workflow, not filed as a standard AP entry. The ISS rate and ISS base on the invoice tell you the amount to remit; the municipality of the provider tells you where to remit it. The extraction tool gives you the data. The tax remittance itself is a separate compliance step that your accounting or tax team must execute through the relevant prefeitura's payment system.

Can I batch-process NFS-e documents alongside regular international invoices?

Yes. If your column definitions are broad enough to cover both document types (e.g., "Invoice Number," "Vendor Name," "Total Amount"), you can include Brazilian NFS-e documents in the same batch as international invoices. The extraction engine reads each document independently and fills in whichever fields it finds. However, for NFS-e-specific fields — like the LC 116 service code or ISS amount — those columns will be empty for non-Brazilian invoices, which is expected and does not cause errors.

How does the 2026 tax reform affect NFS-e field extraction?

The reform does not change how extraction works — it changes what fields appear on future NFS-e documents. As municipalities update their layouts to include IBS and CBS fields alongside or in place of ISS, you will need to update your column definitions to include the new field names. The extraction approach remains the same: add the new column name, and the AI locates the corresponding value. The gradual transition through 2033 means you will likely process documents with both old and new tax fields during the overlap period.

Do I need a Brazilian tax ID (CNPJ) to use this extraction approach?

No. Data extraction from a received NFS-e is a document processing task, not a tax filing action. You do not need a CNPJ to extract data from an NFS-e PDF or XML into a spreadsheet. The CNPJ fields on the document identify the service provider and the service taker; the extraction tool reads them as data points and places them in your output columns — it does not interact with any municipal tax system.

From Per-Document Typing to Per-Batch Processing

The NFS-e was designed to make tax collection efficient for the government — and it does. Every service invoice issued in Brazil is validated by a municipal tax authority before it reaches you, which means the data on it has already been checked for consistency. The inefficiency is entirely on the receiving end: the AP clerk retyping fields that a machine has already verified, from a document that varies by city, into a spreadsheet that needs to be correct for tax reconciliation.

Semantic extraction changes the receiving end of that equation. The fields are already there, already validated, already machine-readable (or near enough). Getting them into your spreadsheet in one batch is a workflow decision, not a technical breakthrough. Test it on your next batch of NFS-e documents — see if the time per document drops from the 3-minute manual benchmark to the seconds it takes to define your columns once and let the extraction run.