Pourquoi le traitement des factures CFDI mexicaines
est plus complexe que prévu

Plus qu'une simple facture longue : le problème de surface

Un CFDI (Comprobante Fiscal Digital por Internet) conforme à l'Article 29-A du CFF n'est pas simplement une facture longue. C'est un document XML imposé par le gouvernement, dont la structure est définie par la norme technique de l'Anexo 20 — un cahier des charges qui, dans sa version actuelle CFDI 4.0, définit plus de 100 éléments XML possibles et plusieurs chaînes de validation conditionnelles. Mais pointer le nombre de champs comme le problème rate ce qui ralentit réellement le traitement. La difficulté n'est pas qu'il y ait beaucoup de champs. La difficulté est que les champs sont liés entre eux de manière à créer des obligations de suivi entre des documents, des systèmes et des moments distincts.

Les symptômes sont faciles à repérer. Une facture est rejetée par le PAC (Proveedor Autorizado de Certificación) de votre fournisseur parce que le RFC (Registro Federal de Contribuyentes — l'identifiant fiscal mexicain) du destinataire ne correspond pas exactement au registre des contribuables du SAT — une différence aussi minime qu'un accent manquant. Un paiement qui a été crédité la semaine dernière n'apparaît sur aucune des factures ouvertes de votre grand livre, car le paiement a été émis sous la forme d'un CFDI distinct de type Pago référençant l'UUID (Universally Unique Identifier) de la facture d'origine, plutôt que d'apparaître comme une ligne sur le document original. Une facture traitée par votre équipe il y a trois semaines s'avère avoir été annulée par le fournisseur — mais personne dans votre entreprise n'a accepté ou rejeté la demande d'annulation dans les 72 heures, elle a donc été automatiquement approuvée. Votre écriture de comptes fournisseurs fait désormais référence à un document annulé.

Ce ne sont pas des cas exceptionnels. Ce sont les conditions de fonctionnement normales du traitement des factures de fournisseurs mexicains à toute échelle supérieure à une poignée par mois. Et elles ne proviennent pas de mauvaises pratiques des fournisseurs ou d'outils de comptes fournisseurs inadéquats, mais de l'architecture même du système CFDI — un système dont les objectifs de conception étaient la visibilité réglementaire et le contrôle fiscal, et non l'efficacité opérationnelle pour le côté récepteur de la transaction.

Couche 1 : L'architecture réglementaire qui fait de chaque CFDI une mini-déclaration fiscale

Dans la plupart des pays, une facture est un document commercial : elle enregistre ce qui a été vendu, à qui et pour quel montant. La déclaration fiscale intervient plus tard — lorsque le vendeur dépose sa déclaration de TVA, lorsque l'acheteur comptabilise la dépense. Au Mexique, la facture est la déclaration fiscale. La distinction n'est pas théorique. Elle modifie les informations qui doivent être présentes au moment de la création et qui doit les vérifier avant que le document n'ait force de loi.

Le Mexique fonctionne selon ce que les chercheurs en systèmes fiscaux appellent un modèle de validation en temps réel. En vertu de l'article 29, section IV du CFF, chaque CFDI doit être transmis au SAT (Service d'administration fiscale, l'autorité fiscale fédérale mexicaine) avant de pouvoir être émis au destinataire. La transmission passe par un PAC — un intermédiaire certifié par le SAT — qui valide la structure XML selon les règles de l'Anexo 20, vérifie que les RFC de l'émetteur et du destinataire existent dans le registre actif des contribuables du SAT, confirme que le CSD (Certificat de Sceau Numérique) de l'émetteur est valide et non révoqué, contrôle la cohérence interne des calculs fiscaux, et seulement ensuite applique le timbre fiscal digital (cachet fiscal numérique) et renvoie le CFDI validé avec son UUID attribué.

Pour votre équipe AP, cela signifie que chaque CFDI reçu a déjà passé un point de contrôle gouvernemental. Les données qu'il contient ne sont pas une simple affirmation du fournisseur — ce sont des données que le SAT a vues. Cela rend ces données plus fiables qu'une facture classique. Cela signifie aussi que les erreurs dans les données — un RFC incorrect, un mauvais code de régime fiscal — ne peuvent pas être corrigées par votre fournisseur avec un simple PDF mis à jour. Le CFDI erroné doit être annulé via un processus formel d'annulation, et un nouveau doit être émis depuis le début.

Les données requises ne se limitent pas à « nom, date, montant ». L'article 29-A du CFF impose que chaque CFDI de type Ingreso (facture de revenus) contienne : le RFC de l'émetteur, sa raison sociale et son code de régime fiscal ; le RFC du destinataire, sa raison sociale, le code postal de son domicile fiscal et le code Uso CFDI déclarant l'utilisation fiscale de la facture par le destinataire ; le lieu et la date d'émission ; un numéro de folio unique ; le sceau numérique de l'émetteur ; des lignes de détail avec quantités, unités de mesure, codes de classification de produits/services du SAT (ClaveProdServ), prix unitaires et totaux ; une ventilation complète des taxes par type (IVA — Taxe sur la Valeur Ajoutée — transferts et retenues) ; la forme de paiement (Forma de Pago) et la méthode de paiement (Método de Pago, codé PUE pour paiement unique ou PPD pour paiement différé/échelonné) ; ainsi que l'UUID et l'horodatage de certification.

Chacun de ces champs est important non seulement pour vos archives, mais aussi pour les moteurs de recoupement du SAT. Le RFC et le nom du destinataire sont recoupés avec le registre des contribuables du SAT. Le code de régime fiscal — un identifiant numérique comme 601 pour les sociétés, 612 pour les particuliers avec activités commerciales, 605 pour les salariés — détermine le traitement fiscal applicable aux deux parties de la transaction. Une discordance entre le régime déclaré de l'émetteur et le type de revenu déclaré peut déclencher un signalement automatique pour contrôle fiscal. C'est pourquoi vos fournisseurs mexicains sont si rigides pour obtenir votre RFC et votre code de régime fiscal corrects avant d'émettre une facture : ils ne font pas de bureaucratie inutile. Ils se conforment à un système qui rejette les factures contenant des données ne correspondant pas aux registres du SAT.

La réforme fiscale de 2026 a ajouté une nouvelle dimension à cette couche. Une nouvelle disposition (Fracción IX) a été ajoutée à l'article 29-A du CFF, effective au 1er janvier 2026, exigeant que les CFDIs reflètent des transactions réelles et véridiques. Si un CFDI ne représente pas un acte juridique ou une opération réelle, il sera considéré comme faux — avec des conséquences incluant désormais la responsabilité pénale pour les émetteurs, les destinataires et les intermédiaires. Cela augmente les enjeux de chaque CFDI que votre entreprise reçoit : un fournisseur qui vous émet une facture pour des services non réellement fournis ne commet pas seulement une erreur de déclaration. Il crée un document que le SAT peut présumer faux, et le nom et le RFC de votre entreprise peuvent être publiés comme destinataire d'un faux CFDI, avec 30 jours pour corriger vos déclarations fiscales.

Résumé de la complexité de la couche 1 : le document que vous traitez n'a pas été conçu pour vous. Il a été conçu pour l'infrastructure de surveillance en temps réel du SAT. Votre flux de travail AP hérite de chaque champ et de chaque validation exigée par le SAT — que ces champs soient pertinents ou non pour votre comptabilité.

Couche 2 : L'architecture documentaire — Pourquoi une transaction génère deux (ou plus) XML

Si la couche réglementaire ajoute des champs obligatoires, la couche d'architecture documentaire divise la transaction elle-même en plusieurs fichiers. C'est là que le traitement des CFDI diverge le plus nettement de ce qu'une équipe AP formée aux formats de factures américains ou européens attend.

La division commence par un champ appelé Método de Pago. Lorsque la valeur est PUE (Pago en Una Sola Exhibición — paiement en une seule fois), le CFDI Ingreso enregistre la transaction complète : biens ou services, montants, taxes, et le fait que le paiement est réglé intégralement au moment de l'émission. Un document, une transaction. C'est le CFDI le plus proche d'une facture ordinaire.

Lorsque la valeur est PPD (Pago en Parcialidades o Diferido — paiement échelonné ou différé), le CFDI Ingreso enregistre uniquement l'obligation. Le paiement effectif — quand il a lieu, combien, par quel moyen — est enregistré dans un CFDI séparé de type Pago (paiement), qui porte le Complemento de Recepción de Pagos (Complément de réception de paiements, parfois appelé Complemento de Pago). Ce complément référence l'UUID du CFDI Ingreso d'origine et enregistre : la date de paiement, le montant payé, le mode de paiement (virement, chèque, espèces, portefeuille électronique), la devise et le taux de change le cas échéant, et le solde restant après ce paiement.

Une transaction commerciale génère désormais deux XML qui doivent être suivis ensemble. Si le paiement est effectué en trois versements, cela génère quatre XML : un Ingreso et trois CFDI Pago, chacun avec son propre UUID, chacun référençant l'original via la structure du complément. Les rapprocher signifie faire correspondre l'UUID de chaque complément Pago à l'UUID de l'Ingreso d'origine, additionner les paiements partiels et confirmer que le solde atteint zéro. Si vous manquez un CFDI Pago dans votre boîte de réception, l'Ingreso apparaît impayé dans votre grand livre indéfiniment — même si la banque montre le débit.

Cette structure à deux documents crée des problèmes en aval qui s'aggravent avec le volume. À la clôture mensuelle, une équipe comptable traitant 50 factures de fournisseurs mexicains utilisant des conditions PPD doit potentiellement rapprocher 100 XML ou plus — chacun nécessitant une référence croisée UUID entre l'Ingreso et son ou ses compléments Pago. Un rapprochement manuel implique d'ouvrir chaque XML Pago, de trouver le nœud UUID référencé, de rechercher une correspondance dans la base de données Ingreso traitée, de vérifier que les montants concordent, et de marquer les deux comme rapprochés. À trois minutes par rapprochement, 50 paires PPD consomment deux heures et demie de temps de personnel comptable — chaque mois, pour les fournisseurs d'un seul pays.

Il existe une autre dimension de séparation des documents : la relation entre le XML et la représentation PDF. Selon la loi mexicaine, le fichier XML — signé numériquement et tamponné par le PAC — est le document juridiquement faisant autorité. Le PDF est une représentation visuelle réglementée par le SAT (il doit inclure un code-barres bidimensionnel encodant un lien vers le portail de vérification du SAT), mais il n'a aucun poids juridique indépendant. Si les données du PDF diffèrent de celles du XML correspondant — ce qui peut arriver lorsque les systèmes ERP des fournisseurs génèrent le PDF à partir d'un modèle qui tronque ou reformate les champs — le XML est ce que le SAT considère comme correct. Une équipe comptable qui saisit les données du PDF sans vérifier le XML traite, d'un point de vue conformité, une impression décorative.

Pour en savoir plus sur le processus d'extraction des données CFDI à partir du XML et du PDF vers Excel, consultez notre guide pratique d'extraction CFDI. Pour le traitement des factures CFDI à grande échelle — en particulier la référence croisée UUID entre les compléments Pago — consultez notre guide de traitement par lots CFDI.

Couche 3 : Le piège de l’annulation — Pourquoi corriger une erreur prend 72 heures et deux signatures

Dans la plupart des environnements de traitement de factures, corriger une erreur signifie que le fournisseur envoie une note de crédit ou un PDF révisé, et que l’acheteur comptabilise l’ajustement. Dans le système CFDI, une facture émise et timbrée ne peut pas être modifiée. Elle ne peut qu’être annulée — et l’annulation est elle-même un processus réglementé impliquant les deux parties, un système gouvernemental et un délai.

Selon les règles actuelles, annuler un CFDI nécessite que l’émetteur soumette une demande d’annulation via la boîte postale fiscale du SAT (Buzón Tributario) en précisant l’un des quatre codes de motif standardisés : 01 — document émis avec des erreurs liées (le CFDI annulé sera remplacé par un document connexe) ; 02 — document émis avec des erreurs non liées ; 03 — la transaction n’a pas eu lieu ; 04 — opération nominative connexe dans une facture globale. Le code 01 est le plus courant pour les corrections commerciales, et il oblige l’émetteur à préciser l’UUID du CFDI de remplacement qui se substitue à celui annulé.

Une fois la demande d’annulation soumise, le destinataire dispose de 72 heures (trois jours ouvrés) pour l’accepter ou la rejeter. Si le destinataire ne fait rien, l’annulation est automatiquement approuvée par expiration du délai. S’il la rejette, le CFDI reste légalement actif, et l’émetteur doit soit renégocier avec le destinataire, soit recourir aux canaux de résolution des litiges du SAT.

Il existe des exceptions limitées où l’approbation du destinataire n’est pas requise : les CFDIs de paie (Nómina), les factures inférieures à 1 000 MXN, les transactions avec le grand public (utilisant le RFC générique XAXX010101000), et les annulations effectuées dans les 72 heures suivant l’émission initiale. Pour tout le reste — chaque CFDI Ingreso commercial supérieur à 1 000 MXN — le délai d’acceptation de 72 heures du destinataire s’applique.

Pour l’équipe AP destinataire, cela crée deux risques opérationnels. Le premier est le risque de document annulé : un CFDI que vous avez traité et comptabilisé il y a trois semaines peut avoir été annulé par le fournisseur, et comme personne dans votre organisation ne s’est connecté à la boîte postale fiscale du SAT pour accepter ou rejeter la demande, elle a été approuvée silencieusement. Vos livres contiennent désormais une écriture adossée à un document fiscal annulé — une constatation que le SAT traitera comme une dépense appuyée par un CFDI invalide, rejetant la déduction et pouvant entraîner des arriérés d’impôts et des pénalités.

Le second est le défaut de suivi des remplacements : lorsqu’un fournisseur annule un CFDI avec le code motif 01, il émet un CFDI de remplacement avec un nouvel UUID. Votre équipe AP doit alors localiser l’écriture d’origine, l’annuler et saisir le remplacement — en faisant correspondre le nouvel UUID à l’ancien. Si le remplacement arrive dans un fil de discussion différent, avec un objet légèrement différent, traité par un autre membre de l’équipe, le lien entre l’original et le remplacement est perdu, et les deux versions peuvent se retrouver simultanément dans votre système.

Couche 4 : Multi-RFC et maux de tête transfrontaliers

Les trois couches ci-dessus s'appliquent à toute organisation recevant des factures CFDI mexicaines. Pour les multinationales, il existe une quatrième complication liée à l'interaction du système RFC avec les opérations transfrontalières.

Une entreprise avec plusieurs entités juridiques au Mexique — une filiale de fabrication, une filiale de distribution, une entité de services — aura un RFC distinct pour chacune. Les factures CFDI envoyées au mauvais RFC sont légalement adressées au mauvais contribuable. Un fournisseur émet la facture au RFC de la filiale de fabrication, mais les marchandises ont été livrées et consommées par l'entité de distribution. L'entité de fabrication ne peut pas déduire légalement la dépense car la transaction n'a pas eu lieu sous son immatriculation fiscale — et l'entité de distribution n'a aucun CFDI pour justifier son coût des marchandises. Corriger cela nécessite un cycle d'annulation et de réémission, avec toutes les implications d'acceptation du destinataire sous 72 heures décrites ci-dessus.

Pour les entreprises étrangères qui reçoivent des factures CFDI de fournisseurs mexicains mais n'ont pas leur propre RFC, le RFC générique pour destinataire étranger — XEXX010101000 — peut être utilisé. Ce RFC a des limitations importantes. Il ne permet pas au destinataire de réclamer des crédits de TVA ou de déduire la dépense à des fins fiscales mexicaines (ce qui, pour une entreprise étrangère sans obligation de déclaration fiscale au Mexique, est généralement sans importance). Plus significatif sur le plan opérationnel : comme XEXX010101000 est un identifiant générique utilisé par des milliers d'entités non liées, il n'offre aucune traçabilité vers une entité corporative spécifique. Si votre entreprise a trois bureaux régionaux, chacun recevant des factures CFDI de différents fournisseurs mexicains, tous utilisant XEXX010101000, il n'existe aucun moyen au niveau du RFC d'acheminer les factures vers la bonne entité lors du traitement. La logique de routage doit être intégrée à votre flux de travail AP — en se fiant au nom du fournisseur, au champ de description ou au destinataire de l'e-mail — dont aucun n'a la fiabilité structurelle d'un identifiant fiscal.

Il y a aussi le problème de décalage du régime fiscal côté récepteur. Lorsqu'un fournisseur mexicain émet un CFDI, il doit enregistrer le code du régime fiscal du destinataire. Si votre entreprise a obtenu un RFC pour une entité mexicaine, cette entité est enregistrée sous un régime spécifique — par exemple, 601 (Régime général des personnes morales). Si le fournisseur saisit par erreur 612 (Particuliers avec activités commerciales) parce que quelqu'un a fourni le mauvais code lors de l'intégration, le CFDI peut quand même passer la validation PAC (car 612 est un code de régime valide), mais il contiendra une erreur de données structurelle que le SAT peut signaler lors d'un audit futur. Le CFDI est valide mais incorrect — le type d'erreur le plus difficile à détecter avant qu'il ne devienne un problème.

Pour une analyse du défi plus large du traitement des documents sur les marchés hispanophones, consultez notre aperçu de l'extraction de documents sur les marchés hispaniques.

Pourquoi les approches basées sur des modèles échouent avec le CFDI

Une réponse courante à la complexité du traitement des factures est l'OCR basé sur des modèles : définir un modèle pour chaque mise en page de fournisseur, mapper les champs à des positions et extraire les données par coordonnées. Cette approche suppose que le format du document est suffisamment cohérent pour qu'un modèle entraîné sur un échantillon fonctionne sur les centaines suivants. Le CFDI brise cette hypothèse sur deux fronts.

Premièrement, la représentation PDF varie selon le fournisseur. Même si chaque CFDI contient les mêmes champs obligatoires définis par l'Anexo 20, chaque ERP ou système de facturation du fournisseur rend le PDF différemment. Un fournisseur place l'UUID dans le coin supérieur droit sous forme de chaîne de 36 caractères. Un autre l'intègre uniquement dans le code-barres QR en bas. Un troisième l'imprime dans une police condensée dans le pied de page. Un modèle conçu pour la mise en page du fournisseur A échoue complètement sur la facture du fournisseur B.

Deuxièmement, le PDF et le XML peuvent contenir des données différentes. L'ERP d'un fournisseur peut générer le PDF à partir d'un sous-ensemble des champs XML — affichant le total des lignes mais pas la ventilation de la TVA, affichant le nom commercial du fournisseur au lieu de la raison sociale enregistrée. Si votre outil d'extraction lit le PDF, il capture les données imprimées simplifiées. Si votre obligation de conformité exige les détails fiscaux complets du XML, le PDF est insuffisant. Une équipe AP qui rapproche le PDF rapproche moins de données que ce que le SAT considère comme le document faisant autorité.

L'approche qui gère cette variabilité structurelle est celle qui lit le contenu du document — la signification sémantique de champs comme UUID, RFC, IVA 16%, Régimen Fiscal — indépendamment de leur emplacement sur la page et indépendamment du fait que la source soit un PDF ou un XML. L'extraction sémantique identifie un RFC non pas parce qu'il se trouve aux coordonnées (200, 450) mais parce qu'il correspond au modèle d'un identifiant alphanumérique de 12 ou 13 caractères étiqueté "RFC" dans le texte environnant. C'est la différence entre cartographier des positions visuelles et comprendre le contenu du document — et c'est la différence qui rend le traitement du CFDI viable à grande échelle plutôt qu'une charge de maintenance de modèles par fournisseur.

Ce que cela implique pour votre workflow AP au Mexique

En combinant ces quatre couches, un workflow de traitement CFDI qui en tient compte nécessite des fonctionnalités que la plupart des systèmes AP standards — conçus autour de l'idée qu'une facture est un document unique, autonome et sans état — ne fournissent pas nativement.

Ingestion multi-format. Le workflow doit accepter à la fois le XML et le PDF en entrée, car les fournisseurs livrent les deux et les données faisant autorité se trouvent dans le XML. Extraire uniquement du XML supprime l'étape de vérification visuelle (le document imprimé correspond-il aux données structurées ?). Extraire uniquement du PDF supprime le document légal. Les deux formats doivent alimenter le même pipeline d'extraction, produisant une ligne de sortie unifiée par CFDI.

Rapprochement basé sur l'UUID. L'UUID — l'identifiant de 36 caractères intégré dans chaque CFDI — est la clé permanente qui relie les factures Ingreso à leurs compléments Pago, suit les annulations et connecte chaque document au portail de vérification du SAT. Un workflow CFDI qui ne capture, ne stocke et ne recoupe pas les UUID entre les lots ne peut pas effectuer le rapprochement des paiements PPD sans recherches manuelles. Pour les workflows de rapprochement par lots, consultez notre guide de traitement CFDI par lots.

Validation du régime et du RFC à l'entrée. Avant qu'un CFDI n'entre dans votre système comptable, le RFC du destinataire et le code du régime fiscal doivent être validés par rapport aux données enregistrées de votre entreprise. Une discordance détectée à l'entrée évite une cascade : la dépense est comptabilisée sous la mauvaise entité, l'équipe fiscale découvre l'erreur lors de la préparation de l'audit, et la correction implique un cycle d'annulation-réémission avec un fournisseur qui n'est peut-être plus joignable.

Conscience du statut d'annulation. Un CFDI une fois traité n'est pas un CFDI définitivement réglé. Les workflows qui incluent des vérifications périodiques du statut de l'UUID sur le portail de vérification du SAT — ou qui exigent que les fournisseurs informent votre équipe des demandes d'annulation via un canal défini — réduisent le risque de conserver des documents annulés dans votre grand livre.

Aucun de ces éléments ne nécessite une intégration PAC à l'échelle de l'entreprise ou une plateforme dédiée de conformité fiscale mexicaine. Cela nécessite une étape de traitement qui comprend ce qu'est un CFDI — un enregistrement multi-document, avec état et validé par le gouvernement — et qui extrait ses données en conséquence, plutôt que de le traiter comme un long PDF avec des chiffres supplémentaires.

Questions fréquentes

Pourquoi les fournisseurs mexicains ne peuvent-ils pas simplement émettre une facture PDF normale ?

Parce que la loi mexicaine ne reconnaît pas le PDF comme un document fiscal valide. Depuis 2014, tous les contribuables au Mexique — entreprises, professionnels indépendants et particuliers exerçant des activités commerciales — sont tenus d'émettre des factures CFDI XML validées par un PAC et enregistrées en temps réel auprès du SAT. Un fournisseur qui émet uniquement un PDF ne produit pas une facture légalement valide selon la loi fiscale mexicaine, et vous ne pouvez pas utiliser un tel document pour justifier une déduction fiscale au Mexique.

Quelle est la différence entre PUE et PPD en pratique ?

PUE (paiement unique) signifie que la facture est réglée intégralement au moment de l'émission — un seul CFDI couvre l'ensemble de la transaction. PPD (paiement différé/échelonné) signifie que la facture enregistre l'obligation, et chaque paiement ultérieur génère un CFDI distinct de type Pago avec son propre UUID et un Complemento de Pago faisant référence à la facture d'origine. Le PPD nécessite le suivi d'au moins deux XML par transaction ; le PUE n'en nécessite qu'un. Le code de méthode de paiement (PUE ou PPD) apparaît dans le champ Método de Pago sur le CFDI de type Ingreso.

Dois-je conserver le XML ou le PDF suffit-il pour nos archives ?

Vous devez conserver le XML. Selon l'article 30 du CFF, l'émetteur et le récepteur doivent conserver les fichiers CFDI XML pendant au moins cinq ans. Le PDF est une représentation visuelle réglementée — il doit inclure un code QR renvoyant au portail de vérification du SAT — mais il n'a aucune valeur juridique indépendante. Lors d'un contrôle, le SAT demandera le XML, pas le PDF.

Que se passe-t-il si j'ignore une demande d'annulation d'un fournisseur ?

Si vous ne répondez pas dans les 72 heures (trois jours ouvrés), l'annulation est automatiquement approuvée par expiration du délai. Le CFDI devient nul, et toute déduction fiscale ou écriture de dépense dans votre système adossée à ce CFDI n'est plus étayée par un document fiscal valide. Si votre entreprise déclare ses impôts au Mexique, cela crée un risque de non-conformité. Si votre entreprise ne déclare pas au Mexique, le risque opérationnel est de payer sur une facture annulée sans s'en rendre compte.

Puis-je utiliser le RFC générique XEXX010101000 pour toutes les factures fournisseurs mexicaines ?

Oui, si votre entreprise n'a pas d'immatriculation fiscale mexicaine ni de RFC propre. Cependant, XEXX010101000 est un identifiant générique partagé par tous les destinataires étrangers — il n'offre aucune traçabilité au niveau de l'entité. Si votre entreprise possède plusieurs bureaux, départements ou entités recevant des CFDI, vous aurez besoin d'un mécanisme de routage interne (basé sur le nom du fournisseur, la description ou l'email) pour diriger chaque facture vers la bonne file de traitement.

La complexité de la CFDI est-elle pire que celle des autres systèmes de facturation électronique ?

Le système mexicain est l'un des plus strictement contrôlés au monde, aux côtés du NF-e brésilien. Les deux utilisent un visa gouvernemental en temps réel, exigent un XML structuré avec signature numérique, et créent des obligations de rapprochement entre les factures originales et les documents de paiement ou de transport ultérieurs. La complexité spécifique du système mexicain réside dans la double structure PPD/Pago et le mécanisme d'annulation avec acceptation du destinataire — des fonctionnalités sans équivalent direct dans la plupart des mandats de facturation électronique européens.