Mexikanische CFDI-Rechnungsverarbeitung
50+ XMLs von 14 Lieferanten, eine saubere AP-Tabelle

Wenn 50 CFDI-XMLs auf den Monatsabschluss treffen – Die Lücke zwischen „Jedes XML ist gültig" und „Der Batch ist sauber"

Das mexikanische CFDI-System basiert auf einem Drei-Parteien-Freigabemodell: Der Lieferant erstellt ein XML nach Anexo-20-Spezifikationen, ein zertifizierter PAC validiert und stempelt es mit einer UUID (dem 36-stelligen Folio Fiscal), und der SAT erhält es in Echtzeit. Wenn ein CFDI als Empfänger in Ihrer Kreditorenbuchhaltung ankommt, ist das XML bereits zertifiziert. Dies unterscheidet sich von Papierrechnungen oder reinen PDF-Rechnungen in den meisten anderen Ländern – und erzeugt einen irreführenden ersten Eindruck.

Da jedes XML einzeln gültig ist, gehen AP-Teams davon aus, dass auch der Batch sauber sein wird. Das ist er nicht. Fünf strukturelle Probleme treten auf, wenn Sie 50+ CFDI-XMLs von mehreren Lieferanten sammeln und in einer einzigen AP-Tabelle konsolidieren möchten:

PUE- und PPD-Mischung. CFDI-Rechnungen enthalten ein Feld „Método de Pago", das Ihren gesamten Batch in zwei grundlegend unterschiedliche Verarbeitungspipelines aufteilt. PUE-Rechnungen (Pago en una sola exhibición) sind in sich abgeschlossen – die Rechnung ist der endgültige Steuerbeleg. PPD-Rechnungen (Pago en parcialidades o diferido) sind unvollständig, bis ein passender Pago-CFDI mit einem Complemento de Pago eintrifft. In einem Batch von 50 Lieferanten-XMLs könnten Sie 32 PUE und 18 PPD haben. Die PPD-Rechnungen können erst gebucht werden, wenn die Zahlungsergänzung eingegangen und gegen die ursprüngliche Rechnungs-UUID verifiziert wurde. Wenn Ihre AP-Tabelle alle als gleichwertige Positionen behandelt, buchen Sie 18 Transaktionen, die für IVA-Zwecke noch nicht abzugsfähig sind.

Uso-CFDI-Fragmentierung. Jeder CFDI trägt einen obligatorischen Uso-CFDI-Code – einen SAT-Katalogwert, der bestimmt, wie der Empfänger (Ihr Unternehmen) die Rechnung für Steuerzwecke anwendet. G01 (allgemeiner Geschäftserwerb), G03 (allgemeine Ausgabe) und D01 (abzugsfähiger Erwerb für bestimmte Vorgänge) sind in einem Lieferantenbatch üblich – lösen jedoch unterschiedliche Steuerbehandlungen, verschiedene DIOT-Meldekategorien und unterschiedliche IVA-Vorsteuerregeln aus. Eine Tabelle, die alle CFDIs ohne den Uso-CFDI-Code in eine einzige Spalte „Steuer" packt, ist für die Einreichung der DIOT, der monatlichen Umsatzsteuer-Voranmeldung bis zum 17., unbrauchbar.

Fehlgeschlagene UUID-basierte Deduplizierung. Die meisten AP-Systeme deduplizieren anhand von Lieferantenname + Rechnungsnummer. Bei CFDI ist die Rechnungsnummer (Folio) nur innerhalb einer einzelnen Serie eines Lieferanten eindeutig – und selbst dann kann ein Lieferant nach Stornierung und Neuausstellung einer korrigierten Rechnung eine neue UUID anhängen. Die wahre eindeutige Kennung ist das 36-stellige Folio Fiscal (UUID), das vom PAC beim Timbrado vergeben wird. Ohne Extrahieren der UUID aus jedem XML werden zwei verschiedene CFDIs verschiedener Lieferanten mit demselben Folio-Wert als Duplikate markiert – oder ein korrigierter Ersatz-CFDI wird nicht als Ersatz für das Original erkannt.

