El Documento de Flete Brasileño
Por qué los XML de CT-e aún requieren reingreso manual

La paradoja del CT-e: nace digital y se vuelve a teclear a mano

El término "documento de transporte electrónico" genera una expectativa en cualquier profesional de logística que lo escuche: que los datos fluyan electrónicamente del sistema del transportista al sistema del destinatario, porque eso es lo que hacen los documentos electrónicos. Pero el CT-e es electrónico en un sentido específico: es un documento fiscal electrónico presentado y autorizado por la autoridad fiscal estatal antes de que la carga se mueva. Su principal consumidor es SEFAZ, no el remitente, no el destinatario y, ciertamente, no el analista de fletes que necesita que el valor del servicio llegue al libro de costos.

El sistema SEFAZ de Brasil procesa más de 300 millones de documentos CT-e al año en 27 autoridades fiscales estatales independientes. El sistema está diseñado para garantizar que cada movimiento de carga pueda rastrearse, tributar y auditarse. No está diseñado para entregar datos estructurados al sistema logístico del destinatario. El transportista recibe el XML autorizado como parte del flujo de emisión. Que el destinatario lo reciba depende por completo de las capacidades de facturación e integración del transportista, que, en una industria fragmentada de más de 650.000 transportistas registrados, varían enormemente.

La guía de extracción de datos de CT-e cubre el flujo de trabajo práctico para convertir impresos DACTE en filas estructuradas de hoja de cálculo. Este artículo da un paso atrás para examinar las razones estructurales por las que ese flujo de trabajo es necesario en primer lugar: las cuatro capas de la paradoja del CT-e que mantienen viva la reescritura manual de datos en las operaciones logísticas brasileñas de todos los tamaños.

Capa 1: Accesibilidad del XML — Por qué los transportistas no envían el archivo estructurado

La explicación más directa para la reentrada manual parecería ser la más fácil de resolver: los transportistas tienen el XML del CT-e, los consignatarios lo quieren, así que los transportistas deberían enviarlo. En la práctica, el flujo del XML del transportista al consignatario está obstruido por tres factores estructurales que ninguna parte puede resolver por sí sola.

Primero, el XML está dirigido a SEFAZ, no al consignatario. Cuando un transportista emite un CT-e, el XML se firma y se transmite a la autoridad fiscal estatal para su autorización. El consignatario es un campo de datos dentro del documento — un destinatario en el sentido legal/operativo, no en el sentido del flujo de datos. La obligación del transportista es entregar la mercancía y proporcionar el impreso DACTE o el PDF que la acompaña. Entregar el XML es un servicio comercial, no un requisito legal, y muchos transportistas lo tratan como una función de venta adicional en su portal de facturación.

Segundo, el panorama de los transportistas está demasiado fragmentado para el XML como estándar. El sector de transporte de carga por carretera de Brasil incluye aproximadamente 650.000 transportistas registrados. Los más grandes, como JSL (que cotiza en bolsa, ~R$8 mil millones de ingresos) y Braspress (el mayor transportista de carga parcial en América Latina), operan portales de facturación sofisticados que proporcionan descarga de XML, acceso API y entrega automatizada de facturas. Pero la mayoría de los transportistas son pequeños — propietarios-operadores de un solo camión (transportador autónomo) o empresas regionales con menos de diez vehículos. Su flujo de trabajo de emisión de CT-e puede ser un portal web gratuito de SEFAZ o un software básico de emisión de CT-e que genera el XML para SEFAZ pero no tiene ningún mecanismo para entregarlo al consignatario después. Para estos transportistas, proporcionar el PDF del DACTE por correo electrónico es el límite de sus capacidades digitales.

Tercero, el propio sistema del consignatario puede no ser capaz de consumir el XML. Incluso cuando un transportista proporciona el XML — lo que muchos transportistas grandes hacen por defecto — el sistema logístico o ERP del consignatario debe estar configurado para importarlo. En el ecosistema ERP brasileño, la importación de XML de CT-e es compatible con el TDF de SAP (Tax Declaration Framework, que requiere una implementación de SAP S/4HANA que cuesta más de R$500.000 en honorarios de consultoría) y el módulo fiscal de TOTVS Protheus (R$2.000–R$10.000 por mes en licencias). Para las empresas de mercado medio que se encuentran entre "demasiado grandes para ser totalmente manuales" y "demasiado pequeñas para la inversión en módulos ERP", el XML llega pero aterriza en la misma bandeja de entrada de correo electrónico que el PDF del DACTE — y el analista de fletes abre el PDF porque es lo que siempre ha hecho.

