VERI*FACTU und individuelle Rechnungssoftware: Was Spanien bis zum 1. Januar 2027 verlangt

Vor dem 1. Januar 2027 muss jedes Unternehmen in Spanien, das Körperschaftsteuer (Impuesto sobre Sociedades) erklärt und seine Rechnungen mit Software erstellt, eine Software verwenden, die an das Real Decreto 1007/2023 angepasst ist. Jede Rechnung erhält einen gehashten Datensatz, der mit dem vorherigen verkettet ist, und einen QR-Code, den der Kunde bei der Steuerbehörde prüfen kann. Alle anderen Betroffenen, vor allem Selbstständige, haben bis zum 1. Juli 2027 Zeit.

Wenn Ihre Rechnungen aus einem kommerziellen Paket kommen, ist das im Wesentlichen Aufgabe Ihres Anbieters. Wenn sie aus Software kommen, die jemand für Sie geschrieben hat oder die Ihr eigenes Team geschrieben hat, ist es Ihre Aufgabe. Sie ändern den Code, und Sie unterschreiben die Erklärung, dass er den Vorgaben entspricht.

Die Termine und die zwei Verschiebungen

Das ist der dritte Satz an Terminen, eine gewisse Skepsis ist also berechtigt.

• Das Real Decreto 1007/2023 gab Unternehmen ursprünglich bis zum 1. Juli 2025 Zeit.
• Das Real Decreto 254/2025 vom 1. April 2025 verschob das auf den 1. Januar 2026 für Körperschaftsteuerpflichtige und den 1. Juli 2026 für alle anderen. Der Grund war konkret: Die technische Verordnung, die Orden HAC/1177/2024, war erst am 28. Oktober 2024 veröffentlicht worden.
• Das Real Decreto-ley 15/2025 vom 2. Dezember 2025 verschob beide Termine um ein Jahr. Sein Text steht im BOE, und der Kongress hat es noch im selben Monat bestätigt.

Die Mitteilung der AEAT zur Fristverlängerung, aktualisiert am 26. März 2026, ist eindeutig: „las entidades que presenten el Impuesto sobre Sociedades deberán tener adaptados sus SIF antes del 1 de enero de 2027. El resto de obligados tributarios, antes del 1 de julio de 2027.“

Kann sich das noch einmal verschieben? Stand Oktober 2026 deutet offiziell nichts darauf hin. Die erste Verzögerung hatte einen technischen Grund, den es nicht mehr gibt. Die Übermittlungsdienste der AEAT sind seit dem 23. April 2025 im Produktivbetrieb, und seit dem 29. Juli 2025 dürfen Softwareanbieter nur noch angepasste Systeme anbieten. Auf eine dritte Verschiebung zu setzen ist eine Wette, kein Plan.

Welcher Termin gilt für Sie? Eine SL oder SA erklärt Körperschaftsteuer, ein Unternehmen mit eigenem ERP fällt also fast sicher unter den 1. Januar 2027. Das ist weniger als drei Monate entfernt. Der Juli-Termin gilt für Selbstständige und die übrigen betroffenen Steuerpflichtigen.

Wer erfasst ist und wer nicht

Die FAQ der AEAT zum Anwendungsbereich reduzieren ihn auf vier Verneinungen. Sie sind erfasst, wenn Sie nicht ausschließlich von Hand fakturieren, nicht am SII teilnehmen (weder verpflichtend noch freiwillig), Ihren steuerlichen Sitz nicht im Baskenland oder in Navarra haben und keine Befreiung erhalten haben.

Die Ausnahmen in der Praxis:

• Teilnehmer am SII. Das Suministro Inmediato de Información ist Pflicht für Unternehmen mit mehr als 6 Millionen Euro Umsatz, für Mehrwertsteuergruppen und für Unternehmen im Register für monatliche Vorsteuererstattung (REDEME), andere können sich freiwillig anschließen. Die AEAT sagt es klar: „El ámbito subjetivo de ambos proyectos es excluyente.“ Wenn Sie ins SII wechseln, senden Sie keine VERI*FACTU-Datensätze mehr und drucken keinen QR-Code mehr.
• Baskenland und Navarra. Unternehmen mit steuerlichem Sitz dort unterstehen den foralen Steuerverwaltungen und deren eigenen Regeln, nicht dem RD 1007/2023.
• Rein manuelle Rechnungsstellung. Ein Rechnungsbuch auf Papier ist nicht erfasst. Ebenso wenig eine Tabellenkalkulation, die nur zum Tippen, Drucken und Aufbewahren von Rechnungen dient; eine, die zusätzlich Ihre Umsatzsteuerbücher erzeugt, dagegen schon.

