Automatic inbound of NF-e and CT-e in SAP: acknowledgment, events and reconciliation

Three layers that must close together

The starting point is a simple question: how does the recipient know, today, which documents exist against its CNPJ, and what does it do with each one?

Automatic inbound of tax documents and why the recipient needs it

The expression describes a flow, not a product. What defines the flow is the source of the data, which is the National Environment, and the destination, which is the posting in the ERP.

From document to posting in six steps

The flow is the same for almost every invoice received. What changes from company to company is who owns each step and what evidence is kept.

The first three steps depend on the National Environment and on how the capture tool consumes the service. The next two depend on the design of the purchasing and receiving process. The last step is the one that slips most: an event that arrives after posting must find the posting and produce the right tax effect, and that only happens if someone defined in advance the effect of each event.

The page on electronic tax documents in SAP describes the map of the five documents and the failure points in overview. What follows goes deeper into receiving and events, without repeating that map. For the choice of tool and the move away from GRC NF-e, the page from GRC NF-e to DRC covers the decision; here the focus is what the tax layer must see in either of the two.

A note on vocabulary. The text uses recipient for whoever receives the invoice, even when, in SAP, the posting is called goods receipt, service entry or invoice. The distinction matters because the rule speaks of the recipient, and the acknowledgment obligation falls on it, not on the module that makes the posting.

The DF-e distribution service: query by NSU, access key and what the recipient receives

Distribution does not deliver everything to everyone. What each party receives depends on its role in the invoice, and, for the recipient, depends on whether it has acknowledged.

Legal basis NF-e portal technical note itself

The three queries

Usage rules that decide whether inbound is reliable

Three practical consequences come from these rules. The first: the NSU sequence is the control instrument of automatic inbound. The technical note says the National Environment generates NSU with no gaps and that a gap in the interested party's base indicates a distribution failure, which must be closed with the single query by NSU. Whoever does not control the sequence does not know what they did not receive.

The second: there is a 90-day window to recover what was left behind. A gap discovered after that period can no longer be closed by this service, and the invoice depends on the supplier, on another channel or on the public query. The third: the service punishes compulsive querying. A routine that repeats the query without waiting the required hour blocks the CNPJ, and a CNPJ blocked for an hour during closing is a process problem, not a network problem.

The design of the query routine, the retry order and the wait policy are decisions of the capture tool. What the tax layer requires is that these decisions are documented and that someone looks at the report of gaps and rejections. That is the role of the monitor covered further on.

Recipient, carrier and third party see different things

The cards show, in summary, what each role receives from the National Environment. The distinction between summary and full invoice is the point that surprises beginners most.

NT 2014.002. The text of NT 2014.002 says that, before acknowledgment, the recipient receives only the NF-e summary structure and the cancellation, and that the carrier only receives the invoice if it is in the transport group or was named in the Interested Party event (code 110150). Third parties receive the invoice if the CNPJ or CPF is in the autXML field. The technical note also covers the distribution of tax authority, endorsement, extension and passage record events, which the cards do not reproduce.

The consequence is direct for automatic inbound: a recipient that never acknowledges never receives the full XML through the service, only the summary. The summary is enough for the company to know the invoice exists and decide on acknowledgment. It is not enough to post. A routine that "captures" only summaries and counts that as inbound is counting documents it cannot yet post.

There is one setup that deserves attention: the company that is, at the same time, recipient and carrier, or recipient and third party, on the same invoice. The technical note says that, before generating NSU for the carrier and for the autXML CNPJ, the service checks whether those CNPJs are also recipients on the same invoice, and, if they are, does not generate the NSU until the recipient acknowledges. This prevents a company from getting around acknowledgment by using another role.

Awareness, confirmation, non-recognition and operation not performed: events and deadlines

Acknowledgment is the mechanism by which the recipient tells the National Environment what happened with the operation. The four events have different effects and deadlines.

Legal basis text Confaz

Deadlines: what the adjustment says and what changed

Clause 15-C of SINIEF Adjustment 07/05, as worded by SINIEF Adjustment 14/26 with effect from 01.06.26, allows conclusive events to be recorded within 90 days, counted from the NF-e authorization. The earlier wording, given by SINIEF Adjustment 44/20, provided for 180 days and was in force from 11.12.20 to 31.05.26. Anyone consulting material from before June 2026 therefore finds 180 days, and that number is no longer the one in the compiled text of Confaz. NT 2020.001 v1.50 still shows 180 days, which is consistent with the wording of the time; the version of the material matters.