Capa 2: El DACTE como fuente de información de facto

El DACTE (Documento Auxiliar do Conhecimento de Transporte Eletrônico) existe por diseño regulatorio: es el resumen impreso que debe acompañar físicamente a la mercancía según los términos del Ajuste SINIEF 07/2007. Cumple un propósito de fiscalización: cuando un vehículo es detenido en un puesto de control de la SEFAZ (blitz fiscal), el conductor presenta el DACTE y el inspector escanea el código QR o ingresa la chave de acesso para verificar la carga contra el CT-e autorizado. Es un documento diseñado para la inspección, no para la transferencia de datos.

En la práctica, el DACTE se ha convertido en la principal fuente de información del consignatario por una razón que no tiene nada que ver con la regulación: es el único documento que llega de manera consistente con la mercancía. El XML puede llegar o no. El DACTE siempre llega, porque la carga no puede moverse sin él.

El DACTE contiene entre 30 y 50 puntos de datos, un subconjunto del XML completo del CT-e. El esquema completo incluye descripciones de carga a nivel de ítem, múltiples desgloses de impuestos por producto, claves de acceso de NF-e referenciadas e información adicional de texto libre (informações complementares) que puede contener referencias contractuales o instrucciones especiales de manejo. Gran parte de estos datos no se imprimen en el DACTE. Un equipo de logística que trabaje únicamente con el DACTE opera, por tanto, con un conjunto de datos reducido, y esa reducción introduce sus propios riesgos. El valor a receber puede diferir del valor do serviço debido a retenciones que solo se listan en el XML. El cálculo de la base del ICMS depende de tasas y exclusiones que el DACTE puede presentar como una única cifra final sin mostrar los pasos intermedios.

A pesar de estas limitaciones, el DACTE es lo que tiene el equipo de logística. La tarea de ingreso de datos se define por lo que está en la página impresa, no por lo que está en el XML. Y ahí es donde opera la segunda capa de la paradoja: el documento más fácil de acceder (la impresión del DACTE) contiene menos datos que el documento más difícil de acceder (el XML), pero el equipo construye su proceso en torno al accesible.

Capa 3: Costo del Módulo ERP — Cuando la Solución Técnica es Demasiado Costosa

La solución técnicamente correcta a la paradoja de datos del CT-e es bien conocida en los círculos de logística y finanzas brasileños: implementar un módulo ERP que importe el XML del CT-e directamente, lo valide contra los registros de SEFAZ y publique automáticamente las entradas de costo de flete. SAP TDF, TOTVS Protheus Fiscal y los módulos de localización brasileña de Oracle admiten este flujo. La tecnología existe. El costo, para la mayoría de las operaciones logísticas de mercado medio, es prohibitivo.

SAP TDF se basa en SAP S/4HANA. Una empresa que aún no está en S/4HANA enfrenta una transformación ERP de varios años y varios millones de reales antes de siquiera considerar el módulo de importación de CT-e. Para las empresas que ya están en S/4HANA, una implementación de TDF toma de 6 a 12 meses y cuesta R$200,000–R$500,000 en honorarios de consultoría, más costos de licencia continuos que varían según el número de usuarios y la configuración del módulo.

TOTVS Protheus, aunque más accesible para el mercado medio brasileño, aún impone un costo de licencia de R$2,000–R$10,000 por mes según la pila de módulos, más consultoría de implementación. La decisión de agregar el módulo fiscal no se impulsa solo por el CT-e — es una inversión más amplia en la infraestructura financiera y fiscal de la empresa. La función de importación de CT-e es una partida dentro de un caso de negocio más grande, y si el procesamiento de NF-e de la empresa ya se maneja manualmente sin un módulo, agregar el módulo solo para CT-e rara vez supera el umbral de ROI.

El resultado es un vacío de procesamiento. Las grandes empresas en SAP S/4HANA con TDF pueden procesar XML de CT-e automáticamente. Las operaciones muy pequeñas que procesan 20 CT-e al mes continúan manualmente porque el volumen no justifica ninguna inversión. Las operaciones de mercado medio — 200–500 CT-e al mes — ocupan el incómodo punto medio: el proceso manual cuesta R$30,000–R$80,000 al año en mano de obra, pero el módulo ERP cuesta más de implementar de lo que cuesta el proceso manual en un solo año. El caso de inversión requiere una visión de varios años que muchas empresas no están estructuradas para evaluar.