Verzögerung beim Abgleich des Complemento de Pago. Bei PPD-Rechnungen kommt der Zahlungsbeleg (CFDI Tipo Pago mit Complemento de Pago) separat – manchmal Tage oder Wochen nach der ursprünglichen Ingreso-Rechnung. Er verweist auf die ursprüngliche Rechnungs-UUID, erfasst den Zahlungsbetrag, das Datum und die Methode und muss mit der offenen AP-Position abgeglichen werden. In einem manuellen Workflow ist der Abgleich von 18 PPD-Rechnungen mit ihren jeweiligen Complemento de Pago über einen Batch von 50+ Dokumenten eine Abstimmungsaufgabe, die Stunden dauern kann – und ein einziger verpasster Abgleich hinterlässt einen nicht abzugsfähigen Aufwand in Ihrer Buchhaltung.

RFC-Formatvarianten im Empfängerknoten. CFDI 4.0 schreibt die exakte RFC im Empfängerknoten (Ihres Unternehmens) vor. Manche Lieferanten – insbesondere kleinere oder landwirtschaftliche Erzeuger – stellen jedoch CFDIs mit der generischen RFC XAXX010101000 aus, wenn sie nicht über Ihre vollständigen Steuerdaten verfügen. Andere senden Rechnungen an die RFC Ihrer Tochtergesellschaft, während Ihr Kreditorenbuchhaltungssystem die RFC der Muttergesellschaft erwartet. Diese Abweichungen werden auf SAT-Ebene erkannt: Der CFDI existiert und ist zertifiziert, aber die Empfänger-RFC stimmt nicht mit Ihrer registrierten Steuernummer überein, was dazu führen kann, dass der IVA-Vorsteuerabzug bei einer Prüfung verweigert wird.

PUE vs. PPD in großen Mengen – Warum ein einziges Feld Ihren gesamten Monatsabschlussprozess spaltet

Im mexikanischen CFDI-System ist die Zahlungsmethode (Método de Pago) keine reine Meldeerleichterung. Es handelt sich um eine steuerliche Klassifizierung, die bestimmt, ob eine Rechnung sofort oder erst nach Einreichung eines entsprechenden Zahlungsbelegs abzugsfähig ist. Gemäß der Resolución Miscelánea Fiscal (RMF) sind PUE-Rechnungen bei Ausstellung abzugsfähig. PPD-Rechnungen werden erst abzugsfähig, wenn das Zahlungsergänzungsdokument (Complemento de Pago) ausgestellt und das Zahlungsereignis beim SAT registriert wurde.

Für die Stapelverarbeitung schafft diese Binärität eine praktische Gabelung in Ihrem Workflow:

Die Auswirkung auf die Stapelverarbeitung: Vor jeder Extraktion müssen Sie die CFDI-XMLs zunächst nach Zahlungsmethode sortieren. Der PUE-Batch kann direkt zur Extraktion und Buchung gehen. Der PPD-Batch benötigt einen zweiten Durchlauf – jede Einkommensrechnung muss vor der Verbuchung mit dem entsprechenden Zahlungs-CFDI abgeglichen werden. Wenn Sie den Batch nicht vorher aufteilen, haben Sie 18 gebuchte Transaktionen, die steuerlich noch nicht vollständig sind, und Ihre DIOT wird nicht mit Ihrem Kreditorenbuch übereinstimmen.

Für Kreditorenbuchhaltungsteams, die am Monatsende 50+ CFDI-XMLs verarbeiten, ist das Sortieren nach Zahlungsmethode – und das Führen einer laufenden Liste nicht abgeglichener PPD-UUIDs – der mit Abstand wichtigste Vorverarbeitungsschritt. Es ist auch der am häufigsten übersprungene Schritt, da die meisten Stapelverarbeitungstools alle Rechnungen als gleichwertig behandeln.

Uso-CFDI-Sortierung – Warum G01, G03 und D01 nicht in derselben Abstimmung landen dürfen

