Every electronic tax document must reach the right posting in SAP
NF-e (electronic goods invoice), NFS-e (electronic service invoice), CT-e (electronic freight document), MDF-e (electronic cargo manifest) and NFC-e (electronic retail invoice) go in and out of SAP every day. When the flow works, nobody looks at it. When it fails, it shows up as an invoice that does not come in, an event nobody answered, or a tax posted differently from what the document says. This page covers the flow, the points of failure and what DFSpro checks in the tax layer.
It also covers one point that needs a decision: the end of SAP GRC NF-e (SAP Electronic Invoicing for Brazil, SAP's solution to issue and receive electronic invoices) and the move to SAP Document and Reporting Compliance (DRC).
NF-e, NFS-e, CT-e, MDF-e and NFC-e go in and out of SAP every day, and a failure shows up as an invoice that does not come in or a tax posted differently from the document. DFSpro designs, configures and proves the document cycle in SAP. The end of SAP GRC NF-e and the move to DRC need a decision.
Choose your entry point by your role
For the same document cycle, each area needs its own answer. Choose yours.
01Tax and fiscal
What the rule sets at each step and what is checked.
Go to the section02IT and SAP architecture
What standard SAP documents and what needs an extension.
Go to the section03Accounting and bookkeeping
How the document status decides its entry in SPED.
Go to the section04Audit and internal control
Nine scenarios, with expected value and evidence.
Go to the sectionDocument map: what they are and where the risk appears
Five documents, one set of events and two directions, issuing and receiving. What changes from one document to another is where the risk appears.
| Document | What it is | Where the risk appears |
|---|---|---|
| NF-e | Electronic invoice for goods, issued and received. | CFOP (tax code for operations and services), taxes and master data that do not match the invoice, and rejection by validation rule. |
| NFS-e | Service invoice, in the national standard and still in municipal standards. | Different layouts by municipality, withholdings, service codes and standards living side by side. |
| CT-e | Electronic freight document. Issuing, events and freight. | Link to the goods invoice, and freight posted with a tax different from the document. |
| MDF-e | Electronic manifest of tax documents. When to issue and close. | Closing of the manifest and the trail of the transport document chain. |
| NFC-e | Electronic consumer invoice, used in retail. | High volume, point-of-sale integration and contingency. |
| Events | Recipient response, cancellation and correction letter. | An event that is not recorded leaves SAP and SEFAZ (the state tax authority) with different versions of the same invoice. |
The NF-e carries the largest volume and most of the tax rule
On issuing, the NF-e starts from a tax determination made in SAP. If the CFOP, the base or the rate is wrong in the setup, the invoice goes out wrong, and it is rejected or, worse, authorized with an error. On receiving, the supplier invoice arrives as XML and must become a posting that is consistent with the purchase order, with the goods received and with the tax credit the company is entitled to.
The least visible part is what happens between the two points. The XML arrives, but the capture fails. The document comes in, but the tax posted differs from what the invoice says. The cancellation event arrives after the posting. Each of these failures is small on its own and expensive when it piles up until the close.
That is why the DFSpro check does not start in the issuing or capture tool. It starts in the tax rule that feeds both, because that is where the error is born and where it can be fixed once, instead of invoice by invoice.
There is also the side of proof. In an audit, the authorized XML is the valid tax document before the tax authority, and the DANFE (the printed auxiliary document of the electronic invoice) is only the supporting representation that travels with the goods. What SAP books must be explainable from the XML, field by field, and that is only possible when the source setup can be traced.
From the document to the posting in SAP
The path is the same for almost all documents. What changes is the rule each step applies.
Document received
The XML arrives through the electronic tax document distribution channel or directly from the supplier, and is captured.
Validation
The document is checked against the purchase order, the goods receipt and the tax master data, before any posting.
Posting
The incoming or billing document is created, with taxes and CFOP determined and booked.
Event and reconciliation
Recipient response, cancellations and corrections are followed up and reconciled with what SEFAZ records.
At each step, the tax layer must be set up consistently with the one before, and DFSpro checks that consistency. The capture and issuing solution the company chose remains the tool for each step. The check is on the tax layer.
NFS-e, CT-e, MDF-e e NFC-e
Each document family has its own risk logic, and treating them all like the NF-e is a common source of error.
NFS-e: national standard and municipalities
The national NFS-e standard becomes mandatory from 2026, and each municipality's calendar must be checked case by case. In practice, many companies live for a while with the national standard and with municipal layouts together. SAP must handle both without duplicating the withholding rule or the service code. The cycle for receiving and delivering the service invoice is in service invoice, NFTS and withholdings.
CT-e e MDF-e
Transport documents, linked to the goods invoice. The risk is in the link: freight posted with a tax different from the document, a manifest that is not closed, a chain of third parties with no trail. The check follows the cargo from its path to the posting.
NFC-e
Retail document, with very high volume, issued at the point of sale. What matters is the point-of-sale integration with SAP, the contingency when SEFAZ is unavailable and the consolidation of values in the tax calculation. Issuing in the store, contingency and rejections have a service of their own: NFC-e in retail with SAP.
Failure signs in automatic entry and in events
Automatic entry means capturing the received XML and creating the posting without typing. When it fails, the symptom often shows up far from the cause.
- Supplier invoices that do not come in and are noticed only when the supplier asks for payment.
- Recurring manual postings of documents that should have come in on their own.
- Recipient response events with no owner and no follow-up deadline.
- An invoice cancelled at SEFAZ that SAP did not receive, leaving an undue tax credit.
- Tax posted on entry that differs from what the XML says, with no record of the reason.
- CT-e and MDF-e with no link to the matching goods invoice.
- A queue of documents in error that is only looked at at the close.
The event monitor is the natural tool to follow these points. What DFSpro checks is whether the recorded event produces the right tax effect in SAP.
Each step in the cycle of the NF-e has a rule and a proof in SAP
The rule sets what the issuer may do at each step. The service is to prove that SAP respects it. The full text of the rule is in electronic tax document legislation. Here is what is checked at each step.
| Step | What Ajuste SINIEF 07/05 sets | What is checked in SAP |
|---|---|---|
| Authorization and rejection | Authorization of use comes after the tax authority's review (clause 6) and, once granted, the NF-e can no longer be changed (clause 7, § 1). A rejection returns the reason, among them a duplicate number or a layout failure. The rejected file is not kept for consultation and, in some cases, can be sent again (clause 7, § 2). | The invoice has a status consistent with the tax authority's answer. A rejection goes to a queue with an owner. Resending does not duplicate the number. |
| Cancellation | Up to 24 hours from authorization, with no movement of the goods, no service provided and no link to an Escrow Duplicate, by event (clauses 12 and 13). Clause 12-A covers another case of cancellation, to be read in the consolidated text. | Check that the reversal of the source document and of the posting follows the event. A request after the deadline or with the goods in transit is handled by the path the client defined. |
| Number voiding | Up to the 10th day of the following month, when there is a break in the sequence (clause 14). Paragraph 6, in force from 01/11/2026, removes Acre, Bahia and São Paulo from the request. | The report of numbering gaps by series and establishment is run before the deadline. Check that the rule by state is set up. |
| Correction letter | It does not correct the variables that determine the tax (base, rate, price difference, quantity, value), nor the recipient or sender, nor the date (clause 14-A). | Check that a tax correction by letter is blocked. The path the law provides for this error is defined by the client. |
| Contingency | Three general forms: SVC, EPEC and a security form for the DANFE. Item IV also provides for generating the document in advance in contingency and authorizing it later, in the operations of § 5-D of clause 9, with new wording from 03/08/2026 (effective date to be checked in the consolidated text). Afterwards, cancel the authorized invoices that did not take place and void those that were not authorized (clauses 11 and 11-A). | The form used is recorded. The later clean-up has a list, an owner and a deadline. |
Official source: consolidated text of Ajuste SINIEF 07/05 at Confaz, read on 16/10/2026. The table does not replace the wording in force on the date of each operation. The EPEC specification is in Technical Note 2014.001, version 1.41, published on 04/08/2026 (list on the NF-e Portal, read on 16/10/2026). The recipient response, which is also part of the cycle, has its own page, the one on automatic document entry.
What standard SAP documents
Separating what is written in SAP's documentation from what the operation needs prevents promising a function the environment does not have.
What SAP Help says
In the documentation of the Electronic Nota Fiscal (NF-e) function of SAP ERP, SAP states that the system generates the NF-e in the processes that require it. Communication with the tax authority uses a messaging service, chosen by the client or an SAP product. The NF-e and CT-e monitor follows the document from posting to authorization and lets you switch to contingency, cancel with an authorization request, run the numbering gap report and view the logs.
What the source does not describe
The documentation read does not cover capturing received documents or the recipient response. Check in your own environment whether it does either of these before relying on it.
What needs an extension
What the operation needs and the documentation does not describe may need an extension or setup in another solution, depending on how the environment reads: a voiding deadline alert, a rejection queue with an owner, the link between the invoice and the purchase order, handling of late events. It enters the scope after the environment has been read.
Source: SAP Help, documentation of the NF-e function of SAP ERP, read on 16/10/2026. It is SAP ERP documentation and names the messaging product of that time. The end of GRC NF-e maintenance and the DRC are covered in the next section and on the page on migration to DRC.
The status of the document decides how it enters SPED
An authorized document, a cancelled one and one booked outside the period enter the file in different ways. Whoever does not know the rule finds the difference in the PVA (the validation program for the file).
| Document status | Code in the file | What the Practical Guide says |
|---|---|---|
| Regular | 00 | It enters with all fields and with the child records. The NF-e key is mandatory in all situations, except voided numbering. |
| Cancelled | 02 | Only the identification fields are reported and, for an NF-e the company issued itself, the key. No child records are reported. |
| Cancelled, booked after the period | 03 | Cancelled and booked after the period: only identification and key, as with code 02. The general rule for late booking, for documents with a value, says that on a sale the tax is not totaled in the period and is paid with surcharges, and that on a purchase the credit is considered normally. The rule of each state must be read. |
| Denied and voided numbering | 04 and 05 | They stopped being mandatory on 01/12/2021 and the codes were discontinued in January 2023. |
The check DFSpro does starts from this rule: the list of cancelled invoices on the tax authority's portal matches the invoices with code 02 and 03 in the file, and a cancellation that arrived after the month closed shows up as late, not as forgotten. The design of the file is in SPED Fiscal in SAP, and the bridge to the ledger in tax and accounting reconciliation.
Official source read on 15/10/2026: the practical guide to the digital tax bookkeeping, in its version 3.2.4, updated on 30/07/2026. The reading covers what the guide describes, not a decision on how to treat the tax, which belongs to the client.
Six setup points and who decides each one
Before the first document goes out, some points must be decided and proven. Not all of them are technical.
Digital certificate
Decides: the company, which buys and renews it.
Proves: requests to cancel, void and send a correction letter need a signature with an ICP-Brasil certificate (clauses 13, 14 and 14-A). Check its validity and its link to the CNPJ.
Series and numbering
Decides: the company, by establishment.
Proves: a break in the sequence requires voiding. Check that each series has gap control and an owner.
Messaging with the tax authority
Decides: the company, between its own option and a product.
Proves: SAP describes both possibilities. Check that the environment uses the one chosen and that the rejection reaches the ERP.
Contingency form
Decides: the company, among the forms the rule lists.
Proves: the form is recorded and the later clean-up has a routine, a list and a deadline.
CFOP and invoice taxes
Decides: the client's tax team, owner of the thesis.
Proves: the determination applies the decision without deviation. The parameters are described in tax setup in SAP.
Test environment
Decides: the project, with the integrator.
Proves: what each test environment confirms and what it leaves open, as in tax tests in SAP.
End of SAP GRC NF-e and the move to DRC
This is the point on the page that needs the most decision, because it means replacing a tool the tax team uses every day.
What SAP announced about the end of SAP GRC NF-e
SAP planned the end of main maintenance of SAP GRC NF-e (SAP Electronic Invoicing for Brazil, the solution many companies use to issue and receive NF-e and CT-e inside SAP) for 31/12/2025 and recommends moving to DRC, in its outbound and inbound options for Brazil (SAP Community, 13/04/2023).
According to SAP, outbound DRC for Brazil covers SEFAZ NF-e, NF3-e, CT-e and MDF-e, and NFS-e for Rio de Janeiro and São Paulo. The published scope does not mention CBS or IBS (Feature Scope, version 1.0, 17/03/2025).
In public comments, an SAP specialist said there is no official migration tool and that customer-specific maintenance does not cover legal change, including the tax reform (29/09/2023 and 07/03/2025).
What migrates, what DRC covers and the method are in Migration from GRC NF-e to DRC. Anyone also evaluating NTT DATA's issuing and receiving product will find what it publishes in GUEPARDO e-Invoicing.
The decision to migrate, the environment and the date belong to the client. DFSpro does not replace the integrator who runs the technical migration: it works on the tax layer of the project, on what must be set up, on what the new flow changes in the posting and on what must be tested in the first close.
ECC to S/4HANA migration Tax setup in SAP Ancillary obligations and SPED
Nine scenarios to prove the cycle works in SAP
An authorized document proves the tax authority accepted it, not that the cycle is right. Proof is built with scenarios, and each one has its expected value set before it runs.
| Scenario | Expected value, set beforehand | Evidence kept |
|---|---|---|
| Authorized invoice | Authorization protocol and authorized XML saved on the document. | Public lookup on the NF-e portal equals what SAP records. |
| Rejection for layout | Invoice in a queue with the reason and the owner. Resending only where clause 7 allows. | Record of the rejection and the resend, with no duplicate number. |
| Cancellation within 24 hours | Event recorded, with reversal of the source document and of the posting. | Event, reversals and code 02 in the SPED file. |
| Cancellation after the deadline | Request blocked or routed to the path the client defined. | System message and the path taken. |
| Number voiding | A numbering gap created in the test appears in the report and is voided before the 10th day of the following month. | Gap report and voiding protocol. |
| Correction letter | Rate correction blocked. An allowed field is consolidated in the last letter (clause 14-A, § 4). | Blocked attempt and consolidated letter. |
| Contingency | Authorized invoices that did not take place are cancelled and the unauthorized ones are voided. | Clean-up list with owner and date. |
| Entry with a tax different from the XML | The determination rule that prevailed is identified. | Record of the reason for the difference. |
| Late event | The supplier's cancellation, after posting, changes the period's credit and the file. | Posting of the effect and the matching line in SPED. |
The expected value comes from the rule and from a calculation made outside the system, never from SAP's own result. What was not proven becomes an open item with a deadline, never an assumed working state. This is a proof criterion, not a legal requirement. See also NFC-e in retail with SAP, where contingency and rejection in the store have their own method.
Service scope and the client's part
What does
- Designs and configures the document cycle in SAP: tax determination, status and event rules.
- Tests each scenario against the expected value and keeps the evidence.
- Checks the effect of each event on bookkeeping and on SPED.
- Records what was left out of scope and who owns it.
What does not do
- Decide the tax thesis, such as CFOP, tax treatment and credit. That belongs to the client.
- Issue or capture the documents. The tool belongs to the company.
- Run the technical migration of GRC NF-e. That belongs to the integrator.
- Guarantee acceptance by the tax authority or compliance.
Official sources read for this page
- Confaz: Ajuste SINIEF 07/05, consolidated text, clauses 6, 7, 11, 11-A, 12 to 14-A and 15-C, read on 16/10/2026
- NF-e Portal: main page and list of technical notes, read on 16/10/2026
- Receita Federal, guide to the digital tax bookkeeping, edition 3.2.4 of 30/07/2026, consulted on 15/10/2026
- SAP Help: Electronic Nota Fiscal (NF-e), SAP ERP function, read on 16/10/2026
Blog articles on NF-e, NFC-e and NFCom with IBS and CBS
Questions to take to your internal discussion
01Is the move from GRC NF-e to DRC an IT project or a Tax project?+
Both. Replacing the tool is technical, but the tax team must validate CFOP, taxes, events and bookkeeping in the new flow. Those who look only at the technical side often find differences in the first close in production.
02Is the national NFS-e standard already mandatory?+
The national standard becomes mandatory from 2026, according to the regulation, and each municipality's calendar must be confirmed directly. In practice, standards still live side by side in many cases, and SAP must handle both. What changes from one city to another is in NFS-e by municipality in SAP.
03Automatic document entry: what is it?+
It is capturing the XML of the received document and creating the posting without typing. It works well when the tax master data and the determination rules are right. When they are not, automatic entry just posts the error faster.
04What is the event monitor for?+
To follow events such as recipient response, cancellation and correction letter, showing what is pending and who answers for each item. Without it, the event only shows up when it has already become a difference.
05Are electronic documents part of the SAP Tax Diagnostic scope?+
Yes, to the extent that bookkeeping and calculation depend on them. The diagnostic checks whether what was issued and received matches what was calculated and booked, without replacing the issuing and capture tool the company already uses.
06Does the rule apply to both SAP versions, ECC and S/4HANA?+
It applies to both. The way documents are integrated into SAP may change between versions, but the tax rule that feeds each document must be right in both.
07Does DFSpro issue or capture the documents?+
That is not its role. Issuing and capture stay with the solution the company chose. DFSpro checks the tax layer that feeds and receives these documents, inside the SAP environment integrated with GUEPARDO Tax.
08How does checking events link to the tax close?+
A cancellation or a correction that arrives after posting changes the period's tax credit. If the event has no effect in SAP, the tax calculation and SPED carry a value that SEFAZ no longer recognizes. The check links each type of event to the posting it should change.
09What is the first sign that the document flow needs review?+
Recurring manual postings of documents that should come in on their own, invoices noticed only when the supplier asks for payment, and events with no owner. Any one of the three, repeated over more than one close, shows that the tax rule or the master data behind the flow needs a look.
10Does anything change for companies that issue documents under several CNPJs and states?+
The number of combinations changes. Each CNPJ and each state may have a different validation rule, NFS-e calendar and requirement. The check treats this spread as a risk of its own, because the same rule copied to several units without review multiplies the error.
11How long does a company have to cancel an NF-e?+
Up to 24 hours counted from the authorization of use, and as long as the goods have not moved (Ajuste SINIEF 07/05, clause 12). After the deadline, the path depends on the state's law and on the operation, and the choice of tax treatment belongs to the client.
12Until when can a number be voided?+
Up to the 10th day of the month after the break in the sequence (clause 14). From 01/11/2026, paragraph 6 removes Acre, Bahia and São Paulo from the voiding request. The rule of each state where there is an establishment must be checked.
13Can I correct the tax amount with the correction letter?+
No. Clause 14-A bars correcting the variables that determine the tax, such as tax base, rate, quantity and value, and also changing the recipient and the date. The test checks that SAP blocks this use, and the alternative path is defined by the client.
14For how many days can the recipient record its response?+
Clause 15-C sets 90 days from authorization for Confirmation, Unawareness and Operation Not Carried Out, in the wording of Ajuste SINIEF 14/26 in force since 01/06/2026. The earlier wording said 180 days, and there are exceptions in Annex II. The detail of events and deadlines is on the automatic entry page.
15Does a cancelled invoice appear in the SPED Fiscal file?+
Yes, with status code 02, or 03 when it is booked outside the period. Only the identification fields are reported and, for an invoice the company issued itself, the key, with no child records (Practical Guide of EFD-ICMS/IPI 3.2.4).
16What does the issuer do when SEFAZ does not answer?+
It can operate in contingency, using the general forms of clause 11: sending to SVC, sending the EPEC or printing the DANFE on a security form. Item IV adds an advance generation for cases of § 5-D of clause 9, to be checked. Afterwards it must clean up, cancelling the authorized invoices that did not take place and voiding the unauthorized ones (clause 11-A).
Start with the path of your document
The first step is an SAP Tax Diagnostic, which checks whether what SAP issues and receives matches what was calculated and booked. If the open decision is the move from GRC NF-e to DRC, the conversation helps size what the tax team must validate before the project.