Warum die mexikanische CFDI-Rechnungsverarbeitung
schwieriger ist als die meisten Teams erwarten

Mehr als nur eine lange Rechnung: Das oberflächliche Problem

Ein CFDI (Comprobante Fiscal Digital por Internet) gemäß CFF Artikel 29-A ist nicht einfach eine lange Rechnung. Es ist ein staatlich vorgeschriebenes XML-Dokument, dessen Struktur durch die technische Norm Anexo 20 definiert wird – eine Spezifikation, die in der aktuellen CFDI 4.0-Version über 100 mögliche XML-Elemente und mehrere bedingte Validierungsketten definiert. Aber auf die reine Feldanzahl als Problem zu verweisen, verfehlt, was die Verarbeitung tatsächlich verlangsamt. Die Schwierigkeit liegt nicht in der Vielzahl der Felder. Die Schwierigkeit liegt darin, dass die Felder in Beziehungen zueinander stehen, die Nachverfolgungspflichten über separate Dokumente, separate Systeme und separate Zeitpunkte hinweg erzeugen.

Die Symptome sind leicht zu erkennen. Eine Rechnung wird von Ihrem PAC (Proveedor Autorizado de Certificación) des Lieferanten zurückgewiesen, weil die RFC (Registro Federal de Contribuyentes – Mexikos Steuer-ID) des Empfängers nicht exakt mit dem Steuerzahlerregister des SAT übereinstimmt – eine Abweichung so klein wie ein fehlender Akzent. Eine Zahlung, die letzte Woche auf dem Konto einging, taucht in keiner offenen Rechnung Ihres Hauptbuchs auf, weil die Zahlung als separater CFDI vom Typ Pago ausgestellt wurde, der die UUID (Universally Unique Identifier) der Originalrechnung referenziert, anstatt als Posten im Originaldokument zu erscheinen. Eine Rechnung, die Ihr Team vor drei Wochen bearbeitet hat, stellt sich als vom Lieferanten storniert heraus – aber niemand in Ihrem Unternehmen hat die Stornierungsanfrage innerhalb des 72-Stunden-Fensters angenommen oder abgelehnt, sodass sie automatisch genehmigt wurde. Ihr Kreditorenbuchungseintrag verweist nun auf ein ungültiges Dokument.

Dies sind keine Ausnahmefälle. Sie sind die normalen Betriebsbedingungen bei der Verarbeitung mexikanischer Lieferantenrechnungen ab einer Größenordnung von mehr als ein paar Dutzend pro Monat. Und sie rühren nicht von schlechten Lieferantenpraktiken oder unzureichenden Kreditorenbuchhaltungstools her, sondern von der Architektur des CFDI-Systems selbst – eines Systems, dessen Designziele regulatorische Transparenz und Steuerdurchsetzung waren, nicht betriebliche Effizienz für die empfangende Seite der Transaktion.

Ebene 1: Die regulatorische Architektur, die jede CFDI zu einer Mini-Steuererklärung macht

In den meisten Ländern ist eine Rechnung ein Handelsdokument: Sie hält fest, was verkauft wurde, an wen und zu welchem Preis. Die Steuererklärung erfolgt später – wenn der Verkäufer die Umsatzsteuervoranmeldung einreicht, wenn der Käufer die Ausgabe verbucht. In Mexiko ist die Rechnung die Steuererklärung. Der Unterschied ist nicht akademisch. Er ändert, welche Informationen zum Zeitpunkt der Erstellung vorhanden sein müssen und wer sie prüfen muss, bevor das Dokument rechtsgültig ist.

Mexiko arbeitet mit einem Modell, das Steuersystemforscher als Echtzeit-Freigabemodell bezeichnen. Gemäß CFF Artikel 29, Abschnitt IV muss jede CFDI vor Ausstellung an den Empfänger an das SAT (Servicio de Administración Tributaria, Mexikos Bundessteuerbehörde) übermittelt werden. Die Übermittlung erfolgt über einen PAC – einen SAT-zertifizierten Vermittler –, der die XML-Struktur gemäß den Anexo-20-Regeln validiert, prüft, ob sowohl die RFC des Ausstellers als auch die des Empfängers im aktiven Steuerpflichtigenregister des SAT existieren, bestätigt, dass das CSD (Certificado de Sello Digital, digitales Siegelzertifikat) des Ausstellers gültig und nicht widerrufen ist, prüft, ob die Steuerberechnungen in sich schlüssig sind, und erst dann den digitalen Steuerstempel (Timbre Fiscal Digital) anbringt und die validierte CFDI mit der zugewiesenen UUID zurückgibt.

