Traitement de factures CFDI mexicaines
50+ XML de 14 fournisseurs, un seul tableau AP propre

Quand 50 XML CFDI arrivent en fin de mois — l'écart entre « chaque XML est valide » et « le lot est propre »

Le système CFDI mexicain fonctionne sur un modèle de validation tripartite : le fournisseur génère un XML selon les spécifications de l'Anexo 20, un PAC certifié le valide et l'horodate avec un UUID (le Folio Fiscal de 36 caractères), et le SAT le reçoit en temps réel. Lorsqu'un CFDI arrive dans votre service comptable en tant que récepteur, le XML a déjà été certifié. Cela diffère des factures papier ou des factures fournisseur au format PDF dans la plupart des autres pays — et crée une première impression trompeuse.

Parce que chaque XML est individuellement valide, les équipes comptables supposent que le lot sera également propre. Ce ne sera pas le cas. Cinq problèmes structurels apparaissent lorsque vous rassemblez 50+ XML CFDI de plusieurs fournisseurs et tentez de les consolider dans un seul tableur comptable :

Mélange PUE et PPD. Les factures CFDI comportent un champ Método de Pago qui divise votre lot en deux pipelines de traitement fondamentalement différents. Les factures PUE (Pago en una sola exhibición) sont complètes en elles-mêmes — la facture est l'enregistrement fiscal final. Les factures PPD (Pago en parcialidades o diferido) sont incomplètes jusqu'à l'arrivée d'un CFDI de Paiement correspondant avec un Complemento de Pago. Dans un lot de 50 XML fournisseur, vous pourriez avoir 32 PUE et 18 PPD. Les PPD ne peuvent être comptabilisées tant que le complément de paiement n'est pas reçu et vérifié par rapport à l'UUID de la facture d'origine. Si votre tableur comptable les traite toutes comme des lignes équivalentes, vous comptabiliserez 18 transactions qui ne sont pas encore déductibles pour la TVA.

Fragmentation de l'Uso CFDI. Chaque CFDI porte un code Uso CFDI obligatoire — une valeur du catalogue SAT qui détermine comment le récepteur (votre entreprise) appliquera la facture à des fins fiscales. G01 (acquisition commerciale générale), G03 (dépense générale) et D01 (acquisition déductible pour opérations spécifiques) sont tous courants dans un lot de fournisseurs — mais ils déclenchent des traitements fiscaux différents, des catégories de déclaration DIOT différentes et des règles de crédit de TVA différentes. Un tableur qui regroupe tous les CFDI dans une seule colonne « Taxe » sans le code Uso CFDI est inutile pour remplir la DIOT, la déclaration mensuelle de TVA sur achats due avant le 17.

Échec de la déduplication basée sur l'UUID. La plupart des systèmes comptables dédoublonnent sur le nom du fournisseur + le numéro de facture. Dans le CFDI, le numéro de facture (Folio) n'est unique qu'au sein d'une seule Série d'un fournisseur — et même là, un fournisseur peut ajouter un nouvel UUID après avoir annulé et réémis une facture corrigée. Le véritable identifiant unique est le Folio Fiscal (UUID) de 36 caractères attribué par le PAC lors du timbrado. Sans extraire l'UUID de chaque XML, deux CFDI différents de fournisseurs différents avec la même valeur de Folio seront signalés comme des doublons — ou un CFDI de remplacement corrigé ne sera pas reconnu comme remplaçant l'original.

Retard de rapprochement du Complemento de Pago. Pour les factures PPD, le reçu de paiement (CFDI Tipo Pago avec Complemento de Pago) arrive séparément — parfois des jours ou des semaines après la facture Ingreso d'origine. Il référence l'UUID de la facture d'origine, enregistre le montant du paiement, la date et le mode de paiement, et doit être recoupé avec la ligne comptable ouverte. Dans un flux manuel, faire correspondre 18 factures PPD à leur Complemento de Pago respectif dans un lot de 50+ documents est un exercice de rapprochement qui peut prendre des heures — et un seul oubli laisse une dépense non déductible dans votre comptabilité.

Variations du format RFC dans le bloc du récepteur. La norme CFDI 4.0 impose le RFC exact dans le nœud du récepteur (votre entreprise). Mais certains fournisseurs — notamment les petits ou les producteurs agricoles — émettent des CFDIs avec le RFC générique XAXX010101000 lorsqu'ils ne disposent pas de vos données fiscales complètes. D'autres envoient des factures au RFC de votre filiale alors que votre système AP attend le RFC de la société mère. Ces écarts sont signalés au niveau du SAT : le CFDI existe, il est certifié, mais le RFC du récepteur ne correspond pas à votre ID fiscal enregistré, ce qui peut entraîner un refus du crédit de TVA lors d'un audit.

