Warum die Verarbeitung mexikanischer CFDI-Rechnungen
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 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 sich mit dem Volumen vervielfachen. Beim Monatsabschluss muss ein AP-Team, das 50 mexikanische Lieferantenrechnungen mit PPD-Bedingungen verarbeitet, möglicherweise 100 oder mehr XML-Dateien abgleichen — jede erfordert eine UUID-Referenzierung zwischen dem Ingreso und seinen Pago-Komplement(en). Eine manuelle Abstimmung bedeutet, jede Pago-XML zu öffnen, den referenzierten UUID-Knoten zu finden, die verarbeitete Ingreso-Datenbank nach einer Übereinstimmung zu durchsuchen, die Übereinstimmung der Beträge zu prüfen und beide als abgeglichen zu markieren. Bei drei Minuten pro Abstimmung 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 der XML- und der PDF-Darstellung. Nach mexikanischem Recht ist die XML-Datei — digital signiert und mit PAC-Stempel — 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 Verifikationsportal der SAT verlinkt), hat aber kein eigenständiges rechtliches Gewicht. Wenn die Daten im PDF von den Daten in der entsprechenden XML abweichen — was passieren kann, wenn Lieferanten-ERP-Systeme das PDF aus einer Vorlage rendern, die Felder kürzt oder umformatiert — gilt die XML als das, was die SAT als korrekt betrachtet. Ein AP-Team, das Daten aus dem PDF übernimmt, ohne die XML zu prüfen, verarbeitet aus Compliance-Sicht einen dekorativen Ausdruck.

Weitere Informationen zum Workflow der Extraktion von CFDI-Daten aus XML und PDF in Excel finden Sie in unserem Leitfaden zur CFDI-Extraktion. Für die Verarbeitung von CFDI-Rechnungen im Batch-Maßstab — insbesondere die UUID-Referenzierung über Pago-Komplemente hinweg — siehe unseren Leitfaden zur Batch-CFDI-Verarbeitung.

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 Herausforderungen

Die drei oben genannten Ebenen gelten für jedes Unternehmen, das mexikanische CFDI-Rechnungen erhält. Für multinationale Unternehmen kommt eine vierte Komplikation hinzu, die spezifisch für das Zusammenspiel des RFC-Systems mit grenzüberschreitenden Operationen ist.

Ein Unternehmen mit mehreren juristischen Einheiten in Mexiko — eine Fertigungstochter, eine Vertriebstochter, eine Dienstleistungsgesellschaft — hat für jede eine eigene 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 Fertigungstochter aus, aber die Waren wurden an die Vertriebseinheit geliefert und von dieser verbraucht. Die Fertigungseinheit kann die Ausgabe rechtlich nicht absetzen, da die Transaktion nicht unter ihrer Steuerregistrierung erfolgte — und die Vertriebseinheit hat keinen CFDI zur Stützung ihrer Warenkosten. Die Behebung erfordert einen Stornierungs- und Neuausstellungszyklus mit allen oben beschriebenen Auswirkungen der 72-Stunden-Empfängerbestätigung.

Für ausländische Unternehmen, die CFDI-Rechnungen von mexikanischen Lieferanten erhalten, aber keine eigene RFC besitzen, kann die generische Ausländer-RFC — 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 abzusetzen (was für ein ausländisches Unternehmen ohne mexikanische Steuererklärungspflicht in der Regel irrelevant ist). Operativ bedeutsamer: Da XEXX010101000 eine generische Kennung ist, die von Tausenden unabhängiger Einheiten verwendet wird, bietet sie keine Rückverfolgbarkeit zu einer bestimmten Unternehmenseinheit. Wenn Ihr Unternehmen drei regionale Büros hat, die jeweils CFDI-Rechnungen von verschiedenen mexikanischen Lieferanten erhalten, alle mit XEXX010101000, gibt es auf RFC-Ebene keine Möglichkeit, Rechnungen während der Verarbeitung der richtigen Einheit zuzuordnen. Die Routing-Logik muss in Ihren AP-Workflow eingebaut werden — gestützt auf den Lieferantennamen, das Beschreibungsfeld oder den E-Mail-Empfänger — keines davon hat die strukturelle Zuverlässigkeit einer Steuer-ID.

