NFS-e national standard: what a service provider needs in place ready in the ERP

What the national NFS-e is and what changed

Timeline of the national standard

Where the portal calls the date a forecast, the table says it is a forecast.

Two caveats on reading dates. First: the 2022 implementation plan uses the verb forecast, and the portal itself marks it as a forecast, so it describes the intent of the time, not the production date of each module. Second: the IBS and CBS display schedule is phased by service category and by regime. The Belo Horizonte City Hall records the existence of Joint Act RFB/CGIBS No. 4/2026 and of a version 4,A, dated 30/07/2026, and the Questions and Answers cite Act No. 4/2026 as the basis of the schedule. Before fixing a date in the project, check the act in force for your service category.

Legal basis with article numbers

Who decides what: law, agreement, technical note and city parameter.

The practical hierarchy is this: the complementary law gives the obligation and the limit, the agreement and the CGNFS-e give the layout, the technical notes give the field, and the city gives the local parameter (rate, deduction, withholding, deadline). When an error shows up at issuance, ask in which of these layers it started before touching the ERP. It is the same logic that the page on tax setup in SAP applies to tax calculation: the defect is usually in the layer that decides, not in the one that executes.

How it works inside, with the official terms

Six concepts explain almost everything: DPS, Sefin Nacional, ADN, Municipal Panel, CNC (National Taxpayer Registry) and event.

→

Validation is synchronous. This changes how you test: the rejection appears at the moment of sending, with a code, and a parameter error (rate, deduction, place) is as common as a layout error.

The APIs the ERP will meet

Two characteristics decide the integration design. First, signing the DPS and mTLS authentication (mutual authentication by certificate) require the provider's own ICP-Brasil digital certificate, and today there is no electronic power-of-attorney mechanism for third parties or integrators. To issue on behalf of several CNPJs, the system must sign and transmit each batch with each taxpayer's certificate. The regulation already provides for the Provider of Signature and Authorization of Electronic Tax Documents, but the feature appears as under development (Source: NFS-e Questions and Answers, topic 17.7). Second, only individuals and MEI issue without a certificate, and only manually through a screen or app. Automated batch issuance by API always requires the certificate.

A test environment exists. The taxpayer manual points to the interactive documentation in Restricted Production at adn.producaorestrita.nfse.gov.br, and the Questions and Answers recommend validating the integration there before pointing to production (Source: Manual of the National Issuer APIs, NFS-e Questions and Answers, topic 19.5). Invoices generated in Restricted Production have no legal effect.

Who issues and who receives

Four roles appear on the invoice. What each can and cannot do defines where the ERP needs a rule.

Withholding and customer deserve attention from the ERP of whoever buys services. The received invoice carries the field tpRetISSQN, and the standard's rule is restrictive: the customer is not allowed to flag withholding when the city of taxation is not the customer's own city. When the tax is due to the provider's city, the provider pays it, and the invoice goes out as not withheld (Source: NFS-e Questions and Answers, topics 7.1 and 7.9). For the flow of whoever receives and posts the invoice, with withholdings and NFTS, see service invoice and NFTS automation.

Participating city and non-participating city

The national standard coexists with municipal systems until 2032. What decides the channel is the city's configuration and the company's regime.

Three parameters of the municipal parameters API sum up this coexistence for a software house, and also apply to an ERP team that integrates directly. The first is aderenteEmissorNacional: value 1 means the city uses the national issuers and the integration goes straight to the Sefin Nacional, value 0 means issuance takes place in the city's system, except for MEI and item 99. The second is situacaoEmissaoPadraoContribuintesRFB: value 1 enables by default any company in the city in the Federal Revenue CNPJ base, value 0 requires the city to register each taxpayer in the CNC, with municipal registration and authorization date, which is typical of a phased migration. The third is permiteAproveitamentoDeCreditos, which only acts in assessment, in the MAN, and does not affect filling in the XML (Source: NFS-e Questions and Answers, topic 19.6).

There is an exclusivity rule that avoids the costliest error of this phase: the same taxpayer cannot issue at the same time through its own system and the National Issuer in the same period. The issuer's use authorization defines, taxpayer by taxpayer, where each must bill in each period. Issuance is only allowed from the later of the individual authorization date and the agreement's effective date (Source: NFS-e Questions and Answers, topics 5.2 and 5.3). For the ERP, this means storing, per issuing CNPJ, from which date on the channel is the national one.

ISS, IBS and CBS on the same invoice

The service invoice is the first document where the old tax and the new ones appear together. That is why each field has two readings.

What the law already says and what it does not say about ISS and IBS on the invoice

