The Brazilian Freight Document
Why CT-e XMLs Still Require Manual Re-Entry

The CT-e Paradox: Born Digital, Manually Re-Typed

The term "electronic freight document" creates an expectation in any logistics professional who hears it: that the data flows electronically from the carrier's system to the consignee's system, because that is what electronic documents do. But the CT-e is electronic in a specific sense — it is an electronic fiscal document submitted to and authorized by the state tax authority before the cargo moves. Its primary consumer is SEFAZ, not the shipper, not the consignee, and certainly not the freight analyst who needs the service value to hit the cost ledger.

Brazil's SEFAZ system processes over 300 million CT-e documents annually across 27 independent state tax authorities. The system is designed to ensure that every freight movement can be traced, taxed, and audited. It is not designed to deliver structured data to the consignee's logistics system. The carrier receives the authorized XML as part of the issuance flow. Whether the consignee receives it depends entirely on the carrier's billing and integration capabilities — which, in a fragmented industry of over 650,000 registered carriers, vary enormously.

The CT-e data extraction guide covers the practical workflow for turning DACTE printouts into structured spreadsheet rows. This article steps back to examine the structural reasons that workflow is needed in the first place — the four layers of the CT-e paradox that keep manual data re-entry alive in Brazilian logistics operations of every size.

Layer 1: XML Accessibility — Why Carriers Don't Send the Structured File

The most direct explanation for manual re-entry would seem to be the easiest to fix: carriers have the CT-e XML, consignees want it, so carriers should send it. In practice, the flow of the XML from carrier to consignee is obstructed by three structural factors that no single party can resolve.

First, the XML is addressed to SEFAZ, not to the consignee. When a carrier issues a CT-e, the XML is signed and transmitted to the state tax authority for authorization. The consignee is a data field within the document — a recipient in the legal/operational sense, not in the data-flow sense. The carrier's obligation is to deliver the goods and provide the DACTE printout or PDF that accompanies them. Delivering the XML is a commercial service, not a legal requirement, and many carriers treat it as an upsell feature in their billing portal.

Second, the carrier landscape is too fragmented for XML-as-standard. Brazil's road freight sector includes approximately 650,000 registered carriers. The largest, like JSL (publicly traded, ~R$8 billion revenue) and Braspress (the largest LTL carrier in Latin America), operate sophisticated billing portals that provide XML download, API access, and automated invoice delivery. But the majority of carriers are small — single-truck owner-operators (transportador autônomo) or regional companies with fewer than ten vehicles. Their CT-e issuance workflow may be a free SEFAZ web portal or a basic emissor CT-e software that generates the XML for SEFAZ but has no mechanism to deliver it to the consignee afterward. For these carriers, providing the DACTE PDF by email is the limit of their digital capabilities.

Third, the consignee's own system may not be able to consume the XML. Even when a carrier provides the XML — which many large carriers do as a default — the consignee's logistics system or ERP must be configured to import it. In the Brazilian ERP ecosystem, CT-e XML import is supported by SAP's TDF (Tax Declaration Framework, which requires an SAP S/4HANA implementation costing upwards of R$500,000 in consulting fees) and TOTVS Protheus's fiscal module (R$2,000–R$10,000 per month in licensing). For mid-market companies that fall between "too large for fully manual" and "too small for ERP module investment," the XML arrives but lands in the same email inbox as the DACTE PDF — and the freight analyst opens the PDF because that is what she has always done.

Layer 2: The DACTE as the De Facto Information Source

The DACTE (Documento Auxiliar do Conhecimento de Transporte Eletrônico) exists by regulatory design — it is the printed summary that must physically accompany the goods under the terms of Ajuste SINIEF 07/2007. It serves the enforcement purpose: when a vehicle is stopped at a SEFAZ roadblock (blitz fiscal), the driver presents the DACTE, and the inspector scans the QR code or enters the chave de acesso to verify the cargo against the authorized CT-e. It is a document designed for inspection, not for data transfer.

In practice, the DACTE has become the consignee's primary information source for a reason that has nothing to do with the regulation: it is the only document that consistently arrives with the goods. The XML may or may not come. The DACTE always does — because the cargo cannot move without it.

