Le document de fret brésilien
Pourquoi les XML CT-e nécessitent encore une saisie manuelle

Le paradoxe du CT-e : né numérique, ressaisi manuellement

L'expression « document de transport électronique » crée une attente chez tout professionnel de la logistique qui l'entend : que les données circulent électroniquement du système du transporteur vers celui du destinataire, car c'est ce que font les documents électroniques. Mais le CT-e est électronique dans un sens précis — c'est un document fiscal électronique soumis à l'autorité fiscale de l'État et autorisé par elle avant le déplacement de la marchandise. Son principal destinataire est la SEFAZ, pas l'expéditeur, pas le destinataire, et certainement pas l'analyste fret qui a besoin que la valeur du service atteigne le registre des coûts.

Le système SEFAZ du Brésil traite plus de 300 millions de documents CT-e par an auprès de 27 autorités fiscales d'État indépendantes. Le système est conçu pour garantir que chaque mouvement de fret puisse être tracé, taxé et audité. Il n'est pas conçu pour fournir des données structurées au système logistique du destinataire. Le transporteur reçoit le XML autorisé dans le cadre du flux d'émission. Que le destinataire le reçoive dépend entièrement des capacités de facturation et d'intégration du transporteur — qui, dans un secteur fragmenté de plus de 650 000 transporteurs enregistrés, varient énormément.

Le guide d'extraction de données CT-e couvre le flux de travail pratique pour transformer les impressions DACTE en lignes structurées de feuille de calcul. Cet article prend du recul pour examiner les raisons structurelles pour lesquelles ce flux de travail est nécessaire en premier lieu — les quatre couches du paradoxe du CT-e qui maintiennent la ressaisie manuelle des données en vie dans les opérations logistiques brésiliennes de toutes tailles.

Couche 1 : Accessibilité XML — Pourquoi les transporteurs n'envoient pas le fichier structuré

L'explication la plus directe de la saisie manuelle semblerait être la plus facile à corriger : les transporteurs disposent du XML du CT-e, les destinataires le souhaitent, donc les transporteurs devraient l'envoyer. En pratique, le flux du XML du transporteur vers le destinataire est entravé par trois facteurs structurels qu'aucune partie ne peut résoudre seule.

Premièrement, le XML est adressé à la SEFAZ, pas au destinataire. Lorsqu'un transporteur émet un CT-e, le XML est signé et transmis à l'autorité fiscale de l'État pour autorisation. Le destinataire est un champ de données dans le document — un destinataire au sens juridique/opérationnel, pas au sens du flux de données. L'obligation du transporteur est de livrer les marchandises et de fournir l'imprimé DACTE ou le PDF qui les accompagne. La livraison du XML est un service commercial, pas une exigence légale, et de nombreux transporteurs la traitent comme une fonctionnalité de vente incitative dans leur portail de facturation.

