Spaniens E-Rechnungsreform macht Rechnungen
komplexer — nicht einfacher

Ein Land, drei E-Rechnungssysteme — und sie kommunizieren nicht miteinander

Die meisten nicht-spanischen Unternehmen gehen bei der Aussage „Spanien führt die E-Rechnung ein“ davon aus, dass es ein einheitliches nationales System gibt. Das ist nicht der Fall. Spanien hat drei parallele Rechtsrahmen, die regeln, wie Rechnungen erstellt, signiert, übermittelt und gespeichert werden. Sie dienen unterschiedlichen Zwecken und unterliegen unterschiedlichen Rechtsgrundlagen:

Diese drei Systeme sind keine Alternativen zueinander. Sie bestehen nebeneinander. Ein Unternehmen in Madrid mit 5 Millionen Euro Umsatz muss sowohl Verifactu einhalten (wie seine Rechnungssoftware Datensätze erzeugt) als auch Crea y Crece (wie es B2B-Rechnungen sendet und empfängt). Ein Unternehmen in Bilbao muss TicketBAI statt Verifactu einhalten, plus Crea y Crece für die B2B-Übermittlung. Ein Unternehmen mit über 10 Millionen Euro Umsatz, das bereits im SII ist, ist von Verifactu befreit, muss aber Crea y Crece einhalten. Das Venn-Diagramm besteht nicht aus drei getrennten Kreisen – es sind überlappende Pflichten, die je nach Standort, Unternehmensgröße und bestehendem Compliance-Status variieren.

Verifactu: Der nationale Standard, der immer wieder verschoben wird

Verifactu ist der Bestandteil des spanischen Anti-Betrugsgesetzes (Ley 11/2021, Änderung von Artikel 29.2.j der Ley General Tributaria), der Rechnungssoftware reguliert. Die Kernanforderung: Jedes Computersystem, das in Spanien Rechnungen erstellt, muss manipulationssichere, kryptografisch verkettete Rechnungsdatensätze erzeugen – einen digitalen Fingerabdruck (Hash), der jede Rechnung mit der vorherigen verknüpft und so eine unzerbrechliche Prüfkette schafft. Rechnungen müssen einen QR-Code zur Überprüfung in der AEAT-Datenbank tragen. Software, die das Löschen oder Ändern von Rechnungsdatensätzen ohne Prüfpfad erlaubt, ist verboten.

Die Frist wurde zweimal verschoben. Ursprünglich auf den 1. Juli 2025 festgelegt, wurde sie zunächst auf 2026 und dann per Real Decreto-Ley 15/2025 vom 2. Dezember 2025 auf den 1. Januar 2027 für Unternehmen und den 1. Juli 2027 für Selbstständige verschoben. Softwareanbieter mussten ab dem 29. Juli 2025 den Verkauf nicht konformer Systeme einstellen – eine Frist, die mit teilweiser Bereitschaft verstrichen ist. Die AEAT führt eine Liste zertifizierter Software; Mitte 2026 sind große Plattformen wie Holded, Quipu und Billin Verifactu-bereit, aber Tausende kleinerer Rechnungstools und kundenspezifischer ERP-Module sind es nicht.

Was Verifactu für den Rechnungsempfänger bedeutet, ist ein neues visuelles Element: der QR-Code. Im Verifactu-Modus (Echtzeitübermittlung an die AEAT, optional aber empfohlen) trägt die Rechnung die Kennzeichnung "VeriFactu" oder "Factura verificable en la sede electrónica de la AEAT" und einen QR-Code, der zum AEAT-Prüfportal führt. Im Nicht-Verifactu-Modus (sichere lokale Speicherung, keine automatische Übermittlung) trägt die Rechnung weiterhin den QR-Code und den verketteten Hash, jedoch nicht die "VeriFactu"-Kennzeichnung. Aus Sicht des Empfängers erzeugen beide Modi Rechnungen, die anders aussehen als vor Verifactu – die zugrunde liegenden Datenfelder (NIF, Base Imponible, IVA, IRPF) bleiben jedoch gleich.

TicketBAI: Warum das Baskenland ein eigenes System entwickelte

Die spanischen Autonomen Gemeinschaften mit eigener Steuerhoheit — das Baskenland und Navarra — haben das verfassungsmäßige Recht, ihre eigenen Steuersysteme zu verwalten. Das Baskenland nutzte dieses Recht, um TicketBAI zu schaffen, ein betrugsbekämpfendes Rechnungssystem, das Verifactu konzeptionell ähnelt, aber operativ eigenständig ist. TicketBAI wurde von den drei Foralsteuerverwaltungen (Álava, Gipuzkoa, Bizkaia) in Zusammenarbeit mit der baskischen Regierung entwickelt.