Other rules of the same clause: awareness of issuance can be recorded within 10 days of authorization (paragraph 4) and, if recorded, obliges the recipient to record a conclusive event (paragraph 5). Each conclusive event can be recorded up to twice, and only the most recent counts (paragraph 2), and correction must happen within 30 days, counted from the first acknowledgment (paragraph 3). Finally, paragraph 6 says that, after 90 days with no conclusive event recorded, the operation described in the invoice is considered to have occurred, with the same effects as confirmation.

When acknowledgment is mandatory

Annex II of SINIEF Adjustment 07/05 obliges the recipient to record one of the conclusive events for an NF-e that requires the fuel detail group, for one covering alcohol for non-fuel purposes in bulk and, when the recipient is a distributor or wholesaler, for one covering cigarettes, alcoholic beverages, soft drinks and mineral water. In these cases, the deadlines of the annex replace the general deadline of clause 15-C (paragraph 1). Clause 15-B, paragraph 2, also allows the state to require the record from other taxpayers.

• Intrastate operation: 20 days for confirmation and operation not performed, 10 days for non-recognition.
• Interstate operation: 35 days for confirmation and operation not performed, 15 days for non-recognition.
• Interstate operation destined to an incentive area: 70 days for confirmation and operation not performed, 15 days for non-recognition.

In practice. Even outside Annex II, acknowledgment is a good control practice, for three reasons. It releases the full XML in the distribution service. It fixes the company's position on the operation before silence is read as confirmation. And, for an unknown invoice, it is the evidence that the company did not take part in the operation, which matters in a registration fraud case. Which event to record in each situation is a decision for the owner of the purchasing process together with tax, and cannot be automated without a rule.

A golden rule, which DFSpro adopts in its checks: the confirmation event should not be triggered automatically by the arrival of the invoice. It states that the goods were received. If the system confirms on capture, and the goods never arrive, the company declares to the tax authority something that is not true and loses the possibility of cancellation by the issuer. The correct trigger ties confirmation to actual receipt, with evidence.

Event table: who records, what the effect is and where the rule is

An event is the record of an occurrence related to the invoice after it is authorized. It is through events that the invoice status changes without the original XML changing.

Legal basis SINIEF Adjustment 07/05

Two notes on the table. First, the events for passage record, for an NF-e referenced in another invoice, in a CT-e or in an MDF-e and for export endorsement are recorded automatically, by propagation, by tax administration systems (paragraph 2-A), not by whoever receives the invoice. Second, the list is not closed in time: the same adjustment gained, in 2025, events recorded by the Brazilian postal service (paragraph 2-B, effective from 09.10.25), and Technical Note 2025.002 created new events tied to IBS and CBS, covered further on.

The table does not replace the MOC. The event code, the XML layout, the justification requirement and the rejection rules of each event are in the technical notes and in the manual, and the capture tool must be tested against those rules, not against a website's summary.

Transport events: delivery proof, disagreement and closing of the manifest

Transport has its own national environment and its own events. Some of them go back to the NF-e by propagation.

Legal basis SINIEF Adjustment 09/07 SINIEF Adjustment 21/10

The CT-e adjustment was changed in 2026: SINIEF Adjustment 26/26 removed the EPEC from the list of CT-e events, effective from 05.10.26 (cl. 18-A, paragraph 1, III, revoked). Anyone with a transport contingency routine must check the current state of the adjustment, not what was written in earlier material.

Why transport events matter for the goods invoice

The delivery proof and the failed delivery, when recorded in the CT-e, are propagated to the NF-e that the freight document references (SINIEF Adjustment 07/05, cl. 15-A, XVIII, XIX and XXIV to XXVII), and proof of delivery by the carrier replaces the paper delivery stub (cl. 15-A, paragraph 5). For the recipient, this means physical receipt now has an electronic trail that can be checked against the goods receipt posting.

For the freight taker, the service-in-disagreement event is the instrument to contest a CT-e. The text of the adjustment defines the event as a statement by the taker declaring that the service was not as agreed. The deadline for this record by the taker must be checked in the CT-e MOC before building the freight contest routine.

