Warum die Verarbeitung mexikanischer CFDI-Rechnungen
schwieriger ist, als die meisten Teams erwarten

Ein mexikanischer Lieferant sendet zwei Dateien an Ihren AP-Posteingang: eine PDF und eine XML. Die PDF sieht aus wie eine Rechnung. Die XML sieht aus, als dürfe sie nur ein Entwickler anfassen. Die Verarbeitung dieser Rechnung – das Extrahieren der Daten in Ihr ERP, der Abgleich der Zahlung, die Ablage für die Prüfung – wird Ihr Team mehr als dreimal so viel Zeit kosten wie bei jeder anderen ausländischen Rechnung in der Warteschlange. Das Format selbst ist der Engpass, und die meisten Gründe dafür sind auf der gedruckten Seite nicht sichtbar.

Neu bei CFDI? Dieser Artikel setzt voraus, dass Sie wissen, was eine CFDI ist, und konzentriert sich darauf, warum die Verarbeitung schwierig ist. Für die Einführung in Mexikos elektronisches Rechnungssystem für Anfänger – was eine CFDI ist, wie die PAC-Validierung funktioniert und was jedes Feld bedeutet – beginnen Sie mit unserem CFDI-Leitfaden für Anfänger. Wenn Sie hier sind, um einen Extraktions-Workflow aufzubauen, anstatt die Schwierigkeit zu verstehen, deckt der vollständige CFDI-Extraktionsleitfaden jede Methode von Anfang bis Ende ab.

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.

Kernaussage: Die Komplexität der CFDI-Verarbeitung hat drei unabhängige strukturelle Ebenen – regulatorisch, dokumentarisch und operativ – und jede Ebene verstärkt die darunterliegende. Zu verstehen, warum jede Ebene existiert, ist der erste Schritt zum Aufbau eines Workflows, der alle drei bewältigen kann.

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 zu CFF Artikel 29-A hinzugefügt, die ab dem 1. Januar 2026 vorschreibt, dass CFDIs reale und wahrheitsgemäße Transaktionen widerspiegeln müssen. Wenn ein CFDI keinen tatsächlichen Rechtsakt oder Vorgang darstellt, gilt er als falsch – mit Konsequenzen, die nun auch strafrechtliche Haftung für Aussteller, Empfänger und Vermittler umfassen. Das 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 SAT als falsch vermuten darf, und der Name und die RFC Ihres Unternehmens können als Empfänger eines falschen CFDIs veröffentlicht werden, mit 30 Tagen Zeit, um 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 von SAT erstellt. Ihr AP-Workflow erbt jedes Feld und jede Validierung, die SAT verlangt – unabhängig davon, ob diese Felder für Ihre Buchhaltung relevant sind.

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

Wenn die Regulierungsebene Pflichtfelder hinzufügt, teilt die Dokumentarchitektur-Ebene 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-amerikanischen oder europäischen Rechnungsformaten geschult wurde, erwartet.

Die Aufteilung beginnt mit einem Feld namens Método de Pago. Wenn der Wert PUE (Pago en Una Sola Exhibición – Einmalzahlung) ist, erfasst der CFDI Ingreso selbst 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. Das ist das, was einem gewöhnlichen Rechnungsformat am nächsten kommt.

Wenn der Wert PPD (Pago en Parcialidades o Diferido – Raten- oder Zahlungsaufschub) ist, erfasst der Ingreso-CFDI nur die Verpflichtung. Die tatsächliche Zahlung – wann sie erfolgt, wie hoch sie ist, auf welchem Weg – wird in einem separaten CFDI vom Typ Pago erfasst, der das Complemento de Recepción de Pagos (Zahlungseingangskomplement, manchmal auch Complemento de Pago genannt) trägt. Dieses Komplement 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. Wenn die Zahlung in drei Raten erfolgt, werden vier XMLs erzeugt: ein Ingreso und drei Pago-CFDIs, jeweils mit eigener UUID, die jeweils über die Komplementstruktur auf das Original verweisen. Der Abgleich bedeutet, die UUID jedes Pago-Komplements mit der UUID des ursprünglichen Ingresos abzugleichen, die Teilzahlungen zu summieren und zu bestätigen, dass der Saldo null erreicht. Verpassen Sie einen Pago-CFDI in Ihrem Posteingang, und der Ingreso erscheint in Ihrer Buchhaltung auf unbestimmte Zeit als unbezahlt – obwohl die Bank die Belastung zeigt.

