Brazil NF-e Fiscal Document Compliance

The problem

Brazil is the hardest fiscal environment most F&O programmes will meet. A sale is not authorised by a single national service but by the SEFAZ of the issuing state, each with its own availability and its own contingency behaviour. The document itself — NF-e — carries a layered tax calculation where ICMS, ICMS-ST, IPI, PIS and COFINS interact with CFOP, CST/CSOSN, NCM and the operation's origin and destination. Services are a different document entirely (NFS-e, governed municipally), freight is another (CT-e), and everything eventually has to reconcile into SPED fiscal and accounting obligations.

The operational risk is blunt: goods cannot legally leave the dock without an authorised NF-e and a printable DANFE. When a state service is down, you need contingency, not a queue. When a document is rejected for a CFOP that does not match the operation, someone has to see that message, not a generic failure. And the fiscal data behind it all has to be complete enough that SPED files can be produced from the system rather than reconstructed from it.

What ECOSIRE builds

ECOSIRE builds a Brazilian fiscal document extension for your Dynamics 365 Finance & Operations environment. It is X++ extension code in a dedicated model — event handlers, chain of command, table and form extensions, no overlayering — packaged and released through your LCS or Azure DevOps pipeline.

Fiscal document generation

Sales invoices, transfer orders and returns produce NF-e XML with the fields the layered tax model actually requires: CFOP per line derived from the operation, CST or CSOSN, NCM, origin, unit conversion, and the ICMS / ICMS-ST / IPI / PIS / COFINS groups. Ledger dimensions and posting profiles stay in F&O where they belong; the extension reads them rather than duplicating them, so the fiscal document and the financial posting cannot drift apart.

SEFAZ authorisation and contingency

A transmission service handles certificate-based signing and the call to the SEFAZ authorisation service for the issuing state, storing the protocol number, authorisation key and returned XML. State-level endpoint configuration lets a group operating in several states run one code base. When a service is unavailable, contingency handling issues the document under the configured contingency mode and reconciles it when the service returns — with the reconciliation tracked, not left to memory.

DANFE, CT-e and NFS-e

DANFE output is generated for print and PDF from the authorised XML. Where freight is in scope, CT-e is handled with the same authorisation and storage pattern. NFS-e, being municipal, is built against the specific municipalities in your scope — this is quoted explicitly, because a build covering three municipalities is a different job from one covering thirty.

Cancellation, CC-e and inutilização

The full correction lifecycle is implemented: cancellation inside the permitted window, carta de correção electronica for permitted field corrections, and inutilização for unused number ranges. Each stores the authority's response against the document, so the fiscal history is complete.

Operations, batch and data

Batch framework jobs drive transmission, status query and retry with bounded, idempotent logic keyed on the document — a re-run never produces a second authorisation attempt for an already authorised key. A workspace shows pending, authorised, rejected and contingency documents with the SEFAZ rejection text attached, and a monitoring tile for documents blocking dispatch. Fiscal books data is exposed through data entities over OData and the Data management framework so SPED generation and your Power BI reporting read the same records. Where your warehouse operation needs it, authorisation status is surfaced so the warehouse mobile app flow does not release a load whose document is not authorised.

Who this is for

Manufacturers, distributors and multi-state operations running Brazilian legal entities on F&O, particularly groups issuing from more than one state, moving goods between their own sites, or carrying both goods and service revenue in the same entity.

How delivery works

This is built to order — there is no ready-made download. A scoping call establishes your legal entities, issuing states, municipalities for NFS-e, whether CT-e is in scope, your certificate handling, and your tax determination setup. You get a fixed quote against that written scope. ECOSIRE builds against your F&O version, delivers a deployable package, and installs it in your test or sandbox environment, where we authorise real document shapes against the SEFAZ homologation environment with your fiscal team present. Production cutover follows your normal release process, and a support window covers defects and authority-driven schema changes after go-live.

Lead time is typically two to four weeks from signed quote for a focused NF-e scope; broad scope across many states, municipalities and CT-e is quoted with its own timeline at scoping.