TicketBAI erfordert die Echtzeitübermittlung von Rechnungsdaten zum Zeitpunkt der Ausstellung — nicht optional wie bei Verifactu. Jede Provinz setzt es leicht unterschiedlich um: Gipuzkoa und Álava verlangen die sofortige Übermittlung an ihre jeweiligen Foralsteuerbehörden, während Bizkaia (im Rahmen des Batuz-Systems) die Übermittlung innerhalb eines bestimmten Zeitrahmens erlaubt und zusätzliche Buchhaltungsdaten (LROE-Bücher) integriert. Bis 2023 verarbeitete allein Álava laut Daten der Provinzsteuerbehörde 300.000 TicketBAI-Rechnungen pro Tag.

Der Formatunterschied ist für AP-Teams relevant, die Rechnungen von Lieferanten aus dem Baskenland erhalten. Eine TicketBAI-Rechnung trägt eine TBAI-Identifikationsnummer und einen QR-Code, der zum Verifikationsportal der Foralsteuerbehörde führt — nicht zur AEAT. Die XML-Kette verwendet einen anderen Signaturmechanismus als Verifactu. Bezeichnungen auf der Rechnung können auf Baskisch (Euskara) neben oder anstelle von Spanisch erscheinen: "Guztira" für Gesamtbetrag, "Oinarria" für Bemessungsgrundlage, "BEZ" für MwSt. Keine dieser Unterschiede betrifft die Kerndatenfelder — Beträge, Steuer-IDs, Sätze bleiben gleich. Sie beeinflussen jedoch jedes Tool, das auf spanische Bezeichnungen zur Felderkennung angewiesen ist.

Crea y Crece: Die B2B-Pflicht, die eine weitere Ebene hinzufügt

Während Verifactu und TicketBAI regeln, wie Rechnungssoftware Rechnungen erstellt, legt das Ley Crea y Crece fest, wie diese Rechnungen zwischen Unternehmen übermittelt werden. Artikel 12 des Gesetzes schreibt vor, dass alle B2B-Rechnungen elektronisch, in einem strukturierten Format und über ein interoperables Plattform-Ökosystem ausgetauscht werden müssen. Die Durchführungsverordnung, Real Decreto 238/2026, wurde am 24. März 2026 vom Ministerrat verabschiedet und am 31. März 2026 im BOE veröffentlicht.

Der Zeitplan wird durch eine bevorstehende Ministerialverordnung ausgelöst (voraussichtliches Inkrafttreten am 1. Oktober 2026), die den Countdown für die Einhaltung startet:

• 12 Monate nach der Verordnung (voraussichtlich Oktober 2027): Unternehmen mit einem Jahresumsatz von über 8 Millionen Euro müssen B2B-E-Rechnungen ausstellen und empfangen
• 24 Monate nach der Verordnung (voraussichtlich Oktober 2028): Alle übrigen Unternehmen und Freiberufler, einschließlich Autónomos, müssen die Vorschriften einhalten
• 36 Monate nach der Verordnung (voraussichtlich Oktober 2029): Kleinere Unternehmen müssen der AEAT auch Daten zum Zahlungsstatus melden

Die akzeptierten Formate sind der europäische Standard EN 16931, umgesetzt als FacturaE, UBL 2.1 oder CII. Bemerkenswerterweise deutet der Entwurf der Ministerialverordnung auf einen Wechsel von FacturaE zu UBL als primärem Format für die öffentliche Plattform hin. Empfänger müssen den Rechnungsstatus – Annahme, Ablehnung, vollständige oder teilweise Zahlung – innerhalb von vier Kalendertagen an die AEAT melden. Die öffentliche Plattform (SPFE, Sistema Público de Facturación Electrónica) wird von der AEAT betrieben und kostenlos zur Verfügung gestellt, zusammen mit interoperablen privaten Plattformen.

Für AP-Teams bedeutet Crea y Crece zweierlei. Erstens ändert sich das Format eingehender Rechnungen: Lieferanten, die zuvor PDFs gesendet haben, werden beginnen, strukturierte elektronische Rechnungen zu senden. Zweitens, und problematischer, wird der Übergang eine lange Reihe gemischter Formate hervorbringen: Einige Lieferanten werden auf UBL/CII umgestellt haben, andere werden noch FacturaE verwenden, und eine beträchtliche Anzahl wird durch das Raster fallen und weiterhin das senden, was sie zuvor gesendet haben – Strafen hin oder her.