Was das in der Praxis bedeutet: Ein Lieferant sendet Ihnen am 1. März einen PPD-Ingreso-CFDI über MXN 150.000. Sie empfangen und verarbeiten ihn. Am 15. März sendet der Lieferant einen Pago-CFDI über MXN 75.000 — aber die Betreffzeile der E-Mail lautet „complemento de pago" und der Anhang ist eine weitere XML-Datei. Wenn Ihr AP-Team nicht weiß, dass es diese XML-Datei öffnen und den Knoten Complemento de Pago lesen muss, um die referenzierte UUID zu finden, wird diese Zahlung über MXN 75.000 in Ihrem System nie mit der ursprünglichen Rechnung verknüpft. Die Rechnung bleibt offen. Der Lieferant fragt nach, warum er noch nicht bezahlt wurde. Sie haben bereits bezahlt. Beide Seiten haben korrekte Aufzeichnungen. Sie existieren nur in zwei getrennten Dokumenten, die in Ihrem AP-Workflow nichts miteinander verbindet.

Diese Zwei-Dokumenten-Struktur verursacht nachgelagerte Probleme, die mit dem Volumen zunehmen. Beim Monatsabschluss hat ein AP-Team, das 50 mexikanische Lieferantenrechnungen mit PPD-Bedingungen verarbeitet, potenziell 100 oder mehr XML-Dateien abzugleichen — jede erfordert eine UUID-Querverbindung zwischen dem Ingreso und seinen Pago-Komplement(en). Ein manueller Abgleich 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 Abgleich verbrauchen 50 PPD-Paare zweieinhalb Stunden AP-Personalzeit — jeden Monat, für die Lieferanten eines einzigen Landes.

Es gibt noch 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 die ERP-Systeme des Lieferanten das PDF aus einer Vorlage rendern, die Felder abschneidet oder umformatiert — gilt die XML als das, was 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 CFDI-Extraktionsleitfaden. Für die Verarbeitung von CFDI-Rechnungen im Batch-Betrieb — insbesondere die UUID-Querverbindung über Pago-Komplemente hinweg — siehe unseren Batch-CFDI-Verarbeitungsleitfaden.

Ebene 3: Die Stornierungsfalle — Warum die Korrektur eines Fehlers 72 Stunden und zwei Unterschriften dauert

In den meisten Rechnungsverarbeitungsumgebungen bedeutet die Korrektur eines Fehlers, dass der Lieferant eine Gutschrift oder ein überarbeitetes 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 ist selbst ein regulierter Prozess, an dem beide Parteien, ein Regierungssystem und eine Uhr beteiligt sind.

Nach den aktuellen Regeln muss der Aussteller für die Stornierung eines CFDI einen Stornierungsantrag über das SAT Buzón Tributario (Steuerpostfach) einreichen und dabei einen von vier standardisierten Stornierungsgrund-Codes angeben: 01 — Beleg mit Fehlern in Bezug 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 Nominalvorgang in Sammelrechnung. Code 01 ist bei geschäftlichen Korrekturen am häufigsten und erfordert, dass der Aussteller die UUID des Ersatz-CFDI angibt, der den stornierten ersetzt.