Für Ihre AP-Abteilung bedeutet dies, dass jede eingehende CFDI bereits eine behördliche Validierungsprüfung durchlaufen hat. Die darin enthaltenen Daten sind keine Behauptung des Lieferanten – es sind Daten, die das SAT gesehen hat. Dies macht die Daten zuverlässiger als eine typische Rechnung. Es bedeutet auch, dass Fehler in den Daten – eine falsche RFC, ein falscher Steuerregime-Code – nicht von Ihrem Lieferanten mit einer schnellen aktualisierten PDF korrigiert werden können. Die fehlerhafte CFDI muss über einen formellen Stornierungsprozess storniert und eine neue von Grund auf ausgestellt werden.

Die erforderlichen Daten selbst sind nicht nur „Name, Datum, Betrag". CFF Artikel 29-A schreibt vor, dass jede CFDI vom Typ Ingreso (Einkommensrechnung) enthalten muss: die RFC des Ausstellers, den Firmennamen (razón social) und den Steuerregime-Code (régimen fiscal); die RFC des Empfängers, den Firmennamen, die Postleitzahl des Steuerdomizils und den Uso-CFDI-Code, der angibt, wie der Empfänger die Rechnung für Steuerzwecke verwendet; Ort und Datum der Ausstellung; eine eindeutige Folionummer; das digitale Siegel des Ausstellers; detaillierte Positionen mit Mengen, Maßeinheiten, SAT-Produkt-/Dienstleistungsklassifikationscodes (ClaveProdServ), Einzelpreisen und Gesamtsummen; eine vollständige Steueraufschlüsselung nach Art (IVA – Impuesto al Valor Agregado, Mehrwertsteuer – Überweisungen und Einbehalte); Zahlungsform (Forma de Pago) und Zahlungsmethode (Método de Pago, codiert als PUE für Einmalzahlung oder PPD für gestundete/Teilzahlungen); sowie die UUID und den Zeitstempel der Zertifizierung.

Jedes dieser Felder ist nicht nur für Ihre Buchhaltung wichtig, sondern auch für die Querverweis-Engines des SAT. Die RFC und der Name des Empfängers werden mit dem Steuerpflichtigenregister des SAT abgeglichen. Der Steuerregime-Code – ein numerischer Identifikator wie 601 für Kapitalgesellschaften, 612 für Einzelpersonen mit Geschäftstätigkeit, 605 für Angestellte – bestimmt die steuerliche Behandlung auf beiden Seiten der Transaktion. Eine Diskrepanz zwischen dem angegebenen Regime des Ausstellers und der Art der gemeldeten Einkünfte kann eine automatische Prüfungsflagge auslösen. Deshalb bestehen Ihre mexikanischen Lieferanten so sehr darauf, vor Rechnungsstellung Ihre korrekte RFC und Ihren Steuerregime-Code zu erhalten: Sie sind nicht bürokratisch. Sie befolgen ein System, das Rechnungen ablehnt, deren Daten nicht mit den SAT-Aufzeichnungen übereinstimmen.

Die Steuerreform 2026 hat dieser Ebene eine neue Dimension hinzugefügt. Eine neue Bestimmung (Fracción IX) wurde in Artikel 29-A des CFF aufgenommen, gültig ab 1. Januar 2026, die verlangt, dass CFDIs reale und wahrheitsgetreue Transaktionen abbilden. Wenn ein CFDI keinen tatsächlichen Rechtsakt oder Vorgang darstellt, gilt er als falsch – mit Folgen, die nun strafrechtliche Haftung für Aussteller, Empfänger und Vermittler umfassen. Dies erhöht die Tragweite jedes CFDIs, den Ihr Unternehmen erhält: Ein Lieferant, der Ihnen eine Rechnung für nicht tatsächlich erbrachte Leistungen ausstellt, begeht nicht nur einen Meldefehler. Er erstellt ein Dokument, das die SAT als falsch vermuten kann, und der Name und die RFC Ihres Unternehmens können als Empfänger eines falschen CFDIs veröffentlicht werden, mit 30 Tagen Zeit, Ihre Steuererklärungen zu korrigieren.