PUE vs PPD en vrac — Pourquoi un seul champ divise tout votre processus de fin de mois

Dans le système CFDI mexicain, le Método de Pago n'est pas une commodité de déclaration. C'est une classification fiscale qui détermine si une facture peut être déduite immédiatement ou seulement après le dépôt d'un justificatif de paiement correspondant. Selon la Resolución Miscelánea Fiscal (RMF), les factures PUE sont déductibles dès leur émission. Les factures PPD deviennent déductibles uniquement lorsque le Complemento de Pago est émis et que l'événement de paiement est enregistré auprès du SAT.

Pour le traitement par lots, ce binaire crée une bifurcation pratique dans votre flux de travail :

L'implication pour le traitement par lots : avant toute extraction, vous devez d'abord trier les XML CFDI par Método de Pago. Le lot PUE peut aller directement à l'extraction et à la comptabilisation. Le lot PPD nécessite un passage secondaire — chaque Ingreso doit être associé à son CFDI Pago correspondant avant d'entrer dans le grand livre. Si vous ne séparez pas les lots en amont, vous aurez 18 transactions comptabilisées mais pas encore fiscalement complètes, et votre DIOT sera en désaccord avec votre grand livre AP.

Pour les équipes AP traitant 50+ XML CFDI en fin de mois, trier par Método de Pago — et tenir une liste à jour des UUID PPD non rapprochés — est l'étape de prétraitement la plus importante. C'est aussi celle qui est le plus souvent ignorée, car la plupart des outils de traitement par lots considèrent toutes les factures comme équivalentes.

Tri Uso CFDI — Pourquoi G01, G03 et D01 ne peuvent pas partager la même conciliation

Le catalogue Uso CFDI (c_UsoCFDI) est une liste de codes gérée par le SAT que le récepteur — votre entreprise — doit attribuer correctement pour chaque CFDI reçu. Ce n'est pas la décision du fournisseur ; c'est votre déclaration sur la façon dont la dépense sera traitée. Les trois codes les plus courants dans un lot de fournisseurs :

Les CFDI G01, G03 et D01 alimentent différentes lignes de la DIOT — la déclaration mensuelle de TVA sur les achats au Mexique, due le 17 de chaque mois et désormais déposée entièrement en ligne via la plateforme web du SAT. Si votre extraction par lot traite les trois codes comme une seule colonne « Taxe », votre préparateur DIOT doit retrier manuellement les données extraites par Uso CFDI avant le dépôt. C'est une étape supplémentaire sur 50+ lignes.

La solution est simple : extrayez le code Uso CFDI comme colonne dédiée dans votre sortie par lot. Ainsi, votre feuille de calcul AP peut être triée, pivotée ou filtrée par code avant le dépôt DIOT — et votre conciliation de fin de mois peut valider que chaque ligne G01 du lot correspond à un RFC fournisseur dans la section G01 de la DIOT, chaque G03 dans sa section respective, etc. Une extraction à deux colonnes (Montant + Taxe) est un lot défaillant. Une extraction multi-colonnes qui préserve Uso CFDI, UUID, Método de Pago et RFC fournisseur est une boucle fermée.

Dédoublement par UUID — Pourquoi le Folio Fiscal, et non le Folio, est votre véritable numéro de facture

Chaque XML CFDI comporte deux identifiants qui se ressemblent mais servent à des fins totalement différentes : le Folio (numéro de facture attribué par la propre séquence de numérotation du fournisseur) et l'UUID (le Folio Fiscal de 36 caractères attribué par le PAC lors du timbrage). Pour le dédoublement des comptes fournisseurs, le Folio n'est pas fiable. L'UUID est la seule clé de confiance.

Trois modes de défaillance du dédoublement spécifiques au traitement par lots de CFDI :

Collision de Folio entre fournisseurs. Le fournisseur A émet le Folio n°1523 dans la Série A. Le fournisseur B émet également le Folio n°1523 dans la Série F. Si votre système de comptes fournisseurs dédouble uniquement sur le nom du fournisseur + le Folio, les deux sont reconnus comme uniques — mais si le même fournisseur retransmet le même CFDI après une correction, le système ne le détectera pas comme un doublon car l'UUID a changé alors que le Folio est resté le même. Vous avez besoin d'un dédoublement au niveau de l'UUID.