Der Uso-CFDI-Katalog (c_UsoCFDI) ist eine vom SAT gepflegte Codeliste, die der Empfänger – Ihr Unternehmen – jedem erhaltenen CFDI korrekt zuweisen muss. Dies ist keine Entscheidung des Lieferanten, sondern Ihre Erklärung, wie die Ausgabe behandelt wird. Die drei häufigsten Codes in einer Lieferantencharge:

G01-, G03- und D01-CFDIs fließen in verschiedene Zeilen der DIOT – Mexikos monatlicher Umsatzsteuer-Voranmeldung, fällig bis zum 17. eines jeden Monats und jetzt vollständig online über die SAT-Webplattform eingereicht. Wenn Ihr Chargenextraktionsergebnis alle drei Codes als eine einzige Spalte „Steuer" behandelt, muss Ihr DIOT-Ersteller die extrahierten Daten vor der Einreichung manuell nach Uso CFDI neu sortieren. Das ist ein zusätzlicher Durchlauf bei über 50 Zeilen.

Die Lösung ist einfach: Extrahieren Sie den Uso-CFDI-Code als eigene Spalte in Ihrem Chargenergebnis. Dann kann Ihre Kreditorenbuchhaltungstabelle vor der DIOT-Einreichung nach Code sortiert, pivotiert oder gefiltert werden – und Ihr Monatsabschluss kann validieren, dass jede G01-Zeile in der Charge mit einem Lieferanten-RFC im G01-Abschnitt der DIOT übereinstimmt, jede G03 in ihrem jeweiligen Abschnitt usw. Eine zweispaltige Extraktion (Betrag + Steuer) ist eine fehlerhafte Charge. Eine mehrspaltige Extraktion, die Uso CFDI, UUID, Método de Pago und Lieferanten-RFC bewahrt, ist ein geschlossener Kreislauf.

UUID-Deduplizierung – Warum der Folio Fiscal, nicht der Folio, Ihre tatsächliche Rechnungsnummer ist

Jede CFDI-XML enthält zwei Kennungen, die ähnlich aussehen, aber völlig unterschiedlichen Zwecken dienen: den Folio (die vom Lieferanten vergebene Rechnungsnummer aus dessen eigener Nummernfolge) und die UUID (den 36-stelligen Folio Fiscal, der vom PAC beim Timbrado vergeben wird). Für die AP-Deduplizierung ist der Folio unzuverlässig. Die UUID ist der einzig vertrauenswürdige Schlüssel.

Drei Deduplizierungsfehlermodi, die spezifisch für die CFDI-Stapelverarbeitung sind:

Lieferantenübergreifende Folio-Kollision. Lieferant A stellt Folio #1523 in Serie A aus. Lieferant B stellt ebenfalls Folio #1523 in Serie F aus. Wenn Ihr AP-System nur auf Lieferantenname + Folio dedupliziert, werden beide als eindeutig erkannt – aber wenn derselbe Lieferant nach einer Korrektur dieselbe CFDI erneut sendet, erkennt das System dies nicht als Duplikat, da sich die UUID geändert hat, während der Folio gleich blieb. Sie benötigen eine Deduplizierung auf UUID-Ebene.

Korrektur durch CFDI-Ersetzung. Gemäß den SAT-Stornierungsregeln kann ein Lieferant eine CFDI mit Motivo 01 („Rechnung mit Fehlern und falschen Daten ausgestellt“) stornieren und eine korrigierte Version mit einer neuen UUID erneut ausstellen. Die alte UUID wird ungültig, aber ein System, das nach Folio dedupliziert, sieht denselben Folio sowohl in der stornierten als auch in der korrigierten XML – und könnte die korrigierte Version als Duplikat markieren und die gültige Rechnung unterdrücken.

Erneute Einreichung in einem anderen Stapelzyklus. Lieferanten senden gelegentlich XMLs erneut, die Sie bereits verarbeitet haben – insbesondere bei monatlichem Stapelversand per E-Mail. Ohne UUID-basierte Deduplizierung landet dieselbe CFDI in zwei aufeinanderfolgenden Monatsend-Stapeln und wird doppelt verbucht.

