O Documento de Frete Brasileiro
Por Que os XMLs de CT-e Ainda Exigem Redigitação Manual

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

O termo "documento fiscal eletrônico de transporte" cria uma expectativa em qualquer profissional de logística que o ouve: que os dados fluem eletronicamente do sistema da transportadora para o sistema do destinatário, porque é isso que documentos eletrônicos fazem. Mas o CT-e é eletrônico em um sentido específico — é um documento fiscal eletrônico submetido e autorizado pela Secretaria da Fazenda estadual antes da carga ser movimentada. Seu consumidor principal é a SEFAZ, não o remetente, não o destinatário e, certamente, não o analista de frete que precisa do valor do serviço para lançar no razão de custos.

O sistema da SEFAZ do Brasil processa mais de 300 milhões de documentos CT-e anualmente em 27 Secretarias da Fazenda estaduais independentes. O sistema foi projetado para garantir que cada movimentação de frete possa ser rastreada, tributada e auditada. Ele não foi projetado para fornecer dados estruturados ao sistema de logística do destinatário. A transportadora recebe o XML autorizado como parte do fluxo de emissão. Se o destinatário o recebe depende inteiramente das capacidades de faturamento e integração da transportadora — que, em um setor fragmentado com mais de 650.000 transportadoras registradas, variam enormemente.

O guia de extração de dados de CT-e aborda o fluxo de trabalho prático para transformar impressos do DACTE em linhas estruturadas de planilha. 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 mantêm a redigitação manual de dados viva em operações logísticas brasileiras de todos os portes.

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

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

Primeiro, o XML é endereçado à SEFAZ, não ao destinatário. Quando uma transportadora emite um CT-e, o XML é assinado e transmitido à Secretaria da Fazenda estadual para autorização. O destinatário é um campo de dados dentro do documento — um receptor no sentido legal/operacional, não no sentido de fluxo de dados. A obrigação da transportadora é entregar a mercadoria e fornecer a impressão do DACTE ou o PDF que a acompanha. Entregar o XML é um serviço comercial, não uma exigência legal, e muitas transportadoras tratam isso como um recurso adicional (upsell) em seu portal de faturamento.

Segundo, o cenário das 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 faturas. Mas a maioria das transportadoras é pequena — caminhoneiros autônomos (transportador autônomo) ou empresas regionais com menos de dez veículos. Seu fluxo de trabalho 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 destinatário depois. Para essas transportadoras, fornecer o DACTE em PDF por e-mail é o limite de suas capacidades digitais.