In SAP, the inbound CT-e is usually posted as a service or as a component of the goods cost, and the link with the goods invoice is the risk point: freight posted with a different tax than the freight document reports, or freight without the matching invoice. The page on electronic tax documents describes this risk in the general map, and freight reconciliation follows the same logic as the goods reconciliation described further on.

What the issuer can do after authorization, and what arrives after posting

Canceling and correcting are issuer events, but the effect lands on the recipient. The rule limits both, and it is that limit that reconciliation must know.

There are, therefore, clear limits on what the issuer can do after authorization, and that explains why cancellation after the deadline and a value error require other paths, such as a return invoice or a complementary invoice, which are in the legislation of each document.

Cancellation after posting: the case automatic inbound must anticipate

A cancellation that arrives after posting is the most expensive event to ignore. The recipient has already posted the invoice, already booked the credit and, perhaps, already paid the supplier. When the event reaches the National Environment, it is distributed to the recipient even without acknowledgment (NT 2014.002, footnote 1), which means the company can learn of the cancellation even without having confirmed the operation. If automatic inbound does not match the cancellation to the posting, SAP keeps treating as valid an invoice that SEFAZ no longer recognizes.

Each type of event must have its expected effect in SAP written down: cancellation must generate a pending item to reverse the posting, the credit and, where applicable, the payable, with an owner and a deadline. The correction letter must generate a check of the corrected fields against the posting. The delivery proof must be readable against the goods receipt. Without that table of effects, the event is just information.

EPEC, extension and other events

The advance issuance event in contingency is recorded by the issuer before authorization, and SINIEF Adjustment 07/05 says the DANFE printed in contingency by the EPEC is presumed unfit when the Federal Revenue Service has not regularly received the event (cl. 17-D). NT 2014.002 includes the EPEC among the documents distributed to the recipient. The deadline extension request, tied to the return of goods sent for industrialization, has request and tax authority reply events, also distributed to the recipient. They are lower-volume events, but it is in them that automatic inbound tends to have gaps, because few tools have been tested against them.

SAP and inbound: DRC inbound, the former GRC NF-e

What SAP publishes about the inbound service and what the tax layer must have.

Legal basis Official SAP documentation: 13 April 2023 DRC page on the SAP Brazil website

What SAP publishes and what is defined in the project

What the environment must have for inbound to be reliable

Eight guidance items from DFSpro, organized from registration to report. They are not a legal requirement: they are what you expect to find when inbound works.

In practice. The eight items apply to any capture tool, from DRC to a third-party solution or an in-house interface. They do not depend on knowing how each tool names its screens, and so can be defined before the technical choice. The master data that supports determination is on the page on tax master data, and the determination rule on the page on tax setup.

From invoice to posting: MIRO, MIGO, CFOP, credit and the EFD block C

Reconciliation is the part of inbound that decides whether the credit booked can be defended. It starts at the XML and ends at the file delivered.

Legal basis EFD ICMS/IPI Practical Guide, version 3.2.2. Since 10/09/2026, COTEPE/ICMS Act 86/26 indicates version 3.2.4 (COTEPE/ICMS Act 44/18, art. 1, sole paragraph). Before generating the file, check the guide in force on the SPED Portal.

Invoice, purchase order and receipt reconciliation

In practice. Cause and handling describe project practice, not the rule. What the five lines have in common is that the divergence needs a queue, an owner and a deadline, and that the record of the decision is part of the tax evidence. MIGO, which records the goods receipt, and MIRO, which records the supplier invoice, are the two ends of the reconciliation, which is why the invoice is checked against both before posting.

CFOP, CST and credit

The inbound CFOP is determined from the invoice's outbound CFOP and the nature of the operation for the recipient, and the CST (tax situation code) of the inbound tax decides whether there is a right to credit. The determination rule belongs to the setup layer, and automatic inbound that runs it on incorrect supplier or material master data produces incorrect postings at volume. When the invoice carries a full-taxation CST and the inbound record marks the material as having no right to credit, or the reverse, there is a divergence that only shows up at tax calculation.

The right to credit is a matter of the legislation of each tax and each state, and is not asserted here. What the EFD bookkeeping says on the subject is that, on inbound documents, the tax amount, tax base and rate fields should only be filled in if the buyer has the right to claim the credit, in the declarant's view (EFD ICMS/IPI Practical Guide, version 3.2.2, record C100). Automatic inbound, therefore, cannot fill in the credit by simply reading the XML: the XML shows the tax stated by the issuer, and the credit depends on the buyer's position.