Ausländische Unternehmen sind erfasst, wenn sie in Spanien eine Betriebsstätte haben.

Wenn Sie mit einem kommerziellen Paket fakturieren (A3, Sage, Holded und ähnliche), ist der Anbieter der Hersteller und muss eine angepasste Version mit eigener Erklärung liefern. Spielen Sie das Update ein, prüfen Sie, ob die Erklärung vorhanden ist, und Sie können hier aufhören zu lesen.

Dieser Artikel richtet sich an alle anderen: ein individuelles ERP, ein vor fünfzehn Jahren geschriebenes Programm in Access, Delphi oder FileMaker oder ein Abrechnungsmodul in Ihrer eigenen Webplattform.

Ihr Unternehmen ist der Hersteller

Artikel 13.1 der Verordnung legt die Zertifizierung auf denjenigen, der das System herstellt, und zwar per declaración responsable, einer Erklärung in eigener Verantwortung. Die FAQ der AEAT zur Zertifizierung beantworten den Fall der Eigenentwicklung direkt: „Cada sistema en operación debe disponer de una Certificación emitida mediante declaración responsable de su productor (artículo 13.1 RRSIF). Si el software hubiera sido desarrollado por la propia empresa, será esta la que deba certificarlo.“

Was das in der Praxis bedeutet:

• Es gibt keine externe Prüfung. Die AEAT nennt es eine „auto-certificación“ des Herstellers. Niemand genehmigt Ihr System vorab. Sie unterschreiben, und Sie stehen dafür ein.
• Ein Auftragnehmer, der für Sie eine Erweiterung als Produkt baut, zertifiziert diese Erweiterung. Wenn Sie sie selbst gebaut haben, zertifizieren Sie sie.
• Die Erklärung muss im System selbst sichtbar sein, in jeder Version, und außerdem außerhalb davon abrufbar, unabhängig vom Produkt.
• Ihr Inhalt ist vorgegeben durch Artikel 15 der Orden HAC/1177/2024: unter anderem Name, Kennung und Version des Systems, seine Komponenten, ob es ausschließlich im VERI*FACTU-Modus arbeitet, Name, NIF und Anschrift des Herstellers sowie Datum und Ort der Unterschrift.

Unangenehm ist der Fall des Programms, dessen Autor vor Jahren gegangen ist. Jemand muss trotzdem die angepasste Version herstellen und dafür unterschreiben. Legen Sie schriftlich fest, wer das ist, bevor die Arbeit beginnt.

Wer ein zertifiziertes kommerzielles Produkt anpasst, braucht nur dann eine eigene Erklärung, wenn die Änderung berührt, wie die Anforderungen der Verordnung umgesetzt sind. Eine Änderung außerhalb der Kontrolle des Herstellers, die diese Umsetzung verändern kann, ist nicht konform.

Was auf dem Spiel steht, regelt Artikel 201 bis der Ley General Tributaria: eine feste Geldbuße von 150.000 Euro pro Geschäftsjahr und pro Systemtyp für die Herstellung von Systemen, die die Anforderungen nicht erfüllen, und 50.000 Euro pro Geschäftsjahr für den Besitz eines Systems, das zertifiziert sein müsste und es nicht ist oder das verändert wurde. Welche davon bei einem selbst gebauten System greifen würde, ist eine Frage für Ihre Steuerberatung. Klein ist keiner der beiden Beträge.

Was die Software leisten muss

Ein Datensatz für jede Rechnung, im Moment der Ausstellung

Artikel 9.1 verlangt, dass das System einen registro de facturación de alta erzeugt, und zwar „de forma simultánea o inmediatamente anterior a la expedición de cada factura“. Eine stornierte Rechnung erhält einen Stornodatensatz (registro de anulación).

Artikel 10 zählt auf, was der Datensatz enthält: NIF und Name des Ausstellers, den Empfänger, wo erforderlich, Serie und Nummer, Ausstellungs- und Leistungsdatum, Rechnungsart, Angaben zu einer gegebenenfalls berichtigten Rechnung, eine Beschreibung, den Gesamtbetrag, die Mehrwertsteuerregelung, Bemessungsgrundlage, Steuersätze und Steuerbeträge, Gründe für Befreiung oder Nichtsteuerbarkeit, die Identität des Systems und seines Herstellers sowie einen sekundengenauen Zeitstempel.

In älteren Systemen versteckt sich hier die Arbeit:

