O Documento de Frete Brasileiro
Por que os XMLs do CT-e Ainda Exigem Digitação Manual

O Paradoxo do CT-e: Nascido Digital, Redigitado Manualmente

O termo "documento fiscal eletrónico" cria uma expectativa em qualquer profissional de logística que o ouça: que os dados fluem eletronicamente do sistema do transportador ao sistema do consignatário, porque é o que os documentos eletrónicos fazem. Mas o CT-e é eletrónico num sentido específico — é um documento fiscal eletrónico enviado e autorizado pela administración tributária estadual antes de que a carga se mova. O seu principal consumidor é a SEFAZ, não o remitente, não o consignatário, e certamente não o analista de frete que precisa que o valor do serviço chegue ao ledger de custos.

O sistema SEFAZ do Brasil processa mais de 300 milhões de documentos CT-e anualmente em 27 administraciones tributárias estaduais independentes. O sistema está desenhado para garantir que cada movimento de frete possa ser rastreado, tributado e auditado. Não está desenhado para entregar dados estruturados ao sistema de logística do consignatário. O transportador recebe o XML autorizado como parte do fluxo de emissão. Se o consignatário o recebe depende inteiramente das capacidades de facturação e integração do transportador — que, numa indústria fragmentada de mais de 650.000 transportadores registrados, variam enormemente.

O guia de extração de dados CT-e cobre o fluxo de trabalho prático para converter impressões DACTE em filas de planilha estruturadas. Este artigo recua para examinar as razões estruturais pelas quais esse fluxo de trabalho é necessário em primeiro lugar — as quatro camadas do paradoxo do CT-e que mantienen viva a re-digitação manual de dados em operações logísticas brasileiras de todos os tamanhos.

Camada 1: Acessibilidade do XML — Por que as Transportadoras Não Enviam o Arquivo Estruturado

A explicação mais direta para a digitação manual pareceria a mais fácil de resolver: as transportadoras têm o XML do CT-e, os consignatários o querem, então as transportadoras deveriam enviá-lo. Na prática, o fluxo do XML da transportadora para o consignatário é obstruído por três fatores estruturais que nenhuma parte isolada consegue resolver.

Primeiro, o XML é endereçado à SEFAZ, não ao consignatário. Quando uma transportadora emite um CT-e, o XML é assinado e transmitido à autoridade fiscal estadual para autorização. O consignatário é um campo de dados dentro do documento — um destinatário no sentido jurídico/operacional, não no sentido de fluxo de dados. A obrigação da transportadora é entregar as mercadorias e fornecer o DACTE impresso ou em PDF que as acompanha. Entregar o XML é um serviço comercial, não uma exigência legal, e muitas transportadoras tratam isso como um recurso de venda adicional em seu portal de faturamento.

Segundo, o cenário de transportadoras é fragmentado demais para o XML como padrão. O setor de transporte rodoviário de cargas do Brasil inclui aproximadamente 650.000 transportadoras registradas. As maiores, como JSL (de capital aberto, ~R$8 bilhões de receita) e Braspress (a maior transportadora LTL da América Latina), operam portais de faturamento sofisticados que oferecem download de XML, acesso via API e entrega automatizada de notas fiscais. Mas a maioria das transportadoras é pequena — caminhoneiros autônomos (transportador autônomo) ou empresas regionais com menos de dez veículos. Seu fluxo de emissão de CT-e pode ser um portal web gratuito da SEFAZ ou um software emissor de CT-e básico que gera o XML para a SEFAZ, mas não tem mecanismo para entregá-lo ao consignatário depois. Para essas transportadoras, fornecer o PDF do DACTE por e-mail é o limite de suas capacidades digitais.

Terceiro, o próprio sistema do consignatário pode não conseguir consumir o XML. Mesmo quando uma transportadora fornece o XML — o que muitas grandes transportadoras fazem por padrão — o sistema logístico ou ERP do consignatário precisa estar configurado para importá-lo. No ecossistema de ERPs brasileiro, a importação de XML de CT-e é suportada pelo TDF da SAP (Tax Declaration Framework, que exige uma implementação SAP S/4HANA com custo superior a R$500.000 em honorários de consultoria) e pelo módulo fiscal do TOTVS Protheus (R$2.000–R$10.000 por mês em licenciamento). Para empresas de médio porte que ficam entre "grandes demais para o processo totalmente manual" e "pequenas demais para investir em módulo de ERP", o XML chega, mas cai na mesma caixa de e-mail que o PDF do DACTE — e o analista de fretes abre o PDF porque é o que sempre fez.

