NFC-e in retail with SAP: issuance, contingency and rejection under control
NFC-e is Brazil's electronic receipt for sales at the counter. It is issued in seconds, in front of the customer, and any failure becomes a queue at the register. This service covers what SAP must do so that every store sale reaches an authorized receipt and the tax calculation with the same value.
DFSpro configures and proves the tax layer: master data, the tax rule for each item, the status returned to SAP, contingency, and reconciliation with the register and with SPED. The issuer or the POS stays the one in your landscape. The tax decision belongs to the client.
Go straight to the part of NFC-e that your role needs
Four entry points to the same receipt: each role sees a different part of the path between the register and the books.
01Retail tax team
The rules by state, the item CFOP and CST, the identified consumer, and what the tax reform changes on the counter receipt.
See this role's section02Store IT and POS (PDV)
The three issuance setups, offline contingency, what to do after an outage, and how to read each rejection.
See this role's section03Store operations
Cancel, replace and void: deadlines, conditions, and what the register can do without creating a tax problem.
See this role's section04Controllership and accounting
NFC-e in SPED Fiscal and in the tax calculation, reconciling the register with the receipt, and what changes with every store opened.
See this role's sectionNFC-e shortcuts
What the NFC-e at the counter requires from SAP
NFC-e (model 65) is the electronic receipt for a sale to the final consumer, authorized by SEFAZ (the state tax authority) before the taxable event. For each sale, SAP must deliver the right tax data and receive the status back.
Authorized before the sale ends
Ajuste SINIEF 19/16 gives NFC-e legal validity through the qualified electronic signature and the state's authorization of use, before the taxable event occurs.
Instant answer, one receipt at a time
NFC-e travels in a batch of one receipt, with an immediate answer. The MOC rejects a batch with more than one, and technical note 2023.002 removes denial and batching from NFC-e.
Part of the rules belongs to each state
The state decides whether it accepts NFC-e, which contingencies are valid, whether the DANFE can be a short version, and the limit for a sale without identifying the consumer.
For NF-e, CT-e and the other documents, the topic has its own owner: electronic tax documents in SAP. The rules and dates are in electronic tax document legislation.
A national rule, plus one decision per state
Ajuste SINIEF 19/16 and the MOC set the standard. Each state chooses what the standard leaves open.
| Topic | What the national rule says | What the state decides |
|---|---|---|
| Adoption and registration | NFC-e can replace the consumer sales receipt, the ECF coupon, the CF-e-SAT and the model 4 receipt, at the discretion of each state. The taxpayer must be registered with the state, on request or by the state's own initiative. | Whether it accepts NFC-e and who registers. Without acceptance, the MOC rejects with code 702. |
| Contingency | There are three alternatives: prior generation with later authorization, ECF or SAT, and the prior event for issuance in contingency (EPEC). | Which alternatives are valid. If the state does not accept offline contingency, the receipt is rejected with code 712. |
| NFC-e DANFE | Printed on an ordinary printer, with a QR Code and the access key. | Whether it accepts the short DANFE and electronic delivery instead of paper, when the consumer agrees. |
| Identified consumer | CPF or CNPJ for a sale of BRL 10,000.00 or more, at the consumer's request, and in a non-face-to-face operation. | The limit for a sale without identification. If the state sets none, BRL 10,000.00 applies. |
| Cancellation | The base deadline is half an hour from the authorization of use. | The state can shorten this window. |
| Voiding | The request for unused numbers goes up to the 10th day of the following month. | Acre, Bahia and São Paulo are outside this request from 01/11/2026. |
| Home delivery | Requires the consumer's address and the carrier's data. | Whether it allows NFC-e in this operation. Without permission, the rejection is 785. |
A chain in several states keeps a matrix of rules by state, and the client's SAP configuration carries the difference for each establishment, designed and proved by DFSpro.
Three issuance setups in stores, and the role of DFSpro in each one
SAP's position in issuance defines who builds the XML, who holds the certificate, and where each rejection starts.
Issuer or POS outside SAP
The issuer builds, signs and transmits the NFC-e, and SAP receives the sale and the status. DFSpro handles the data and the rule that SAP gives the issuer, and the return.
POS integrated with SAP
When the item's tax rule comes from the client's SAP landscape, the issuer only builds the document. DFSpro configures the rule and proves that the item reaches the receipt as the company defined it.
Integration layer in the middle
A service connects the POS to SAP. DFSpro handles the tax side of the data that crosses the bridge and the return, with the design of tax integration.
Who does what at each step
Item data
Who handles it: the master data in the client's landscape. DFSpro: designs the cleanup of NCM, CEST, GTIN and unit, then configures and proves the load.
Tax rule
Who handles it: the tax determination in the landscape or in the issuer. DFSpro: configures the rule in SAP and checks it item by item against what the issuer transmits.
XML, signature and transmission
Who handles it: the issuer or the POS, with the client's ICP-Brasil certificate. DFSpro: does not replace the issuer, and tests the return and the rejections with it.
Receipt status in SAP
Who handles it: the integration between issuer and SAP. DFSpro: configures the handling of each status and the pending queue.
Reconciliation and bookkeeping
Who handles it: the client's controllership and tax team. DFSpro: designs the reconciliation report and proves the bookkeeping.
From the register slip to the authorized receipt in eight steps
Each step hands the next one data that SEFAZ validates. A rejection almost always starts in the first steps.
- 01
Sale recorded
Items, quantities, payment method and, if the consumer asks, the CPF.
- 02
Item tax data
NCM, CEST when there is one, GTIN, unit, the CFOP for a sale to the final consumer, and CST or CSOSN.
- 03
XML built
Model 65, final consumer and face-to-face operation, with the IBS and CBS group on the item, in the rollout stage currently in force.
- 04
Signature and key
Signature with an ICP-Brasil certificate and a 44-digit access key.
- 05
Transmission
One NFC-e per batch, with an immediate answer from the SEFAZ of the issuer's state.
- 06
Authorization
SEFAZ returns the authorization protocol. On rejection, it returns the code and the message.
- 07
NFC-e DANFE
Printed or sent by electronic means, with a QR Code, depending on the state and the consumer.
- 08
Status in SAP
Authorized, rejected, in contingency, canceled or voided, for reconciling the register.
The agreed service level for NFC-e authorizers is an answer in under 30 seconds, 85% of the time. When the answer does not come, the register cannot wait, and this is where contingency comes in.
Key, QR Code, CSC and lookup
Four elements let the consumer check the receipt, and three of them depend on store parameters.
Access key
It has 44 characters and is printed on the DANFE in 11 blocks of four. The consumer can look up the receipt by typing the key on the SEFAZ website.
QR Code
It measures at least 25 mm by 25 mm, with clear space around it. It leads to the public SEFAZ lookup, and the lookup URL is also in the XML, in the supplementary information.
CSC
An alphanumeric security code of 16 to 36 characters, known only to SEFAZ and the issuer. The company can have up to 2 valid CSCs per state, and the QR Code hash, in SHA-1, uses the CSC.
Public lookup
The state keeps the lookup for at least 180 days, by key or QR Code. After that, it can offer only partial information about the receipt.
The CSC is a parameter for each establishment, with an owner and a renewal date. An error in the CSC or in the lookup URL shows up as a QR Code that does not open or as a rejected receipt.
The nine divisions of the NFC-e DANFE
| Division | What it carries | What the store must watch |
|---|---|---|
| I. Header | CNPJ, company name, the issuer's address and the text “Documento Auxiliar da Nota Fiscal de Consumidor Eletrônica”. | Establishment record identical to the one at SEFAZ. |
| II. Item detail | Code, description, quantity, unit, unit price and total of each item. | The state may allow the DANFE without this division, if the consumer agrees. |
| III. Totals | Number of items, total value, surcharges and discounts, amount due, payment method, amount paid and change. | The register totals and the receipt totals must match. |
| IV. Lookup by key | The state's lookup address and the access key in 11 blocks of four digits. | Correct address for each state, identical to the one in the XML. |
| V. QR Code | The QR Code image, at least 25 mm by 25 mm. | CSC and lookup URL valid for the environment. |
| VI. Consumer | CPF, CNPJ or foreigner ID, or “CONSUMIDOR NÃO IDENTIFICADO”. | It prints only the identification that is in the XML. |
| VII. Identification and protocol | Number, series, issue date and time in local time, and the authorization protocol. | In contingency, the protocol is not printed. |
| VIII. Tax message | Text of interest to the tax authority, the contingency notice and the test environment notice. | A receipt in contingency carries the text on two lines, in two places. |
| IX. Taxpayer message | Additional information from the issuer, such as the tax transparency law. | An institutional message goes only after the end of the DANFE. |
The NFC-e DANFE is only the simplified representation of the sale. The issuer is exempt from sending the XML to the consumer, unless the consumer asks before issuance, and the paper must stay legible for at least six months.
When the receipt cannot wait for SEFAZ
The register does not stop, and the receipt must be regularized later. What changes is what SAP keeps during the outage.
Contingency is an exception, not a routine. The taxpayer decides to enter it, without asking the tax authority for permission, and only when a technical problem prevents authorizing the receipt in real time.
Three sources of technical problems, according to the MOC
Store network or server
A failure in the taxpayer's internal servers or network that prevents building, signing or sending the receipt.
SEFAZ authorization system
The state SEFAZ is down or slow, and the issuer gets no answer to the authorization request.
Communication channel
The store's Internet is unavailable, or its response time is no longer suitable for service at the register.
The three alternatives in Ajuste SINIEF 19/16
Offline, with tpEmis 9
It generates, signs and prints the DANFE without prior authorization. Transmission goes up to the end of the first business day after issuance.
EPEC, with tpEmis 4
It records a summary of the receipt at SEFAZ before printing. The receipt is transmitted within 168 hours, and the state decides whether it accepts EPEC.
ECF or SAT
Alternative tax equipment, in the states that keep this option. The MOC treats offline contingency as the current operating model.
What a receipt in contingency must have
- Date and time of entry into contingency and the justification filled in. Rejection 556 blocks these fields in normal issuance, and 557 requires them in contingency.
- On the DANFE, the text “EMITIDA EM CONTINGÊNCIA Pendente de autorização”, below the header and below the receipt identification.
- In the QR Code, the issue date and time, so that the consumer's lookup reports that this is a receipt in contingency.
- New numbering, moving forward by one number, because it is forbidden to reuse in contingency the number of a receipt transmitted as normal.
- Establishment copy: a second copy of the DANFE or electronic storage of the XML, with a statement in the model 6 book or a declaration, depending on the state.
The MOC warns that a receipt in contingency appears in the public lookup only after it is authorized, and that the issuer bears the risk of losing the information until it is in the tax authority's database. The tax authority can restrict contingency for those who overuse it.
Transmit, handle the rejection, and clear what stayed pending
Contingency ends only when all receipts are authorized or resolved and SAP knows the status of each sale.
- 01
Transmit on time
Offline: up to the end of the first business day after. EPEC: up to 168 hours. With the same access key and the same original numeric code.
- 02
Handle the rejection
Generate again with the same number and series, fixing the irregularity, without changing what determines the tax amount.
- 03
Resolve the pending ones
A receipt transmitted during the outage with no answer stays pending: cancel it if it was authorized, void the number if it was not.
- 04
Check the sales
No SAP sale may stay without a receipt, and none may have two authorized receipts.
- 05
Record the episode
Keep the reason, the start and the end of the contingency for each establishment, with the numbers of the receipts involved.
An example from the MOC itself
Receipt 20 is transmitted and SEFAZ does not answer. The issuer enters contingency and issues receipt 21. Once the problem is over, 21 is transmitted. If 20 was authorized, it is canceled. If not, the number is voided.
DFSpro proves this path in the test environment: it interrupts transmission, issues in contingency, transmits later, and checks what SAP shows at each step, including the sale that stayed without a receipt.
Cancel, replace or void: each case has a deadline
The deadline is short, and the choice of path depends on whether the receipt was authorized and whether the goods left.
Sale undone right after authorization
Cancellation event, type 110111, within half an hour of the authorization of use and with the goods still in the store. The state can shorten the window, and outside it comes rejection 501. Basis: Ajuste SINIEF 19/16, clause 15, and the MOC.
Operation covered by another NFC-e in contingency
The original receipt is canceled with a reference to the one issued in contingency, within 168 hours of the authorization of use, and the state can reduce this. Basis: Ajuste SINIEF 19/16, clause 15-A.
Wrong receipt, with a replacement
Cancellation by replacement, type 110112, an event specific to NFC-e: it gives the key of the replacement receipt. The MOC sets 168 hours, with the exception of state legislation.
Skipped number, no receipt issued
Request to void a range of numbers, with a justification of 15 to 255 characters, up to the 10th day of the following month. Acre, Bahia and São Paulo are outside from 01/11/2026. Basis: clause 16 and the MOC.
Before canceling or voiding, three questions
Did the goods leave?
Cancellation is valid only if the goods did not leave. After that, the path is another process, defined by the state and by the store's policy.
Was the receipt authorized?
A number that was never authorized is voided. An authorized receipt is canceled. Transmitting the receipt later cancels a voiding request already made.
Is the state's deadline the same?
The state can reduce the cancellation deadline. The store needs the deadline in force in its own state, not the standard one.
At the counter, the risk is the order of actions: the operator cancels after the deadline, or voids a number that contingency will still transmit. DFSpro designs, in the client's landscape, the visible receipt status and the rule that blocks the action outside the window.
The most common rejections, and what each one means
The codes below come from the MOC validation rules. The middle column shows the cause that repeats most often in stores.
A rejection carries a code and a message. The code points to the MOC rule that failed, and the cause is almost always in the data that the POS or SAP sent.
Item data
| Code | What the MOC rejects | Common cause at the counter | How to handle it |
|---|---|---|---|
| 779 | NFC-e with an incompatible NCM | An NCM in the material record that NFC-e does not accept. | Correct the NCM in the master data and resend. |
| 734 | Trade unit outside the table | An internal SAP unit with no match in the MOC table. | Keep the unit mapping for each material. |
| 611 and 883 | Invalid or missing GTIN | Wrong barcode digit, or an item without a GTIN and without the expression “SEM GTIN”. | Validate the digit and use “SEM GTIN” where there is no code. |
| 725 | Invalid CFOP for NFC-e | A CFOP for an operation that the MOC does not accept in a sale to the final consumer. | Use the consumer sales CFOP, starting with 5. |
Value, consumer and delivery
| Code | What the MOC rejects | Common cause at the counter | How to handle it |
|---|---|---|---|
| 750 | Value above the limit without identifying the recipient | A high-value sale without a CPF. The limit belongs to the state, and BRL 10,000.00 applies if the state set no other. | Require identification at the register and keep the limit by state. |
| 789 | Recipient is an ICMS taxpayer | A sale to a taxpayer entered as NFC-e, with an IE (state registration) indicator other than 9. | Handle the sale to a taxpayer in the NF-e flow. |
| 785 and 788 | Home delivery not allowed by the state, or without the recipient's address | A delivery request without the address in the sale record. | Make the address mandatory and check the state's permission. |
Issuance, date and contingency
| Code | What the MOC rejects | Common cause at the counter | How to handle it |
|---|---|---|---|
| 703 | Issue date and time later than the receipt time | A POS clock set ahead. | Synchronize the clock of every POS. |
| 704 | Issue date and time behind the transmission | A POS that issues and sends later, without entering contingency. The tolerance in normal issuance is 5 minutes. | Issue in real time or formally enter contingency. |
| 556 and 557 | Contingency justification filled in normal issuance, or missing in contingency | The issuer treats the issuance mode as free text. | Treat the issuance mode as an issuer parameter. |
| 712 and 714 | Offline contingency not accepted by the state, or contingency invalid for NFC-e | The issuer enters a mode that the state does not accept. | Set up the accepted mode for each state. |
| 783 | NFC-e is not authorized by SVC | The issuer tries the NF-e contingency environment. | Use offline contingency or EPEC, depending on the state. |
| 539 | Duplicate with a difference in the access key | A number reused after a failure. | Move the numbering forward on entering contingency. |
| 126 and 453 | Batch with more than one NFC-e, or an asynchronous answer for a batch of one | Issuer configured with the NF-e standard. | Send one NFC-e per batch, with a synchronous answer. |
Tax reform on the item
| Code | What the MOC rejects | Common cause at the counter | How to handle it |
|---|---|---|---|
| 1115 | IBS and CBS group not filled in | An item built without the IBSCBS group. | Include the group on the item, with CST and classification. |
| 1020 and 1023 | IBS and CBS CST or classification does not exist | A code typed in or inherited from an old table. | Load the official CST and classification tables. |
| 1024 and 1025 | Classification incompatible with the CST, or not allowed for the receipt model | A code accepted in NF-e and forbidden on the counter receipt. | Check the indicator of use by model. |
Infrastructure and certificate
| Code | What the MOC rejects | Common cause at the counter | How to handle it |
|---|---|---|---|
| 281, 291 and 293 | Expired certificate, or an error in the certification chain | The establishment's certificate expired or was installed without the chain. | Monitor the validity of each certificate. |
| 108 and 109 | Service temporarily stopped, or with no forecast | State SEFAZ is down. | Check the service status and trigger contingency. |
| 702 | NFC-e not accepted by the issuer's state | An establishment without registration in the state. | Complete the registration before the first sale. |
CFOP, CST and CEST in the sale to the consumer
The NFC-e item carries fewer groups than the NF-e item, and the MOC rejects what does not fit the retail receipt.
CFOP for a sale to the consumer
In the books, NFC-e carries only a CFOP starting with 5. Rejection 725 blocks the CFOP that the MOC does not accept on the receipt.
CST and CSOSN
The item's ICMS rule comes from the issuer's tax regime. For CSOSN 500, the MOC accepts only CFOP 5.405, 5.656, 5.667 and 5.910.
CEST and tax substitution
An item with ICMS-ST and no CEST is rejected (806). The item's ST rule must be in the record before it reaches the register.
Groups that NFC-e does not carry
The MOC rejects on NFC-e the groups for IPI, import tax, ICMS sharing between states, and PIS-ST and COFINS-ST.
The calculation of the item's tax follows the design of the tax setup and of tax calculation in SAP. The tax thesis for each product belongs to the client, and DFSpro proves that the chosen rule reaches the receipt unchanged.
When the customer asks for the CPF and takes an ICMS credit at the counter, the receipt must carry the right identification. The article NFC-e at the counter gives a concrete case.
CST and classification by item, and what retail does not use
The new group enters the counter receipt's item with the same technical notes as NF-e, and some rules apply only to model 65.
The NFC-e item now carries the IBSCBS group, with the three-digit CST and the six-digit tax classification, and MOC rule 1115, rolled out in stages, rejects an item without this group.
IBS and CBS CST
A three-digit code, from the IBS and CBS CST table. Rejection 1020 applies to a code that does not exist.
Tax classification
A six-digit code, from the cClassTrib table, compatible with the CST (rejection 1024). The table carries the indicator of use by document model, and 1025 blocks a code not allowed on NFC-e.
Layout version
Technical note 2025.002, in version 1.52 published on 01/10/2026, is the one in force on the NF-e Portal. Validation rule 1115 is rolled out in stages in the MOC.
What NFC-e does not accept in the IBS and CBS group
- Presumed credit on the retail receipt, blocked by rejection 1049.
- IBS sub-calculation classification for the Manaus Free Trade Zone, blocked by 1165.
- CBS return group, blocked by 1187.
- Indicator code for the place of the supply operation, blocked by 1099.
- ICMS group provided for advance payment, blocked by 1280.
- Issuance by a taxpayer that is exclusive to IBS and CBS, and by a taxpayer without a state registration, blocked by 156.
The dates and the reading of each act are in electronic tax document legislation, and the calculation and tax assessment are in CBS and IBS in SAP.
The alphanumeric CNPJ also changes the NFC-e layout, a topic covered in alphanumeric CNPJ in SAP.
CPF on the receipt, limit by state, and non-face-to-face sale
Identification is mandatory in three situations. The rest is the consumer's choice.
| Situation | Consumer identification | What prints on the DANFE |
|---|---|---|
| Sale of BRL 10,000.00 or more | Mandatory, by CPF, CNPJ or foreigner document. The state can set another limit, and technical note 2026.002 provides a table with the limit for each state. | “CONSUMIDOR CPF” or “CNPJ”, with the number. |
| Consumer's request | Mandatory, at any value. | The identification requested, with the number. |
| Non-face-to-face operation | Mandatory, with the consumer's address. | The identification and the delivery address. |
| Sale below the limit, no request | Optional. | “CONSUMIDOR NÃO IDENTIFICADO”. |
DFSpro designs with the client the validated CPF field at the register, the limit for a sale without identification by state and by store, and the mandatory address for home delivery.
NFC-e accepts identifying the consumer by CNPJ, but the MOC rejects a recipient that is an ICMS taxpayer (789). A sale to a taxpayer follows the NF-e flow, which has its own page at electronic tax documents.
Payment method, change and the link to settlement
The counter receipt records how the sale was paid, and the reform links this information to the tax calculation.
Mandatory payment group
The layout requires the payment information group in NF-e and NFC-e. In an adjustment or return receipt, the payment method is “no payment”.
Method, amount and change
The DANFE prints the payment method, the amount paid and the change. Change has been mandatory since technical note 2016.002, and SAP must receive the three values from the register.
Link to split payment
Technical note 2026.006 created the YC group and event 110300 to link the receipt to the payment transaction. The topic is covered in split payment in SAP.
From the register to the file: what the books require from NFC-e
NFC-e enters the ICMS books with its own rules, leaner than those of NF-e.
| Where | What the official rule says | Check question |
|---|---|---|
| EFD ICMS/IPI, record C100 | NFC-e (code 65) enters only in outputs and never in inputs. The CFOP starts with 5. | Is every authorized NFC-e of the period in C100, and only the output ones? |
| EFD ICMS/IPI, records C190, C195 and C197 | As a rule, NFC-e carries only C100 and C190. Records C195 and C197 enter if state legislation requires an adjustment. C185 is at the state's discretion. | Does the C190 total by CFOP, CST and rate match the store's receipts? |
| EFD ICMS/IPI, C100 fields | The participant code, ICMS-ST, IPI, PIS and COFINS are not filled in for NFC-e. | Does the file leave without these fields, and is no participant created for the consumer's CPF? |
| Tax reform | Documents that carry only the new taxes and are not about ICMS or IPI are not entered in the books. | Does a counter receipt with ICMS and IBS and CBS enter normally? |
The ICMS calculation starts from the books, and the difference that starts on the receipt shows up later, in the payment slip. Both topics have their own service: SPED Fiscal and tax assessment.
The counter reconciliation compares, by store and by day, the total of authorized NFC-e with the register closing and with the ledger entry. To reconcile other documents the same way, see tax and accounting reconciliation in SAP.
What multiplies with each store opened
Series, CSC, certificate and registration are per establishment or per state. Forgetting one of them is the cause of the new store's first rejection.
Numbering and series per establishment
Each store numbers its receipts in sequence, from 1 to 999,999,999, within a series. The new store asks for its own series.
ICP-Brasil certificate
The signature uses a certificate with the CPF or CNPJ of any establishment of the taxpayer. The validity of each certificate goes into the chain's calendar.
CSC per company and per state
Up to 2 valid CSCs per company in each state. A third CSC requires revoking one of the two, and the new establishment uses the CSC already in force.
Registration per state
The store issues only after it is registered in the state where it holds its registration, and each state brings its own decisions on contingency, limit and DANFE.
Store opening checklist
- NFC-e registration in the state and the establishment's state registration.
- The establishment's series, CSC and certificate, with a renewal date.
- State parameters: contingency mode, identification limit and permission for home delivery.
- End-to-end test in the test environment: authorize, reject, enter contingency, cancel and check the status in SAP.
- Reconciliation of the first sales day against the register.
Whoever opens stores in a chain repeats the same problems, described in expanding chain and NFC-e. The topic also appears in tax rollout in SAP.
Test environment: what to prove before the real sale
The cheapest rejection is the one that happens in the test environment.
Notice on the DANFE
Every NFC-e issued in the test environment carries the text “EMITIDA EM AMBIENTE DE HOMOLOGAÇÃO, SEM VALOR FISCAL”, in capital letters and centered. Paper without this notice in a store is a sign of the wrong environment.
CSC for the test environment
The company asks the state Finance Secretariat for its own CSC to test with. The production CSC does not work for testing, and the test one does not work for the store.
Window between test and production
Each technical note gives the rollout date in the test environment and in production. The interval between the two is the time to prove the item, the rule and the return in SAP.
Minimum scenarios before opening a store or applying a technical note
- Authorize a simple sale and check the status in SAP.
- Trigger a rejection caused by item data and handle it until authorization.
- Enter contingency, issue, transmit later and resolve the pending receipt.
- Cancel within the deadline and try to cancel outside it.
- Sell above the identification limit, with and without a CPF.
- Issue an item with the IBS and CBS group and with a classification that is not allowed.
The method for each scenario, with the expected value written beforehand, is in tax testing in SAP.
Ten errors that repeat in retail, and how to avoid them
Each error has a symptom at the register and a prevention in the records or in the process.
| Common error | Effect | How to avoid it |
|---|---|---|
| Reusing the number of a receipt transmitted as normal when entering contingency | Duplicate (539) or two receipts for the same sale. | Move the numbering forward on entering contingency. |
| POS clock out of time | Rejection 703, with the sale stuck at the register. | Synchronize the clock of every POS to the same source. |
| CSC expired, revoked or from the test environment | A QR Code that does not match SEFAZ. | CSC per establishment and per environment, with a renewal date. |
| Item without a correct NCM or GTIN | Rejections 779, 611 and 883. | Clean up the master data before the load into the store. |
| CFOP and CST copied from NF-e to NFC-e | Rejection 725 and groups that NFC-e does not accept. | A tax rule of its own for the sale to the consumer. |
| Same identification limit in all states | Rejection 750, or identification requested without need. | Table of limits by state, applied by store. |
| Contingency without control of the transmission queue | A stuck receipt, at risk of passing the transmission deadline and the state's rule. | Dashboard of pending receipts by store and by age. |
| Canceling after the deadline or after the goods left | Rejection 501 and a sale without tax treatment. | Block cancellation outside the window and guide the register. |
| Voiding a number that contingency still transmits | The voiding request is canceled by the transmission of the receipt. | Check the status of the range before voiding. |
| Sale in SAP without a receipt, or with two receipts | A difference between the register, the receipt and the ledger. | Record the access key on the sale and reconcile by store and by day. |
Five numbers to look at every week
NFC-e fails silently when nobody looks at the dashboard, and five indicators cover most of the risk.
Rejections by code and by store
They show whether the cause is the item data, the issuer or one state. Act when a new code appears, or an old code grows in one store only.
Receipts in contingency, by age
They show how long a receipt has been stuck and how much time is left before the state's limit. Act when the age gets close to the transmission deadline.
SEFAZ response time, by state
It shows whether the response is within the service level of 30 seconds, 85% of the time. Act when the slowness repeats and contingency becomes routine.
Certificate and CSC validity
It shows the renewal calendar for each establishment. Act ahead of time, before rejection 281 stops the store.
Difference between register, receipt and ledger
It shows a sale without a receipt, a receipt without a sale, and a duplicate receipt, by store and by day. Act at the daily close, before the error reaches SPED.
The MOC warns that the tax authority can restrict contingency for those who overuse it. A dashboard by store shows the use before the tax authority does.
Six deliverables, from the current chain to reconciling the register
The deliverables follow the order of the problem: first the data, then the rule, the return, the test and the proof.
- 01
Chain diagnostic
Stores, states, issuer, integration and the latest rejections, starting from the tax diagnostic.
- 02
Item master data
NCM, CEST, GTIN, unit and origin, cleaned up and proved in tax master data.
- 03
Tax rule
ICMS, CST and CSOSN, and the IBS and CBS group, configured by item and by state.
- 04
Status return
Each receipt status handled in the client's landscape, with a pending queue and an owner for each case.
- 05
Contingency and rejection tested
Scenarios in the test environment, with the method from tax testing.
- 06
Reconciliation and bookkeeping
A report on the difference between register, receipt and ledger, and the proof of the ICMS file.
After delivery, the same routine returns with every new technical note and every store opened, within AMS Fiscal. If the landscape uses GUEPARDO Tax, DFSpro implements it and runs its governance. The license belongs to NTT DATA, owner of the product, and DFSpro sells it as an Authorized Channel.
Retail is a sector served by DFSpro, and the view by sector is in distribution and retail.
Who proves and who decides
The system shows what happens in each sale. Choosing how to operate within each state's rule belongs to whoever answers for the company.
DFSpro configures the tax layer in SAP and proves, with the data of your landscape, that the tax rule, the status return, contingency and reconciliation work as the company defined. The tax decision always belongs to the client.
DFSpro proves
- That the item data and the tax rule reach the receipt unchanged.
- That each receipt status, including contingency, shows up correctly in SAP.
- That cancellation, voiding and rejection follow the agreed path.
- That the register, the receipt and the books match, by store and by day.
The company and the issuer decide
- The tax thesis for each product and the matching CST.
- The contingency mode, among those the state accepts.
- The cancellation policy and the consumer identification policy.
- The issuer, the POS and the certificate, and the answer to a SEFAZ notice.
Reference rules and manuals
Ajuste SINIEF, MOC, technical notes and the Federal Revenue guide.
National legislation
Taxpayer Guidance Manual
Frequently asked questions about NFC-e in retail with SAP
01Does DFSpro issue my store's NFC-e?+
No. The issuer or the POS in your landscape builds, signs and transmits the receipt. DFSpro configures the tax layer in SAP: item master data, tax rule, status return, contingency and reconciliation, and proves that everything reaches the receipt as the company defined.
02Does it fit any issuance setup and any chain size?+
It fits the setups in which SAP takes part in the data, the rule, the return or the reconciliation, whether the issuer is external, integrated, or linked through an integration layer. What changes with size is the number of states, stores and issuers, and the scoping conversation defines the cut.
03We already have GUEPARDO Tax. Do I need anything more?+
GUEPARDO Tax belongs to NTT DATA, and DFSpro implements it, runs its governance and sells the license as an Authorized Channel. NFC-e also depends on the issuer and the integration. DFSpro checks, with the data of your landscape, which tax rule reaches the receipt and whether the return and the reconciliation close.
04What should the store have ready before the first conversation?+
The list of stores by state, the name of the issuer or POS, access to the SAP data, the latest rejections, and one person from the tax team and another from store IT who answer for what the rule leaves open. The rest is built together.
05How is contingency tested?+
In the test environment. Transmission is interrupted, a receipt is issued in contingency, transmitted later, and what SAP shows at each step is checked, including the sale that stayed without a receipt and the receipt pending a return. The evidence is kept with the date and the owner.
06What to do with a receipt issued in contingency that was not transmitted?+
Transmit it as soon as the failure ends, within the rule's deadline: up to the end of the first business day after issuance in offline contingency, and up to 168 hours in EPEC. The receipt may be rejected, and the deadline comes from Ajuste SINIEF 19/16. The dashboard of pending receipts by store keeps a receipt from passing the limit.
07Why is NFC-e rejected even with SAP configured?+
Because the cause is usually outside the tax rule: the item's NCM or GTIN, the unit, the POS clock, an expired certificate, a contingency mode the state does not accept, or the identification limit. Each MOC code points to one of these causes, and the most common ones have a defined treatment.
08Until when can I cancel an NFC-e?+
Within half an hour of the authorization of use and with the goods still in the store. The state can shorten the window, and after it the MOC rejects with code 501. There is also cancellation by replacement and cancellation of a receipt that contingency already covered, both with a 168-hour deadline.
09When is voiding needed and who makes the request?+
When the numbering sequence breaks and the number was not used. The taxpayer asks up to the 10th day of the following month, with a digital certificate and a justification. From 01/11/2026, three states are outside this request: Acre, Bahia and São Paulo. If the receipt is transmitted later, the request is canceled.
10Is the CPF on the receipt mandatory?+
In three situations: a sale of BRL 10,000.00 or more, the consumer's request, and a non-face-to-face operation, with the address. The state can set another limit for a sale without identification, and technical note 2026.002 provides a table by state. Outside these situations, the DANFE comes out with “consumer not identified”.
11What changes in NFC-e with the tax reform?+
The item now carries the IBS and CBS group, following the MOC's staged rollout, with the three-digit CST and the six-digit tax classification. The MOC lists what NFC-e does not accept in this group, such as presumed credit and CBS return. DFSpro configures the rule by item and proves the result, and the dates are in the electronic tax document legislation.
12Who decides the rule of each state?+
The state decides what Ajuste SINIEF and the MOC leave open, such as the acceptance of NFC-e, contingency, the short DANFE and the identification limit. The company decides how to operate within that rule. DFSpro keeps the matrix by state in SAP and proves that each store follows its own.
13How does NFC-e relate to NF-e?+
A sale to a taxpayer, an operation away from the counter and the other documents follow the NF-e flow. The MOC rejects NFC-e for a recipient that is an ICMS taxpayer. The NF-e flow has its own service, in electronic tax documents in SAP.
14What evidence should I keep for each store?+
The XML and the protocol of each receipt, the record of each contingency with reason, start and end, the cancellation and voiding requests, the day's reconciliation report, and the company's decision for each exception. That way, someone else can redo the check months later and reach the same result.
15What happens if the state SEFAZ goes down?+
The MOC returns codes 108 or 109, for a stopped service. The decision to enter contingency belongs to the taxpayer, without the tax authority's permission, and the mode the state accepts is the one that applies. After the outage, the receipts are transmitted on time and the pending ones are canceled or voided.
16Does NFC-e go into SPED Fiscal?+
Yes, in record C100, only in outputs, with a CFOP starting with 5. As a rule, it carries C100 and C190, and records C195 and C197 if state legislation requires. The EFD-ICMS/IPI Practical Guide also says not to fill in the participant, ICMS-ST, IPI, PIS and COFINS in C100.
17How is the scope closed and how do we start?+
Through contact. The company describes its stores, states, issuer and the last month's rejections, and the conversation defines the cut and the order of deliverables. Commercial terms come into the conversation after the scope is designed.
Bring last month's rejections and the list of stores by state
Tell us the issuer and the states where your chain operates. Describe your chain: issuer, states and the rejection that bothers you most. The scope starts from that conversation, with no price and no commitment on timing.
To go deeper first: electronic tax documents in SAP and electronic tax document legislation.