Complementary Law 214 says that service invoices may now show IBS and CBS (art. 62, I) and that the national environment receives the shared document (art. 62, II). The layout reflects this with the IBSCBS group inside the DPS. The rules on place of operation for IBS and CBS rest on art. 11 of the law and have their own criterion, which does not always match the list of ISS exceptions. So, from 2026 on, the invoice calls for two separate looks at the same fact: where ISS is due, and where the operation is considered for IBS and CBS (Source: NFS-e Questions and Answers, topic 7.5; Technical Note 009, item 2.10).

What the law and the acts do not settle on their own, and what the company must decide with the help of Tax and its advisers, is the practical effect of each transition period on tax calculation. The page on the reform with CBS and IBS covers collection and regimes. Here the invoice is what matters: in 2026, the IBS and CBS base is calculated by deducting ISS, PIS, COFINS and unconditional discounts, whether or not ISS was withheld (Source: NFS-e Questions and Answers, topic 32.6), and the invoice total stays equal to the net amount, because IBS and CBS only become part of the total on 01/01/2027 (Source: NFS-e Questions and Answers, topic 15.5). The São Paulo City Hall also reminds that 2026 is a test year, in which whoever meets the ancillary obligations is exempt from paying IBS and CBS, and that the law remains valid with no deadline extension and no waiver of penalties (Source: São Paulo City Hall).

IBS and CBS display schedule on the NFS-e

Two points avoid confusion. Suspending the rule that requires the IBSCBS group on the invoice does not suspend the city's obligation to integrate with the national environment, which keeps the sanction of art. 62, § 7. And if the company decides to fill in the group before the date, all content validations of the group are applied normally, which makes voluntary filling a real test, not a rehearsal (Source: NFS-e Questions and Answers, topic 15.2).

Fields and data the ERP needs to have

Seventeen requirements of the standard, each with its source and the point where it usually weighs on the master data or the document.

The last column describes where the data usually lives in an SAP service billing environment, and not a product function that SAP has announced. The point is the same in any ERP: each field of the standard has an owner in the master data or in the document, and when the owner does not exist the invoice comes from manual filling. The page on tax master data in SAP describes how to check those records, and the one on tax setup covers the determination rules that feed the value.

SAP and the NFS-e: where SAP comes in

What SAP has published about Brazil and what the standard requires, regardless of the product.

In project practice, there are three possible architectures for the NFS-e, and all of them depend on the same set of data. In the first, the ERP builds the DPS and sends it to the Sefin Nacional through its own or a third-party integration layer, with the issuer's certificate. In the second, the ERP stays integrated with the city's web service, which shares with the ADN, a path the law allows until 2032 for those in a city with its own issuer who are not Simples taxpayers. In the third, part of the invoices go out through the public issuer (portal or app) and the ERP imports the XML. The choice between them is the project's. What is not optional is that service billing delivers complete data, and that the invoice return comes back to the ERP with number, key and XML.

What this demands of the tax layer becomes concrete in five questions the team can answer without waiting for any product announcement. Which table translates the service billed in SAP to the national taxation code and to the NBS? Where is the address of the unit that uses the service, rather than the customer's headquarters? How does the ERP tell own PIS and COFINS debit from withholding of those taxes? Who maintains, by city of each issuing establishment, the parameters of rate, deduction, withholding and cancellation deadline? And, when the invoice is cancelled or replaced, which SAP document reverses the posting? If one of these answers is a person's name and not a table, the risk is in the process, not in the tool.

Events, cancellation and substitution

The issued invoice is not the end of the cycle. Events change what the invoice is worth, and the ERP must track each one.

Substitution rules that avoid rework

A wrong place of taxation is the error that needs the most care, because substituting often does not solve it: the system tends to block a change of place outside the standard deadlines. The Questions and Answers describe three risks of an invoice issued with the wrong place: a tax assessment for lack of a correct invoice in the real city, active debt in the city named by mistake, and a block on the clearance certificate there. The route to correction is the Tax Review Request for Cancellation in the wrong city, with proof that the service was rendered elsewhere (Source: NFS-e Questions and Answers, topic 29.3). It is worth treating the place of taxation as a test validation and a sample review item, not as a filling detail.

City by city: channel, date and parameters

Each city decides whether invoices are authorized in the national environment or in its own system with sharing, and publishes its calendar. Rio de Janeiro, São Paulo, Belo Horizonte and Porto Alegre show four different paths. The ERP needs a parameter table by city. The detail, with the city's migration in six stages, the cancellation and substitution rules and the rejection errors, is in NFS-e by city in SAP.

How to prepare: a plan in four steps

A readiness plan for companies with SAP and a service obligation, without depending on a specific product.

The most underrated step is the third. Layout rejection shows up early and is easy to fix. Parameter rejection, such as a deduction not allowed, an incompatible withholding or a benefit not reported, only shows up with real operation, city by city.