Ebene 1 zusammengefasst: Das Dokument, das Sie verarbeiten, wurde nicht für Sie erstellt. Es wurde für die Echtzeit-Überwachungsinfrastruktur der SAT entwickelt. Ihr AP-Workflow erbt jedes Feld und jede Validierung, die die SAT verlangt – unabhängig davon, ob diese Felder für Ihre Buchhaltung relevant sind.

Ebene 2: Die Dokumentenarchitektur – Warum eine Transaktion zwei (oder mehr) XMLs erzeugt

Wenn die regulatorische Ebene Pflichtfelder hinzufügt, teilt die Dokumentenarchitektur die Transaktion selbst auf mehrere Dateien auf. Hier weicht die CFDI-Verarbeitung am stärksten von dem ab, was ein AP-Team, das mit US- oder europäischen Rechnungsformaten vertraut ist, erwartet.

Die Aufteilung beginnt mit einem Feld namens Método de Pago. Wenn der Wert PUE (Pago en Una Sola Exhibición – Zahlung in einer einzigen Rate) ist, erfasst der CFDI Ingreso die vollständige Transaktion: Waren oder Dienstleistungen, Beträge, Steuern und die Tatsache, dass die Zahlung zum Zeitpunkt der Ausstellung vollständig beglichen ist. Ein Dokument, eine Transaktion. Dies ist die größte Annäherung eines CFDIs an eine gewöhnliche Rechnung.

Wenn der Wert PPD (Pago en Parcialidades o Diferido – Zahlung in Raten oder gestundet) ist, erfasst der Ingreso-CFDI nur die Verpflichtung. Die tatsächliche Zahlung – wann sie erfolgt, in welcher Höhe, auf welche Weise – wird in einem separaten CFDI vom Typ Pago (Zahlung) erfasst, der das Complemento de Recepción de Pagos (Zahlungseingangsergänzung, manchmal Complemento de Pago genannt) trägt. Diese Ergänzung verweist auf die UUID des ursprünglichen Ingreso-CFDIs und erfasst: das Zahlungsdatum, den gezahlten Betrag, die Zahlungsmethode (Überweisung, Scheck, Bargeld, elektronische Geldbörse), die Währung und den Wechselkurs (falls zutreffend) sowie den verbleibenden Saldo nach dieser Zahlung.

Eine Geschäftstransaktion erzeugt nun zwei XMLs, die gemeinsam verfolgt werden müssen. Erfolgt die Zahlung in drei Raten, entstehen vier XMLs: ein Ingreso und drei Pago-CFDIs, jeder mit eigener UUID, jeder verweist über die Ergänzungsstruktur auf das Original. Der Abgleich bedeutet, die UUID auf jeder Pago-Ergänzung mit der UUID des ursprünglichen Ingreso abzugleichen, die Teilzahlungen zu summieren und zu bestätigen, dass der Saldo Null erreicht. Fehlt ein Pago-CFDI in Ihrem Posteingang, erscheint der Ingreso in Ihrer Buchhaltung auf unbestimmte Zeit als unbezahlt – obwohl die Bank die Belastung zeigt.

Diese Zwei-Dokumenten-Struktur verursacht nachgelagerte Probleme, die mit der Menge wachsen. Zum Monatsabschluss muss ein AP-Team, das 50 mexikanische Lieferantenrechnungen mit PPD-Konditionen bearbeitet, möglicherweise 100 oder mehr XMLs abgleichen – jedes erfordert eine UUID-Referenzierung zwischen dem Ingreso und seinen Pago-Komplementen. Manueller Abgleich bedeutet: Jedes Pago-XML öffnen, den referenzierten UUID-Knoten finden, in der verarbeiteten Ingreso-Datenbank nach einer Übereinstimmung suchen, die Beträge auf Übereinstimmung prüfen und beide als abgeglichen markieren. Bei drei Minuten pro Abgleich verbrauchen 50 PPD-Paare zweieinhalb Stunden AP-Personalzeit – jeden Monat, für die Lieferanten eines einzigen Landes.