Terceiro, o sistema próprio do destinatário pode não ser capaz de consumir o XML. Mesmo quando a transportadora fornece o XML — o que muitas transportadoras de grande porte fazem por padrão — o sistema logístico ou ERP do destinatário precisa estar configurado para importá-lo. No ecossistema de ERPs brasileiro, a importação de XML de CT-e é suportada pelo TDF (Tax Declaration Framework) da SAP (que exige uma implementação SAP S/4HANA com custos superiores a R$ 500.000 em consultoria) e pelo módulo fiscal do TOTVS Protheus (R$ 2.000 a 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 acaba na mesma caixa de entrada de e-mail que o PDF do DACTE — e o analista de frete abre o PDF porque é o que sempre fez.

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

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 em relação ao 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 destinatá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 vir. O DACTE sempre vem — 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 esquema completo inclui descrições de carga em nível de item, múltiplos detalhamentos de tributos por produto, chaves de acesso de NF-e referenciadas e informações complementares de 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 documento acessível.

Camada 3: Custo do Módulo ERP — Quando a Soluçã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 automaticamente as entradas de custo de frete. O SAP TDF, o TOTVS Protheus Fiscal e os módulos de localização brasileira da Oracle suportam esse fluxo. A tecnologia existe. O custo, para a maioria das operações logísticas de médio porte, é proibitivo.

O SAP TDF é um módulo adicional do SAP S/4HANA. Uma empresa que ainda não utiliza o S/4HANA enfrenta uma transformação de ERP de vários anos e milhões de reais antes mesmo de considerar o módulo de importação de CT-e. Para as empresas que já estão no S/4HANA, uma implementação do TDF leva de 6 a 12 meses e custa entre R$ 200.000 e R$ 500.000 em taxas de consultoria, além dos 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 a 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 de linha 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 o CT-e raramente ultrapassa 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-es por mês, continuam manualmente porque o volume não justifica nenhum investimento. Operações de médio porte — 200 a 500 CT-es por mês — ocupam o meio doloroso: o processo manual custa entre R$ 30.000 e 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 setor de transporte rodoviário de cargas no Brasil. A base de transportadoras registradas na ANTT, de 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 variante 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 — onde 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 motoristas autônomos, não é. A estrutura do setor torna um pipeline de dados totalmente integrado uma meta irrealista para a maioria dos destinatários, independentemente do investimento em ERP.

A implicação prática: o problema de entrada 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 análise de XML ou configuração de modelo — quebra quando o número de transportadoras ultrapassa algumas unidades.

É por isso que a extração na camada visual — ler a impressão do DACTE como uma imagem e convertê-la em dados estruturados — não é uma solução alternativa para o problema de integração, mas a única solução que aborda diretamente a fragmentação do setor. Ela não exige nenhuma ação da transportadora. Ela lida com qualquer layout de DACTE de qualquer transportadora no mesmo lote. E não depende do roteiro 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 e 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 virtualmente toda operação logística: grande o suficiente para ter escala, fragmentada o suficiente para impedir a padronização e logo abaixo do limite de investimento para a solução empresarial.

A extração visual — tratando a impressão do DACTE como documento de origem 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 consignatário (Camada 1). Funciona com o DACTE que já está disponível (Camada 2). Custa ordens de grandeza a menos que um módulo ERP e entrega resultados em horas, não em meses (Camada 3). E lida com todos os layouts de transportadoras em um único lote, sem integração por transportadora (Camada 4).

O mecanismo é direto: faça o upload do 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 combinando um modelo pré-configurado. A saída é uma linha de planilha por documento, pronta para seu razão de custos existente ou importação para o 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 a extração por documento — incluindo colunas calculadas que calculam o frete por kg, validação efetiva da alíquota de ICMS ou agregação mensal em lote — o guia de processamento em lote para razões de custo de frete de CT-e estende o fluxo de trabalho 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) geralmente fornecem download do XML através de seus portais de faturamento. Pequenas transportadoras e autônomos 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 para o governo. Na prática, contratos de aquisição com grandes transportadoras podem exigir a entrega do XML; com o restante do mercado, o DACTE em PDF ou impresso é o que você receberá.

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

O DACTE contém os dados necessários para o rastreamento de custos e pagamento à transportadora — valor do serviço, valor do ICMS, peso, rota, partes envolvidas. Ele não contém o detalhamento completo da carga por item, algumas discriminações de imposto a nível de produto ou o histórico completo de eventos (alterações de CT-e, eventos de cancelamento). Para a contabilidade de custos de frete, o DACTE cobre os campos essenciais. Para a 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 rastreamento de custos; solicite o XML para conformidade quando a equipe fiscal precisar da discriminação completa 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 própria licença do S/4HANA. 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 ERP que cobre todos os documentos fiscais brasileiros — a importação do XML do CT-e é uma funcionalidade dentro de um escopo de módulo maior. Alguns pacotes de localização de ERP menores podem oferecer importação de CT-e a um custo menor, mas geralmente exigem que a empresa já esteja naquela plataforma de ERP.

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

Você pode — e grandes embarcadores frequentemente o fazem. A limitação prática é que a alavanca de imposição funciona para transportadoras que competem pelo seu negócio. Para fretes pontuais, cargas de emergência ou rotas atendidas por apenas uma ou duas transportadoras, a alavancagem é mais fraca. E para as muitas pequenas transportadoras que entregam cargas de entrada de seus fornecedores (não transportadoras contratadas por você), 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 a análise do XML?

A análise do XML é 100% precisa 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 documento por IA — excelente em PDFs e digitalizações limpas (até 99% em campos impressos), ligeiramente inferior em fotografias de baixa qualidade ou anotações manuscritas. A diferença é que a análise do XML nem sempre está disponível, e a extração visual é sempre possível. A escolha não é entre a precisão do XML e a precisão do DACTE; é entre a extração do DACTE (com seu pequeno trade-off de precisão) e a redigitação manual do DACTE (com sua taxa de erro de 1–4% e custo de tempo 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 juntamente com a NF-e (fatura de mercadorias), a NFS-e (fatura de serviços), o MDF-e (manifesto de frete que agrupa vários documentos CT-e em um único veículo) e o BP-e (bilhete de passagem). Para o gerenciamento de custos logísticos, a relação principal é entre o CT-e e a NF-e: o CT-e documenta o custo do transporte, a 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.