ViDA 2030 & ERP: Integration über einen E-Rechnungs-Layer
ViDA ist beschlossen, die zentralen Termine kommen näher — und für viele ERP-Teams stellt sich 2026 die gleiche Frage: in der ERP-Kernlogik ergänzen oder einen separaten Layer vorschalten? Die Antwort ist in den allermeisten Fällen die zweite. Genau dafür ist ein E-Rechnungs-Layer wie Factora gemacht.
Wenn du die übergeordnete ViDA-Timeline und den Stichtag 1. Juli 2030 noch einordnen willst, lies parallel unseren Beitrag zu ViDA 2030 und grenzüberschreitenden B2B-Rechnungen. Dieser Artikel hier ist die Architektur-Antwort darauf.
Das Wichtigste in Kürze
- Stichtag 1. Juli 2030: Digital Reporting Requirements (DRR) für grenzüberschreitende B2B-Umsätze in der EU werden wirksam.
- Bis 1. Januar 2035 sollen nationale Echtzeit- und Digital-Reporting-Systeme an EU-Standards harmonisiert sein.
- Ein E-Rechnungs-Layer trennt Erzeugung, Validierung, Format-Routing und Reporting-Anbindung sauber von der ERP-Kernlogik.
- Mehrere Formate parallel (XRechnung, ZUGFeRD, UBL/Peppol BIS Billing) lassen sich über einen Layer ohne Mehrfach-Implementierung im ERP betreiben.
- Factora ist explizit als „Infrastruktur hinter E-Rechnungen” positioniert und per REST-API in ERP-, Plattform- oder Branchensoftware integrierbar.
- Vorsicht bei Überansprüchen: 2026 sollte niemand „vollständige ViDA-Konformität” versprechen — die Reform wird schrittweise bis 2035 ausgerollt.
Was ViDA 2030 für ERP-Systeme konkret bedeutet
ViDA („VAT in the Digital Age”) wurde am 11. März 2025 vom Rat der EU final beschlossen und am 25. März 2025 im Amtsblatt veröffentlicht. Der für ERP-Architekturen wichtigste Termin ist der 1. Juli 2030: Ab dann sollen die Digital Reporting Requirements (DRR) für grenzüberschreitende B2B-Umsätze innerhalb der EU greifen. Strukturierte E-Rechnungen werden dafür die technische Voraussetzung — ohne sauberes EN-16931-Datenmodell ist DRR nicht möglich.
Für Bestands-ERPs heißt das in der Praxis dreierlei:
- Die Rechnungsdaten müssen strukturiert und EN-16931-nah vorliegen — nicht nur als PDF oder freies XML.
- Es braucht mehrere Ausgabeformate parallel (XRechnung für DACH-B2G, ZUGFeRD für hybride B2B-Fälle, UBL für Peppol-Routing).
- Es kommt eine Reporting-Schicht dazu — nicht erst 2030, aber spätestens dann produktiv.
Das ist deutlich mehr als „ein neuer Rechnungsexport”.
Warum ERPs das nicht in der Kernlogik lösen sollten
Theoretisch lässt sich jeder dieser Bausteine direkt im ERP umsetzen. Praktisch passieren dabei drei Dinge:
- Format-Vielfalt frisst Wartungslast. XRechnung, ZUGFeRD und UBL/Peppol entwickeln sich nicht synchron. Der KoSIT-Validator wird laufend aktualisiert (siehe XRechnung-Bugfix Winter 2025/26), Peppol-Codelisten ändern sich (siehe Peppol-Stichtag 1. August 2026), die EU-Norm bekommt 2026 ein Update. Jede dieser Bewegungen müsste ohne Layer einzeln im ERP nachgezogen werden.
- Compliance- und Domänenlogik mischen sich. Steuerlogik, Buchungs- und Belegfluss gehören ins ERP. EN-16931-Mapping, Schematron-Validierung und Format-Rendering nicht. Wenn beides im selben Code lebt, sinken Test- und Liefergeschwindigkeit messbar.
- Reporting kommt obendrauf. Sobald DRR ab 2030 greift, müssen ERP-Daten zusätzlich an Reporting-Endpunkte fließen — innerhalb von 10 Tagen nach Belegerstellung. Wer das in jedes Modul einzeln einbaut, verschiebt das Problem.
Genau hier setzt der Layer-Ansatz an.
Der Layer-Ansatz: Was ein E-Rechnungs-Layer leistet
Ein E-Rechnungs-Layer ist keine zusätzliche Anwendung für Endnutzer, sondern eine Infrastrukturkomponente zwischen ERP und Außenwelt. Seine Aufgaben:
- Strukturierung der Eingangsdaten auf ein EN-16931-nahes Modell
- Format-Rendering in XRechnung, ZUGFeRD und UBL für Peppol
- Validierung gegen den aktuellen KoSIT-Validator und Peppol-Schematron
- Routing an den richtigen Empfänger (E-Mail, Peppol Access Point, Behördenportal)
- Archivierung in GoBD-konformer Form
- Reporting-Schnittstelle für DRR-relevante Daten ab 2030
Dahinter steht ein architektonisches Prinzip: Trennung der Concerns. Das ERP behält die fachliche Hoheit über Belege, Steuerlogik und Buchungen. Der Layer übernimmt alles, was sich aus regulatorischen Gründen schneller ändert als die ERP-Releases.
Architektur-Skizze: ERP → Layer → Empfänger und Reporting
So sieht eine typische Integration aus, wenn ein Bestands-ERP an einen E-Rechnungs-Layer angebunden wird:
| Stufe | System | Aufgabe |
|---|---|---|
| 1 | ERP / Branchensoftware | Beleg erfassen, Stammdaten verwalten, Steuerlogik anwenden |
| 2 | API-Übergabe | Rechnungsdaten strukturiert an den Layer übergeben (REST/JSON) |
| 3 | E-Rechnungs-Layer | EN-16931-Mapping, Format-Rendering, Validierung |
| 4 | Format-Ausgabe | XRechnung, ZUGFeRD oder UBL — je nach Empfangskanal |
| 5 | Routing | Versand per E-Mail, Peppol Access Point, Behördenportal |
| 6 | Archivierung | GoBD-konforme Aufbewahrung des originären Datensatzes |
| 7 | Reporting (ab 2030) | DRR-relevante Daten an die ViDA-Reporting-Pipeline übergeben |
Wichtig ist die Reihenfolge: Stufen 3–7 sind außerhalb der ERP-Kernlogik. Das ERP muss seinen Code nur dort anpassen, wo es Daten herausgibt — nicht überall dort, wo sich Formate, Validatoren oder Reporting-Pflichten ändern.
Wie Factora als Layer integriert wird
Factora ist auf der Startseite ausdrücklich als „Infrastruktur hinter E-Rechnungen” positioniert. Die Factora API ist genau dafür da: ERP-, Plattform- und Branchensoftware übergeben strukturierte Rechnungsdaten und erhalten validierte E-Rechnungen zurück — ohne selbst ein UBL-Mapping, einen Schematron-Lauf oder ein ZUGFeRD-PDF/A bauen zu müssen.
Welche Felder eine solche Übergabe sauber modellieren sollte, beschreiben wir im Detail im Beitrag Peppol per API: Welches Datenmodell Softwareanbieter wirklich brauchen. Kurz zusammengefasst:
- ein semantisches Rechnungsmodell statt direktem Format-Mapping
- saubere VAT-Kategorien (nicht nur Prozentwerte)
- belastbare Referenzketten (Buyer Reference, Order Reference, Korrekturbezüge)
- konsistente Endpoint-IDs für Peppol-fähige Adressierung
Wenn das im Übergabe-Punkt sitzt, ist die ViDA-Vorbereitung bereits zu großen Teilen geleistet — unabhängig davon, was der konkrete EU-Rechtsakt in den nächsten Jahren noch detailliert.
Pragmatischer Vorteil gegenüber einer „ViDA-fertigen” ERP-Erweiterung
Im Markt finden sich 2026 erste Versprechen wie „vollständig ViDA-konform”. Das ist mit Vorsicht zu lesen: Die EU-Kommission selbst spricht von einem schrittweisen Rollout bis Januar 2035. Was 2030 verbindlich ist und wie genau die DRR-Endpunkte je Mitgliedsstaat aussehen, wird sich bis dahin noch konkretisieren.
Für ERP-Teams heißt das: Wer heute auf einen monolithischen ViDA-Block im Kernsystem setzt, baut auf einem beweglichen Fundament. Ein Layer-Ansatz ist konservativer:
- Heute produktiv für alle aktuellen E-Rechnungs-Pflichten (E-Rechnungspflicht 2027, DACH-B2G, Peppol-B2B)
- Erweiterbar Richtung DRR und ViDA-Reporting, ohne ERP-Migration
- Ablösbar im schlimmsten Fall — der Layer ist ein Drittanbieter, das ERP bleibt unangetastet
Diese Tonalität haben wir auch in unserem Timeline-Artikel zu ViDA 2030 für grenzüberschreitende B2B-Rechnungen durchgehalten: keine Überansprüche, aber eine belastbare Vorbereitung.
Was du heute schon vorbereiten kannst
Auch wenn ViDA-DRR erst 2030 greift, sind drei Schritte heute schon sinnvoll:
1. Datenmodell auf EN-16931-Nähe trimmen
Wenn dein ERP heute nur Pflichtfelder für Inlandsfälle abbildet, wird es spätestens bei grenzüberschreitenden B2B-Umsätzen eng. Steuerkategorien, Steuerbefreiungsgründe, Währungen, Käufer- und Lieferantendaten gehören sauber strukturiert — nicht in Freitextfeldern. Vergleich von XRechnung und ZUGFeRD hilft, die EN-16931-Basis zu sehen.
2. Übergabe-Punkt zum Layer definieren
Bevor du einen Layer auswählst, klär den Vertrag: Welche Felder gibt das ERP raus, in welcher Granularität, in welchem Trigger? Idealerweise REST/JSON gegen ein dokumentiertes Schema, nicht ein nächtlicher CSV-Export. Auch DATEV-Schnittstellen brauchen ähnliche Disziplin.
3. Reporting-Felder schon mitführen
Felder, die ab 2030 für DRR relevant werden — saubere VAT-IDs, Ländercodes, Referenzen auf zugrundeliegende Bestellungen — kosten heute fast nichts und sparen 2029 ein Migrationsprojekt. „Was nicht erfasst ist, kann auch nicht gemeldet werden” gilt für DRR genauso wie für Buchhaltung.
Fazit
ViDA 2030 ist kein „Big Bang”, aber auch kein Nebenthema. Wer 2026 plant, hat zwei Optionen: alles ins ERP ziehen — und damit die regulatorische Bewegungsenergie in den eigenen Release-Zyklus zwingen. Oder einen E-Rechnungs-Layer vorschalten — und die Kernlogik freihalten.
Der Layer-Ansatz ist nicht nur architektonisch sauberer, er ist auch wirtschaftlich konservativer: Heute produktiv für alle aktuellen Pflichten, erweiterbar Richtung DRR, im Ernstfall austauschbar. Genau diese Rolle füllt Factora.
→ Factora API ansehen — separates technisches Angebot für produktive Integrationen.
Quellen:
- Europäische Kommission: Adoption of the VAT in the Digital Age package (11. März 2025)
- Europäische Kommission: VAT in the Digital Age (ViDA) — Übersicht
- vatcalc.com: EU 2030 Digital Reporting Requirements & E-Invoice Update
- Verband elektronische Rechnung (VeR): EN 16931 — Glossar
- E-Rechnung-Bund: E-Rechnung für ERP-Hersteller
Letzter Faktencheck: Mai 2026.
Häufig gestellte Fragen
Warum reicht eine ERP-Erweiterung für ViDA 2030 oft nicht aus?
Weil ViDA mehr ist als ein zusätzliches Rechnungsformat. Ein Bestands-ERP muss nicht nur EN-16931-konforme Strukturen erzeugen, sondern auch Validierung, Format-Routing (XRechnung, ZUGFeRD, UBL/Peppol BIS Billing), Archivierung und perspektivisch das Digital-Reporting an Steuerbehörden bedienen. Diese Logik in die ERP-Kernfunktion zu zwingen, erhöht Wartungslast und Lieferzeiten — ein vorgelagerter Layer trennt diese Concerns sauber.
Was ist ein E-Rechnungs-Layer im ViDA-Kontext?
Ein E-Rechnungs-Layer ist eine eigenständige Komponente zwischen ERP und externen Empfängern bzw. Reporting-Endpunkten. Er nimmt die Rechnungsdaten aus dem ERP entgegen, modelliert sie EN-16931-konform, erzeugt das passende Format (XRechnung, ZUGFeRD, UBL für Peppol) und übernimmt Validierung sowie Versand. Für ViDA-DRR ist er der Punkt, an dem strukturierte Daten in die Reporting-Kette einlaufen.
Welche Termine bei ViDA sind für ERP-Architekturen wirklich relevant?
Zentral ist der 1. Juli 2030: Ab dann sollen die Digital Reporting Requirements für grenzüberschreitende B2B-Umsätze in der EU greifen. Bis Januar 2035 sollen bestehende nationale Echtzeit-Reporting-Systeme an EU-Standards angeglichen werden. Wer heute baut, sollte beide Stufen architektonisch mitdenken — ohne 2026 schon eine vollständige ViDA-Konformität zu versprechen.
Kann Factora als Layer in bestehende ERP-Systeme integriert werden?
Ja. Factora ist als E-Rechnungs-Infrastruktur konzipiert und über eine REST-API ansprechbar. ERP-, Plattform- oder Branchensoftware-Hersteller übergeben strukturierte Rechnungsdaten und erhalten validierte XRechnung- bzw. ZUGFeRD-Dateien zurück, ohne eigene EN-16931-Logik aufzubauen. Details dazu auf der Seite zur [Factora API](/api/).