Correction par substitution de CFDI. Selon les règles d'annulation du SAT, un fournisseur peut annuler un CFDI avec le Motivo 01 (« facture émise avec des erreurs contenant des données incorrectes ») et réémettre une version corrigée avec un nouvel UUID. L'ancien UUID est invalidé, mais un système qui dédouble par Folio verra le même Folio sur le XML annulé et le XML corrigé — et peut marquer la version corrigée comme un doublon, supprimant ainsi la facture valide.

Réenvoi dans un cycle de lot différent. Les fournisseurs renvoient parfois des XML que vous avez déjà traités — surtout s'ils utilisent la livraison par lots par courriel en fin de mois. Sans dédoublement basé sur l'UUID, le même CFDI atterrit dans deux lots de fin de mois consécutifs et est comptabilisé deux fois.

Pour la comptabilisation par lots des comptes fournisseurs, l'extraction doit inclure l'UUID comme colonne dédiée. Avant de valider toute ligne dans le grand livre, vérifiez l'UUID par rapport à votre historique de transactions. Un nombre d'UUID distincts qui correspond au nombre de XML dans le lot est un contrôle d'intégrité rapide — si 50 fichiers produisent 47 UUID distincts, vous avez 3 doublons à examiner avant la validation.

Le problème du Complemento de Pago — quand la facture indique PPD et que le reçu de paiement arrive des jours plus tard

Le Complemento de Pago est le mécanisme qui clôt la vie fiscale d'une facture PPD. Lorsqu'un fournisseur émet un Ingreso CFDI avec Método de Pago = PPD, la transaction n'est pas fiscalement close tant qu'un Pago CFDI séparé n'arrive pas, portant un Complemento de Pago qui référence l'UUID de la facture d'origine.

Pour les équipes AP, le Complemento de Pago crée un problème de rapprochement à deux documents qui se multiplie à l'échelle du lot :

Décalage temporel. L'Ingreso arrive pendant le mois. Le Pago CFDI avec le complément de paiement arrive des jours ou des semaines plus tard — souvent dans une période comptable différente. Votre lot de fin de mois peut contenir 35 Ingreso PPD CFDI et seulement 28 Pago CFDI correspondants. Les 7 non appariés ne peuvent pas être clôturés. Si vous les comptabilisez quand même, la dépense n'est pas déductible de la TVA, et le rapprochement algorithmique du SAT signalera l'écart.

Suivi des acomptes. Lorsqu'un paiement fournisseur est effectué en plusieurs fois, chaque paiement partiel génère son propre Pago CFDI. Un Ingreso de 100 000 MXN payé en trois versements produit trois Pago CFDI — chacun référençant le même UUID d'origine mais enregistrant un montant et une date de paiement différents. Votre feuille de calcul AP doit suivre l'état du paiement au niveau de l'échéance, et non de la facture, car le crédit de TVA devient disponible progressivement à mesure que chaque Complemento de Pago est émis.

Rapprochement inter-lots. En pratique, le Complemento de Pago arrive rarement dans le même lot que l'Ingreso d'origine. La clôture AP de fin de mois nécessite d'extraire la liste des UUID PPD ouverts du lot du mois précédent, de les recouper avec les nouveaux Pago CFDI reçus, puis de clôturer les paires correspondantes. C'est un travail de rapprochement manuel qui évolue linéairement avec la taille du lot — 35 éléments PPD ouverts = 35 recherches manuelles, chacune nécessitant de trouver le XML Pago, d'extraire les champs du complément et de vérifier que les montants correspondent.

Variantes du format RFC — Pourquoi XAXX010101000 bloque votre recherche de fournisseur

La CFDI 4.0 a considérablement renforcé les exigences d'identification du récepteur par rapport à la version 3.3. Sous CFDI 4.0, le nœud récepteur doit contenir le RFC exact (ID fiscal), le nom légal (Nombre), le code postal (DomicilioFiscalReceptor) et le régime fiscal (RegimenFiscalReceptor) — le tout pré-validé par rapport à la base de données des contribuables du SAT avant que le PAC n'appose le timbre. Cela visait à éliminer le problème des « fantômes fiscaux », où des factures étaient émises à des contribuables inexistants ou non concordants.