From posting to EFD block C

What this means for the flow: an invoice canceled after posting must reach the EFD as canceled, not as valid. If the cancellation arrives after the period is closed, the company must decide, with tax, among the paths the state's legislation allows, and should not decide alone inside the capture routine. The CT-e goes into block D and follows the same logic. The page on ancillary obligations and SPED covers the path of the data to the file and the signs of divergence between calculation and file; the focus here is the entry door of that path.

The new events of NT 2025.002 for IBS and CBS: credit, assisted calculation and cancellation

The reform adds events that the recipient needs to know how to record. The codes and authors are those of version 1.40 of the technical note.

Legal basis IBS Steering Committee website

Item 8 states that these events are part of the IBS and CBS ancillary obligations, that they are indispensable for calculation and credit control, and that correct and timely recording is a condition for enjoying the exemption from paying IBS and CBS provided in art. 348, paragraph 1, of the Constitutional Amendment for the 2026 taxable events. The text warns that non-compliance may lead to loss of the benefit. It also directs that these events be sent individually, without batching, and says they are authorized at SVRS, the Rio Grande do Sul virtual SEFAZ.

Event 211120, for allocating an item to personal consumption, appears in the code list, but the technical note records that it was removed because paragraph 6 of art. 57 of Complementary Law 214/2025 was repealed by Complementary Law 227/2026. It is a good example of why the event list must be read in the version in force: a code that existed in one version may have been withdrawn in another.

What this changes for automatic inbound

For the first time, receiving an invoice has an effect on calculation that depends on a recipient event. Before, the credit depended on posting and bookkeeping. With the events for claiming presumed credit, capitalizing an item and accepting debit, the recipient has actions to carry out after inbound, and the capture tool must know how to issue these events, or tax needs its own routine to do so. Whoever handles only invoice receipt is left with half the flow.

Which companies and in which situations each event is required depends on LC 214/2025 and on the calculation rules. What is stated is what the technical note says: the events exist, have a defined author and follow the MOC layout. The decision on when to record is up to the tax team, supported by the legislation. The page on the tax reform, CBS and IBS in SAP covers the whole change; the focus here is what changes in inbound and in events.

Sign, likely cause and check: the table of inbound failures

Ten situations in which automatic inbound fails most often, with the likely cause and what to check. It is an investigation guide, not a diagnosis.

Two of the lines deserve emphasis because of their cost. The first is the invoice canceled after posting: the event arrives, but nobody links it to the posting. The risk appears months later, in the tax calculation or in an audit. The second is the invoice that the National Environment starts to consider confirmed by lapse of time, which is the effect of paragraph 6 of clause 15-C. A company that does not monitor the acknowledgment clock may be confirming, by omission, operations that in fact did not take place.

Credit disallowance is a consequence, not a cause. When an audit questions an inbound ICMS, PIS or Cofins credit, the question is whether, on that date, the invoice was valid, whether the operation took place and whether the buyer had the right to the credit. The three answers depend on automatic inbound having recorded the right event, at the right time, and having kept the evidence.

What to follow and how to organize the governance of monitoring

The monitor is the routine that stops automatic inbound from becoming a black box. Propose indicators, frequency, owner and evidence.

How to organize governance in four decisions

The monitor's governance connects to what DFSpro calls, on other pages, a rule with an owner: nothing that affects credit is left without a named person responsible. The page on post-go-live stabilization covers the follow-up of the first cycles after a tool change, and it is in that period that the first gap and rejection reports tend to appear in volume.

Automatic inbound readiness in twenty points

Four blocks, five items each. An honest answer to each item shows where inbound depends on a specific person.

In practice. The checklist has twenty items and serves as a script for an internal conversation. An unchecked item is not, by itself, a violation: it is a point where the company depends on a person, on memory or on luck. The SAP Tax Diagnostic organizes this kind of check with the company's team.

Nine ways to turn automatic inbound into a risk

The errors below are recurring failures in automatic inbound. Each one has a direct link to a rule cited above.

Who answers for which part of inbound

The division of roles is the company's decision. The table is a starting point and must be adjusted to the real org chart.

The tax layer of inbound, alongside the integrator

DFSpro's work on this topic is to check the tax layer, without replacing whoever operates the tool.

Or assess readiness in 2 minutes.