Deuxièmement, le paysage des transporteurs est trop fragmenté pour que le XML soit la norme. Le secteur du fret routier brésilien compte environ 650 000 transporteurs enregistrés. Les plus grands, comme JSL (coté en bourse, ~8 milliards de R$ de chiffre d'affaires) et Braspress (le plus grand transporteur de lots en Amérique latine), exploitent des portails de facturation sophistiqués qui fournissent le téléchargement du XML, l'accès API et la livraison automatisée des factures. Mais la majorité des transporteurs sont de petites entreprises — des propriétaires-exploitants à camion unique (transportador autônomo) ou des entreprises régionales de moins de dix véhicules. Leur flux d'émission de CT-e peut être un portail web gratuit de la SEFAZ ou un logiciel émetteur de CT-e de base qui génère le XML pour la SEFAZ mais n'a aucun mécanisme pour le livrer au destinataire ensuite. Pour ces transporteurs, fournir le PDF du DACTE par e-mail est la limite de leurs capacités numériques.

Troisièmement, le système du destinataire lui-même peut ne pas être en mesure de consommer le XML. Même lorsqu'un transporteur fournit le XML — ce que de nombreux grands transporteurs font par défaut — le système logistique ou l'ERP du destinataire doit être configuré pour l'importer. Dans l'écosystème ERP brésilien, l'importation du XML du CT-e est prise en charge par le TDF de SAP (Tax Declaration Framework, qui nécessite une implémentation SAP S/4HANA coûtant plus de 500 000 R$ en frais de conseil) et le module fiscal de TOTVS Protheus (2 000 à 10 000 R$ par mois en licence). Pour les entreprises de taille intermédiaire qui se situent entre « trop grandes pour être entièrement manuelles » et « trop petites pour investir dans un module ERP », le XML arrive mais atterrit dans la même boîte de réception que le PDF du DACTE — et l'analyste de fret ouvre le PDF parce que c'est ce qu'elle a toujours fait.

Couche 2 : le DACTE comme source d'information de facto

Le DACTE (Documento Auxiliar do Conhecimento de Transporte Eletrônico) existe par conception réglementaire — c'est le résumé imprimé qui doit physiquement accompagner les marchandises selon les termes de l'Ajuste SINIEF 07/2007. Il sert à des fins de contrôle : lorsqu'un véhicule est arrêté à un barrage de la SEFAZ (blitz fiscal), le conducteur présente le DACTE, et l'inspecteur scanne le code QR ou saisit la chave de acesso pour vérifier la cargaison par rapport au CT-e autorisé. C'est un document conçu pour l'inspection, pas pour le transfert de données.

En pratique, le DACTE est devenu la principale source d'information du destinataire pour une raison qui n'a rien à voir avec la réglementation : c'est le seul document qui arrive systématiquement avec les marchandises. Le XML peut arriver ou non. Le DACTE, lui, arrive toujours — car la cargaison ne peut pas circuler sans lui.

Le DACTE contient entre 30 et 50 points de données, un sous-ensemble du XML complet du CT-e. Le schéma complet comprend des descriptions de marchandises au niveau des lignes, plusieurs ventilations fiscales par produit, des clés d'accès NF-e référencées et des informations complémentaires en texte libre (informações complementares) pouvant contenir des références contractuelles ou des instructions de manutention spéciales. Une grande partie de ces données n'est pas imprimée sur le DACTE. Une équipe logistique travaillant uniquement à partir du DACTE opère donc sur un ensemble de données réduit — et cette réduction introduit ses propres risques. Le valor a receber peut différer du valor do serviço en raison de retenues listées uniquement dans le XML. Le calcul de la base ICMS dépend de taux d'imposition et d'exclusions que le DACTE peut présenter comme un seul chiffre final sans montrer les étapes intermédiaires.

Malgré ces limites, le DACTE est ce que l'équipe logistique a sous la main. La tâche de saisie des données est définie par ce qui figure sur la page imprimée, pas par ce qui se trouve dans le XML. Et c'est là que la deuxième couche du paradoxe opère : le document le plus facile à obtenir (l'impression du DACTE) contient moins de données que le document plus difficile à obtenir (le XML), mais l'équipe construit son processus autour du document accessible.

Niveau 3 : Coût du module ERP — quand la solution technique est trop chère

La solution techniquement correcte au paradoxe des données CT-e est bien connue dans les cercles brésiliens de logistique et de finance : implémenter un module ERP qui importe directement le XML du CT-e, le valide par rapport aux enregistrements SEFAZ, et enregistre automatiquement les écritures de coût de fret. SAP TDF, TOTVS Protheus Fiscal et les modules de localisation brésilienne d'Oracle prennent tous en charge ce flux. La technologie existe. Le coût, pour la plupart des opérations logistiques de taille moyenne, est prohibitif.

SAP TDF repose sur SAP S/4HANA. Une entreprise qui n'est pas déjà sur S/4HANA fait face à une transformation ERP de plusieurs années et de plusieurs millions de réais avant de pouvoir envisager le module d'importation CT-e. Pour les entreprises déjà sur S/4HANA, une implémentation TDF prend 6 à 12 mois et coûte entre R$200 000 et R$500 000 en frais de conseil, plus des coûts de licence récurrents qui varient selon le nombre d'utilisateurs et la configuration du module.

TOTVS Protheus, bien que plus accessible pour le marché intermédiaire brésilien, impose tout de même un coût de licence de R$2 000 à R$10 000 par mois selon la pile de modules, plus du conseil en implémentation. La décision d'ajouter le module fiscal n'est pas motivée par le CT-e seul — c'est un investissement plus large dans l'infrastructure financière et fiscale de l'entreprise. La fonction d'importation CT-e n'est qu'une ligne dans un business case plus vaste, et si le traitement NF-e de l'entreprise est déjà géré manuellement sans module, ajouter le module uniquement pour le CT-e dépasse rarement le seuil de ROI.

Le résultat est un vide de traitement. Les grandes entreprises sur SAP S/4HANA avec TDF peuvent traiter le XML CT-e automatiquement. Les très petites opérations traitant 20 CT-e par mois continuent manuellement car le volume ne justifie aucun investissement. Les opérations de taille moyenne — 200 à 500 CT-e par mois — occupent le milieu douloureux : le processus manuel coûte R$30 000 à R$80 000 par an en main-d'œuvre, mais le module ERP coûte plus cher à implémenter que le processus manuel ne coûte en une seule année. Le business case exige une vision pluriannuelle que de nombreuses entreprises ne sont pas structurées pour évaluer.

Couche 4 : Fragmentation du secteur — plus de 650 000 transporteurs

Le facteur structurel qui amplifie toutes les autres couches est l'échelle et la fragmentation du secteur du fret routier brésilien. La base de transporteurs enregistrés auprès de l'ANTT, d'environ 650 000 opérateurs, fait de la normalisation sectorielle un idéal théorique qu'aucun système pratique ne peut atteindre. Un destinataire recevant du fret entrant de 200 fournisseurs peut interagir avec 80 à 100 transporteurs différents en un seul mois. Chacun utilise son propre système de facturation, sa propre variante de mise en page DACTE, son propre format d'envoi par e-mail et sa propre définition de la « remise de facture ».

L'intégration ERP au niveau du transporteur — où chaque transporteur transmet son XML CT-e au système du destinataire — exigerait que chacun de ces 80 à 100 transporteurs prenne en charge une intégration API. Pour les grands transporteurs, c'est réalisable. Pour la majorité des petits transporteurs et des propriétaires-exploitants, ce ne l'est pas. La structure du secteur fait d'un pipeline de données entièrement intégré une cible irréaliste pour la plupart des destinataires, quel que soit leur investissement ERP.

L'implication pratique : le problème de saisie de données du destinataire n'est pas que les transporteurs refusent d'envoyer le XML. C'est que les données arrivent par 100 canaux différents, dans 100 mises en page DACTE différentes, et le seul dénominateur commun est la page imprimée qui accompagne la marchandise. Toute solution exigeant une intégration par transporteur — qu'il s'agisse de configuration API, de personnalisation de l'analyse XML ou de configuration de modèles — échoue dès que le nombre de transporteurs dépasse une poignée.

C'est pourquoi l'extraction au niveau visuel — lire l'impression DACTE comme une image et la convertir en données structurées — n'est pas une solution de contournement au problème d'intégration, mais la seule solution qui répond directement à la fragmentation du secteur. Elle ne requiert aucune action du transporteur. Elle traite toute mise en page DACTE de tout transporteur dans le même lot. Et elle ne dépend pas de la feuille de route ERP du destinataire.

Ce que l'extraction au niveau visuel change

Les quatre couches du paradoxe du CT-e — l'inaccessibilité du XML, le DACTE par défaut, le coût du module ERP, la fragmentation du secteur — forment un piège structurel que la refonte manuelle des processus ne peut pas contourner. Chaque couche est résolvable indépendamment pour un sous-ensemble de cas, mais la combinaison couvre pratiquement toutes les opérations logistiques : assez grandes pour avoir de l'échelle, assez fragmentées pour empêcher la standardisation, et juste sous le seuil d'investissement pour la solution d'entreprise.

L'extraction visuelle — qui traite l'impression du DACTE comme document source et en extrait les données grâce à l'Extraction de colonnes personnalisées basée sur l'IA — brise le piège à un autre endroit. Elle n'exige pas que le XML circule du transporteur au destinataire (couche 1). Elle fonctionne avec le DACTE déjà disponible (couche 2). Elle coûte des ordres de grandeur de moins qu'un module ERP et livre des résultats en quelques heures, pas en quelques mois (couche 3). Et elle gère tous les formats de transporteurs en un seul lot, sans intégration par transporteur (couche 4).

Le mécanisme est simple : téléversez le PDF ou l'image du DACTE, saisissez les noms de colonnes à extraire, et l'IA localise chaque valeur sur la page imprimée en comprenant ce qu'elle signifie — sans correspondre à un modèle préconfiguré. Le résultat est une ligne de feuille de calcul par document, prête pour votre registre de coûts existant ou votre import ERP. Le guide d'extraction CT-e étape par étape détaille les définitions de colonnes et le flux de traitement.

Pour les équipes qui ont besoin de plus qu'une extraction par document — notamment les colonnes calculées qui calculent le coût du fret au kg, la validation du taux ICMS effectif ou l'agrégation mensuelle par lot — le guide de traitement par lots pour les registres de coûts de fret CT-e étend le flux pour gérer des lots multi-transporteurs avec une analyse des coûts intégrée.

Questions fréquemment posées

Ne puis-je pas simplement demander le XML du CT-e au transporteur ?

Vous pouvez le demander. Que vous le receviez de manière fiable dépend du transporteur. Les grands transporteurs (JSL, Braspress, Rodonaves) fournissent généralement le téléchargement du XML via leurs portails de facturation. Les petits transporteurs et les propriétaires-exploitants peuvent ne pas avoir de mécanisme pour renvoyer ou partager le XML après l'émission, car leur outil d'émission est un formulaire web gratuit de la SEFAZ qui envoie le XML uniquement au gouvernement. En pratique, les contrats d'approvisionnement avec les grands transporteurs peuvent imposer la livraison du XML ; avec le reste du marché, le DACTE PDF ou l'impression est ce que vous obtiendrez.

L'impression du DACTE suffit-elle comme données, ou ai-je besoin du XML complet ?

Le DACTE contient les données nécessaires au suivi des coûts et au paiement du transporteur — valeur du service, montant ICMS, poids, itinéraire, parties. Il ne contient pas le détail complet des marchandises par ligne, certaines ventilations fiscales au niveau du produit, ni l'historique complet des événements (amendements du CT-e, événements d'annulation). Pour la comptabilité analytique du fret, le DACTE couvre les champs essentiels. Pour la conformité SPED EFD ICMS/IPI au plus haut niveau de détail, le XML complet est préférable. La stratégie pratique : extraire le DACTE pour le suivi des coûts ; demander le XML pour la conformité lorsque l'équipe fiscale a besoin de la ventilation fiscale complète.

Quel est le coût réel de la mise en œuvre de l'importation XML du CT-e dans mon ERP ?

Pour SAP S/4HANA avec TDF, estimez R$200 000–R$500 000 en frais de conseil plus 6 à 12 mois de mise en œuvre, en plus de la licence S/4HANA elle-même. Pour TOTVS Protheus, estimez R$24 000–R$120 000 par an en licences (R$2 000–R$10 000/mois) plus le conseil de mise en œuvre à R$30 000–R$80 000. Pour les modules équivalents Oracle ou Sage, le coût est comparable. Ces chiffres concernent la mise en œuvre du module ERP qui couvre tous les documents fiscaux brésiliens — l'importation du XML du CT-e est une fonctionnalité dans le cadre d'un module plus vaste. Certains packages de localisation ERP plus petits peuvent offrir l'importation du CT-e à un coût inférieur, mais exigent généralement que l'entreprise soit déjà sur cette plateforme ERP.

Puis-je exiger de mes transporteurs qu'ils envoient le XML dans mes contrats d'approvisionnement ?

Oui, vous le pouvez — et les grands expéditeurs le font souvent. La limite pratique est que le levier d'application fonctionne pour les transporteurs qui se font concurrence pour votre activité. Pour les expéditions ponctuelles, le fret urgent ou les routes desservies par un ou deux transporteurs seulement, le levier est plus faible. Et pour les nombreux petits transporteurs qui livrent le fret entrant de vos fournisseurs (pas des transporteurs que vous avez contractés), vous n'avez aucune relation contractuelle du tout. Dans ces cas — qui représentent une part importante du fret entrant pour la plupart des fabricants — le DACTE est le seul document qui existe entre vous et les données de transport.

L'extraction visuelle du DACTE produit-elle la même précision que l'analyse XML ?

L'analyse XML est précise à 100 % car les données sont déjà structurées. L'extraction visuelle d'un imprimé DACTE ou d'un PDF introduit les limites de précision de toute lecture de document par IA — excellente sur les PDF et scans propres (jusqu'à 99 % sur les champs imprimés), légèrement inférieure sur les photographies de mauvaise qualité ou les annotations manuscrites. La différence est que l'analyse XML n'est pas toujours disponible, tandis que l'extraction visuelle est toujours possible. Le choix n'est pas entre la précision XML et la précision DACTE ; il est entre l'extraction DACTE (avec son léger compromis de précision) et la ressaisie manuelle du DACTE (avec son taux d'erreur de 1 à 4 % et un coût de 90 secondes par document).

Où le CT-e s'inscrit-il dans l'écosystème plus large des documents électroniques au Brésil ?

Le CT-e fonctionne aux côtés de la NF-e (facture de marchandises), de la NFS-e (facture de services), du MDF-e (manifeste de fret qui regroupe plusieurs CT-e sur un seul véhicule) et du BP-e (billet de passager). Pour la gestion des coûts logistiques, la relation clé est entre le CT-e et la NF-e : le CT-e documente le coût de transport, la NF-e documente la valeur des marchandises, et les deux ensemble produisent le coût total rendu. Le guide du hub de documents électroniques brésiliens fournit un aperçu complet de la façon dont ces documents interagissent et où chacun s'inscrit dans le flux de travail logistique.