Für die Stapel-AP muss die Extraktionsausgabe die UUID als eigene Spalte enthalten. Prüfen Sie vor der Buchung jeder Position im Hauptbuch die UUID gegen Ihren Transaktionsverlauf. Eine eindeutige UUID-Anzahl, die der Anzahl der XMLs im Stapel entspricht, ist eine schnelle Integritätsprüfung – wenn 50 Dateien 47 eindeutige UUIDs ergeben, haben Sie 3 Duplikate, die vor der Buchung untersucht werden müssen.

Das Problem des Complemento de Pago – Wenn die Rechnung PPD ausweist und der Zahlungseingang erst Tage später eintrifft

Der Complemento de Pago ist der Mechanismus, der den fiskalischen Lebenszyklus einer PPD-Rechnung abschließt. Wenn ein Lieferant einen Ingreso-CFDI mit der Zahlungsmethode PPD ausstellt, ist die Transaktion steuerlich erst abgeschlossen, wenn ein separater Pago-CFDI eingeht, der einen Complemento de Pago enthält, der auf die ursprüngliche Rechnungs-UUID verweist.

Für AP-Teams schafft der Complemento de Pago ein Zwei-Belege-Abstimmungsproblem, das sich im Batch-Betrieb vervielfacht:

Zeitliche Lücke. Der Ingreso trifft im Laufe des Monats ein. Der Pago-CFDI mit dem Zahlungscomplement kommt Tage oder Wochen später – oft in einer anderen Abrechnungsperiode. Ihr Monatsend-Batch könnte 35 Ingreso-PPD-CFDIs enthalten, aber nur 28 passende Pago-CFDIs. Die 7 ungepaarten können nicht abgeschlossen werden. Buchen Sie sie trotzdem, sind die Ausgaben nicht IVA-abzugsfähig, und der SAT-Algorithmus zur Abstimmung wird die Diskrepanz melden.

Verfolgung von Teilzahlungen. Erfolgt eine Lieferantenzahlung in Raten, erzeugt jede Teilzahlung einen eigenen Pago-CFDI. Ein Ingreso über 100.000 MXN, gezahlt in drei Raten, erzeugt drei Pago-CFDIs – jeder verweist auf dieselbe ursprüngliche UUID, verbucht aber einen anderen Zahlungsbetrag und ein anderes Datum. Ihre AP-Tabelle muss den Zahlungsstatus auf Ratenebene verfolgen, nicht auf Rechnungsebene, da der IVA-Vorsteuerabzug mit jedem ausgestellten Complemento de Pago schrittweise möglich wird.

Batch-übergreifende Abstimmung. In der Praxis trifft der Complemento de Pago selten im selben Batch wie der ursprüngliche Ingreso ein. Der AP-Monatsabschluss erfordert, die Liste der offenen PPD-UUIDs aus dem Vormonats-Batch zu ziehen, mit neu eingegangenen Pago-CFDIs abzugleichen und dann die passenden Paare zu schließen. Dies ist manuelle Abstimmungsarbeit, die linear mit der Batch-Größe skaliert – 35 offene PPD-Posten = 35 manuelle Nachforschungen, bei denen jeweils die Pago-XML gefunden, die Complement-Felder extrahiert und die Beträge auf Übereinstimmung geprüft werden müssen.

RFC-Format-Varianten – Warum XAXX010101000 Ihre Lieferantenstammsuche blockiert

CFDI 4.0 hat die Identifikationsanforderungen für den Empfänger (Receptor) im Vergleich zu Version 3.3 deutlich verschärft. Unter CFDI 4.0 muss der Empfängerknoten die exakte RFC (Steuernummer), den gesetzlichen Namen (Nombre), die Postleitzahl (DomicilioFiscalReceptor) und das Steuerregime (RegimenFiscalReceptor) enthalten – alles vorab gegen die SAT-Steuerzahlerdatenbank validiert, bevor der PAC den Stempel aufsetzt. Dies sollte das Problem der „Steuergeister" beseitigen, bei denen Rechnungen an nicht existierende oder nicht passende Steuerzahler ausgestellt wurden.

