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

Le terme « document de fret é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 spécifique — c'est un document fiscal électronique soumis à et autorisé par l'autorité fiscale de l'État avant que la cargaison ne se déplace. Son principal consommateur est la SEFAZ, pas l'expéditeur, pas le destinataire, et certainement pas l'analyste de fret qui a besoin de la valeur du service pour alimenter le grand livre des coûts.

Le système SEFAZ du Brésil traite plus de 300 millions de documents CT-e par an dans 27 autorités fiscales d'État indépendantes. Le système est conçu pour garantir que chaque mouvement de fret peut ê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 tableur. 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é du XML — Pourquoi les transporteurs n'envoient pas le fichier structuré

L'explication la plus directe de la ressaisie manuelle semblerait être la plus facile à corriger : les transporteurs ont le XML du CT-e, les destinataires le veulent, 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'impression DACTE ou le PDF qui les accompagne. Fournir le XML est un service commercial, pas une obligation légale, et de nombreux transporteurs le traitent comme une fonctionnalité payante 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 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 offrent le téléchargement de XML, l'accès API et la livraison automatisée de factures. Mais la majorité des transporteurs sont petits — des propriétaires-exploitants de camion unique (transportador autônomo) ou des entreprises régionales avec moins de dix véhicules. Leur flux de travail 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 par la suite. Pour ces transporteurs, fournir le PDF DACTE par e-mail est la limite de leurs capacités numériques.