Sobald der Stornierungsantrag eingereicht ist, hat der Empfänger 72 Stunden (drei Werktage) Zeit, ihn anzunehmen oder abzulehnen. Ergreift der Empfänger keine Maßnahme, wird die Stornierung durch Zeitablauf automatisch genehmigt. Lehnt der Empfänger sie ab, bleibt der CFDI rechtlich aktiv, und der Aussteller muss entweder neu mit dem Empfänger verhandeln oder die Streitbeilegungskanäle des SAT einschalten.

Es gibt begrenzte Ausnahmen, bei denen die Zustimmung des Empfängers nicht erforderlich ist: Lohnabrechnungs-CFDIs (Nómina), Rechnungen unter MXN 1.000, Transaktionen mit der allgemeinen Ö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 (Einnahmen-CFDI) über MXN 1.000 — gilt das 72-stündige Annahmefenster des Empfängers.

Für das empfangende AP-Team schafft dies zwei betriebliche Gefahren. Die 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 Ihrem Unternehmen sich im SAT Buzón Tributario (Steuerpostfach) angemeldet hat, um den Antrag anzunehmen oder abzulehnen, wurde er stillschweigend genehmigt. Ihre Bücher enthalten nun einen Eintrag, der durch ein ungültiges Steuerdokument gestützt wird — ein Befund, den das SAT als Ausgabe behandelt, die durch einen ungültigen CFDI gestützt wird, wodurch der Abzug nicht anerkannt wird und möglicherweise Steuernachzahlungen und Strafen ausgelöst werden.

Die zweite ist die Lücke bei der Nachverfolgung von Ersatzdokumenten: Wenn ein Lieferant einen CFDI mit dem Stornierungsgrund-Code 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 eingeben — wobei die neue UUID der alten zugeordnet werden muss. Wenn der Ersatz in einem anderen E-Mail-Thread mit einer leicht abweichenden Betreffzeile eintrifft und von einem anderen Teammitglied verarbeitet wird, geht die Verbindung zwischen Original und Ersatz verloren, und beide Versionen können 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 empfängt. 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 Personen 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 Fertigungsgesellschaft kann die Ausgabe rechtlich nicht absetzen, da die Transaktion nicht unter ihrer Steuerregistrierung stattfand – und die Vertriebseinheit hat keine CFDI zur Untermauerung ihrer Warenkosten. Die Behebung erfordert einen Stornierungs- und Neuausstellungszyklus mit allen oben beschriebenen 72-Stunden-Empfängerakzeptanz-Implikationen.

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 Unternehmen 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 keine RFC-Ebene, um Rechnungen während der Verarbeitung an die richtige Einheit zu leiten. Die Routing-Logik muss in Ihren AP-Workflow eingebaut werden – basierend auf dem Lieferantennamen, dem Beschreibungsfeld oder dem 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 eine 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 (Einzelpersonen mit Geschäftstätigkeit) eingibt, weil jemand beim Onboarding den falschen Code angegeben hat, kann die CFDI die PAC-Validierung dennoch bestehen (da 612 ein gültiger Regime-Code ist), aber sie enthält einen strukturellen Datenfehler, den SAT bei einer zukünftigen Prüfung beanstanden kann. Die CFDI ist gültig, aber falsch – die schwierigste Art von Fehler, bevor er zum Problem wird.

Für eine Analyse der übergreifenden Herausforderungen bei 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 Antwort auf die Komplexität der Rechnungsverarbeitung ist die vorlagenbasierte OCR: Definieren Sie eine Vorlage für das Layout jedes Lieferanten, ordnen Sie Felder Positionen zu und extrahieren Sie Daten anhand von Koordinaten. Dieser Ansatz setzt voraus, dass das Dokumentformat konsistent genug ist, dass eine anhand eines Musters trainierte Vorlage auch für die nächsten hundert funktioniert. CFDI bricht diese Annahme auf zwei Ebenen.