Es gibt eine weitere Dimension der Dokumententrennung: die Beziehung zwischen XML und PDF-Darstellung. Nach mexikanischem Recht ist die XML-Datei – digital signiert und PAC-gestempelt – das rechtlich maßgebliche Dokument. Das PDF ist eine visuelle Darstellung, die von der SAT reguliert wird (es muss einen zweidimensionalen Barcode enthalten, der auf das SAT-Prüfportal verweist), hat aber kein eigenständiges rechtliches Gewicht. Weichen die Daten im PDF von denen im entsprechenden XML ab – was passieren kann, wenn Lieferanten-ERP-Systeme das PDF aus einer Vorlage rendern, die Felder kürzt oder umformatiert –, gilt das XML als das von der SAT als korrekt angesehene. Ein AP-Team, das Daten aus dem PDF übernimmt, ohne das XML zu prüfen, verarbeitet aus Compliance-Sicht einen dekorativen Ausdruck.

Weitere Informationen zum Workflow der CFDI-Datenextraktion aus XML und PDF in Excel finden Sie in unserem Leitfaden zur CFDI-Extraktion. Für die Stapelverarbeitung von CFDI-Rechnungen – insbesondere die UUID-Referenzierung über Pago-Komplemente hinweg – lesen Sie unseren Leitfaden zur CFDI-Stapelverarbeitung.

Layer 3: Die Stornierungsfalle — Warum die Korrektur eines Fehlers 72 Stunden und zwei Unterschriften braucht

In den meisten Rechnungsverarbeitungsumgebungen bedeutet die Korrektur eines Fehlers, dass der Lieferant eine Gutschrift oder eine überarbeitete PDF sendet und der Käufer die Anpassung verbucht. Im CFDI-System kann eine ausgestellte und gestempelte Rechnung nicht bearbeitet werden. Sie kann nur storniert werden – und die Stornierung selbst ist ein regulierter Prozess, der beide Parteien, ein Regierungssystem und eine Uhr einbezieht.

Nach den aktuellen Regeln erfordert die Stornierung eines CFDI, dass der Aussteller einen Stornierungsantrag über das SAT-Steuerpostfach (Buzón Tributario) einreicht und dabei einen von vier standardisierten Grundcodes angibt: 01 — Beleg mit Fehlern im Zusammenhang ausgestellt (d. h. der stornierte CFDI wird durch ein zugehöriges Dokument ersetzt); 02 — Beleg mit nicht zusammenhängenden Fehlern ausgestellt; 03 — die Transaktion wurde nicht durchgeführt; 04 — zugehöriger nomineller Vorgang in einer Globalrechnung. Code 01 ist der häufigste für geschäftliche Korrekturen und erfordert, dass der Aussteller die UUID des Ersatz-CFDI angibt, der den stornierten ersetzt.

Nach Einreichung des Stornierungsantrags hat der Empfänger 72 Stunden (drei Werktage) Zeit, um ihn anzunehmen oder abzulehnen. Reagiert der Empfänger nicht, wird die Stornierung automatisch durch Zeitablauf genehmigt. Lehnt der Empfänger ab, bleibt der CFDI rechtlich gültig, und der Aussteller muss entweder neu mit dem Empfänger verhandeln oder den Streit über die SAT-Schlichtungskanäle eskalieren lassen.

Es gibt begrenzte Ausnahmen, bei denen die Zustimmung des Empfängers nicht erforderlich ist: Lohn-CFDIs (Nómina), Rechnungen unter MXN 1.000, Transaktionen mit der breiten Öffentlichkeit (unter Verwendung der generischen RFC XAXX010101000) und Stornierungen innerhalb von 72 Stunden nach der ursprünglichen Ausstellung. Für alles andere – jeden kommerziellen Ingreso-CFDI über MXN 1.000 – gilt das 72-stündige Annahmefenster des Empfängers.