Camada 2: O DACTE como Fonte de Informação de Fato

O DACTE (Documento Auxiliar do Conhecimento de Transporte Eletrônico) existe por design regulatório — é o resumo impresso que deve acompanhar fisicamente as mercadorias nos termos do Ajuste SINIEF 07/2007. Ele serve ao propósito de fiscalização: quando um veículo é parado em uma blitz fiscal da SEFAZ, o motorista apresenta o DACTE, e o inspetor escaneia o QR code ou digita a chave de acesso para verificar a carga contra o CT-e autorizado. É um documento projetado para inspeção, não para transferência de dados.

Na prática, o DACTE se tornou a principal fonte de informação do consignatário por um motivo que nada tem a ver com a regulamentação: é o único documento que chega consistentemente junto com as mercadorias. O XML pode ou não chegar. O DACTE sempre chega — porque a carga não pode circular sem ele.

O DACTE carrega entre 30 e 50 pontos de dados, um subconjunto do XML completo do CT-e. O schema completo inclui descrições de carga em nível de item, múltiplos detalhamentos de impostos por produto, chaves de acesso de NF-e referenciadas e informações complementares em texto livre que podem conter referências contratuais ou instruções especiais de manuseio. Grande parte desses dados não é impressa no DACTE. Uma equipe logística que trabalha apenas com o DACTE opera, portanto, com um conjunto reduzido de dados — e essa redução introduz seus próprios riscos. O valor a receber pode diferir do valor do serviço devido a retenções listadas apenas no XML. O cálculo da base de ICMS depende de alíquotas e exclusões que o DACTE pode apresentar como um único valor final sem mostrar as etapas intermediárias.

Apesar dessas limitações, o DACTE é o que a equipe logística tem. A tarefa de entrada de dados é definida pelo que está na página impressa, não pelo que está no XML. E é aí que opera a segunda camada do paradoxo: o documento mais fácil de acessar (a impressão do DACTE) carrega menos dados do que o documento mais difícil de acessar (o XML), mas a equipe constrói seu processo em torno do acessível.

Camada 3: Custo do Módulo ERP — Quando a Correção Técnica É Cara Demais

A solução tecnicamente correta para o paradoxo dos dados do CT-e é bem conhecida nos círculos de logística e finanças brasileiros: implementar um módulo ERP que importe o XML do CT-e diretamente, valide-o contra os registros da SEFAZ e lance os lançamentos de custo de frete automaticamente. SAP TDF, TOTVS Protheus Fiscal e os módulos de localização brasileira da Oracle suportam todos esse fluxo. A tecnologia existe. O custo, para a maioria das operações logísticas de médio porte, é proibitivo.

O SAP TDF fica sobre o SAP S/4HANA. Uma empresa que ainda não está no S/4HANA enfrenta uma transformação de ERP de vários anos e milhões de reais antes de sequer considerar o módulo de importação de CT-e. Para as empresas que já estão no S/4HANA, uma implementação de TDF leva de 6 a 12 meses e custa R$200.000–R$500.000 em honorários de consultoria, além de custos contínuos de licenciamento que variam conforme o número de usuários e a configuração do módulo.

O TOTVS Protheus, embora mais acessível para o mercado médio brasileiro, ainda impõe um custo de licenciamento de R$2.000–R$10.000 por mês, dependendo da pilha de módulos, além da consultoria de implementação. A decisão de adicionar o módulo fiscal não é impulsionada apenas pelo CT-e — é um investimento mais amplo na infraestrutura financeira e fiscal da empresa. O recurso de importação de CT-e é um item dentro de um caso de negócio maior, e se o processamento de NF-e da empresa já é feito manualmente sem um módulo, adicionar o módulo apenas para CT-e raramente supera o limite de ROI.