Three invoices, three paths, one routine

The situation is built to illustrate the method and does not describe any client.

A hypothetical example, with no real client, to show how the pieces fit. A distributor with three establishments under the same base CNPJ buys from two hundred suppliers and receives, on average, a few hundred invoices a day. It uses a capture tool that queries the National Environment once an hour.

On another invoice, the supplier issues a cancellation on the same day as authorization, but the distributor only captures the event two days later, after the posting has already been made. Since the cancellation is distributed to the recipient even without acknowledgment, the monitor sees it, the reversal pending item is created with an owner and a deadline, and the payable is held before its due date. On a third invoice, the recipient never received the goods, and the confirmation was never triggered: the invoice stays in summary until purchasing decides on operation not performed or non-recognition, within the deadline in force.

The example shows that the difference between inbound that works and inbound that fails is rarely in the query technology. It is in having defined, beforehand, who decides and what evidence is kept.

Sources for each fact

The list gives the link for each source. Legal and technical facts appear in the text with the act or technical note beside them.

The version to use in any project is the one in force on the date, checked on the portal.

• SINIEF Adjustment 07/05 (NF-e): events, deadlines, cancellation, CC-e, Annex II (Confaz): https://www.confaz.fazenda.gov.br/legislacao/ajustes/2005/AJ007_05
• SINIEF Adjustment 09/07 (CT-e): events and cancellation (Confaz): https://www.confaz.fazenda.gov.br/legislacao/ajustes/2007/AJ_009_07
• SINIEF Adjustment 21/10 (MDF-e): events (Confaz): https://www.confaz.fazenda.gov.br/legislacao/ajustes/2010/AJ_021_10
• NF-e portal: main page and recipient acknowledgment service (Federal Revenue Service and ENCAT): https://www.nfe.fazenda.gov.br/portal/principal.aspx
• NF-e portal: list of Technical Notes (Federal Revenue Service and ENCAT): https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=04BIflQt1aY=
• NF-e portal: manuals, including MOC version 7.0 (Federal Revenue Service and ENCAT): https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=ndIjl+iEFdE=
• CT-e portal (Federal Revenue Service and ENCAT): https://www.cte.fazenda.gov.br/portal/principal.aspx
• NT 2014.002 v1.40: electronic tax document distribution web service (copy of the document) (NF-e National Environment): https://www.reformatributaria.com/wp-content/uploads/2026/07/NT2014.002_v1.40-WsNFeDistribuicaoDFe-CNPJ-alfa.pdf
• NT 2020.001 v1.50: recipient acknowledgment (copy of the document) (NF-e National Environment): https://inventti.com.br/wp-content/uploads/2024/03/NT_2020.001-v1.50.pdf
• NT 2025.002 v1.40: NF-e and NFC-e adaptations to the Consumption Tax Reform (IBS Steering Committee): https://www.cgibs.gov.br/upload/arquivos/202606/17141803-nt-2025-002-v1-40-rtc-nf-e-ibs-cbs-is-final.pdf
• EFD ICMS/IPI Practical Guide, version 3.2.2 (Federal Revenue Service, SPED): http://sped.rfb.gov.br/arquivo/download/8112
• SAP Document and Reporting Compliance, inbound invoicing option for Brazil (SAP Help Portal): https://help.sap.com/docs/DC_NFe
• SAP Electronic Invoicing for Brazil (SAP NFE): end of mainstream maintenance, 13/04/2023 (SAP Community): https://blogs.sap.com/2023/04/13/sap-electronic-invoicing-for-brazil-sap-nfe-end-of-maintenance/
• SAP Document and Reporting Compliance, product page in Brazil (SAP): https://www.sap.com/brazil/products/financial-management/document-reporting-compliance.html

Sister pages on the subject: electronic tax documents in SAP, from GRC NF-e to DRC, ancillary obligations and SPED, tax setup and tax reform, CBS and IBS. For the NFS-e, the NFS-e section of the electronic tax documents page covers the national standard and the municipalities.

Find out what your environment receives, acknowledges and books

The first step is to map who acknowledges today, whether the NSU sequence is controlled and what the effect of each event on posting is. The conversation through the contact page lets us discuss your case, with no price and no commitment on timing.

To go deeper first: NFS-e national standard, electronic tax documents, from GRC NF-e to DRC, ancillary obligations and SPED and tax setup.