Für das empfangende AP-Team schafft dies zwei betriebliche Risiken. Das erste ist das Risiko ungültiger Dokumente: Ein CFDI, den Sie vor drei Wochen verarbeitet und verbucht haben, könnte vom Lieferanten storniert worden sein, und weil niemand in Ihrer Organisation im SAT-Steuerpostfach angemeldet war, um den Antrag anzunehmen oder abzulehnen, wurde er stillschweigend genehmigt. Ihre Bücher enthalten nun einen Eintrag, der durch ein ungültiges Steuerdokument gedeckt ist – ein Befund, den SAT als Ausgabe behandeln wird, die durch einen ungültigen CFDI gestützt wird, was den Abzug verweigert und möglicherweise Nachsteuern und Strafen auslöst.

Das zweite ist die Lücke bei der Nachverfolgung von Ersatzdokumenten: Wenn ein Lieferant einen CFDI mit Grundcode 01 storniert, stellt er einen Ersatz-CFDI mit einer neuen UUID aus. Ihr AP-Team muss nun den ursprünglichen Eintrag finden, ihn stornieren und den Ersatz neu erfassen – wobei die neue UUID der alten zugeordnet werden muss. Wenn der Ersatz in einem anderen E-Mail-Thread mit einem leicht abweichenden Betreff eintrifft und von einem anderen Teammitglied bearbeitet wird, geht die Verbindung zwischen Original und Ersatz verloren, und beide Versionen könnten gleichzeitig in Ihrem System landen.

Ebene 4: Multi-RFC und grenzüberschreitende Kopfschmerzen

Die drei obigen Ebenen gelten für jedes Unternehmen, das mexikanische CFDI-Rechnungen erhält. Für multinationale Konzerne kommt eine vierte Komplikation hinzu, die spezifisch mit dem Zusammenspiel des RFC-Systems und grenzüberschreitenden Geschäften zusammenhängt.

Ein Unternehmen mit mehreren juristischen Personen in Mexiko – einer Produktionstochter, einer Vertriebstochter, einer Dienstleistungsgesellschaft – hat für jede eine separate RFC. CFDI-Rechnungen, die an die falsche RFC gesendet werden, sind rechtlich an den falschen Steuerpflichtigen adressiert. Ein Lieferant stellt die Rechnung auf die RFC der Produktionstochter aus, aber die Ware wurde an die Vertriebsgesellschaft geliefert und von ihr verbraucht. Die Produktionstochter kann die Ausgabe rechtlich nicht abziehen, da die Transaktion nicht unter ihrer Steuerregistrierung stattfand – und die Vertriebsgesellschaft hat keinen CFDI, um ihre Warenkosten zu belegen. Die Behebung erfordert einen Stornierungs- und Neuausstellungszyklus mit allen oben beschriebenen Auswirkungen der 72-Stunden-Empfängerakzeptanz.

Für ausländische Unternehmen, die CFDI-Rechnungen von mexikanischen Lieferanten erhalten, aber selbst keine RFC besitzen, kann die generische RFC für ausländische Empfänger – XEXX010101000 – verwendet werden. Diese RFC hat wichtige Einschränkungen. Sie erlaubt es dem Empfänger nicht, IVA-Gutschriften geltend zu machen oder die Ausgabe für mexikanische Steuerzwecke abzuziehen (was für ein ausländisches Unternehmen ohne mexikanische Steuererklärungspflicht meist irrelevant ist). Operativ bedeutsamer: Da XEXX010101000 ein generischer Identifikator ist, der von Tausenden nicht verbundener Unternehmen verwendet wird, bietet er keine Rückverfolgbarkeit zu einer bestimmten juristischen Person. Wenn Ihr Unternehmen drei regionale Büros hat, die jeweils CFDI-Rechnungen von verschiedenen mexikanischen Lieferanten erhalten, alle mit XEXX010101000, gibt es keine RFC-basierte Möglichkeit, Rechnungen während der Verarbeitung der richtigen Einheit zuzuordnen. Die Zuordnungslogik muss in Ihren Kreditoren-Workflow eingebaut werden – basierend auf dem Lieferantennamen, dem Beschreibungsfeld oder dem E-Mail-Empfänger –, von denen keines die strukturelle Zuverlässigkeit einer Steuer-ID hat.