Es gibt auch das Problem der régimen fiscal-Diskrepanz auf der Empfängerseite. Wenn ein mexikanischer Lieferant einen CFDI ausstellt, muss er den Steuerregime-Code des Empfängers erfassen. 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 (natürliche Personen 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 künftigen Prüfung beanstanden kann. Der CFDI ist gültig, aber falsch — die schwierigste Art von Fehler, bevor er zum Problem wird.

Für eine Analyse der breiteren Herausforderung der Dokumentenverarbeitung in spanischsprachigen Märkten, siehe 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

Betrachtet man alle vier Ebenen zusammen, benötigt ein CFDI-Verarbeitungsworkflow, der sie 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 liegen. Die Extraktion nur aus dem XML verzichtet auf den visuellen Verifizierungsschritt (entspricht das gedruckte Dokument den strukturierten Daten?). Die Extraktion nur aus dem PDF verzichtet auf den rechtlichen Nachweis. Beide Formate sollten in dieselbe Extraktionspipeline einfließen und eine einheitliche Ausgabezeile pro CFDI erzeugen.

UUID-basierter Abgleich. Die UUID – die 36-stellige Kennung, die in jedem CFDI eingebettet ist – ist der dauerhafte Schlüssel, der Ingreso-Rechnungen mit ihren Pago-Komplementen verknüpft, Stornierungen nachverfolgt und jedes Dokument mit dem Verifikationsportal des SAT verbindet. Ein CFDI-Workflow, der UUIDs nicht über Stapel hinweg erfasst, speichert und abgleicht, kann die PPD-Zahlungsabstimmung nicht ohne manuelle Nachforschungen durchführen. Für Stapelabgleich-Workflows siehe unseren Leitfaden zur CFDI-Stapelverarbeitung.

Regime- und RFC-Validierung beim Eingang. Bevor ein CFDI in Ihr Buchhaltungssystem gelangt, sollten die RFC des Empfängers und der régimen fiscal-Code gegen die registrierten Daten Ihres Unternehmens validiert werden. Ein beim Eingang erkannter Abweichung 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 erreichbar ist.

Bewusstsein für den Stornierungsstatus. Ein einmal verarbeiteter CFDI ist kein dauerhaft abgeschlossener CFDI. Workflows, die regelmäßige UUID-Statusprüfungen gegen das Verifikationsportal des SAT umfassen – oder die Lieferanten verpflichten, Ihr Team über einen definierten Kanal über Stornierungsanfragen zu informieren – reduzieren das Risiko, ungültige Dokumente im Hauptbuch zu halten.

Nichts davon erfordert eine PAC-Integration auf Unternehmensebene oder eine dedizierte mexikanische Steuerkonformitätsplattform. Erforderlich ist ein Verarbeitungsschritt, der versteht, was ein CFDI ist – ein mehrteiliges, zustandsbehaftetes, staatlich validiertes Dokument – und seine Daten entsprechend extrahiert, anstatt es 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 besitzt. XEXX010101000 ist jedoch eine generische Kennung, die von allen ausländischen Empfängern gemeinsam genutzt wird – sie bietet keine Identifikation auf Unternehmensebene. Wenn Ihr Unternehmen mehrere Niederlassungen, Abteilungen oder Rechtseinheiten hat, die CFDI-Rechnungen erhalten, benötigen Sie einen internen Weiterleitungsmechanismus (basierend auf Lieferantenname, Beschreibung oder E-Mail), um jede Rechnung der richtigen Verarbeitungswarteschlange zuzuordnen.

Ist die CFDI-Komplexität schlimmer als bei anderen Ländern mit E-Rechnungssystemen?

Das mexikanische System gehört zu den am strengsten kontrollierten der Welt, neben Brasiliens NF-e. Beide nutzen eine Echtzeit-Freigabe durch die Behörden, beide erfordern strukturiertes XML mit digitalen Signaturen, und beide schaffen Abstimmungspflichten zwischen Originalrechnungen und nachfolgenden Zahlungs- oder Transportdokumenten. Die besondere Komplexität des mexikanischen Systems liegt in der Doppeldokumentstruktur PPD/Pago und dem Stornierungsmechanismus mit Empfängerfreigabe – Funktionen, die in den meisten europäischen E-Rechnungspflichten keine direkte Entsprechung haben.