Was Ihre Software für VeriFactu erfüllen muss: die Anforderungen im Einzelnen

Woher die Anforderungen stammen

Aus zwei Vorschriften, die man zusammen lesen muss. Das Real Decreto 1007/2023 (Königliches Dekret) genehmigt die Verordnung (Reglamento) und legt fest, was gewährleistet sein muss; die Orden HAC/1177/2024 (Ministerialerlass) geht ins Detail und regelt, wie: Formate, Algorithmen, Millimeter. Alles Folgende stammt von dort.

1. Die sechs Eigenschaften aus Artikel 8

Artikel 8 ist das Rückgrat. Er verlangt, dass das System die Integrität, Aufbewahrung, Zugänglichkeit, Lesbarkeit, Nachverfolgbarkeit und Unveränderbarkeit der Rechnungsdatensätze gewährleistet. Das klingt nach Absichtserklärung, aber Absatz 2 wird konkret, und dort wird es ernst:

• 8.2.a) — einmal erzeugt und erfasst, dürfen die Daten nicht verändert werden können, ohne dass das System es erkennt. Als Veränderung gilt das Verbergen oder Löschen eines Datensatzes ebenso wie die Änderung seiner Daten. Jede Korrektur erfolgt über einen zusätzlichen, späteren Datensatz; das Original bleibt erhalten.
• 8.2.b) — die Datensätze müssen verkettet sein, sodass sich ihre Spur in der Reihenfolge ihrer Erstellung vom ersten bis zum letzten nachprüfen lässt.

So prüfen Sie es: Lassen Sie sich vorführen, was passiert, wenn Sie eine bereits ausgestellte Rechnung korrigieren wollen. Lässt das Programm Sie die Rechnung bearbeiten und speichern, erfüllt es die Vorschrift nicht. Es muss Sie zu einer Korrekturrechnung oder einer Stornierung führen.

2. Der Ausstellungsdatensatz: wann er entsteht und was er enthält

Artikel 9 legt den Zeitpunkt fest: Der registro de facturación de alta (Datensatz zur Rechnungsausstellung) wird gleichzeitig mit oder unmittelbar vor der Ausstellung jeder Rechnung erzeugt. Das ist kein nächtlicher Lauf und kein Knopf, den jemand am Monatsende drückt.

Artikel 10 zählt seinen Inhalt auf: Steuernummer von Aussteller und Empfänger, Nummer und Serie, Daten, Rechnungsart, Aufschlüsselung von Bemessungsgrundlagen und Steuerbeträgen, der Hash des vorherigen Datensatzes, die Kennung des erzeugenden Rechnungssystems und der Zeitstempel, unter anderem. Insgesamt achtzehn Angaben, Buchstaben a) bis q) (das spanische Alphabet zählt das ñ mit).

So prüfen Sie es: Fragen Sie, ob der Datensatz in derselben Transaktion wie die Rechnung erzeugt wird. Kann die Rechnung ausgestellt sein, während der Datensatz getrennt davon scheitert, haben Sie eine Lücke: zwei verschiedene Wahrheiten über dasselbe Dokument.

3. Der Hash: SHA-256 und Verkettung

Artikel 12 der Verordnung verlangt, Ausstellungs- und Stornodatensätzen einen Hash (huella) hinzuzufügen. Die Orden HAC/1177/2024 legt in ihrem Artikel 13 fest, welche Felder je nach Art des Datensatzes genau in die Berechnung eingehen, und ihr Anhang lässt nur einen Algorithmus zu: SHA-256.

Jeder Datensatz enthält einen Teil des Hashs des vorherigen. So entsteht eine Kette: Würde jemand einen Datensatz in der Mitte manipulieren, stimmten alle späteren Hashes nicht mehr. Das ist der Mechanismus, der die Unveränderbarkeit aus Artikel 8 überprüfbar macht.

So prüfen Sie es: Fragen Sie, ob das System eine Funktion hat, um die Integrität der gesamten Kette zu prüfen, und was es tut, wenn es einen Bruch entdeckt. Ein Programm, das Hashes berechnet, sie aber nie prüft, überbringt Ihnen die schlechte Nachricht am Tag der Steuerprüfung, nicht vorher.

4. Der Stornodatensatz

Artikel 11 regelt den registro de facturación de anulación (Stornodatensatz), der erzeugt wird, wenn eine Rechnung irrtümlich ausgestellt wurde. Wichtig ist, was er nicht ist: Er löscht nichts. Er fügt einen Datensatz hinzu, der die Stornierung dokumentiert, und das Original bleibt bestehen.

So prüfen Sie es: Achten Sie darauf, ob das Programm zwischen Stornieren (die Rechnung hätte nie existieren dürfen) und Berichtigen (Betrag oder Angaben waren andere) unterscheidet. Das ist nicht dasselbe und wird nicht gleich gelöst.

5. Das Ereignisprotokoll

Weniger bekannt und oft nur halb zitiert. Artikel 8.3 verlangt, dass das System ein Ereignisprotokoll (registro de eventos) führt, das bestimmte Interaktionen und Vorgänge automatisch erfasst, ohne dass der Nutzer eingreifen kann. Es soll eine Spur dessen hinterlassen, was rund um die Rechnungsdatensätze geschieht – Systemstarts, Konfigurationsänderungen, Störungen –, nicht nur der Rechnungen.