The DACTE carries between 30 and 50 data points, a subset of the full CT-e XML. The full schema includes line-item-level cargo descriptions, multiple tax breakdowns per product, referenced NF-e access keys, and free-text additional information (informações complementares) that may contain contractual references or special handling instructions. Much of this data is not printed on the DACTE. A logistics team working solely from the DACTE is therefore operating on a reduced dataset — and the reduction introduces its own risks. The valor a receber may differ from the valor do serviço due to withholdings listed only in the XML. The ICMS base calculation depends on tax rates and exclusions that the DACTE may present as a single final figure without showing the intermediate steps.

Despite these limitations, the DACTE is what the logistics team has. The data entry task is defined by what is on the printed page, not by what is in the XML. And that is where the second layer of the paradox operates: the document that is easiest to access (the DACTE printout) carries less data than the document that is harder to access (the XML), but the team builds its process around the accessible one.

Layer 3: ERP Module Cost — When the Technical Fix Is Too Expensive

The technically correct solution to the CT-e data paradox is well understood in Brazilian logistics and finance circles: implement an ERP module that imports the CT-e XML directly, validates it against SEFAZ records, and posts the freight cost entries automatically. SAP TDF, TOTVS Protheus Fiscal, and Oracle's Brazilian localization modules all support this flow. The technology exists. The cost, for most mid-market logistics operations, is prohibitive.

SAP TDF sits on top of SAP S/4HANA. A company that is not already on S/4HANA faces a multi-year, multi-million-real ERP transformation before it can even consider the CT-e import module. For the companies that are already on S/4HANA, a TDF implementation runs 6–12 months and costs R$200,000–R$500,000 in consulting fees, plus ongoing licensing costs that vary by user count and module configuration.

TOTVS Protheus, while more accessible for the Brazilian mid-market, still imposes a licensing cost of R$2,000–R$10,000 per month depending on the module stack, plus implementation consulting. The decision to add the fiscal module is not driven by CT-e alone — it is a broader investment in the company's financial and fiscal infrastructure. The CT-e import feature is a line item within a larger business case, and if the company's NF-e processing is already handled manually without a module, adding the module for CT-e alone rarely clears the ROI threshold.

The result is a processing vacuum. Large enterprises on SAP S/4HANA with TDF can process CT-e XML automatically. Very small operations processing 20 CT-e per month continue manually because the volume does not justify any investment. Mid-market operations — 200–500 CT-e per month — occupy the painful middle: the manual process costs R$30,000–R$80,000 per year in labor, but the ERP module costs more to implement than the manual process costs in a single year. The investment case requires a multi-year view that many companies are not structured to evaluate.

Layer 4: Industry Fragmentation — 650,000+ Carriers

The structural factor that amplifies every other layer is the scale and fragmentation of Brazil's road freight industry. The ANTT-registered carrier base of approximately 650,000 operators makes standardization across the industry a theoretical ideal that no practical system can achieve. A consignee receiving inbound freight from 200 suppliers may interact with 80–100 different carriers in a single month. Each uses its own billing system, its own DACTE layout variant, its own email delivery format, and its own definition of "invoice delivery."

ERP integration at the carrier level — where each carrier pushes its CT-e XML to the consignee's system — would require each of those 80–100 carriers to support an API integration. For the large carriers, this is feasible. For the majority of small carriers and owner-operators, it is not. The industry's structure makes a fully integrated data pipeline an unrealistic target for most consignees, regardless of their ERP investment.

The practical implication: the consignee's data entry problem is not that carriers refuse to send the XML. It is that the data arrives through 100 different channels, in 100 different DACTE layouts, and the only common denominator is the printed page that accompanies the goods. Any solution that requires per-carrier integration — whether API setup, XML parsing customization, or template configuration — breaks when the carrier count exceeds a handful.

This is why extraction at the visual layer — reading the DACTE printout as an image and converting it to structured data — is not a workaround for the integration problem but the only solution that directly addresses industry fragmentation. It requires zero action from the carrier. It handles any DACTE layout from any carrier in the same batch. And it does not depend on the consignee's ERP roadmap.

What Extraction at the Visual Layer Changes

The four layers of the CT-e paradox — XML inaccessibility, DACTE as default, ERP module cost, industry fragmentation — form a structural trap that manual process redesign cannot escape. Each layer is independently solvable for a subset of cases, but the combination covers virtually every logistics operation: large enough to have scale, fragmented enough to preclude standardization, and just below the investment threshold for the enterprise solution.