Es gibt auch das Problem des falschen Steuerregimes auf der Empfängerseite. Wenn ein mexikanischer Lieferant einen CFDI ausstellt, muss er den Steuerregime-Code des Empfängers angeben. Wenn Ihr Unternehmen eine RFC für eine mexikanische Einheit erhalten hat, ist diese unter einem bestimmten Regime registriert – sagen wir 601 (Allgemeines Regime für juristische Personen). Wenn der Lieferant fälschlicherweise 612 (Einzelpersonen mit Geschäftstätigkeit) eingibt, weil jemand beim Onboarding den falschen Code angegeben hat, kann der CFDI die PAC-Validierung dennoch bestehen (da 612 ein gültiger Regime-Code ist), aber er enthält einen strukturellen Datenfehler, den SAT bei einer zukünftigen Prüfung beanstanden kann. Der CFDI ist gültig, aber falsch – die schwierigste Art von Fehler, die man erkennt, bevor er zum Problem wird.

Für eine Analyse der allgemeineren Herausforderung der Dokumentenverarbeitung in spanischsprachigen Märkten lesen Sie unsere Übersicht zur Dokumentenextraktion in spanischen Märkten.

Warum vorlagenbasierte Ansätze bei CFDI scheitern

Eine häufige Reaktion auf die Komplexität der Rechnungsverarbeitung ist die vorlagenbasierte OCR: Für jeden Lieferanten wird eine Vorlage für dessen Layout definiert, Felder werden Positionen zugeordnet und Daten koordinatenbasiert extrahiert. Dieser Ansatz setzt voraus, dass das Dokumentformat konsistent genug ist, damit eine an einem Beispiel trainierte Vorlage auch für die nächsten hundert Rechnungen funktioniert. CFDI durchbricht diese Annahme in zweierlei Hinsicht.

Erstens variiert die PDF-Darstellung je nach Lieferant. Obwohl jeder CFDI dieselben Pflichtfelder gemäß Anexo 20 enthält, rendert das ERP- oder Rechnungssystem jedes Lieferanten das PDF anders. Ein Lieferant platziert die UUID als 36-stellige Zeichenfolge in der oberen rechten Ecke. Ein anderer bettet sie nur in den QR-Code-Barcode unten ein. Ein Dritter druckt sie in einer komprimierten Schriftart in der Fußzeile. Eine für das Layout von Lieferant A erstellte Vorlage versagt bei der Rechnung von Lieferant B vollständig.

Zweitens können PDF und XML unterschiedliche Daten enthalten. Das ERP eines Lieferanten rendert das PDF möglicherweise aus einer Teilmenge der XML-Felder – zeigt den Positionsbetrag, aber nicht die IVA-Aufschlüsselung, zeigt den Handelsnamen des Lieferanten anstelle der eingetragenen razón social. Wenn Ihr Extraktionstool das PDF liest, erfasst es die vereinfachten gedruckten Daten. Wenn Ihre Compliance-Verpflichtung die vollständigen Steuerdetails aus dem XML erfordert, reicht das PDF nicht aus. Ein AP-Team, das mit dem PDF abgleicht, gleicht mit weniger Daten ab, als SAT als maßgeblichen Datensatz betrachtet.

Der Ansatz, der diese strukturelle Variabilität bewältigt, ist einer, der den Inhalt des Dokuments liest – die semantische Bedeutung von Feldern wie UUID, RFC, IVA 16%, Régimen Fiscal – unabhängig davon, wo sie auf der Seite erscheinen und unabhängig davon, ob die Quelle ein PDF oder ein XML ist. Semantische Extraktion identifiziert einen RFC nicht, weil er sich an den Koordinaten (200, 450) befindet, sondern weil er dem Muster einer 12- oder 13-stelligen alphanumerischen Kennung entspricht, die im umgebenden Text mit "RFC" beschriftet ist. Dies ist der Unterschied zwischen dem Abbilden visueller Positionen und dem Verstehen von Dokumentinhalten – und es ist der Unterschied, der die CFDI-Verarbeitung im großen Maßstab praktikabel macht, anstatt eine Wartungslast für jede Lieferantenvorlage zu sein.