Der AP-Albtraum: Wenn alle drei Formate eintreffen

Stellen Sie sich ein realistisches Szenario aus Mitte 2027 vor. Ein Vertriebsunternehmen mit Sitz in Madrid und einem Umsatz von 4 Millionen Euro erhält monatlich 80 Lieferantenrechnungen. Zu seinen Lieferanten gehören:

• 35 Lieferanten aus Madrid, Barcelona, Valencia: Alle stellen Verifactu-konforme Rechnungen aus. Einige im „Verifactu-Modus" mit Echtzeit-Übermittlung an die AEAT und dem „VeriFactu"-Label auf dem Dokument. Andere im Nicht-Verifactu-Modus mit QR-Code, aber ohne Echtzeit-Kennzeichnung. Das Rechnungslayout variiert je nach Abrechnungsplattform des Lieferanten – Holded, Quipu, Billin, Sage, FacturaDirecta oder einem individuellen ERP-Modul.
• 12 Lieferanten aus dem Baskenland (Bilbao, San Sebastián, Vitoria-Gasteiz): Alle stellen TicketBAI-Rechnungen mit TBAI-Codes aus. Einige Beschriftungen auf Baskisch. QR-Codes, die auf Portale der Foralsteuerbehörden verweisen, nicht auf die AEAT. Die XML-Kette verwendet einen anderen Hash-Mechanismus.
• 8 Lieferanten, die Kleinstunternehmen oder ältere Firmen sind: Stellen weiterhin nicht-Verifactu-, nicht-TicketBAI-PDFs aus veralteter Software aus, die nicht aktualisiert wurde. Diese Rechnungen sind technisch nicht konform, treffen aber im Posteingang ein und müssen dennoch verarbeitet werden.
• 5 EU-Lieferanten: Senden Rechnungen im Rahmen des Reverse-Charge-Verfahrens mit 0 % Umsatzsteuer und dem Vermerk „Inversión del sujeto pasivo". Diese folgen weder Verifactu noch TicketBAI.
• 20 Lieferanten, die bereits auf Crea y Crece B2B umgestellt haben: Senden strukturierte UBL- oder FacturaE-Rechnungen, die innerhalb von 4 Tagen bestätigt werden müssen.

Der Posteingang des AP-Teams enthält vier Formatregime (Verifactu, TicketBAI, Legacy, Crea y Crece B2B), zwei Steuerbehörden-Jurisdiktionen, mindestens drei Software-Ökosysteme mit unterschiedlichen visuellen Layouts und eine Mischung aus strukturierten (XML/UBL) und unstrukturierten (PDF) Formaten. Die Aufgabe des Teams hat sich nicht geändert: NIF, Bemessungsgrundlage, Umsatzsteueraufschlüsselung, IRPF-Einbehalt und Gesamtbetrag ins Buchhaltungssystem übertragen. Die Formatfragmentierung hat diese Aufgabe lediglich erschwert.

Keine einzige spanische Buchhaltungsplattform verarbeitet alle vier Formate nahtlos. Holded erkennt FacturaE und Verifactu, verarbeitet aber kein TicketBAI-XML. Eine TicketBAI-zertifizierte baskische Plattform verarbeitet TBAI-Rechnungen, aber möglicherweise nicht die spezifische UBL-Variante, die Crea y Crece erfordert. Eine unternehmenseigene SII-Plattform verarbeitet AEAT-Echtzeitdaten, wurde aber nicht für die Erfassung von PDFs von Mikro-Lieferanten entwickelt. Der Extraktionsschritt – das Auslesen der Daten aus dem jeweiligen Format – bleibt der universelle Engpass.

Was das für AP-Teams bedeutet: Formatvielfalt und Datenextraktion

Das strukturelle Problem liegt nicht darin, dass eines dieser Systeme schlecht konzipiert wäre. Verifactus Hash-Verkettung ist kryptografisch solide. TicketBAIs Echtzeitübermittlung hat die Mehrwertsteuerhinterziehung im Baskenland messbar reduziert. Crea y Creces 4-Tage-Statusmeldung adressiert Spaniens chronisches Zahlungsverzugsproblem, das seit einem Jahrzehnt über dem EU-Durchschnitt liegt.