Für die AP-Stapelverarbeitung bedeutet dies praktisch, dass ein Stapel von 50 CFDI-XML-Dateien von Lieferanten keine einheitliche Empfänger-RFC aufweist – selbst wenn alle an Ihr Unternehmen adressiert sind:

In einem Stapel von 50 Lieferanten-CFDI-XML-Dateien, insbesondere von kleineren Lieferanten (landwirtschaftliche Erzeuger, ländliche Händler, unabhängige Dienstleister), tragen 5–10 % eine generische oder nicht passende RFC. Diese CFDI sind zertifiziert und technisch gültig – die SAT hat sie akzeptiert –, aber Ihr Unternehmen kann darauf keine Vorsteuer geltend machen. Die Stapelausgabe muss diese gesondert kennzeichnen, und das AP-Team muss den Lieferanten kontaktieren, um die CFDI mit der korrekten Empfänger-RFC neu ausstellen zu lassen, bevor das Monatsende-Fenster für die DIOT-Einreichung schließt.

CFDI 4.0 Feldvalidierung in Stapeln – Was der SAT ablehnt, bevor Ihr Team es sieht

CFDI 4.0, seit dem 1. April 2023 verpflichtend, führte strengere Feldvalidierungen und neue Pflichtfelder ein. Für AP-Teams, die Stapel von XMLs erhalten, sind die relevanten Änderungen:

RegimenFiscalReceptor ist jetzt Pflicht. Unter CFDI 3.3 war das Steuerregime des Empfängers optional. Unter 4.0 muss jeder CFDI den Regimen-Fiscal-Code des Empfängers enthalten (aus dem SAT-Katalog c_RegimenFiscal). Wenn Ihr Unternehmen unter mehreren Regimen operiert – z. B. Régimen General de Ley Personas Morales (Code 601) für Kerngeschäfte und Régimen de Actividades Empresariales con ingresos a través de plataformas tecnológicas (Code 625) für einen separaten Geschäftszweig – müssen die CFDIs in Ihrem Stapel widerspiegeln, welchem Regime jede Transaktion unterliegt. Eine Diskrepanz zwischen dem RegimenFiscalReceptor der Rechnung und Ihrem registrierten Regime schafft ein Prüfungsrisiko.

RFC + Nombre-Kreuzvalidierung. CFDI 4.0 validiert den RFC des Empfängers vorab gegen den registrierten gesetzlichen Namen in der SAT-Datenbank. Wenn ein Lieferant Ihren korrekten RFC, aber einen leicht falschen gesetzlichen Namen eingibt (z. B. "SA de CV" statt "S.A. de C.V."), lehnt der PAC den CFDI vor dem Timbrado ab. Das bedeutet, dass CFDI 4.0 XMLs, die in Ihrem Posteingang landen, strukturell zuverlässiger sind – aber die Kehrseite ist, dass Fehler bei der Ausstellung eher zu einer glatten Ablehnung führen als zu einer fehlerhaften, aber zertifizierten Rechnung. Der von Ihnen verarbeitete Stapel ist sauberer, aber kleiner: Einige Lieferanten hatten ihre Rechnungen abgelehnt und sie möglicherweise noch nicht neu ausgestellt.

Exportación-Feld. CFDI 4.0 führte ein Pflichtfeld Exportación (c_Exportacion) ein – Werte 01 (nicht ausfuhrrelevant), 02 (endgültige Ausfuhr, A1), 03 (endgültige Ausfuhr, A2) oder 04 (vorübergehende Ausfuhr). Für Unternehmen, die Waren exportieren, enthält ein Stapel von Lieferanten-CFDIs sowohl Rechnungen mit Exportación=01 als auch mit Exportación=02/03. Die 02/03-CFDIs unterliegen einer anderen Umsatzsteuerbehandlung (0 % IVA auf Exportverkäufe) und enthalten oft das Außenhandelskomplement (Complemento de Comercio Exterior 2.0, seit Januar 2024 Pflicht). Diese exportgekennzeichneten Rechnungen müssen im Stapeloutput von Inlandsrechnungen getrennt werden, da die DIOT-Meldung Inlands- und Exportkäufe trennt.