O resultado é um vácuo de processamento. Grandes empresas no SAP S/4HANA com TDF podem processar XML de CT-e automaticamente. Operações muito pequenas que processam 20 CT-e por mês continuam manualmente porque o volume não justifica nenhum investimento. Operações de médio porte — 200–500 CT-e por mês — ocupam o meio doloroso: o processo manual custa R$30.000–R$80.000 por ano em mão de obra, mas o módulo ERP custa mais para implementar do que o processo manual custa em um único ano. O caso de investimento exige uma visão de vários anos que muitas empresas não estão estruturadas para avaliar.

Camada 4: Fragmentação do Setor — Mais de 650.000 Transportadoras

O fator estrutural que amplifica todas as outras camadas é a escala e a fragmentação do transporte rodoviário de cargas no Brasil. A base de transportadoras registradas na ANTT, com aproximadamente 650.000 operadores, torna a padronização em todo o setor um ideal teórico que nenhum sistema prático consegue alcançar. Um destinatário que recebe cargas de 200 fornecedores pode interagir com 80 a 100 transportadoras diferentes em um único mês. Cada uma usa seu próprio sistema de faturamento, sua própria variação de layout do DACTE, seu próprio formato de envio por e-mail e sua própria definição de "entrega de nota fiscal".

A integração com ERP no nível da transportadora — em que cada transportadora envia o XML do CT-e para o sistema do destinatário — exigiria que cada uma dessas 80 a 100 transportadoras suportasse uma integração via API. Para as grandes transportadoras, isso é viável. Para a maioria das pequenas transportadoras e autônomos, não é. A estrutura do setor torna um pipeline de dados totalmente integrado um alvo irrealista para a maioria dos destinatários, independentemente do investimento em ERP.

A implicação prática: o problema de digitação de dados do destinatário não é que as transportadoras se recusam a enviar o XML. É que os dados chegam por 100 canais diferentes, em 100 layouts diferentes de DACTE, e o único denominador comum é a página impressa que acompanha as mercadorias. Qualquer solução que exija integração por transportadora — seja configuração de API, personalização de parsing de XML ou configuração de modelo — falha quando o número de transportadoras passa de algumas poucas.

É por isso que a extração na camada visual — ler o DACTE impresso como imagem e convertê-lo em dados estruturados — não é um contorno para o problema de integração, mas a única solução que aborda diretamente a fragmentação do setor. Ela exige zero ação da transportadora. Ela lida com qualquer layout de DACTE de qualquer transportadora no mesmo lote. E não depende do roadmap de ERP do destinatário.

O que a Extração na Camada Visual Muda

As quatro camadas do paradoxo do CT-e — inacessibilidade do XML, DACTE como padrão, custo do módulo ERP, fragmentação do setor — formam uma armadilha estrutural da qual o redesenho manual de processos não consegue escapar. Cada camada é solucionável de forma independente para um subconjunto de casos, mas a combinação cobre praticamente toda operação logística: grande o suficiente para ter escala, fragmentada o suficiente para impedir padronização, e logo abaixo do limite de investimento para a solução empresarial.

A extração visual — tratando o impresso do DACTE como documento-fonte e extraindo seus dados por meio da Extração de Colunas Personalizadas com IA — quebra a armadilha em um ponto diferente. Ela não exige que o XML flua da transportadora para o destinatário (Camada 1). Funciona com o DACTE que já está disponível (Camada 2). Custa ordens de magnitude menos que um módulo ERP e entrega resultados em horas, não meses (Camada 3). E lida com todos os layouts de transportadoras em um único lote, sem integração por transportadora (Camada 4).

O mecanismo é simples: envie o PDF ou imagem do DACTE, insira os nomes das colunas que deseja extrair, e a IA localiza cada valor na página impressa entendendo o que ele significa — não por correspondência a um modelo pré-configurado. A saída é uma linha de planilha por documento, pronta para seu livro de custos existente ou importação no ERP. O guia passo a passo de extração de CT-e detalha as definições de colunas e o fluxo de processamento.

Para equipes que precisam de mais do que extração por documento — incluindo colunas calculadas que calculam o frete por kg, validação da alíquota efetiva de ICMS ou agregação mensal em lote — o guia de processamento em lote para livros de custo de frete de CT-e estende o fluxo para lidar com lotes de múltiplas transportadoras com análise de custos integrada.

Perguntas Frequentes

Não posso simplesmente solicitar o XML do CT-e à transportadora?