Das Problem ist, dass niemand für den Empfänger konzipiert hat, der alle Formate erhält. Die Gesetzgebung wurde aus Sicht des Ausstellers geschrieben: „Wenn Sie eine Rechnung ausstellen, so machen Sie sie konform." Die Perspektive des Empfängers – „Wenn 80 Lieferanten Ihnen Rechnungen in 80 verschiedenen Compliance-Formaten senden, so extrahieren Sie die Daten" – blieb als Implementierungsdetail dem Markt überlassen.

Das ist kein rein spanisches Phänomen. Italiens FatturaPA-System, Frankreichs bevorstehende E-Rechnungspflicht und Deutschlands geplante ViDA-Umsetzung schaffen an ihren Grenzen ähnliche Fragmentierungen. Was den spanischen Fall besonders macht, ist die Gleichzeitigkeit: drei große Reformen, die in einem 12-Monats-Fenster (2027) zusammenlaufen, verschiedene Segmente der Lieferantenbasis zu unterschiedlichen Zeitpunkten betreffen, ohne einheitliche Formatspezifikation über alle drei Systeme hinweg.

Die operative Antwort für AP-Teams ist nicht, auf eine Formateinheitlichkeit zu warten – sie wird nicht kommen. Die Antwort ist, den Extraktionsschritt vom Compliance-Format zu entkoppeln. Ein Tool, das die visuelle Ebene einer Rechnung liest, ist unerheblich dafür, ob der QR-Code zur AEAT oder zur Foralsteuerbehörde von Gipuzkoa führt. Es liest die für AP relevanten Felder – NIF, Base Imponible, IVA, IRPF, Total – auf die gleiche Weise, unabhängig davon, welche Compliance-Infrastruktur das Dokument erzeugt hat.

Das Problem der Software-Zertifizierung: Das Tool Ihres Lieferanten bestimmt Ihr Datenformat

Sowohl bei Verifactu als auch bei TicketBAI liegt die Pflicht zur Nutzung zertifizierter Software beim Aussteller. Der Empfänger hat keine Kontrolle darüber, welche Software der Lieferant verwendet und folglich auch keine Kontrolle über das Format, in dem die Rechnung eingeht. Dies schafft eine Asymmetrie: Der Lieferant kann das Gesetz einhalten, indem er ein beliebiges zertifiziertes Abrechnungstool kauft, und der Empfänger muss das Ergebnis dieses Tools akzeptieren.

Erschwerend kommt hinzu, dass der Zertifizierungsprozess selbst noch läuft. Die Liste der von der AEAT verifactu-zertifizierten Software wächst, ist aber unvollständig. Einige große ERP-Anbieter erhielten die Zertifizierung Anfang 2026; kleinere Nischen-Tools für bestimmte Branchen warten noch. In dieser Lücke verwenden Lieferanten möglicherweise Tools, die als „Verifactu-ready" beworben werden, aber Ausgaben produzieren, die von der endgültigen Spezifikation abweichen. Der Empfänger erhält ein Dokument, das konform erscheint, aber die Validierung nach dem aktuellen Standard nicht besteht.

Die Strafstruktur verstärkt die Asymmetrie. Nach Verifactu kann ein Unternehmen, das nicht konforme Software verwendet, mit bis zu 50.000 € pro Steuerjahr bestraft werden. Der Softwareanbieter kann mit bis zu 150.000 € pro Jahr und nicht konformem Produkt bestraft werden. Es gibt keine Strafe für den Erhalt einer nicht konformen Rechnung – nur für deren Ausstellung. Die Compliance-Last liegt vollständig auf der Angebotsseite, aber die operative Last der Verarbeitung eingehender Rechnungen liegt vollständig auf der Nachfrageseite.

Ein praktischer Weg durch den Übergang (2026–2028)

Für AP-Teams, die spanische Lieferantenrechnungen verarbeiten, erfordern die nächsten zwei Jahre eine Strategie, die von Formatvielfalt ausgeht, statt auf Konvergenz zu hoffen. Die praktischen Schritte:

1. Akzeptieren Sie, dass Ihr Posteingang mindestens bis 2029 gemischte Formate enthalten wird. Die Crea-y-Crece-Einführung gibt kleinen Lieferanten selbst bei planmäßiger Veröffentlichung der Ministerialverordnung bis Ende 2028 Zeit zur Einhaltung – und die Durchsetzung wird dem gesetzlichen Termin hinterherhinken. Ein Teil der Lieferanten wird noch lange nach dem Stichtag PDFs im alten Format versenden.