Pour le traitement par lots de la comptabilité fournisseur, la conséquence pratique est qu'un lot de 50 XML CFDI provenant de fournisseurs n'aura pas un RFC récepteur uniforme — même si tous sont adressés à votre entreprise :

Dans un lot de 50 XML CFDI de fournisseurs, surtout de petits fournisseurs (producteurs agricoles, distributeurs ruraux, prestataires de services indépendants), 5 à 10 % porteront un RFC générique ou non concordant. Ces CFDI sont certifiés et techniquement valides — le SAT les a acceptés — mais votre entreprise ne peut pas réclamer le crédit de TVA correspondant. Le résultat du lot doit signaler ces cas séparément, et l'équipe comptable doit suivre avec le fournisseur pour réémettre la CFDI avec le RFC récepteur correct avant la clôture de la déclaration DIOT de fin de mois.

Validation de champs CFDI 4.0 en lot — Ce que le SAT rejette avant que votre équipe ne le voie

Le CFDI 4.0, obligatoire depuis le 1er avril 2023, a introduit des validations de champs plus strictes et de nouveaux champs obligatoires. Pour les équipes AP qui reçoivent des lots de XML, les changements pertinents sont :

RegimenFiscalReceptor est désormais obligatoire. Sous CFDI 3.3, le régime fiscal du récepteur était facultatif. Sous 4.0, chaque CFDI doit inclure le code Regimen Fiscal du récepteur (du catalogue SAT c_RegimenFiscal). Si votre entreprise opère sous plusieurs régimes — par exemple, Régimen General de Ley Personas Morales (code 601) pour les activités principales et Régimen de Actividades Empresariales con ingresos a través de plataformas tecnológicas (code 625) pour une ligne d'activité distincte — les CFDI de votre lot doivent refléter le régime sous lequel chaque transaction relève. Une discordance entre le RegimenFiscalReceptor de la facture et votre régime enregistré crée une exposition d'audit.

Validation croisée RFC + Nombre. Le CFDI 4.0 pré-valide le RFC du récepteur par rapport au nom légal enregistré dans la base de données du SAT. Si un fournisseur saisit votre RFC correct mais un nom légal légèrement erroné (par exemple, « SA de CV » au lieu de « S.A. de C.V. »), le PAC rejette le CFDI avant le timbrado. Cela signifie que les XML CFDI 4.0 arrivant dans votre boîte de réception sont structurellement plus fiables — mais en contrepartie, les erreurs à l'émission sont plus susceptibles d'entraîner un rejet pur et simple plutôt qu'une facture certifiée mais défectueuse. Le lot que vous traitez est plus propre mais plus petit : certains fournisseurs auront vu leurs factures rejetées et ne les auront peut-être pas encore réémises.

Champ Exportación. Le CFDI 4.0 a introduit un champ Exportación obligatoire (c_Exportacion) — valeurs 01 (non soumis à l'exportation), 02 (exportation définitive, A1), 03 (exportation définitive, A2) ou 04 (exportation temporaire). Pour les entreprises qui exportent des biens, un lot de CFDI fournisseurs contiendra à la fois des factures Exportación=01 et Exportación=02/03. Les CFDI 02/03 ont un traitement de TVA différent (TVA à 0 % sur les ventes à l'exportation) et incluent souvent le Complément de Commerce Extérieur (Complemento de Comercio Exterior 2.0, obligatoire depuis janvier 2024). Ces factures marquées export doivent être séparées des factures nationales dans le résultat du lot, car la déclaration DIOT sépare les achats nationaux et liés à l'exportation.

Pour le validateur de lots, une analyse rapide de pré-extraction peut révéler des signaux utiles : compter les valeurs distinctes de RegimenFiscalReceptor (plus de 1 = possible discordance de régime), vérifier la distribution du champ Exportación (lot mixte national/exportation) et compter les RFC distincts des récepteurs (RFC génériques signalés). Un pré-vol de 3 secondes sur un lot de 50 XML permet d'économiser une demi-heure de tri en aval.

Limites de téléchargement en lot du portail SAT — Ce que vous pouvez (et ne pouvez pas) extraire du Buzón Tributario

Une contrainte pratique qui façonne le flux de travail AP au Mexique : le portail SAT permet aux contribuables de télécharger leurs CFDIs reçus via le Buzón Tributario, mais avec des limites qui deviennent pertinentes à grande échelle. La fonction de téléchargement massif du portail plafonne généralement à 500 000 registros par requête — bien au-dessus des besoins d'une équipe AP de taille moyenne — mais l'interface web impose une contrainte pratique : les sessions de téléchargement manuel expirent, et naviguer mois par mois parmi les CFDIs reçus pour sélectionner des XML individuels n'est pas plus rapide que de les demander directement aux fournisseurs.