Capa 4: Fragmentación de la industria: más de 650 000 transportadoras

El factor estructural que amplifica todas las demás capas es la escala y la fragmentación de la industria de transporte de carga por carretera en Brasil. La base de transportadoras registradas ante la ANTT, de aproximadamente 650 000 operadores, hace que la estandarización en toda la industria sea un ideal teórico que ningún sistema práctico puede alcanzar. Un destinatario que recibe carga entrante de 200 proveedores puede interactuar con 80 a 100 transportadoras diferentes en un solo mes. Cada una utiliza su propio sistema de facturación, su propia variante de diseño DACTE, su propio formato de entrega por correo electrónico y su propia definición de "entrega de factura".

La integración con ERP a nivel de transportadora — donde cada transportadora envía su XML de CT-e al sistema del destinatario — requeriría que cada una de esas 80 a 100 transportadoras admitiera una integración por API. Para las transportadoras grandes, esto es viable. Para la mayoría de las transportadoras pequeñas y los propietarios-operadores, no lo es. La estructura de la industria hace que una canalización de datos totalmente integrada sea un objetivo poco realista para la mayoría de los destinatarios, independientemente de su inversión en ERP.

La implicación práctica: el problema de ingreso de datos del destinatario no es que las transportadoras se nieguen a enviar el XML. Es que los datos llegan a través de 100 canales diferentes, en 100 diseños DACTE diferentes, y el único denominador común es la página impresa que acompaña a la mercancía. Cualquier solución que requiera integración por transportadora — ya sea configuración de API, personalización del análisis de XML o configuración de plantillas — se rompe cuando el número de transportadoras supera un puñado.

Por eso la extracción en la capa visual — leer el impreso DACTE como imagen y convertirlo en datos estructurados — no es una solución alternativa al problema de integración, sino la única solución que aborda directamente la fragmentación de la industria. No requiere ninguna acción por parte de la transportadora. Maneja cualquier diseño DACTE de cualquier transportadora en el mismo lote. Y no depende de la hoja de ruta del ERP del destinatario.

Qué Cambia la Extracción en la Capa Visual

Las cuatro capas de la paradoja del CT-e — inaccesibilidad del XML, DACTE como predeterminado, costo del módulo ERP, fragmentación de la industria — forman una trampa estructural que el rediseño manual de procesos no puede escapar. Cada capa es solucionable de forma independiente para un subconjunto de casos, pero la combinación cubre prácticamente toda operación logística: lo suficientemente grande para tener escala, lo suficientemente fragmentada para impedir la estandarización, y justo por debajo del umbral de inversión para la solución empresarial.

La extracción visual — tratar el impreso del DACTE como documento fuente y extraer sus datos mediante Extracción de Columnas Personalizadas impulsada por IA — rompe la trampa en un punto diferente. No requiere que el XML fluya del transportista al destinatario (Capa 1). Funciona con el DACTE que ya está disponible (Capa 2). Cuesta órdenes de magnitud menos que un módulo ERP y entrega resultados en horas, no en meses (Capa 3). Y maneja todos los formatos de transportistas en un solo lote sin integración por transportista (Capa 4).

El mecanismo es sencillo: sube el PDF o imagen del DACTE, ingresa los nombres de las columnas que deseas extraer, y la IA localiza cada valor en la página impresa al comprender qué significa — no al coincidir con una plantilla preconfigurada. El resultado es una fila de hoja de cálculo por documento, lista para tu libro de costos existente o importación a ERP. La guía paso a paso de extracción de CT-e explica las definiciones de columnas y el flujo de procesamiento.

Para equipos que necesitan más que extracción por documento — incluyendo columnas calculadas que calculan el costo de flete por kg, validación de tasa efectiva de ICMS, o agregación mensual por lotes — la guía de procesamiento por lotes para libros de costos de flete CT-e extiende el flujo para manejar lotes de múltiples transportistas con análisis de costos integrado.

Preguntas Frecuentes

¿No puedo simplemente solicitar el XML del CT-e al transportista?