Für den Stapelvalidator kann ein schneller Vorab-Scan nützliche Signale liefern: Zählen Sie die verschiedenen RegimenFiscalReceptor-Werte (mehr als 1 = mögliches Regime-Mismatch), prüfen Sie die Verteilung des Exportación-Felds (gemischter Inlands-/Exportstapel) und zählen Sie verschiedene Empfänger-RFCs (generische RFCs werden markiert). Ein 3-Sekunden-Check eines Stapels von 50 XMLs spart eine halbe Stunde nachgelagerte Sortierarbeit.

SAT-Portal-Batch-Download-Limits – Was Sie aus dem Buzón Tributario ziehen können (und was nicht)

Eine praktische Einschränkung, die den mexikanischen AP-Batch-Workflow prägt: Das SAT-Portal ermöglicht Steuerzahlern den Download ihrer erhaltenen CFDIs über das Buzón Tributario – jedoch mit Grenzen, die im größeren Maßstab relevant werden. Die Massen-Download-Funktion des Portals ist in der Regel auf 500.000 Registros pro Anfrage begrenzt – weit mehr, als ein mittelständisches AP-Team benötigt –, aber die Weboberfläche bringt eine praktische Einschränkung mit sich: Manuelle Download-Sitzungen laufen aus, und das monatsweise Durchblättern erhaltener CFDIs, um einzelne XMLs herauszupicken, ist nicht schneller, als sie direkt bei den Lieferanten anzufordern.