• Die Aufschlüsselung der Mehrwertsteuer wird oft erst beim Drucken berechnet und nie gespeichert. Sie muss im Moment der Ausstellung als Daten vorliegen.
• „Ausstellen“ heißt oft nur, einen Bericht zu drucken. Es braucht einen ausdrücklichen Punkt, an dem aus einem Entwurf eine Rechnung wird, und genau dann entsteht der Datensatz.
• Nummern werden nicht mehr wiederverwendet. Eine Rechnung zu löschen und ihre Nummer erneut zu vergeben, in vielen kleinen Systemen eine Gewohnheit, scheitert jetzt: Die AEAT weist den zweiten Datensatz mit „Registro de facturación duplicado.“ zurück. Testrechnungen, die im Produktivsystem ausgestellt werden, sind echte Rechnungen und müssen storniert werden.
• Niemand bearbeitet Datensätze. Laut FAQ der AEAT dürfen direkte Änderungen an der Datenbank der ausgestellten Datensätze keine zulässige Operation sein. Wenn Ihre Mitarbeiter Rechnungen heute per SQL korrigieren, hört das auf. Korrekturen laufen über Berichtigungsrechnungen (facturas rectificativas).

Die Hash-Kette

Jeder Datensatz enthält Serie, Nummer und Datum des vorherigen Datensatzes sowie einen Teil seines Hashwerts (huella). Der Algorithmus ist SHA-256, und die genauen Felder und ihre Verkettung stehen in der technischen Dokumentation der AEAT, zusammen mit den Datensatzbeschreibungen, XSD-Schemas, WSDL sowie dem Katalog der Prüfungen und Fehler.

Bevor ein neuer Datensatz erzeugt wird, muss das System prüfen, dass der letzte korrekt verkettet ist und sein Zeitstempel nicht mehr als eine Minute nach der aktuellen Zeit liegt. Die Datensätze werden in der Reihenfolge erzeugt, in der die Rechnungen ausgestellt werden.

Das hat eine Folge für die Architektur. Jede Installation braucht einen einzigen, serialisierten Punkt, an dem Datensätze entstehen. Zwei Webserver, die ohne Abstimmung an dieselbe Kette anhängen, brechen sie. Die AEAT akzeptiert gemischte Aufbauten, etwa Kassenterminals, die den Datensatz von einem zentralen Backoffice erhalten, aber die Kette selbst liegt an einem Ort.

Jedes System wird über die NIF des Steuerpflichtigen, eine zweistellige System-ID und eine Installationsnummer identifiziert, die sich nie wiederholen darf, auch nicht, wenn dieselbe Software auf demselben Rechner neu installiert wird.

Der QR-Code auf der Rechnung

Jede Rechnung trägt einen QR-Code nach ISO/IEC 18004, zwischen 30x30 und 40x40 mm groß, mit Fehlerkorrekturstufe M. Er codiert eine URL mit der NIF des Ausstellers, Serie und Nummer, Ausstellungsdatum und Gesamtbetrag, die der Kunde bei der AEAT prüfen kann. Im VERI*FACTU-Modus trägt die Rechnung außerdem den Hinweis „VERI*FACTU“ oder „Factura verificable en la sede electrónica de la AEAT“.

Für Altsoftware bedeutet das, die Rechnungsvorlage zu überarbeiten (einen Access-Bericht, ein FileMaker-Layout, einen PDF-Generator) und eine QR-Bibliothek in einen Stack einzubauen, der nie eine hatte.

Zwei Modi: VERI*FACTU oder nicht

VERI*FACTU-Modus. Das System sendet jeden Datensatz automatisch an die AEAT, sobald er erzeugt ist. Im Gegenzug brauchen die Datensätze einen Hashwert, aber keine elektronische Signatur, die AEAT bewahrt sie auf, und ein System, das nur in diesem Modus arbeitet, braucht kein Ereignisprotokoll. Sie brauchen einen SOAP-Client für die veröffentlichten Dienste der AEAT, ein qualifiziertes elektronisches Zertifikat und eine Warteschlange für den Fall, dass die Verbindung ausfällt. Die Entwickler-FAQ der AEAT behandeln einen Ausfall als Störung: Die Datensätze warten in der Warteschlange und werden erneut gesendet, und die Rechnungsstellung läuft weiter.

Nicht-VERI*FACTU-Modus. Die Datensätze bleiben bei Ihnen, und jeder muss mit einem qualifizierten Zertifikat signiert werden (XAdES Enveloped, ETSI EN 319 132). Das System muss außerdem ein signiertes Ereignisprotokoll führen, das Start und Stopp in diesem Modus, Anomalieprüfungen und ihre Ergebnisse, Wiederherstellungen aus Sicherungen und Exporte abdeckt, mit einem zusammenfassenden Ereignis mindestens alle sechs Betriebsstunden, und es muss die Datensätze herausgeben, wenn die AEAT sie anfordert.

