NF-e, NFS-e and CT-e issued from your own system
We connect your system to the state tax authority (SEFAZ), the NFS-e systems or an issuing API to issue, cancel, correct and query NF-e, NFS-e and CT-e.
Who it's for
For companies that issue tax documents in a separate system and retype the data for every sale or shipment.
What it solves
- Every order is typed again into the issuing system, and a typo becomes a rejected document.
- A rejected document sits there unnoticed while the goods wait.
- The digital certificate expired and issuing stopped without warning.
- Each municipality has its own way of issuing NFS-e, and the company works in several.
- The XML files are scattered across emails and folders, and the accountant asks for everything at month-end.
What we do
- Issuing from the order
- The document is built from the order or shipment data, and the authorisation result returns to the order.
- Events after issuing
- For NF-e and CT-e: cancellation, correction letters and voiding unused numbers. For NFS-e: cancellation and replacement. Reasons recorded.
- Rejections handled
- Each rejection shows its cause in plain language and goes into a queue to be fixed and resent.
- National and municipal NFS-e
- Issuing through the national NFS-e standard or the city hall's own system, depending on each municipality.
- Contingency
- What to do when SEFAZ or the issuing service is down, without stopping invoicing.
- Digital certificate
- Your company's digital certificate, usually an A1 certificate for automated issuing, protected, with a warning before it expires.
- XML archive
- Every authorised XML and event stored, searchable and exportable for the accountant.
What you get
- NF-e, NFS-e or CT-e issuing integration, in production
- A rejection queue with cause, correction and resending
- An archive of XML files and events, with search and export
- Alerts for rejections, services down and certificates about to expire
- Tests of every flow in the tax authorities' test environment
How we do it
Mapping
Which documents the company issues, in which states and municipalities, and where the data comes from.
Rules from your accountant
CFOP, CST and rates set by your accountant, turned into rules in the system.
Choosing the route
A direct connection to SEFAZ and the NFS-e systems, or through an issuing API.
Test environment
Issuing, cancellations and rejections tested in the test environment.
Go-live
A supervised switch to production, checking the first documents with the accountant.
Technology examples
- XML
- XSD
- XMLDSig
- SOAP
- REST
- PostgreSQL
- RabbitMQ
In Brazil, we handle
- NF-e
- Brazil's electronic invoice for goods.
- NFS-e
- Brazil's electronic invoice for services, in the national and municipal standards.
- CT-e
- Brazil's electronic transport document.
Related services
FAQ
Do you decide CFOP, CST and tax rates?
No. Tax interpretation stays with your accountant or tax team. Balkan turns those decisions into rules in the system and makes the integration work.
Should we connect straight to SEFAZ or use an issuing API?
It depends on volume and on how many states and municipalities are involved. A direct connection avoids an intermediary but means keeping up with every standard. An issuing API handles that, with its own cost and dependency.
Who holds the digital certificate?
It belongs to your company and stays in your environment, protected. The integration only uses it to sign documents, and nobody needs to receive it by email.
Does it work for carriers?
Yes. CT-e follows the same design: issuing from the shipment, events and XML storage. See also the logistics sector.
Write to Balkan
Talk to us about your project