2. Bauen Sie Ihren AP-Workflow um formatunabhängige Datenextraktion auf. Der gemeinsame Nenner von Verifactu, TicketBAI, Crea y Crece und Legacy-Formaten sind die visuellen Daten: NIF, Beträge, MwSt.-Sätze, IRPF-Einbehalt, Daten. Ein Tool, das diese Felder aus dem gerenderten Dokument extrahiert (anstatt XML zu parsen oder Vorlagen abzugleichen), funktioniert bei allen Formaten identisch. Dies macht separate Verarbeitungspfade für verschiedene Rechnungstypen überflüssig. Details zur Einrichtung dieses Workflows finden Sie unter Extrahieren spanischer Rechnungsdaten in Excel für Einzelrechnungen und Stapelverarbeitung spanischer Lieferantenrechnungen für Workflows mit mehreren Lieferanten.

3. Trennen Sie die Compliance-Ebene von der Datenebene. Der QR-Code auf einer Verifactu- oder TicketBAI-Rechnung ist nützlich für die Steuerprüfung und die Verteidigung bei Betriebsprüfungen. Für die Dateneingabe ist er nicht nützlich. Vermischen Sie diese beiden Funktionen nicht. Speichern Sie die ursprüngliche Rechnungsdatei (mit intaktem QR-Code und digitaler Signatur) für die Compliance-Archivierung – spanisches Recht schreibt eine Aufbewahrung von 4 Jahren für Steuerzwecke und 6 Jahren nach dem Handelsgesetzbuch vor. Extrahieren Sie die Daten separat in Ihr Buchhaltungssystem. Die beiden Ausgaben dienen unterschiedlichen Zwecken und sollten sich nicht gegenseitig einschränken.

4. Planen Sie Lieferanten aus dem Baskenland separat ein. Wenn Ihr AP-Volumen viele TicketBAI-Rechnungen umfasst, stellen Sie sicher, dass Ihr Extraktionstool baskische Bezeichnungen erkennt und nicht auf den Abgleich spanischer Textzeichenfolgen angewiesen ist. „Guztira" sollte als Gesamtbetrag erkannt werden. „BEZ" sollte als MwSt. erkannt werden. Dies ist ein Problem der Sprachadaption, kein Formatproblem.

5. Überwachung der Crea-y-Crece-Statusmeldungspflicht. Die 4-Tage-Frist zur Meldung von Rechnungsannahme, -ablehnung oder -zahlung gilt zuerst für große Unternehmen (voraussichtlich Oktober 2027) und wird dann auf kleinere Unternehmen ausgeweitet. Dies ist eine neue betriebliche Aufgabe, die es zuvor nicht gab. Beginnen Sie parallel zu Ihrem Datenextraktions-Workflow mit dem Aufbau eines Prozesses zur Erfassung von Rechnungseingangsdaten und zur Erstellung von Statusmeldungen. Die öffentliche Plattform (SPFE) stellt die Meldeschnittstelle bereit, aber Sie benötigen interne Systeme, um diese zu speisen.

Eine breitere Analyse zur Dokumentenextraktion in spanischsprachigen Märkten und zu verfügbaren Tools in verschiedenen Preisklassen finden Sie unter günstige Extraktionstools für spanischsprachige Märkte. Einen Vergleich über EU-Märkte hinweg bietet Budget-Rechnungsextraktion für französische TPEs.

FAQ

Ist Verifactu dasselbe wie die verpflichtende E-Rechnung?

Nein. Verifactu regelt, wie Rechnungssoftware Rechnungsdatensätze erzeugt und speichert – es ist eine Anti-Betrugsmaßnahme zur Softwaresicherheit. Crea y Crece regelt, wie B2B-Rechnungen zwischen Unternehmen in strukturiertem elektronischem Format übermittelt werden – es ist ein E-Rechnungsmandat zum Datenaustausch. Es handelt sich um separate Rechtsinstrumente mit unterschiedlichen Fristen, obwohl beide im Zeitraum 2025–2028 in Kraft traten. Rechnungen, die auf der öffentlichen Crea-y-Crece-Plattform erstellt werden, sind automatisch Verifactu-konform und vereinen so beide Pflichten für Nutzer der öffentlichen Lösung.

Muss ich den QR-Code auf jeder erhaltenen Verifactu-Rechnung prüfen?