Was das für Ihren mexikanischen AP-Workflow bedeutet

Wenn man die vier Ebenen zusammenführt, benötigt ein CFDI-Verarbeitungsworkflow, der alle berücksichtigt, Fähigkeiten, die die meisten Standard-AP-Systeme – die auf der Annahme basieren, dass eine Rechnung ein einzelnes, in sich geschlossenes, zustandsloses Dokument ist – nicht nativ bieten.

Multi-Format-Erfassung. Der Workflow muss sowohl XML als auch PDF als Eingabe akzeptieren, da Lieferanten beides liefern und die maßgeblichen Daten im XML leben. Die reine XML-Extraktion verwirft den visuellen Prüfschritt (stimmt das gedruckte Dokument mit den strukturierten Daten überein?). Die reine PDF-Extraktion verwirft den rechtlichen Nachweis. Beide Formate sollten in dieselbe Extraktionspipeline eingespeist werden und eine einheitliche Ausgabezeile pro CFDI erzeugen.

UUID-bewusster Abgleich. Die UUID – die 36-stellige Kennung, die in jedem CFDI eingebettet ist – ist der permanente Schlüssel, der Ingreso-Rechnungen mit ihren Pago-Ergänzungen verknüpft, Stornierungen nachverfolgt und jedes Dokument mit dem SAT-Prüfportal verbindet. Ein CFDI-Workflow, der UUIDs nicht über Chargen hinweg erfasst, speichert und abgleicht, kann keine PPD-Zahlungsabstimmung ohne manuelle Nachforschungen durchführen. Für Batch-Abstimmungsworkflows siehe unseren Leitfaden zur Batch-CFDI-Verarbeitung.

Regime- und RFC-Prüfung beim Eingang. Bevor ein CFDI in Ihr Buchhaltungssystem gelangt, sollten die RFC des Empfängers und der Regime-Steuercode gegen die registrierten Daten Ihres Unternehmens validiert werden. Ein beim Eingang erkannter Fehlbestand verhindert eine Kaskade: Die Ausgabe wird unter der falschen Einheit verbucht, das Steuerteam entdeckt den Fehler während der Prüfungsvorbereitung und die Korrektur erfordert einen Stornierungs-Neuausstellungs-Zyklus mit einem Lieferanten, der möglicherweise nicht mehr reagiert.

Bewusstsein für den Stornierungsstatus. Ein einmal verarbeiteter CFDI ist kein dauerhaft abgeschlossener CFDI. Workflows, die regelmäßige UUID-Statusprüfungen gegen das SAT-Prüfportal beinhalten – oder die von Lieferanten verlangen, Ihr Team über Stornierungsanfragen über einen definierten Kanal zu informieren – verringern das Risiko, ungültige Dokumente in Ihrem Hauptbuch zu halten.

Nichts davon erfordert eine PAC-Integration auf Unternehmensebene oder eine dedizierte mexikanische Steuer-Compliance-Plattform. Erforderlich ist ein Verarbeitungsschritt, der versteht, was ein CFDI ist – ein multi-dokumentaler, zustandsbehafteter, staatlich validierter Datensatz – und seine Daten entsprechend extrahiert, anstatt ihn als langes PDF mit zusätzlichen Zahlen zu behandeln.

Häufig gestellte Fragen

Warum können mexikanische Lieferanten nicht einfach eine normale PDF-Rechnung ausstellen?

