Spain wires tamper-evidence into the invoice itself
Spanien verankert Manipulationssicherheit in der Rechnung selbst
Spain is building something most tax authorities only talk about: a rule that reaches inside the software a business uses to write its invoices, and requires that software to make its own records tamper-evident. It was meant to start in 2026. It now starts in 2027 — and the delay is the most instructive part of the story.
What the rule actually requires
Royal Decree 1007/2023 sets out requirements for the computerised systems that support invoicing by businesses and professionals in Spain. The obligation does not sit with the taxpayer’s bookkeeping habits. It sits with the software.
Every invoice a compliant system issues must generate a corresponding billing record. That record carries a hash of its own contents, and it carries data from the immediately preceding record — so the records form a chain. Alter one entry after the fact and the chain no longer verifies. In certain cases an electronic signature is required as well.
Businesses then have a choice. Under the Veri*factu mode, the system transmits each record to the Agencia Tributaria automatically at the moment of issue. Under the non-Veri*factu mode, records stay with the business, but the integrity requirements are stricter and the system must be able to produce the records on demand. Either way, the chain has to hold.
The target is explicit and unusually candid for a tax regulation: software with dual-use capability. Systems, in other words, that can quietly produce a second set of books.
The delay, and what it signals
The original timetable had the obligation beginning on 1 January 2026 for entities subject to corporate income tax, and 1 July 2026 for everyone else. In late 2025 the government amended the decree and moved both dates back by a year: 1 January 2027 for corporate income tax entities, 1 July 2027 for other businesses and the self-employed.
The stated reason was to allow orderly technical adaptation. That is the standard formulation, and in this case it is also plausible. The obligation does not fall on taxpayers so much as on the vendors who supply them, and there are a great many small Spanish businesses running invoicing software from suppliers who have to re-engineer a core data path — hashing, chaining, signing, and in Veri*factu mode a live connection to the tax authority — and then certify it.
Anyone quoting the 2026 dates is working from superseded material. That includes a large amount of vendor marketing which has not been updated, which is itself worth noting: if a supplier’s compliance page still promises readiness for a deadline that no longer exists, it tells you something about how closely that supplier is following the rule it claims to implement.
Why a payments publication cares about an invoicing rule
Because it is the same problem this publication keeps arriving at from the other direction, and Spain has chosen the opposite solution.
Everywhere in the payments chain, the record of a transaction is produced by the party with the strongest interest in how it reads. A merchant writes its own billing descriptor. A merchant declares its own category code. A merchant states its own expected volumes at onboarding. The controls that follow — dispute ratios, monitoring programmes, periodic review — all operate downstream of a self-description that nobody verified at the point it was made.
Veri*factu attacks that at the source. It does not ask the business to behave honestly and check afterwards. It requires the recording system itself to be built so that dishonest recording leaves a mark. The chain does not prevent a false invoice; it prevents a false invoice from being quietly removed later.
That is a meaningfully different theory of control, and it is worth watching precisely because so much of payment supervision runs on the older theory.
What it does not do
Two limits deserve stating plainly, because vendor material tends to blur them.
First, integrity is not accuracy. A chained, hashed, transmitted record of a fictitious transaction is a perfectly intact record of something that never happened. The system guarantees that records were not altered after creation. It does not guarantee that they were true when created.
Second, the scope is invoicing software. Cash businesses that issue no invoice, and businesses operating outside the system entirely, are not reached by a rule about the systems used by those inside it. The measure narrows one route; it does not close the field.
The direction of travel
Spain is not alone. Several European tax administrations are moving in the same direction — from periodic reporting of summarised figures toward continuous, transaction-level visibility, with the obligation pushed down into the software layer rather than sitting on the taxpayer as a filing duty.
For businesses, the practical consequence is that a purchasing decision about accounting software has quietly become a compliance decision. For the rest of us, the interesting question is whether machine-enforced integrity at the point of record produces better outcomes than after-the-fact audit — and Spain, from 2027, will be a large and observable test of it.
Sources: Royal Decree 1007/2023 of 5 December (BOE-A-2023-24840) and the Agencia Tributaria’s published guidance on computerised invoicing systems. The postponement to 2027 was introduced by a subsequent Royal Decree-Law amending RD 1007/2023 and was widely reported by Spanish tax practices in December 2025. Deadlines and technical specifications should be read from the current consolidated text before relying on them.
Spanien baut etwas, worüber die meisten Steuerverwaltungen nur reden: eine Regel, die bis in die Software hineinreicht, mit der ein Unternehmen seine Rechnungen schreibt, und die von dieser Software verlangt, ihre eigenen Aufzeichnungen manipulationssicher zu machen. Beginnen sollte das 2026. Es beginnt nun 2027 — und die Verschiebung ist der lehrreichste Teil der Geschichte.
Was die Regel tatsächlich verlangt
Das Real Decreto 1007/2023 legt Anforderungen an die EDV-Systeme fest, die in Spanien die Rechnungsstellung von Unternehmen und Selbstständigen tragen. Die Pflicht knüpft nicht an die Buchführungsgewohnheiten des Steuerpflichtigen an. Sie knüpft an die Software an.
Jede Rechnung, die ein regelkonformes System ausstellt, muss einen zugehörigen Rechnungsdatensatz erzeugen. Dieser Datensatz trägt einen Hash über seinen eigenen Inhalt und zusätzlich Daten des unmittelbar vorangegangenen Datensatzes — die Datensätze bilden also eine Kette. Wird ein Eintrag nachträglich verändert, lässt sich die Kette nicht mehr verifizieren. In bestimmten Fällen kommt eine elektronische Signatur hinzu.
Unternehmen haben dann die Wahl. Im Veri*factu-Modus übermittelt das System jeden Datensatz im Moment der Ausstellung automatisch an die Agencia Tributaria. Im Nicht-Veri*factu-Modus bleiben die Datensätze im Unternehmen, dafür sind die Integritätsanforderungen strenger und das System muss die Datensätze auf Anforderung herausgeben können. So oder so muss die Kette halten.
Das Ziel ist ausdrücklich benannt und für eine Steuerregelung ungewöhnlich offen: Software mit Doppelnutzungsfähigkeit. Also Systeme, die im Stillen eine zweite Buchführung erzeugen können.
Die Verschiebung und was sie verrät
Der ursprüngliche Zeitplan sah den Beginn zum 1. Januar 2026 für körperschaftsteuerpflichtige Unternehmen und zum 1. Juli 2026 für alle übrigen vor. Ende 2025 hat die Regierung das Dekret geändert und beide Termine um ein Jahr nach hinten gelegt: 1. Januar 2027 für körperschaftsteuerpflichtige Unternehmen, 1. Juli 2027 für die übrigen Unternehmen und Selbstständigen.
Als Grund wurde die geordnete technische Anpassung genannt. Das ist die übliche Formulierung, und in diesem Fall ist sie auch plausibel. Die Pflicht trifft weniger die Steuerpflichtigen als die Anbieter, die sie beliefern — und es gibt sehr viele kleine spanische Unternehmen mit Rechnungssoftware, deren Hersteller einen zentralen Datenpfad neu bauen müssen: Hashen, Verketten, Signieren und im Veri*factu-Modus eine Live-Verbindung zur Steuerverwaltung — und das anschließend zertifizieren lassen.
Wer die Termine von 2026 zitiert, arbeitet mit überholtem Material. Das betrifft auch große Teile der Anbieterwerbung, die nicht aktualisiert wurde — was für sich genommen aufschlussreich ist: Verspricht die Compliance-Seite eines Herstellers noch Bereitschaft für eine Frist, die es nicht mehr gibt, sagt das etwas darüber, wie genau dieser Hersteller die Regel verfolgt, die er umzusetzen behauptet.
Warum ein Zahlungsmedium sich für eine Rechnungsregel interessiert
Weil es dasselbe Problem ist, bei dem dieses Medium immer wieder von der anderen Seite ankommt — und Spanien den umgekehrten Lösungsweg gewählt hat.
Überall in der Zahlungskette wird der Nachweis einer Transaktion von derjenigen Partei erzeugt, die das größte Interesse an seinem Wortlaut hat. Der Händler formuliert seinen Zahlungstext selbst. Der Händler gibt seinen Kategoriecode selbst an. Der Händler nennt beim Onboarding seine erwarteten Umsätze selbst. Alle nachgelagerten Kontrollen — Streitquoten, Überwachungsprogramme, turnusmäßige Prüfung — setzen hinter einer Selbstbeschreibung an, die im Moment ihrer Abgabe niemand überprüft hat.
Veri*factu setzt an der Quelle an. Es bittet das Unternehmen nicht um Ehrlichkeit und prüft hinterher nach. Es verlangt, dass das aufzeichnende System selbst so gebaut ist, dass unehrliche Aufzeichnung Spuren hinterlässt. Die Kette verhindert keine falsche Rechnung; sie verhindert, dass eine falsche Rechnung später unbemerkt verschwindet.
Das ist eine bemerkenswert andere Kontrolltheorie, und sie verdient Aufmerksamkeit gerade deshalb, weil ein großer Teil der Zahlungsaufsicht nach der älteren funktioniert.
Was es nicht leistet
Zwei Grenzen gehören klar benannt, weil Anbietermaterial sie gern verwischt.
Erstens: Integrität ist nicht Richtigkeit. Ein verketteter, gehashter, übermittelter Datensatz über eine erfundene Transaktion ist ein vollkommen unversehrter Nachweis über etwas, das nie stattgefunden hat. Das System garantiert, dass Datensätze nach ihrer Erzeugung nicht verändert wurden. Es garantiert nicht, dass sie bei ihrer Erzeugung wahr waren.
Zweitens: Der Anwendungsbereich ist Rechnungssoftware. Bargeschäfte ohne Rechnung und Unternehmen, die vollständig außerhalb des Systems arbeiten, erreicht eine Regel über die Systeme derjenigen nicht, die innerhalb arbeiten. Die Maßnahme verengt einen Weg; sie schließt das Feld nicht.
Die Richtung
Spanien steht damit nicht allein. Mehrere europäische Steuerverwaltungen bewegen sich in dieselbe Richtung — weg von periodischer Meldung aggregierter Zahlen, hin zu fortlaufender Sichtbarkeit auf Transaktionsebene, wobei die Pflicht in die Softwareschicht hinuntergereicht wird, statt als Erklärungspflicht beim Steuerpflichtigen zu liegen.
Für Unternehmen bedeutet das praktisch, dass die Kaufentscheidung über eine Buchhaltungssoftware unbemerkt zu einer Compliance-Entscheidung geworden ist. Für alle anderen ist die interessante Frage, ob maschinell erzwungene Integrität am Ort der Aufzeichnung bessere Ergebnisse liefert als nachträgliche Prüfung — und Spanien wird ab 2027 ein großer und gut beobachtbarer Test dafür sein.
Quellen: Real Decreto 1007/2023 vom 5. Dezember (BOE-A-2023-24840) sowie die veröffentlichten Hinweise der Agencia Tributaria zu EDV-gestützten Rechnungssystemen. Die Verschiebung auf 2027 erfolgte durch ein nachfolgendes Real Decreto-Ley zur Änderung des RD 1007/2023 und wurde im Dezember 2025 von spanischen Steuerkanzleien breit berichtet. Fristen und technische Vorgaben sind vor jeder Verwendung in der aktuellen konsolidierten Fassung nachzulesen.