Puede solicitarlo. Que lo reciba de manera confiable depende del transportista. Los transportistas grandes (JSL, Braspress, Rodonaves) generalmente proporcionan la descarga del XML a través de sus portales de facturación. Los transportistas pequeños y los propietarios-operadores pueden no tener un mecanismo para reenviar o compartir el XML después de la emisión, porque su herramienta de emisión es un formulario web gratuito de SEFAZ que envía el XML solo al gobierno. En la práctica, los contratos de compra con transportistas grandes pueden exigir la entrega del XML; con el resto del mercado, el PDF del DACTE o el impreso es lo que obtendrá.

¿El impreso del DACTE es suficiente, o necesito el XML completo?

El DACTE contiene los datos necesarios para el seguimiento de costos y el pago al transportista: valor del servicio, monto del ICMS, peso, ruta, partes. No contiene el detalle completo de los ítems de carga, algunos desgloses de impuestos a nivel de producto, ni el historial completo de eventos (modificaciones del CT-e, eventos de cancelación). Para la contabilidad de costos de flete, el DACTE cubre los campos esenciales. Para el cumplimiento de SPED EFD ICMS/IPI al más alto nivel de detalle, el XML completo es preferible. La estrategia práctica: extraiga el DACTE para el seguimiento de costos; solicite el XML para el cumplimiento cuando el equipo fiscal necesite el desglose completo de impuestos.

¿Cuál es el costo real de implementar la importación de XML de CT-e en mi ERP?

Para SAP S/4HANA con TDF, estime R$200.000–R$500.000 en honorarios de consultoría más 6–12 meses de implementación, además de la licencia de S/4HANA en sí. Para TOTVS Protheus, estime R$24.000–R$120.000 por año en licencias (R$2.000–R$10.000/mes) más consultoría de implementación de R$30.000–R$80.000. Para módulos equivalentes de Oracle o Sage, el costo es comparable. Estas cifras corresponden a la implementación del módulo ERP que cubre todos los documentos fiscales brasileños: la importación de XML de CT-e es una función dentro de un alcance de módulo más amplio. Algunos paquetes de localización de ERP más pequeños pueden ofrecer la importación de CT-e a un costo menor, pero generalmente requieren que la empresa ya esté en esa plataforma ERP.

¿Puedo exigir a mis transportistas que envíen el XML en mis contratos de compra?

Sí puede — y los grandes embarcadores suelen hacerlo. La limitación práctica es que la palanca de cumplimiento funciona para transportistas que compiten por su negocio. Para envíos puntuales, carga de emergencia o rutas atendidas por solo uno o dos transportistas, la influencia es menor. Y para los muchos transportistas pequeños que entregan carga entrante de sus proveedores (no transportistas que usted contrató), no tiene ninguna relación contractual. En estos casos — que representan una parte significativa de la carga entrante para la mayoría de los fabricantes — el DACTE es el único documento que existe entre usted y los datos de transporte.

¿La extracción visual del DACTE produce la misma precisión que el análisis del XML?

El análisis del XML es 100% preciso porque los datos ya están estructurados. La extracción visual de un DACTE impreso o PDF introduce las limitaciones de precisión de cualquier lectura de documentos por IA — excelente en PDFs y escaneos limpios (hasta 99% en campos impresos), ligeramente menor en fotografías de baja calidad o anotaciones manuscritas. La diferencia es que el análisis del XML no siempre está disponible, y la extracción visual siempre es posible. La elección no es entre precisión del XML y precisión del DACTE; es entre extracción del DACTE (con su pequeño sacrificio de precisión) y volver a teclear manualmente el DACTE (con su tasa de error del 1–4% y un costo de 90 segundos por documento).

¿Dónde encaja el CT-e en el ecosistema más amplio de documentos electrónicos de Brasil?

El CT-e opera junto con la NF-e (factura de mercancías), NFS-e (factura de servicios), MDF-e (manifiesto de carga que agrupa múltiples documentos CT-e en un solo vehículo) y BP-e (billete de pasajero). Para la gestión de costos logísticos, la relación clave es entre el CT-e y la NF-e: el CT-e documenta el costo de transporte, la NF-e documenta el valor de las mercancías, y juntos producen el costo total de entrega. La guía del hub de documentos electrónicos de Brasil ofrece una visión completa de cómo interactúan estos documentos y dónde encaja cada uno en el flujo de trabajo logístico.