Weil das mexikanische Recht ein PDF nicht als gültiges Steuerdokument anerkennt. Seit 2014 sind alle Steuerzahler in Mexiko – Unternehmen, Freiberufler und gewerblich tätige Privatpersonen – verpflichtet, CFDI-XML-Rechnungen auszustellen, die von einem PAC validiert und in Echtzeit beim SAT registriert werden. Ein Lieferant, der nur ein PDF ausstellt, erstellt keine rechtlich gültige Rechnung nach mexikanischem Steuerrecht, und Sie können ein solches Dokument nicht für einen Steuerabzug in Mexiko verwenden.

Was ist in der Praxis der Unterschied zwischen PUE und PPD?

PUE (Einmalzahlung) bedeutet, dass die Rechnung zum Zeitpunkt der Ausstellung vollständig beglichen wird – ein CFDI deckt die gesamte Transaktion ab. PPD (gestundet/ratenweise) bedeutet, dass die Rechnung die Verpflichtung erfasst und jede spätere Zahlung einen separaten CFDI vom Typ Pago mit eigener UUID und einem Complemento de Pago erzeugt, der auf die ursprüngliche Rechnung verweist. PPD erfordert die Nachverfolgung von mindestens zwei XMLs pro Transaktion; PUE benötigt eines. Der Zahlungsmethodencode (PUE oder PPD) erscheint im Feld Método de Pago des Ingreso-CFDI.

Muss ich das XML aufbewahren oder reicht das PDF für unsere Unterlagen?

Sie benötigen das XML. Gemäß Artikel 30 CFF müssen sowohl Aussteller als auch Empfänger CFDI-XML-Dateien mindestens fünf Jahre lang aufbewahren. Das PDF ist eine regulierte visuelle Darstellung – es muss einen QR-Code enthalten, der zum Verifikationsportal des SAT führt –, hat aber keine eigenständige rechtliche Gültigkeit. Bei einer Prüfung verlangt das SAT das XML, nicht das PDF.

Was passiert, wenn ich eine Stornierungsanfrage eines Lieferanten ignoriere?

Wenn Sie nicht innerhalb von 72 Stunden (drei Werktage) antworten, wird die Stornierung automatisch durch Zeitablauf genehmigt. Der CFDI wird ungültig, und jeder Steuerabzug oder jede Ausgabenbuchung in Ihrem System, die auf diesem CFDI basiert, wird nicht mehr durch ein gültiges Steuerdokument gestützt. Wenn Ihr Unternehmen in Mexiko Steuern zahlt, entsteht dadurch ein Compliance-Risiko. Wenn Ihr Unternehmen nicht in Mexiko Steuern zahlt, besteht das operative Risiko darin, dass Sie eine Zahlung gegen eine ungültig gewordene Rechnung leisten, ohne es zu merken.

Kann ich die generische RFC XEXX010101000 für alle unsere mexikanischen Lieferantenrechnungen verwenden?

Ja, wenn Ihr Unternehmen keine mexikanische Steuerregistrierung und keine eigene mexikanische RFC hat. XEXX010101000 ist jedoch ein generischer Identifikator, der von allen ausländischen Empfängern gemeinsam genutzt wird – er bietet keine Rückverfolgbarkeit auf Unternehmensebene. Wenn Ihr Unternehmen mehrere Niederlassungen, Abteilungen oder Einheiten hat, die CFDI-Rechnungen erhalten, benötigen Sie einen internen Routing-Mechanismus (basierend auf Lieferantenname, Beschreibung oder E-Mail), um jede Rechnung an die richtige Verarbeitungswarteschlange zu leiten.

Ist die CFDI-Komplexität schlimmer als die E-Rechnungssysteme anderer Länder?

Das mexikanische System gehört zu den am strengsten kontrollierten der Welt, neben Brasiliens NF-e. Beide verwenden eine Echtzeit-Genehmigung durch die Regierung, beide erfordern strukturiertes XML mit digitalen Signaturen, und beide schaffen Abstimmungsverpflichtungen zwischen Originalrechnungen und späteren Zahlungs- oder Transportdokumenten. Die spezifische Komplexität des mexikanischen Systems liegt in der dualen Dokumentenstruktur PPD/Pago und dem Mechanismus zur Stornierung mit Zustimmung des Empfängers – Funktionen, die in den meisten europäischen E-Rechnungsvorschriften kein direktes Äquivalent haben.