Erstens variiert die PDF-Darstellung je nach Lieferant. Auch wenn jede CFDI dieselben Pflichtfelder gemäß Anexo 20 enthält, rendert jedes Lieferanten-ERP oder -Rechnungssystem das PDF anders. Ein Lieferant platziert die UUID in der oberen rechten Ecke als 36-stelligen String. Ein anderer bettet sie nur in den QR-Code am unteren Rand ein. Ein dritter druckt sie in einer komprimierten Schriftart in der Fußzeile. Eine Vorlage, die für das Layout von Lieferant A erstellt wurde, scheitert vollständig an der Rechnung von Lieferant B.

Zweitens können PDF und XML unterschiedliche Daten enthalten. Das ERP eines Lieferanten könnte das PDF aus einer Teilmenge der XML-Felder rendern – mit dem Positionssummenbetrag, aber ohne die IVA-Aufschlüsselung, mit dem Handelsnamen des Lieferanten statt 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 der XML erfordert, ist das PDF unzureichend. Ein AP-Team, das gegen das PDF abgleicht, gleicht gegen 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 eine XML ist. Semantische Extraktion identifiziert eine RFC nicht, weil sie an den Koordinaten (200, 450) liegt, sondern weil sie dem Muster einer 12- oder 13-stelligen alphanumerischen Kennung entspricht, die im umgebenden Text als „RFC“ beschriftet ist. Dies ist der Unterschied zwischen dem Abbilden visueller Positionen und dem Verstehen von Dokumentinhalten – und es ist der Unterschied, der CFDI-Verarbeitung in großem Maßstab praktikabel macht, statt einer Wartungslast von Vorlagen pro Lieferant.

Was das für Ihren mexikanischen AP-Workflow bedeutet

Betrachtet man alle vier Ebenen zusammen, benötigt ein CFDI-Verarbeitungsworkflow, der alle berücksichtigt, Fähigkeiten, die die meisten Standard-AP-Systeme – die davon ausgehen, 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 Prüfschritt (stimmt das gedruckte Dokument mit den strukturierten Daten überein?). Die Extraktion nur aus dem PDF verzichtet auf den rechtlichen Nachweis. Beide Formate sollten in dieselbe Extraktions-Pipeline 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 Batches hinweg erfasst, speichert und abgleicht, kann die PPD-Zahlungsabstimmung nicht ohne manuelle Nachforschungen durchführen. Für Batch-Abstimmungsworkflows siehe unseren Leitfaden zur CFDI-Batch-Verarbeitung.

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.

Stornierungsstatus-Erkennung. 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.

Keines davon erfordert eine PAC-Integration auf Unternehmensebene oder eine spezielle mexikanische Steuerkonformitätsplattform. Erforderlich ist ein Verarbeitungsschritt, der versteht, was ein CFDI ist – ein mehrteiliges, zustandsbehaftetes, staatlich validiertes Dokument – und seine Daten entsprechend extrahiert, statt 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.

Können wir die generische RFC XEXX010101000 für alle unsere mexikanischen Lieferantenrechnungen verwenden?

Ja, sofern 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 Rückverfolgbarkeit auf Unternehmensebene. Wenn Ihr Unternehmen mehrere Niederlassungen, Abteilungen oder Rechtseinheiten hat, die CFDI-Rechnungen empfangen, benötigen Sie einen internen Weiterleitungsmechanismus (basierend auf Lieferantenname, Beschreibung oder E-Mail), um jede Rechnung der richtigen Verarbeitungswarteschlange zuzuführen.

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 nutzen eine Echtzeit-Genehmigung durch die Behörden, beide erfordern strukturiertes XML mit digitalen Signaturen, und beide schaffen Abstimmungspflichten zwischen Originalrechnungen und späteren Zahlungs- oder Transportdokumenten. Die besondere Komplexität des mexikanischen Systems liegt in der Doppeldokumentstruktur PPD/Pago und dem Stornierungsmechanismus mit Zustimmung des Empfängers – Funktionen, die in den meisten europäischen E-Rechnungsvorgaben kein direktes Äquivalent haben.