Brazil NF-e, NFS-e & SPED Compliance

Brazil does not have an e-invoicing requirement so much as a fiscal operating system. A sale is not shipped until an NF-e has been authorised by the state SEFAZ and a 44-digit access key exists; a service invoice follows a different standard, sometimes a different municipality's rules; corrections, cancellations and unused numbering ranges are all separate fiscal events with their own windows; goods movements produce their own documents; and at the end of the period the whole ledger has to be reassembled into SPED digital books whose registers must agree with the documents that were authorised and with the inventory that actually moved. NetSuite can hold every one of those facts. Out of the box it does not assemble them into authorised fiscal documents or into SPED layouts, which is why Brazilian teams end up running an accounting system and a parallel fiscal process that only reconcile once a month, by hand, under deadline.

What ECOSIRE builds

ECOSIRE builds this suite for you. Nothing is pre-built, there is no trial edition, and no download exists until the build is done for your account. We scope it, quote a fixed price, build against a sandbox refresh of your real data, install into your sandbox for sign-off, then promote to production once your fiscal team has authorised and cancelled real documents themselves.

The implementation is native NetSuite work: SuiteScript 2.1 across User Event, Map/Reduce, Scheduled, Suitelet and RESTlet script types; SuiteFlow for authorisation, contingency and correction paths; custom records for fiscal configuration, document control and the full transmission log; custom segments where fiscal analysis needs a dimension your GL does not already carry; and Advanced PDF/HTML templates for the printed representations. It is delivered as an SDF project installed as an unmanaged bundle that you own, source included.

Goods documents: NF-e, NFC-e and fiscal events

A builder module composes the NF-e payload from the transaction and its lines: issuer and recipient blocks including state registration, per-line NCM, CEST, origin, CFOP and unit codes, and the tax blocks for ICMS with its situation code, tax substitution where it applies, the interstate differential, IPI, PIS and COFINS. Those values are not typed by a user; they are resolved from mapped fields on the Item, Customer and Subsidiary records and from a determination table we build to your tax team's rules.

Signing uses your A1 digital certificate. Where your account and release support server-side XML signing natively, we sign inside NetSuite; where they do not, we deploy a thin signing path against the component you already use, and either way the certificate stays under your control and the signed bytes are stored in your File Cabinet. Transmission goes to the correct state authority for the issuing subsidiary, and the returned authorisation protocol, access key and status are stamped onto custom transaction body fields. The DANFE is rendered from an Advanced PDF/HTML template carrying the access key and its barcode and attached to the transaction. Contingency handling, retries and numbering control run from a document-control custom record so two processes can never claim the same number.

Fiscal events are modelled as first-class records rather than checkboxes: cancellation within the permitted window, correction letters, invalidation of unused numbering ranges, and recipient acknowledgement for inbound documents. Each event stores its own protocol and signed response, so an auditor can be handed a complete chain per document.

Service invoices and inbound documents

Service invoicing is handled through a module that abstracts the differences between the national standard and the municipal variations that apply to the cities you actually operate in, with service codes, withholding rules and municipal identifiers held in custom records per subsidiary. Only the municipalities in your agreed scope are implemented, and adding another later is a defined, separately quoted extension rather than a rebuild.

On the inbound side, supplier documents are pulled or imported, parsed into a staging custom record, and matched against open Purchase Orders and Item Receipts by supplier registration, document number, access key and total. Matched documents become Vendor Bills with the source XML permanently attached and their fiscal data carried through to the books; unmatched ones queue on a Suitelet worklist.

SPED digital books

The SPED modules generate the fiscal and contributions files directly from the NetSuite ledger and the authorised documents, not from a re-keyed extract. Map/Reduce generators assemble the register blocks: the opening and participant registers, the document and item-detail registers for goods and services, the tax assessment registers, the inventory block, and the production and stock registers where your scope requires them. A validation pass runs before any file is written, checking that document totals agree with the authorised XML, that item registers resolve to real Item records, that periods are closed and that every register a downstream validator will inspect is populated. Failures are reported per register with a link to the offending NetSuite record, so the fix happens on the source data rather than in a text editor. Files land in the File Cabinet with a generation record capturing period, subsidiary, register counts and hash.

Who this is for

Brazilian entities on NetSuite that are currently running a parallel fiscal process, and multinational groups where Brazil is a OneWorld subsidiary whose local obligations dominate the close. It suits manufacturers and distributors whose ICMS substitution and interstate differential rules are non-trivial, service businesses invoicing across several municipalities, and controllers who need SPED files that reconcile to the ledger by construction rather than by reconciliation.

How delivery works

1. Scoping call. We map your transaction types, item and customer masters, states and municipalities of operation, tax determination rules, certificate arrangement, volumes and which SPED books are in scope. 2. Fixed quote. You receive a written scope with the register-by-register and field-by-field mapping, optional modules priced separately, and a delivery date. Nothing is built until you accept. 3. Build. Development runs against a sandbox refresh so we work with your real master data and your real tax configuration. 4. Install in test. The bundle goes into your sandbox and connects to the authorities' test environments. Your team authorises, cancels, corrects and generates a full test period, and signs off. 5. Production. Installation into production in your chosen window, with configuration and certificate arrangements migrated, followed by hands-on support through the first authorisation cycle. 6. Support window. A defined post-go-live support period is included in the quote, covering defects, layout and code-table updates, and support through your first SPED submission.

What we do not claim

This is a build, not a download, and there is no trial. We are not a certified partner of any software vendor and we do not resell anyone's localisation. We do not provide tax advice and we do not invent tax rules: your tax team or advisors define the determination logic, the CFOP and situation-code matrices, the withholding treatments and which books apply, and we encode those decisions into configuration records you can maintain. Only the states, municipalities, document types and SPED books named in the quote are built. Brazilian fiscal legislation moves, including the ongoing consumption-tax transition, so layouts and code tables are configuration wherever possible; structural changes are covered during the support window and quoted as change requests afterwards.