Troisièmement, le système du destinataire peut ne pas être en mesure de consommer le XML. Même lorsque le 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 CT-e est prise en charge par le TDF (Tax Declaration Framework) de SAP (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 licences). Pour les entreprises de taille intermédiaire, trop grandes pour une saisie entièrement manuelle 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 clé d'accès (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 CT-e complet. Le schéma complet comprend des descriptions de cargaison au niveau de la ligne, plusieurs ventilations fiscales par produit, les 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 limitations, le DACTE est ce que l'équipe logistique a. 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à qu'intervient la deuxième couche du paradoxe : le document le plus facile d'accès (l'impression du DACTE) contient moins de données que le document plus difficile d'accès (le XML), mais l'équipe construit son processus autour du document accessible.

Couche 3 : Coût du module ERP — quand la solution technique est trop onéreuse

La solution techniquement correcte au paradoxe des données CT-e est bien connue dans les milieux brésiliens de la logistique et de la 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 même de pouvoir envisager le module d'importation CT-e. Pour les entreprises déjà sur S/4HANA, une implémentation TDF dure 6 à 12 mois et coûte entre 200 000 et 500 000 R$ en frais de conseil, plus des frais 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 2 000 à 10 000 R$ par mois selon la pile de modules, plus des services de conseil pour l'implémentation. La décision d'ajouter le module fiscal n'est pas motivée par le seul CT-e — il s'agit d'un investissement plus large dans l'infrastructure financière et fiscale de l'entreprise. La fonction d'importation CT-e n'est qu'un élément parmi d'autres dans un business case plus vaste, et si le traitement des NF-e de l'entreprise est déjà effectué manuellement sans module, l'ajout du module pour le seul CT-e dépasse rarement le seuil de rentabilité.

Le résultat est un vide de traitement. Les grandes entreprises sur SAP S/4HANA avec TDF peuvent traiter automatiquement le XML CT-e. 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 douloureux entre-deux : le processus manuel coûte entre 30 000 et 80 000 R$ 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 cas d'investissement nécessite 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'ampleur et la fragmentation du secteur du transport routier de marchandises au Brésil. La base de transporteurs enregistrés auprès de l'ANTT, d'environ 650 000 opérateurs, fait de la normalisation à l'échelle du secteur 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 du DACTE, son propre format d'envoi par e-mail et sa propre définition de la « livraison de facture ».

L'intégration ERP au niveau du transporteur — où chaque transporteur transmet son XML CT-e au système du destinataire — nécessiterait 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é un objectif 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 les marchandises. Toute solution qui nécessite une intégration par transporteur — qu'il s'agisse de configuration d'API, de personnalisation d'analyse XML ou de configuration de modèle — échoue lorsque le nombre de transporteurs dépasse une poignée.

C'est pourquoi l'extraction au niveau visuel — lire le document imprimé DACTE comme une image et le 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 nécessite aucune action de la part du transporteur. Elle traite n'importe quelle mise en page DACTE de n'importe quel 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 — inaccessibilité du XML, DACTE par défaut, coût du module ERP, fragmentation du secteur — forment un piège structurel dont la refonte manuelle des processus ne peut s'échapper. Chaque couche est résoluble indépendamment pour un sous-ensemble de cas, mais la combinaison couvre pratiquement toutes les opérations logistiques : suffisamment vastes pour avoir une échelle, suffisamment fragmentées pour empêcher la standardisation, et juste en dessous du seuil d'investissement pour une solution d'entreprise.

L'extraction visuelle — qui traite l'impression du DACTE comme document source et extrait ses données via l'Extraction de colonnes personnalisées basée sur l'IA — brise le piège à un point différent. Elle ne nécessite 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 fournit des résultats en quelques heures, et non en mois (Couche 3). Et elle gère toutes les mises en page des transporteurs en un seul lot, sans intégration par transporteur (Couche 4).

Le mécanisme est simple : téléchargez le PDF ou l'image du DACTE, saisissez les noms des colonnes que vous souhaitez extraire, et l'IA localise chaque valeur sur la page imprimée en comprenant ce qu'elle signifie — et non en faisant correspondre un modèle préconfiguré. Le résultat est une ligne de tableur par document, prête pour votre grand livre des 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 — y compris les colonnes calculées qui calculent le coût du fret par kg, la validation du taux ICMS effectif, ou l'agrégation mensuelle par lot — le guide de traitement par lots pour les grands livres de coûts de fret CT-e étend le flux pour gérer les lots multi-transporteurs avec une analyse des coûts intégrée.

Questions fréquentes

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é, c'est le PDF du DACTE ou l'impression que vous obtiendrez.

L'impression du DACTE fournit-elle suffisamment de 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 de l'ICMS, poids, itinéraire, parties prenantes. 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é des coûts de 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 l'implémentation de l'importation du XML CT-e dans mon ERP ?

Pour SAP S/4HANA avec TDF, estimez entre 200 000 et 500 000 R$ de frais de conseil, plus 6 à 12 mois d'implémentation, en plus de la licence S/4HANA elle-même. Pour TOTVS Protheus, estimez entre 24 000 et 120 000 R$ par an de licence (2 000 à 10 000 R$/mois) plus un conseil d'implémentation de 30 000 à 80 000 R$. Pour les modules équivalents d'Oracle ou Sage, le coût est comparable. Ces chiffres concernent l'implémentation du module ERP qui couvre tous les documents fiscaux brésiliens — l'importation du XML CT-e est une fonctionnalité dans le cadre d'un module plus vaste. Certains packages de localisation ERP plus petits peuvent proposer l'importation 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 ?

Vous le pouvez — et les grands expéditeurs le font souvent. La limitation pratique est que le levier de mise en application fonctionne pour les transporteurs qui se disputent votre clientèle. Pour les expéditions ponctuelles, les urgences 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 (et non les transporteurs que vous avez contractés), vous n'avez aucune relation contractuelle. 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 offre-t-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 tirage 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, alors que l'extraction visuelle est toujours possible. Le choix ne se fait pas entre la précision du XML et celle du DACTE ; il se fait entre l'extraction du 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ù se situe le CT-e dans l'écosystème plus large des documents électroniques au Brésil ?

Le CT-e coexiste avec la NF-e (facture de marchandises), la NFS-e (facture de services), le MDF-e (manifeste de fret qui regroupe plusieurs documents CT-e sur un même véhicule) et le BP-e (billet de transport de passagers). 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 du transport, la NF-e documente la valeur des marchandises, et les deux ensemble produisent le coût total débarqué. Le guide du hub des documents électroniques brésiliens fournit un aperçu complet de la manière dont ces documents interagissent et de la place de chacun dans le flux de travail logistique.