Pour les équipes AP traitant 50 à 200 CFDI XML par mois, le goulot d'étranglement le plus courant n'est pas les limites de téléchargement du SAT mais la régularité de livraison des fournisseurs. Les grands fournisseurs mexicains utilisant des PAC comme CONTPAQi (#1 PAC au Mexique) ou EDICOM livrent généralement automatiquement les XML certifiés à l'acheteur. Les petits fournisseurs utilisant des outils SAT gratuits ou des PAC low-cost peuvent seulement générer le CFDI sans livraison automatique au récepteur — ce qui signifie que la version PDF (avec code QR pour vérification SAT) arrive à votre équipe AP tandis que le XML doit être demandé séparément.

Le flux de travail en lot pour les CFDIs sporadiques ou de petits fournisseurs où le XML manque implique deux approches pratiques : soit demander le XML au fournisseur (ce qui ajoute 1 à 3 jours ouvrés à la clôture de fin de mois), soit utiliser la version PDF avec un outil d'extraction de données capable de lire les données de facture à partir de PDFs et d'images — extrayant les mêmes champs dans les mêmes colonnes aux côtés des XML que vous possédez. Cette consolidation multi-sources est là où le traitement par lot passe de « exécuter un analyseur XML 50 fois » à un véritable flux de travail opérationnel.

De 50 CFDI XML à un tableur AP — Un flux de travail de fin de mois

Voici un flux de travail par lot qui tient compte des défis structurels décrits ci-dessus. Il est conçu pour un analyste AP en fin de mois, confronté à 50+ CFDI XML provenant de 14 fournisseurs, avec une échéance d'importation CONTPAQi ou Aspel-COI au jour 3 après la clôture.

Ce flux de travail traite le lot en approximativement le même temps qu'il faut à un analyste pour extraire manuellement les données de 6 à 8 CFDI PDF un par un — mais il gère 50+ et produit une sortie prête pour la DIOT, pas seulement « des données dans un tableur ».

Pour une exploration plus approfondie des fondamentaux de l'extraction de données structurées à partir de CFDI XML et PDF — y compris comment gérer des lots multi-formats où tous les fournisseurs ne fournissent pas le XML — consultez notre guide sur l'extraction de factures CFDI mexicaines vers Excel.

FAQ — Traitement par lots des factures CFDI mexicaines

Le traitement par lots de CFDI peut-il gérer des factures PUE et PPD mélangées dans une même exécution ?

Techniquement oui — un outil de lot peut extraire les données des deux. Mais pour la précision comptable, elles doivent être traitées en sous-lots séparés. Les factures PUE peuvent être comptabilisées immédiatement. Les factures PPD doivent être appariées avec leur Complemento de Pago avant comptabilisation. Fusionner les deux dans le même résultat sans l'étape de rapprochement PPD crée des passifs ouverts dans votre grand livre.

Quelle est la limite pratique pour le téléchargement par lots de CFDIs reçus depuis le portail SAT ?

Le téléchargement en masse du portail SAT via le Buzón Tributario prend en charge jusqu'à 500 000 registros par requête — dépassant largement les volumes AP typiques. Cependant, l'interface web est limitée par session et non conçue pour une récupération rapide de XMLs individuels de fournisseurs. Pour la clôture mensuelle AP, demander les XMLs directement aux fournisseurs ou utiliser un service automatisé de livraison PAC-à-récepteur est plus rapide que les téléchargements manuels depuis le portail SAT.

ImageToTable.ai traite-t-il directement les fichiers XML CFDI, ou seulement les versions PDF ?

ImageToTable.ai traite les PDF, images JPG, PNG, et peut gérer des captures d'écran de documents. Pour les fichiers XML CFDI, vous pouvez télécharger le rendu PDF du CFDI (que tout fournisseur mexicain doit fournir avec le XML), et l'outil extrait les mêmes champs — UUID, RFCs, montants, dates, Método de Pago — dans des colonnes structurées. Pour les lots mixtes XML + PDF où certains fournisseurs n'ont envoyé que la version imprimée, tout fusionne dans un seul tableur.

Comment gérez-vous la déduplication des UUID CFDI sur plusieurs lots de fin de mois ?

Tenez un registre courant des UUID. Avant de comptabiliser chaque nouveau lot, vérifiez chaque UUID par rapport au registre. Un nombre d'UUID distincts correspondant au nombre de fichiers confirme l'absence de doublons. Des UUID apparaissant dans deux lots séparés indiquent soit une resoumission (même CFDI envoyé deux fois), soit une correction (annulé et réémis avec un nouvel UUID — l'ancien invalidé). Dans les deux cas, enquêtez avant de comptabiliser. Un résultat d'extraction par lot incluant la colonne UUID fait de cette vérification un exercice de tableau croisé dynamique de 30 secondes.

Pourquoi certains CFDIs utilisent-ils un RFC générique comme XAXX010101000, et puis-je quand même comptabiliser ces factures ?

XAXX010101000 est le RFC générique désigné par le SAT pour un destinataire étranger dont le RFC mexicain n'est pas disponible. Vous pouvez comptabiliser la facture dans votre comptabilité, mais la TVA sur ce CFDI n'est pas créditable — elle ne peut pas être déduite à des fins de TVA. Pour réclamer le crédit de TVA, vous devez demander au fournisseur de réémettre le CFDI avec le RFC correct et enregistré de votre entreprise. C'est l'une des exceptions les plus courantes dans un lot de 50+ CFDIs fournisseurs, et les RFC génériques doivent être signalés avant la comptabilisation.

Le Complemento de Pago peut-il être rapproché automatiquement de sa facture d'origine dans un lot ?

Oui, si votre outil de traitement par lots extrait l'UUID de la facture d'origine de chaque nœud Complemento de Pago du CFDI Pago — l'élément <pago20:Pago> référence l'UUID de la facture d'origine dans son enfant DocumentoRelacionado — et le recoupe avec les UUIDs des factures Ingreso PPD ouvertes. Il s'agit d'un rapprochement structuré XML-à-XML qui peut être entièrement automatisé, transformant 18 rapprochements manuels en zéro.

Quels types de CFDI dois-je attendre dans un lot multi-fournisseurs typique ?

Dans un lot provenant de grands distributeurs et fournisseurs industriels, attendez-vous principalement à des Ingreso (Tipo I) avec Método PPD. Les fabricants et prestataires de services peuvent utiliser à la fois PUE et PPD selon les termes du contrat. Vous pouvez également recevoir des notes de crédit Egreso (Tipo E) pour retours ou ajustements — celles-ci doivent être rapprochées de leur Ingreso d'origine et traitées comme des contre-passations, et non comme des lignes d'écriture autonomes. Les CFDIs de paie (Tipo N, Nómina) sont traités séparément et doivent être filtrés de votre lot AP.

Le Vrai Goulot d'Étranglement dans la Comptabilité Fournisseurs Mexicaine n'est Pas la Vitesse de Saisie — C'est l'Intégrité du Rapprochement

Si chaque XML de CFDI prend 3 minutes à ouvrir, analyser et copier manuellement 8 champs dans un tableur, le traitement de 50 factures fournisseurs consomme 2,5 heures de l'analyste AP en fin de mois. Mais ce calcul omet le coût réel. Les 2,5 heures de saisie sont suivies de 3 à 4 heures supplémentaires de rapprochement — apparier les factures PPD aux complements de paiement, vérifier les UUIDs par rapport aux lots précédents, trier par Uso CFDI pour la déclaration DIOT, et relancer les fournisseurs pour les RFC génériques.

Le goulot d'étranglement dans la comptabilité fournisseurs mexicaine n'est pas la vitesse de saisie. C'est que le résultat d'une extraction manuelle — un tableur avec Nom du Fournisseur, Montant et Taxe — ne contient aucun des champs nécessaires au rapprochement. UUID, Método de Pago, Uso CFDI, Exportación, RegimenFiscalReceptor — ce sont les champs qui transforment une simple liste de factures en un lot AP prêt pour la DIOT et vérifiable. Une extraction par lots qui préserve tous ces champs simultanément élimine l'étape de rapprochement, là où le temps est réellement passé.

La première fois que vous traitez un lot de 50 XMLs CFDI provenant de 14 fournisseurs et exportez un tableur où la colonne UUID est renseignée, la répartition PUE/PPD est pré-triée, et le regroupement Uso CFDI correspond aux sections DIOT — vous réaliserez que l'extraction elle-même n'a jamais été la partie difficile. La partie difficile était le rapprochement que vous faisiez après.