Você pode solicitar. Se você o receberá de forma confiável depende da transportadora. Grandes transportadoras (JSL, Braspress, Rodonaves) normalmente fornecem download do XML por meio de seus portais de faturamento. Pequenas transportadoras e proprietários-operadores podem não ter um mecanismo para reenviar ou compartilhar o XML após a emissão, porque sua ferramenta de emissão é um formulário web gratuito da SEFAZ que envia o XML apenas ao governo. Na prática, contratos de compra com grandes transportadoras podem exigir a entrega do XML; com o restante do mercado, o DACTE impresso ou PDF é o que você receberá.

O impresso do DACTE tem dados suficientes, ou preciso do XML completo?

O DACTE contém os dados necessários para o controle de custos e pagamento à transportadora — valor do serviço, valor do ICMS, peso, rota, partes envolvidas. Ele não contém o detalhamento completo dos itens de carga, alguns detalhamentos de impostos por produto ou o histórico completo de eventos (alterações do CT-e, eventos de cancelamento). Para a contabilidade de custos de frete, o DACTE cobre os campos essenciais. Para conformidade com o SPED EFD ICMS/IPI no mais alto nível de detalhe, o XML completo é preferível. A estratégia prática: extraia o DACTE para controle de custos; solicite o XML para conformidade quando a equipe fiscal precisar do detalhamento completo dos impostos.

Qual é o custo real de implementar a importação de XML do CT-e no meu ERP?

Para SAP S/4HANA com TDF, estime R$200.000–R$500.000 em honorários de consultoria, mais 6–12 meses de implementação, além da licença do S/4HANA em si. Para TOTVS Protheus, estime R$24.000–R$120.000 por ano em licenciamento (R$2.000–R$10.000/mês), mais consultoria de implementação de R$30.000–R$80.000. Para módulos equivalentes da Oracle ou Sage, o custo é comparável. Esses valores são para a implementação do módulo de ERP que cobre todos os documentos fiscais brasileiros — a importação de XML do CT-e é um recurso dentro de um escopo de módulo maior. Alguns pacotes menores de localização de ERP podem oferecer importação de CT-e a um custo menor, mas geralmente exigem que a empresa já esteja nessa plataforma de ERP.

Posso exigir que minhas transportadoras enviem o XML nos meus contratos de compra?

Você pode — e grandes embarcadores costumam fazer isso. A limitação prática é que a alavanca de fiscalização funciona para transportadoras que competem pelo seu negócio. Para fretes pontuais, cargas urgentes ou rotas atendidas por apenas uma ou duas transportadoras, a alavancagem é mais fraca. E para as muitas transportadoras pequenas que entregam cargas de entrada de seus fornecedores (não transportadoras que você contratou), você não tem nenhuma relação contratual. Nesses casos — que representam uma parcela significativa do frete de entrada para a maioria dos fabricantes — o DACTE é o único documento que existe entre você e os dados de transporte.

A extração visual do DACTE produz a mesma precisão que o parsing de XML?

O parsing de XML é 100% preciso porque os dados já estão estruturados. A extração visual de um DACTE impresso ou PDF introduz as limitações de precisão de qualquer leitura de documentos por IA — excelente em PDFs e digitalizações limpas (até 99% em campos impressos), um pouco menor em fotografias de baixa qualidade ou anotações manuscritas. A diferença é que o parsing de XML nem sempre está disponível, e a extração visual é sempre possível. A escolha não é entre precisão de XML e precisão de DACTE; é entre extração de DACTE (com seu pequeno trade-off de precisão) e redigitação manual do DACTE (com sua taxa de erro de 1–4% e custo de 90 segundos por documento).

Onde o CT-e se encaixa no ecossistema mais amplo de documentos eletrônicos do Brasil?

O CT-e opera ao lado do NF-e (nota fiscal de mercadorias), NFS-e (nota fiscal de serviços), MDF-e (manifesto de frete que agrupa vários CT-e em um único veículo) e BP-e (bilhete de passageiro). Para gestão de custos logísticos, a relação principal é entre o CT-e e o NF-e: o CT-e documenta o custo de transporte, o NF-e documenta o valor das mercadorias, e os dois juntos produzem o custo total de aquisição. O guia do hub de documentos eletrônicos brasileiros fornece uma visão geral completa de como esses documentos interagem e onde cada um se encaixa no fluxo de trabalho logístico.