Sie sind gesetzlich nicht verpflichtet, den QR-Code auf erhaltenen Rechnungen zu überprüfen. Der QR-Code ist jedoch Ihre einzige Verteidigung, falls die AEAT bei einer Prüfung die Gültigkeit einer Lieferantenrechnung in Frage stellt. Das Scannen des Codes bestätigt, dass die Rechnung ordnungsgemäß im AEAT-System registriert und nicht verändert wurde. Bei Rechnungen mit hohem Wert oder neuen Lieferantenbeziehungen wird die QR-Prüfung als Compliance-Maßnahme empfohlen. Bei routinemäßigen Rechnungen etablierter Lieferanten kann der QR-Code ohne Echtzeitprüfung mit dem Originaldokument archiviert werden.

Was passiert, wenn ich eine Verifactu-Rechnung von einem Lieferanten erhalte, der eigentlich TicketBAI verwenden müsste?

Ein Lieferant mit steuerlichem Sitz im Baskenland muss TicketBAI-Rechnungen ausstellen, keine Verifactu-Rechnungen. Stellt er stattdessen eine Verifactu-konforme Rechnung aus, liegt der Verstoß auf seiner Seite – er verletzt seine TicketBAI-Pflicht, und die Foralsteuerbehörde kann ihn sanktionieren. Als Empfänger haften Sie nicht für den Compliance-Verstoß des Lieferanten. Sie können die Rechnung normal verarbeiten; die zugrunde liegenden Datenfelder sind strukturell identisch. Weisen Sie den Lieferanten jedoch darauf hin: Sein Verstoß könnte bei einem Abgleich zwischen Verifactu- und TicketBAI-Datenbanken auffallen und Ihren Vorsteuerabzug verzögern.

Wirkt sich der Wechsel zu UBL unter Crea y Crece auf meinen AP-Extraktionsworkflow aus?

Nicht, wenn Ihr Extraktionstool die visuelle Ebene liest, anstatt XML zu parsen. Der Wechsel von FacturaE zu UBL ändert das zugrunde liegende XML-Schema, nicht aber das visuelle Erscheinungsbild der Rechnung in der PDF-Ansicht. Die von Ihnen extrahierten Felder – NIF, Base Imponible, IVA, IRPF, Total – bleiben gleich, unabhängig davon, ob das Quell-XML FacturaE, UBL 2.1 oder CII ist. Wenn Ihr Workflow auf XML-Parsing basiert (z. B. ein Skript, das Daten direkt aus FacturaE-XML-Tags extrahiert), müssen Sie Ihren Parser für UBL aktualisieren. Wenn Sie Daten aus dem visuellen Dokument extrahieren, ist das Format irrelevant.

Wie behandle ich den IRPF-Einbehalt bei Verifactu- und TicketBAI-Rechnungen?

Der IRPF-Einbehalt ist ein feldebenelement der Rechnung, kein formatebenelement. Ob die Rechnung mit Verifactu-zertifizierter Software in Madrid oder TicketBAI-zertifizierter Software in San Sebastián erstellt wurde, die IRPF-Zeile sieht gleich aus: ein Prozentsatz (15 % oder 7 %), ein Euro-Betrag und ein Minuszeichen. Extrahieren Sie ihn als separate Spalte. Für die Batch-Aggregation und den Abgleich mit dem Modelo 111 ist das Format der Rechnung irrelevant – nur der IRPF-Betrag zählt.

Das Reformparadoxon

Die spanische E-Rechnungsreform ist keine einzelne Reform. Es sind drei Reformen mit überlappenden Zeitplänen, unterschiedlichen politischen Zielen (Betrugsbekämpfung, Reduzierung von Zahlungsverzug, Steuertransparenz), die von verschiedenen Behörden verwaltet werden (AEAT für Verifactu und Crea y Crece, Foralverwaltungen für TicketBAI), und Dokumente hervorbringen, die an einem einzigen Punkt zusammenlaufen: dem AP-Posteingang. Die Reformen sollten Ordnung in Spaniens Rechnungsökosystem bringen, indem sie ein Wildwuchs aus Papier, PDF und unstrukturierten Formaten durch ein strukturiertes, rückverfolgbares System ersetzen. Was sie im Übergangszeitraum, der mindestens bis 2029 läuft, hervorgebracht haben, ist das Gegenteil: mehr Formate, mehr Compliance-Vektoren und mehr Möglichkeiten, dass die Daten in einer Struktur ankommen, die Ihre Buchhaltungssoftware nicht nativ verarbeiten kann. Das Paradoxon löst sich erst auf, wenn der Extraktionsschritt vom Format getrennt wird. Lesen Sie, was auf der Seite steht, nicht was die Seite erzeugt hat. Der Rest ergibt sich daraus.