Brazil
B2B, B2C, Outbound, Inbound, Tax Reporting
2026-08-28
Brazil should be modeled as a family of electronic fiscal documents, not as a country connector with one invoice payload.
How to use this guide
A useful project outcome is not a document that merely repeats the rule. It is a traceable decision model that connects the rule to legal entities, transaction scenarios, source data, system behaviour, operating ownership and evidence.
End-to-end operating flow
A platform call is one stage inside a longer business lifecycle.
- Qualify
Determine scope, channel and document path before building the payload. - Validate
Block incomplete identities, tax facts, amounts and references before transmission. - Generate
Create the platform-specific representation with a traceable mapping version. - Submit
Use idempotency and a correlation key so retries do not silently duplicate documents. - Interpret
Convert every response into a finance-readable status and responsible action. - Deliver and reconcile
Coordinate customer delivery with the validated or reported result and ledger posting. - Retain
Archive source, payload, response, representation and later events as one evidence chain.
Country-specific decisions
01
Different transactions require different documents
The Receita Federal catalog distinguishes NF-e for goods, NFC-e for consumer retail, NFS-e for services, CT-e for transport and MDF-e for transport-document control, alongside other specialized documents.
02
Authority and platform vary
Goods and transport documents commonly involve state tax-authority services, while service invoicing has municipal responsibilities and an evolving national NFS-e standard. Legal entity and transaction context determine the route.
03
Build a document-family inventory
A global program should list each Brazilian transaction, document model, issuer, recipient, authorization authority, lifecycle events and archive requirement before designing interfaces.
Treat every artifact as a separate controlled object
The commercial invoice, transmitted payload, authority response and customer document may be related, but they are not interchangeable. Their distinct identities must remain visible in monitoring, reconciliation and audit retrieval.
| Decision area | What must be decided | Evidence to retain |
|---|---|---|
| Source transaction | Identify the authoritative ERP document and the event that makes it eligible for processing. | Document key, version, company, timestamps and source status. |
| Structured payload | Generate the required national or platform representation from validated facts. | Payload version, mapping version, checksum and submission correlation ID. |
| Platform response | Interpret technical and business responses without collapsing them into one success flag. | Raw response, normalized status, reason and next action. |
| Customer representation | Deliver the legally and commercially appropriate readable document through the agreed channel. | Delivered document, recipient, channel and delivery time. |
| Adjustment chain | Link replacement, cancellation, credit/debit or other follow-on documents to the original identity. | Original reference, event history and final reconciled status. |
Failure scenarios the design must handle
- Validation rejection after the ERP invoice has already been posted.
- Network timeout where the platform may have accepted the document but the sender did not receive the response.
- Duplicate submission with a different technical message ID but the same business invoice.
- Authority acceptance without successful customer delivery or finance reconciliation.
- A later correction that breaks the link to the original submitted and delivered artifacts.
Official sources
- Receita Federal electronic fiscal documents catalog
- Receita Federal guidance for the 2026 consumption tax reform
- RFB/CGIBS 2026 implementation calendar for electronic fiscal documents
- Receita Federal and CGIBS notice on temporary validation flexibility
- National NFS-e Technical Note 009