Brazil’s electronic invoicing environment is highly structured. A receivables invoice cannot simply be created in CargoWise and treated as complete. When the transaction qualifies for NFS-e reporting, the right tax authority, service codes, organization registrations, tax details, compliance numbering, and invoice data all need to align before the message can be accepted.
CargoWise now supports integration with the SEFIN Nacional NFS-e APIs published by Brazil’s Federal Government. The process allows eligible CargoWise accounts receivable transactions to be reported electronically for NFS-e authorization through the centralized SEFIN Nacional platform.
For finance and CargoWise administrators operating in Brazil, understanding how this flow works is important because many reporting failures begin with configuration or master-data problems long before the API call is made.
What is Brazil SEFIN Nacional E-Reporting in CargoWise?
The SEFIN Nacional schema is used for reporting taxable sales of services for NFS-e authorization.
In CargoWise, an accounts receivable invoice becomes eligible for this reporting process when the relevant ISS tax authority has transitioned to the Nacional schema and CargoWise messaging has been configured to support that authority.
The process is not simply CargoWise sending an invoice directly to the government.
CargoWise first generates a GEI – Global Electronic Invoice message, which contains a version of the Universal Transaction XML. That message is sent to eHub, where the invoice information is mapped into the SEFIN Nacional schema before the required API calls are made.
This creates an end-to-end flow between:
CargoWise → eHub → SEFIN Nacional → eHub → CargoWise
For users, the important point is that the information entered and configured in CargoWise becomes the source data used to construct the government submission.
What Happens After a CargoWise Invoice is Posted?
The process starts when an eligible AR INV transaction is posted and queued for e-Reporting.
CargoWise sends the GEI to eHub. eHub then maps that data into the Nacional schema and constructs a unique DPS ID.
Before submitting the invoice, eHub makes a DPS Existence API call to determine whether that DPS already exists in the SEFIN system.
If it does not exist, the process moves to DPS Submission.
If SEFIN says the DPS already exists, eHub instead makes a DPS Status Request.
This existence check is particularly useful because it helps prevent the process from simply resubmitting an invoice when the original response may have been lost because of a system or communications interruption.
What is the DPS ID and Why does it Matter?
Every new invoice reported for NFS-e authorization uses a 45-character DPS ID.
According to the CargoWise technical guide, the ID is constructed from several values, including:
- Fixed text identifying the DPS
- Seven-digit municipal IBGE code
- CNPJ
- Tax registration type
- Compliance Book prefix
- DPS number
The resulting structure is used during the DPS Existence, DPS Submission, and DPS Status API calls.
This is a good example of why Brazil e-Reporting depends heavily on CargoWise configuration.
The DPS identifier is not something an operator manually types every time. It is constructed from existing transaction and master-data values.
If those values are wrong, the message itself can be wrong.
Why does the Compliance Book Prefix Need Special Attention?
One configuration detail can create an avoidable reporting failure: the Compliance Book prefix.
The Nacional schema requires the prefix, or Serie, to contain numbers only. CargoWise documentation states that compliance books used by the branch for taxable NFS-e sales should use a prefix between 00001 and 49999 for electronically reported authorization requests.
This is the kind of requirement that can easily be overlooked during implementation.
The invoice may otherwise look correct to the user, but if the Compliance Book configuration does not meet the schema requirement, the outbound mapping can fail.
That is why Brazil e-Reporting setup should be reviewed at the configuration level before teams begin troubleshooting individual invoices.
What Information is Mapped from CargoWise into the NFS-e Submission?
The Nacional schema requires information from several areas of the CargoWise transaction.
The DPS mapping can include data relating to:
- Invoice and compliance number
- Issuing branch
- CNPJ
- Municipal registration
- Receivable organization
- Local or foreign customer addresses
- Service location
- ISS service codes
- NBS code
- Invoice currency
- Service value
- ISS
- PIS
- COFINS
- CSLL
- IRRF
- IBS and CBS data where applicable
The correct mapping depends on how the relevant transaction, organization, tax, and registration information has been configured.
For example, the recipient structure differs depending on whether the receivable organization is located inside or outside Brazil.
For Brazilian organizations, a CNPJ or CPF must be reported. If the organization is recorded as being in Brazil but neither is available, CargoWise cannot complete the mapping and returns an error so the user can correct the organization before re-queuing the transaction.
For foreign recipients, the mapping instead looks for an appropriate NIF or applies the relevant fallback where one cannot be provided.
This makes organization master-data quality critical to successful Brazil e-Reporting.
How are ISS Service Codes Mapped?
Service-code configuration is another important area.
CargoWise maps the ISS Tax Transaction service code into Nacional schema values such as cTribNac and, where appropriate, cTribMun.
A nine-digit ISS service code can be separated so that the first six digits populate the national taxation code while the final three populate the municipal sub-code.
For example, the guide shows a nine-digit service code of 330101100 mapping as:
cTribNac = 330101
cTribMun = 100
A six-digit code would populate cTribNac, while cTribMun would not be reported.
These rules show why tax and service codes should be configured deliberately rather than treated as free-text operational fields.
How does CargoWise Handle PIS, COFINS and CSLL?
The 2026 guide includes updated mapping for the federal tax group following SEFIN technical guidance.
CargoWise can map PISPROV and COFPROV turnover transactions into the piscofins group of the DPS message, while PIS, COFINS, and CSLL retention amounts can also contribute to the relevant retention reporting.
The retention flag is determined according to which combinations of PIS, COFINS, and CSLL transactions exist.
This demonstrates another important principle of e-Reporting:
The government XML is not created independently of accounting.
It is built from the tax transactions recorded against the CargoWise invoice.
Incorrect tax configuration can therefore become incorrect reporting.
What Happens When SEFIN Accepts or Rejects the Invoice?
After a DPS Submission call, SEFIN returns either a successful response or a rejection.
For an approved submission, the response includes information such as the:
- NFS-e Access Key
- NFS-e number
- Authorization date and time
If the submission is rejected, an error code and error details are returned instead.
eHub converts the SEFIN response into a Universal Event XML, or XUE, which is returned to CargoWise.
CargoWise then updates the relevant transaction’s e-Reporting status.
A successful transaction can be updated to SUC, while a rejected transaction becomes FAL, with the rejection information recorded against the transaction. The NFS-e number, authorization date, and Access Key are saved when authorization succeeds.
This provides a closed-loop process rather than requiring finance teams to check a separate government portal and then manually update CargoWise.
How are NFS-e Cancellations Handled?
The reporting lifecycle does not end once an invoice is authorized.
CargoWise also supports NFS-e cancellation events.
When an invoice containing authorized NFS-e details is reversed, the reversal credit note can trigger the e-Reporting process.
The GEI includes the original invoice’s NFS-e Access Key, which eHub uses to construct the cancellation API request. SEFIN then returns either an accepted or rejected cancellation response, which is sent back to CargoWise through XUE.
The cancellation process also evaluates the CargoWise reversal reason and maps that information into the appropriate cancellation reason fields.
For finance teams, this means reversal-reason configuration is not merely internal accounting information. It can influence the electronic message reported externally.
Why does CargoWise Master Data Matter so Much for Brazil E-Reporting?
Many e-Reporting failures are likely to appear technical because the final symptom is a rejected XML or failed API response.
But the actual problem may be much simpler.
A missing CNPJ.
An incorrect municipal registration.
A Compliance Book prefix that contains letters.
A Brazilian city that cannot be mapped to an IBGE code.
An incorrect ISS service code.
A missing tax transaction.
The guide specifically notes, for example, that when eHub cannot match a Brazilian city to an IBGE municipal code, the Nacional schema does not accept a dummy code. An error is returned to CargoWise, so the user must correct the address before the transaction can be re-queued.
That is why e-Reporting implementation should focus as much on data governance and configuration as it does on the technical interface.
How Elicit Helps with CargoWise Brazil E-Reporting Configuration?
Brazil e-Reporting brings accounting configuration, tax setup, organization master data, Compliance Books, eHub messaging, and government API requirements together in one process.
That makes implementation difficult to manage through isolated fixes.
As an official CargoWise Service and Business Partner, Elicit Technology can help CargoWise users review the configuration and data dependencies that support electronic invoicing and government reporting.
Our certified consultants can support CargoWise accounting configuration, e-invoicing integration, registry setup, tax configuration, XML mapping, troubleshooting, workflow design, testing, and ongoing system optimization.
The objective is not simply to get one invoice accepted.
It is to build a configuration where eligible transactions can flow consistently from CargoWise to SEFIN and back without teams manually repairing the same problems each time.
Conclusion
CargoWise’s integration with the Brazil SEFIN Nacional NFS-e schema provides a structured process for reporting eligible receivables invoices for electronic authorization.
CargoWise creates the accounting transaction and GEI message. eHub maps the information, builds the DPS ID, communicates with the SEFIN APIs, and returns the resulting authorization or rejection information through XUE.
But the success of that automation depends heavily on what sits underneath it.
Compliance Book prefixes, CNPJ and CPF records, municipal registrations, IBGE city information, ISS service codes, tax transactions, customer data, and reversal reasons all influence what eventually reaches the government system.
For CargoWise users operating in Brazil, effective e-Reporting therefore starts before the API call.
It starts with getting the CargoWise accounting, tax, organization, and compliance configuration right at the source.