So prüfen Sie es: Lassen Sie sich dieses Protokoll zeigen. Es muss als solches im System existieren und darf nicht das technische Serverlog sein, in das der Anbieter schaut, wann es ihm passt.

6. Die zwei Modalitäten: übermitteln oder signieren

Artikel 15 ermöglicht die freiwillige Übermittlung der Datensätze, und Artikel 16 definiert, was ein VERI*FACTU-System ist: eines, das sie „fortlaufend, sicher, korrekt, vollständig, automatisch, lückenlos, sofort und beweiskräftig“ übermittelt. Die Wahl hat Folgen:

Für die meisten kleinen und mittleren Unternehmen ist VERI*FACTU der weniger komplexe Weg: Statt zu signieren und aufzubewahren, müssen Sie verbunden bleiben.

7. Der QR-Code und der Vermerk auf der Rechnung

Der Erlass geht bis auf den Millimeter. Sein Artikel 21 verlangt einen QR-Code mit einer Seitenlänge zwischen 30 und 40 Millimetern nach der Norm ISO/IEC 18004, der die NIF (spanische Steuernummer) des Ausstellers, die Rechnungsnummer, das Datum und den Betrag enthält. Arbeitet das System als VERI*FACTU, verlangt Artikel 20 zusätzlich den Vermerk „Factura verificable en la sede electrónica de la AEAT“ oder „VERI*FACTU“; in der nicht verifizierbaren Modalität trägt die Rechnung nur den QR-Code.

So prüfen Sie es: Stellen Sie eine Testrechnung aus und scannen Sie den QR-Code mit dem Handy. Er muss Sie zum Prüfdienst der Agencia Tributaria führen. Und achten Sie auf ein Detail, das gern übersehen wird: Arbeitet das System in der Testumgebung, muss der QR-Code auf die Testumgebung zeigen, nicht auf das echte Portal, wo diese Rechnung nicht existiert.

8. Die Konformitätserklärung

Artikel 13 der Verordnung verpflichtet den Hersteller der Software, eine declaración responsable abzugeben, mit der er bestätigt, dass das System Artikel 29.2.j) der Ley General Tributaria (spanische Abgabenordnung) und der Verordnung selbst entspricht. Sie muss schriftlich und sichtbar im Rechnungssystem selbst stehen, in jeder seiner Versionen, und Kunden und Vertriebspartnern ausgehändigt werden.

Zwei praktische Folgen, die kaum jemand erwähnt:

• Sie gilt pro Version. Ein Anbieter mit kontinuierlichem Deployment braucht eine Versionierungsrichtlinie und muss die Erklärung für jede Version aufbewahren, die er je produziert hat.
• Sie gehört ins Programm. Sie ist kein PDF in der Vertriebsschublade: Sie muss im System selbst abrufbar sein.

Was die Vorschrift nicht sagt und sich im Betrieb zeigt

So weit der Wortlaut. Die folgenden vier Punkte stehen nicht im BOE (spanisches Gesetzblatt), sie stammen aus dem laufenden Betrieb:

1. Wiederholte Übermittlung. Das Portal der Agencia Tributaria hat Ausfälle und Wartungsfenster. Wenn ein Netzwerkfehler Ihre Rechnungsstellung stoppt, liegt das Problem im Design, nicht bei der AEAT. Der Datensatz ist bereits erzeugt und verkettet; die Übermittlung muss sich selbst wiederholen, mit sichtbarem Status für jeden einzelnen.
2. Die Modalität wird in der Rechnung festgeschrieben. Entscheidend ist, wie das Dokument ausgestellt wurde, nicht wie das System an dem Tag konfiguriert ist, an dem jemand es nachdruckt. Wird der Vermerk im PDF jedes Mal neu berechnet, kann ein späterer Nachdruck der ursprünglichen Rechnung widersprechen.
3. Eine echte Testumgebung. Bevor Sie echte Rechnungen stellen, müssen Sie gegen die Testumgebung der AEAT proben können, mit ihrer eigenen Prüf-URL.
4. Mehrere Gesellschaften, mehrere Ketten. Wenn Sie aus mehr als einem Unternehmen heraus fakturieren, braucht jedes seine eigene Nummerierung, sein eigenes Zertifikat und seine eigene Hash-Kette, ohne Vermischung. Mehr dazu in VeriFactu in einem Transportunternehmen.

Zehn Fragen an Ihren Anbieter

1. Können Sie mir die Konformitätserklärung der Version zeigen, die ich unter Vertrag habe?
2. In welcher Modalität arbeitet das System, VERI*FACTU oder nicht verifizierbar?
3. Wird der Ausstellungsdatensatz in derselben Transaktion wie die Rechnung erzeugt?
4. Kann ich die Hash-Kette prüfen, direkt im Programm?
5. Was genau passiert, wenn ich eine bereits ausgestellte Rechnung zu ändern versuche?
6. Unterscheidet es zwischen Stornierung und Korrekturrechnung?
7. Wo sehe ich das Ereignisprotokoll?
8. Was passiert, wenn die AEAT nicht antwortet? Wird automatisch wiederholt? Sehe ich das?
9. Wenn ich aus zwei Gesellschaften fakturiere, hat jede ihre eigene Serie und ihr eigenes Zertifikat?
10. Wenn ich nächstes Jahr ins SII wechsle, was muss ich ändern?