Für AP-Teams, die 50–200 CFDI-XMLs pro Monat verarbeiten, ist der häufigere Engpass nicht die SAT-Download-Begrenzung, sondern die Konsistenz der Lieferantenbelieferung. Größere mexikanische Lieferanten, die PACs wie CONTPAQi (#1 PAC in Mexiko) oder EDICOM nutzen, liefern in der Regel zertifizierte XMLs automatisch an den Käufer. Kleinere Lieferanten, die kostenlose SAT-Tools oder günstige PACs verwenden, generieren möglicherweise nur den CFDI ohne automatische Zustellung an den Empfänger – das bedeutet, dass die PDF-Version (mit QR-Code zur SAT-Überprüfung) Ihr AP-Team erreicht, während das XML separat angefordert werden muss.

Der Batch-Workflow für sporadische oder CFDIs kleiner Lieferanten, bei denen das XML fehlt, umfasst zwei praktische Ansätze: entweder das XML vom Lieferanten anfordern (was 1–3 Werktage zum Monatsabschluss hinzufügt) oder die PDF-Version mit einem Datenextraktionstool verwenden, das Rechnungsdaten aus PDFs und Bildern auslesen kann – und dieselben Felder in dieselben Spalten extrahiert, zusammen mit den XMLs, die Sie haben. Diese gemischte Quellenkonsolidierung ist der Punkt, an dem die Batch-Verarbeitung von „einen XML-Parser 50 Mal ausführen" zu einem echten operativen Workflow wird.

Von 50 CFDI-XMLs zu einer AP-Tabelle – Ein Monatsabschluss-Workflow

Hier ist ein Batch-Workflow, der die oben beschriebenen strukturellen Herausforderungen berücksichtigt. Er ist für einen AP-Analysten zum Monatsabschluss konzipiert, der 50+ CFDI-XMLs von 14 Lieferanten gegenübersteht, mit einem CONTPAQi- oder Aspel-COI-Importtermin am 3. Tag nach Abschluss.

Dieser Workflow verarbeitet den Batch in etwa der gleichen Zeit, die ein Analyst benötigt, um manuell Daten aus 6–8 CFDI-PDFs einzeln zu extrahieren – aber er verarbeitet 50+ und liefert Ergebnisse, die DIOT-bereit sind, nicht nur „Daten in einer Tabelle".

Für einen tieferen Einblick in die Grundlagen der Extraktion strukturierter Daten aus CFDI-XMLs und -PDFs – einschließlich der Handhabung von Batches mit gemischten Formaten, bei denen nicht alle Lieferanten das XML bereitstellen – lesen Sie unseren Leitfaden zur mexikanischen CFDI-Rechnungsextraktion nach Excel.

FAQ — Stapelverarbeitung mexikanischer CFDI-Rechnungen

Kann die CFDI-Stapelverarbeitung gemischte PUE- und PPD-Rechnungen in einem Durchlauf verarbeiten?

Technisch ja – ein Stapeltool kann Daten aus beiden extrahieren. Für die buchhalterische Genauigkeit sollten sie jedoch als separate Unterbatches verarbeitet werden. PUE-Rechnungen können sofort verbucht werden. PPD-Rechnungen müssen vor der Verbuchung mit ihrem Complemento de Pago abgeglichen werden. Werden beide ohne den PPD-Abgleich in dieselbe Ausgabe gemischt, entstehen offene Verbindlichkeiten in Ihrer Hauptbuchhaltung.

Was ist die praktische Grenze für den SAT-Portal-Batch-Download empfangener CFDIs?

Der Massendownload des SAT-Portals über den Buzón Tributario unterstützt bis zu 500.000 Registros pro Anfrage – weit mehr als typische Kreditorenvolumina. Die Weboberfläche ist jedoch sitzungszeitbegrenzt und nicht für den schnellen Abruf einzelner Lieferanten-XMLs ausgelegt. Für den Monatsabschluss der Kreditoren ist die direkte Anforderung von XMLs bei Lieferanten oder die Nutzung eines automatisierten PAC-zu-Empfänger-Zustelldienstes schneller als manuelle SAT-Portal-Downloads.

Verarbeitet ImageToTable.ai CFDI-XML-Dateien direkt oder nur PDF-Versionen?

ImageToTable.ai verarbeitet PDFs, JPG-, PNG-Bilder und kann auch Bildschirmfotos von Dokumenten verarbeiten. Für XML-CFDI-Dateien können Sie die PDF-Darstellung des CFDI hochladen (die jeder mexikanische Lieferant zusammen mit dem XML bereitstellen muss), und das Tool extrahiert dieselben Felder – UUID, RFCs, Beträge, Daten, Método de Pago – in strukturierte Spalten. Bei gemischten XML- + PDF-Batches, bei denen einige Lieferanten nur die gedruckte Version gesendet haben, wird alles in einer Tabelle zusammengeführt.

Wie handhaben Sie die CFDI-UUID-Deduplizierung über mehrere Monatsend-Batches hinweg?

Führen Sie ein fortlaufendes UUID-Register. Prüfen Sie vor der Verbuchung jedes neuen Batches jede UUID gegen das Register. Eine eindeutige UUID-Anzahl, die mit der Dateianzahl übereinstimmt, bestätigt keine Duplikate. UUIDs, die in zwei separaten Batches erscheinen, deuten entweder auf eine erneute Einreichung (gleicher CFDI zweimal gesendet) oder eine Korrektur (storniert und mit neuer UUID neu ausgestellt – die alte ist ungültig) hin. In beiden Fällen vor der Verbuchung prüfen. Eine Batch-Extraktionsausgabe mit der UUID-Spalte macht diese Prüfung zu einer 30-Sekunden-Pivot-Tabellen-Übung.

Warum verwenden manche CFDIs eine generische RFC wie XAXX010101000 und kann ich diese Rechnungen trotzdem buchen?

XAXX010101000 ist die von der SAT festgelegte generische RFC für einen ausländischen Empfänger, dessen mexikanische RFC nicht verfügbar ist. Sie können die Rechnung in Ihrer Buchhaltung verbuchen, aber die IVA auf diesen CFDI ist nicht anrechenbar – sie kann nicht für Mehrwertsteuerzwecke abgezogen werden. Um einen IVA-Vorsteuerabzug geltend zu machen, müssen Sie den Lieferanten auffordern, den CFDI mit der korrekten, registrierten RFC Ihres Unternehmens neu auszustellen. Dies ist eine der häufigsten Ausnahmen in einem Batch mit über 50 Lieferanten-CFDIs, und generische RFCs sollten vor der Buchung gekennzeichnet werden.

Kann der Complemento de Pago automatisch im Batch seiner Originalrechnung zugeordnet werden?

Ja, wenn Ihr Batch-Verarbeitungstool die UUID der Originalrechnung aus dem Complemento de Pago-Knoten jedes Pago-CFDI extrahiert – das <pago20:Pago>-Element referenziert die UUID der Originalrechnung in seinem untergeordneten DocumentoRelacionado – und diese mit den UUIDs offener PPD-Ingreso-Rechnungen abgleicht. Dies ist ein strukturierter XML-zu-XML-Abgleich und kann vollständig automatisiert werden, wodurch aus 18 manuellen Abstimmungen null werden.

Welche CFDI-Typen sind in einem typischen Batch mit mehreren Lieferanten zu erwarten?

In einem Batch von großen Distributoren und Industrielieferanten sind hauptsächlich Ingreso (Typ I) mit der Methode PPD zu erwarten. Hersteller und Dienstleister verwenden je nach Vertragsbedingungen sowohl PUE als auch PPD. Sie können auch Egreso (Typ E) Gutschriften für Retouren oder Anpassungen erhalten – diese müssen ihrer ursprünglichen Ingreso-Rechnung zugeordnet und als Gegenbuchungen behandelt werden, nicht als eigenständige Positionen. Lohn-CFDIs (Typ N, Nómina) werden separat verarbeitet und sollten aus Ihrem AP-Batch herausgefiltert werden.

Der wahre Engpass in der mexikanischen Kreditorenbuchhaltung ist nicht die Dateneingabegeschwindigkeit – es ist die Abstimmungsintegrität

Wenn das Öffnen, Scannen und manuelle Übertragen von 8 Feldern aus jedem CFDI-XML in eine Tabelle 3 Minuten dauert, verbraucht die Verarbeitung von 50 Lieferantenrechnungen 2,5 Stunden der Monatsabschlusszeit eines AP-Analysten. Aber diese Berechnung übersieht die wahren Kosten. Den 2,5 Stunden Dateneingabe folgen weitere 3–4 Stunden Abstimmung – Abgleich von PPD-Rechnungen mit Zahlungsbelegen, Prüfung von UUIDs gegen frühere Batches, Sortierung nach Uso CFDI für die DIOT-Meldung und Nachfragen bei Lieferanten wegen generischer RFCs.

Der Engpass in der mexikanischen Kreditorenbuchhaltung ist nicht die Geschwindigkeit der Dateneingabe. Es ist die Tatsache, dass das Ergebnis einer manuellen Extraktion – eine Tabelle mit Lieferantenname, Betrag und Steuer – keines der für die Abstimmung benötigten Felder enthält. UUID, Método de Pago, Uso CFDI, Exportación, RegimenFiscalReceptor – das sind die Felder, die aus einer flachen Rechnungsliste einen DIOT-fähigen, prüfungssicheren AP-Batch machen. Eine Batch-Extraktion, die alle diese Felder gleichzeitig erhält, macht den Abstimmungsdurchlauf überflüssig, in dem die eigentliche Zeit steckt.

Wenn Sie zum ersten Mal einen Batch von 50 CFDI-XMLs von 14 Lieferanten verarbeiten und eine Tabelle exportieren, in der die UUID-Spalte gefüllt, die PUE/PPD-Aufteilung vorsortiert und die Uso-CFDI-Gruppierung mit den DIOT-Abschnitten übereinstimmt – dann werden Sie erkennen, dass die Extraktion selbst nie der schwierige Teil war. Der schwierige Teil war die Abstimmung, die Sie danach gemacht haben.