The first step has its own tool: the readiness assessment helps build the issuance inventory before any test.

If the inventory shows establishments in cities with their own rules, take that list to a conversation with DFSpro before the first integration test.

Four types of company with SAP

Industry, distribution, leasing, transport and business groups reach the NFS-e by different paths.

The four profiles have in common that the risk is not in issuance itself, but in the data that reaches it. The sample-check routine that DFSpro describes on the page on foreign trade in SAP for imports has an equivalent here: sample invoices by city, by service code and by regime, and compare with the official parameter.

Common errors and rejection risks

Twenty code families, with the cause that appears most in the official guidance and the suggested fix. Open each code to see both.

All lines come from the official Questions and Answers material (Source: NFS-e Questions and Answers, topics 4, 7, 8, 10, 11, 15, 17, 18, 21, 23, 27 and 31) and from the taxpayer manual. The fix column sums up the published guidance, which may change with each platform release. Before using a fix in production, check the version of the layout and business rules annex in force.

If these codes already show up in your operation, the readiness assessment helps separate layout errors from municipal parameter errors before touching the ERP.

Duplicates and parallel systems

Two real migration risks: the invoice issued twice and the taxpayer issuing through two channels at the same time.

The invoice number deserves a separate paragraph, because it is where ERP habit and the national rule clash the most. When the DPS arrives, the Sefin Nacional reserves the next number and tries to write the invoice to the ADN. If there is a timeout, a database failure or high concurrency, the reserved number may not become an invoice, and a gap is left in the sequence. Technical Note 007 calls these gaps skips and explains that they are not a defect: uniqueness matters more than continuity. An ERP that audits the numbering sequence as if it were a ledger must accept that, in the national NFS-e, holes do not mean a lost invoice (Source: Technical Note 007, item 3.b; NFS-e Questions and Answers, topics 18.5 and 18.6).

Parallel municipal systems call for a simple and explicit design. While a city with its own issuer shares documents with the ADN, the taxpayer may keep talking to the local web service, and the city transcribes to the national layout. For old invoices, the obligation to share continues even after the migration, for up to six years back (Source: NFS-e Questions and Answers, topics 5.6 and 23.5). For the taxpayer, the practical result is that the national public query, by key, becomes common proof between provider, customer and city.

Relation to SPED and EFD

The service invoice feeds bookkeeping, but the national ISS bookkeeping product is not yet defined in the official sources.

The NFS-e is a tax document. The bookkeeping of services provided and received remains part of the company's set of obligations, and the link between the two worlds is uneven. The ISS Digital Tax Bookkeeping (EFD ISS) appears on the portal as a product of the national basket, but the official page is marked as Under construction, so no national EFD ISS obligation can be stated today (Source: NFS-e Portal: products). The standardized payment slip, in turn, is described as the collection document for taxes shown on the NFS-e, which distributes the proceeds to the entities and lets a single document be issued even with scattered branches, on the model analogous to Simples Nacional (Source: NFS-e Portal: products). The module that runs it, the MAN, is described as Restricted Production, and city adhesion is optional (Source: NFS-e Questions and Answers, topic 14.8).

In practice, three points link the invoice to bookkeeping and deserve Tax's attention. The first is that the Belo Horizonte City Hall stopped requiring supporting documents for deductions in the DES (the electronic services declaration), because the information is now required on the invoice itself, when the city so determines. The second is that withholding of PIS, COFINS and CSLL on the NFS-e was aggregated in the field vRetCSLL without changing how the information is given in the EFD-Reinf, according to Technical Note 007 (Source: Technical Note 007). The third is that the scope of municipal, state and federal obligations has its own page: the page on ancillary obligations and SPED describes the bookkeeping layer, and municipal service obligations vary from one city to another.

How DFSpro works

SAP Tax Governance consultancy, founded in 2018, in Curitiba, focused on the tax layer of the project.

GUEPARDO Tax is a product of NTT DATA, and DFSpro sells it as an Authorized Channel. It is part of the tax environment integrated with SAP in which DFSpro works, and the conversation about how it fits your company's NFS-e flow belongs to the project, case by case. Anyone who wants to see how the tax layer of an SAP project is run can read the page on SAP Tax Diagnostic and the one on GUEPARDO Tax. If the question is what happens to the document flow when the issuance solution changes, the page on migration from GRC NF-e to DRC covers that topic for the NF-e.

Official sources with links

Legislation and official documentation, with a link to the text.

Portals change: before deciding a deadline or rule, open the act in force.

Start with your first issuing establishment

If you have a list of establishments that issue service invoices and want to know what each city requires of the ERP, the readiness assessment organizes that list. If the question is how it fits your SAP project, the conversation through contact is the channel.