Visual extraction — treating the DACTE printout as the source document and extracting its data through AI-powered Custom Column Extraction — breaks the trap at a different point. It does not require the XML to flow from carrier to consignee (Layer 1). It works with the DACTE that is already available (Layer 2). It costs orders of magnitude less than an ERP module and delivers results within hours, not months (Layer 3). And it handles all carrier layouts in a single batch with no per-carrier integration (Layer 4).

The mechanism is straightforward: upload the DACTE PDF or image, enter the column names you want extracted, and the AI locates each value on the printed page by understanding what it means — not by matching a pre-configured template. The output is a spreadsheet row per document, ready for your existing cost ledger or ERP import. The step-by-step CT-e extraction guide walks through the column definitions and processing workflow.

For teams that need more than per-document extraction — including computed columns that calculate freight cost per kg, effective ICMS rate validation, or monthly batch aggregation — the batch processing guide for CT-e freight cost ledgers extends the workflow to handle multi-carrier batches with built-in cost analysis.

Frequently Asked Questions

Can't I just request the CT-e XML from the carrier?

You can request it. Whether you receive it reliably depends on the carrier. Large carriers (JSL, Braspress, Rodonaves) typically provide XML download through their billing portals. Small carriers and owner-operators may not have a mechanism to resend or share the XML after issuance, because their issuance tool is a free SEFAZ web form that sends the XML only to the government. In practice, procurement contracts with large carriers can mandate XML delivery; with the rest of the market, the DACTE PDF or printout is what you will get.

Is the DACTE printout enough data, or do I need the full XML?

The DACTE contains the data needed for cost tracking and carrier payment — service value, ICMS amount, weight, route, parties. It does not contain the full line-item cargo detail, some tax breakdowns at the per-product level, or the complete event history (CT-e amendments, cancellation events). For freight cost accounting, the DACTE covers the essential fields. For SPED EFD ICMS/IPI compliance at the highest level of detail, the full XML is preferable. The practical strategy: extract the DACTE for cost tracking; request the XML for compliance when the tax team needs the complete tax breakdown.

What is the actual cost of implementing CT-e XML import in my ERP?

For SAP S/4HANA with TDF, estimate R$200,000–R$500,000 in consulting fees plus 6–12 months of implementation, on top of the S/4HANA license itself. For TOTVS Protheus, estimate R$24,000–R$120,000 per year in licensing (R$2,000–R$10,000/month) plus implementation consulting at R$30,000–R$80,000. For Oracle or Sage equivalent modules, the cost is comparable. These figures are for the ERP module implementation that covers all Brazilian tax documents — CT-e XML import is a feature within a larger module scope. Some smaller ERP localization packages may offer CT-e import at a lower cost, but generally require the company to already be on that ERP platform.

Can I require my carriers to send the XML in my procurement contracts?

You can — and large shippers often do. The practical limitation is that the enforcement lever works for carriers who compete for your business. For spot shipments, emergency freight, or routes served by only one or two carriers, the leverage is weaker. And for the many small carriers who deliver inbound freight from your suppliers (not carriers you contracted), you have no contractual relationship at all. In these cases — which make up a significant share of inbound freight for most manufacturers — the DACTE is the only document that exists between you and the transportation data.

Does visual extraction from the DACTE produce the same accuracy as XML parsing?

XML parsing is 100% accurate because the data is already structured. Visual extraction from a DACTE printout or PDF introduces the accuracy limitations of any AI document reading — excellent on clean PDFs and scans (up to 99% on printed fields), slightly lower on poor-quality photographs or handwritten annotations. The difference is that XML parsing is not always available, and visual extraction is always possible. The choice is not between XML accuracy and DACTE accuracy; it is between DACTE extraction (with its small accuracy trade-off) and manual re-typing the DACTE (with its 1–4% error rate and 90-second-per-document time cost).

Where does the CT-e fit in Brazil's broader electronic document ecosystem?

The CT-e operates alongside the NF-e (goods invoice), NFS-e (service invoice), MDF-e (freight manifest that groups multiple CT-e documents onto one vehicle), and BP-e (passenger ticket). For logistics cost management, the key relationship is between the CT-e and the NF-e: the CT-e documents the transport cost, the NF-e documents the goods value, and the two together produce total landed cost. The Brazilian electronic document hub guide provides a complete overview of how these documents interact and where each one fits in the logistics workflow.