Für ein individuelles System ist der reine VERI*FACTU-Modus meist der kleinere Umbau. Keine Signaturinfrastruktur, kein Ereignisprotokoll, keine Werkzeuge für Anomalien. Ein System, das beide Modi anbietet, muss all das umsetzen.

Ein Plan, der vor den 1. Januar 2027 passt

Ab Anfang Oktober hat ein Körperschaftsteuerpflichtiger rund dreizehn Wochen. Diese Reihenfolge funktioniert.

1. Woche 1: Bestandsaufnahme. Listen Sie jedes System auf, das Rechnungen ausstellt: das ERP, das Abrechnungsmodul des Webshops, das Abo-Skript, das Kassenterminal. Bestätigen Sie, dass Sie weder am SII teilnehmen noch unter forale Regeln fallen.
2. Woche 1 bis 2: festlegen, wer unterschreibt und welcher Modus. Benennen Sie für jedes System den Hersteller. Wählen Sie den reinen VERI*FACTU-Modus, sofern nichts dagegen spricht. Stellen Sie sicher, dass das qualifizierte Zertifikat des Unternehmens existiert und jemand dafür zuständig ist, denn laut Entwickler-FAQ der AEAT kann das System ohne Zertifikat nicht arbeiten.
3. Woche 2 bis 4: Datenlückenanalyse. Vergleichen Sie, was Ihr System speichert, mit Artikel 10 und der Datensatzbeschreibung der AEAT. Fehlende Aufschlüsselungen der Mehrwertsteuer, Codes für die Rechnungsart und Verweise auf berichtigte Rechnungen zeigen sich hier.
4. Woche 3 bis 8: Umsetzung. Erzeugung der Datensätze bei Ausstellung, die Kette und ihre Prüfungen, unveränderliche Speicherung, Stornierung, der QR-Code auf jeder Vorlage und der Übermittlungsclient mit seiner Warteschlange für Wiederholungen. Entfernen Sie direkte Änderungen an ausgestellten Datensätzen.
5. Woche 6 bis 10: Test. Beginnen Sie in der Testumgebung der AEAT und senden Sie dann echte Datensätze. Die AEAT behandelt die Zeit vor Ihrem Stichtag als Testphase, in der Sie das Senden einstellen und auf ein anderes System zurückgehen dürfen. Lesen Sie die Entwickler-FAQ, bevor Sie die Abläufe für Stornierung und Berichtigung schreiben: Sie decken die meisten Sonderfälle ab.
6. Woche 9 bis 12: erklären und schulen. Schreiben Sie die declaración responsable, zeigen Sie sie in der Anwendung und außerhalb davon an und halten Sie die Version fest. Sagen Sie der Finanzabteilung, dass Nummern nie wiederverwendet werden und Fehler per Berichtigungsrechnung korrigiert werden.
7. Mitte Dezember: Go-live. Eine Frist, die „antes del 1 de enero“ lautet, ist kein Go-live-Termin. Gehen Sie zwei Wochen früher live, damit die ersten Probleme auftauchen, solange noch Zeit ist.

Für den Termin am 1. Juli 2027 gilt derselbe Plan mit mehr Luft. Fangen Sie im Januar an, nicht im Mai.

Zwei Alternativen zum Neubau verdienen eine ehrliche Abwägung. Die AEAT akzeptiert gemischte Architekturen, Ihr ERP kann also weiterhin die Rechnungsdaten vorbereiten, während eine separate, gekaufte oder gebaute Komponente die Datensätze, den QR-Code und die Übermittlung erzeugt, sofern die Erklärungen abdecken, wie die Teile zusammenspielen. Und wenn das alte Programm nur eine Handvoll Rechnungen im Monat ausstellt, kostet die kostenlose Rechnungsanwendung der AEAT für kleine Unternehmen oder ein Standardpaket womöglich weniger als die Anpassung.

Wo Sie Hilfe bekommen

Wir ändern Rechnungscode, den Unternehmen bereits betreiben, auch auf älteren Stacks: die Erzeugung der Datensätze, die Hash-Kette, den QR-Code auf Ihren Vorlagen und den Übermittlungsclient für die AEAT, und wir hinterlassen Tests. Unsere Leistung zur E-Rechnungs-Integration deckt den Umbau ab, und die Wartung von Bestandssystemen ist der Ausgangspunkt, wenn niemand mehr weiß, wie das alte Programm funktioniert.

Wenn für Sie der 1. Januar 2027 gilt und Sie ein individuelles System haben, schreiben Sie an office@c9group.dev. Wir sind Ingenieure, keine Steuerberater: Fragen zu Anwendungsbereich und Haftung gehören zu Ihren Beratern, und wir bauen nach der Antwort, die sie geben.