Kurz gesagt: XRechnung ist ein XML-Standard für E-Rechnungen in Deutschland. Seit Januar 2025 müssen Unternehmen E-Rechnungen empfangen können. Ab Januar 2027 wird auch die Rechnungserstellung verpflichtend. In Delphi lässt sich XRechnung durch strukturiertes Datenmodell-Mapping, validierte XML-Erzeugung, GoBD-konforme Archivierung und integrierte Fehlerbehandlung umsetzen.
Der direkte Fahrplan:
Nach diesem Guide kannst du:
Dieser Guide richtet sich an Finance-Leiter, CFOs, IT-Verantwortliche und Delphi-Entwickler, die Rechnungsprozesse digitalisieren oder bestehende Delphi-Anwendungen um XRechnung-Funktionalität erweitern müssen. Du solltest grundlegende Kenntnisse in Datenmodellierung und Geschäftsprozessen haben. Typische Ausgangssituationen: Du hast ein bestehendes Rechnungssystem in Delphi und musst es XRechnung- und GoBD-konform machen, oder du baust eine neue Lösung für Rechnungserstellung mit integrierten Kontrollen und Archivierung. Voraussetzungen: Delphi-Entwicklungsumgebung, Zugriff auf Rechnungsdaten, Grundverständnis von XML und Geschäftsprozessen, Vertrautheit mit Datenbanken oder ERP-Systemen. Was dieser Guide bewusst nicht abdeckt: Wir konzentrieren uns auf die deutsche XRechnung und nicht auf internationale Varianten. Der Guide behandelt nicht die vollständige Verwaltung von Rechnungsportalen oder die Anbindung an öffentliche Plattformen – nur die technische Erzeugung, Validierung und GoBD-konforme Archivierung.
XRechnung ist ein strukturierter, XML-basierter Rechnungsstandard auf Basis der europäischen Norm EN 16931, konkretisiert für Deutschland. Seit Januar 2025 müssen Unternehmen E-Rechnungen empfangen und verarbeiten können. Ab Januar 2027 wird die Pflicht zur Rechnungserstellung hinzukommen – das gilt für B2B-Rechnungen zwischen Unternehmern. Ein häufiger Fehler ist die Annahme, dass korrektes XML automatisch eine gültige XRechnung bedeutet. Tatsächlich musst du syntaktische Regeln (UN/CEFACT CII oder UBL) und fachliche Regeln (EN 16931) einhalten. Aus Compliance-Sicht ist auch entscheidend: Jede Rechnung muss unveränderbar archiviert, Validierungsergebnisse und Fehler müssen protokolliert und Verantwortlichkeiten müssen dokumentiert werden – das ist eine GoBD-Anforderung und schützt vor Audit-Risiken. Wenn deine Rechnungsdaten in der Quelle unvollständig sind, wird die XRechnung fehlerhaft und die Fehlerbehandlung wird aufwändig. Eine frühe Prüfung und Bereinigung der Datenquellen spart später viel Aufwand. Für die Einordnung in die E-Rechnung-Beratung ist vor allem wichtig, dass Fachlichkeit, Technik und Compliance gemeinsam betrachtet werden.
Bevor du mit der Implementierung startest, musst du klar machen, welche Daten du hast und welche du brauchst. XRechnung benötigt eine Reihe von Pflichtfeldern. Gleichzeitig musst du dokumentieren, wer für Datenqualität verantwortlich ist – das ist ein Kontrollpunkt. Prüfe, ob deine Rechnungsdaten in einer Datenbank, einem ERP-System oder einer anderen Quelle vorliegen und wie du darauf zugreifen kannst.
Kontrollpunkt: Du solltest eine Liste haben, die zeigt: Quelle → Zielfeld in XRechnung → Pflichtfeld ja/nein → Datentyp und Format → Validierungsregel. Wenn kritische Felder fehlen, muss das jetzt geklärt werden. Dokumentiere auch, welche Stammdaten (Verkäufer, Käufer, Steuersätze) aktuell sind und wer diese verwaltet.
Das Mapping ist das Herzstück deiner Lösung. Es übersetzt deine Geschäftsdaten in die XRechnung-Struktur. Gleichzeitig definierst du, welche Kontrollen vor Erzeugung laufen – das ist Compliance-Anforderung. Erstelle eine Mapping-Tabelle mit folgenden Spalten: XRechnung-Feldname (BT-Code), Datentyp, Quelle im System, Transformationsregel, Validierungsregel, Verantwortlicher.
| XRechnung-Feld (BT-Code) | Datentyp | Quelle | Transformationsregel | Validierungsregel |
|---|---|---|---|---|
| BT-1 Rechnungsnummer | String | tblRechnungen.RechnungsNr | 1:1 Übernahme, max. 20 Zeichen | Pflichtfeld, nicht leer |
| BT-2 Rechnungsdatum | Date | tblRechnungen.Datum | Format: YYYY-MM-DD | Pflichtfeld, nicht in Zukunft |
| BT-106 Positionsbetrag | Decimal(15,2) | tblPositionen.Betrag | Auf 2 Dezimalstellen runden | Muss >= 0 sein |
| BT-10 Leitweg-ID | String | tblKäufer.LeitwegID | Nur bei öffentlichen Auftraggebern | Format prüfen, falls vorhanden |
Definiere für Dezimalzahlen die zulässigen Nachkommastellen: Preise dürfen 3 Stellen haben, Summen nur 2. Dokumentiere Steuerlogik: Welche Steuersätze sind zulässig? Gibt es Sonderfälle wie Kleinunternehmerregelung? Definiere Kontrollpunkte vor Freigabe: Sind alle Pflichtfelder gesetzt? Sind Summen konsistent? Sind Kennungen korrekt? Lege fest: 4-Augen-Prinzip für kritische Rechnungen ja/nein? Wer prüft? Wie wird das dokumentiert?
Merke: Kontrollpunkte sind nicht optional – sie sind eine GoBD-Anforderung und schützen vor Audit-Risiken. Dokumentiere, wer für welche Prüfung verantwortlich ist und wie Abweichungen behandelt werden.
Deine Lösung sollte modular aufgebaut sein: Datenquelle → Transformation → Validierung → XML-Erzeugung → Archivierung. So bleibt alles wartbar, prüfbar und audit-sicher. Definiere eine Datenzugriffs-Schicht: Eine Unit oder Klasse, die Rechnungsdaten aus deiner Quelle lädt und Datenqualität prüft. Erstelle eine Transformationsschicht: Eine Klasse, die Rohdaten in ein XRechnung-konformes Datenmodell überführt und Kontrollpunkte prüft. Implementiere eine Validierungsschicht vor XML-Erzeugung: Prüfe Pflichtfelder, Datentypen, Regeln und Konsistenz.
Aus Erfahrung: Viele Unternehmen unterschätzen den Aufwand für Fehlerbehandlung und Nachvollziehbarkeit. Wenn eine Rechnung fehlerhaft ist, muss klar sein: Was ist der Fehler? Wer hat ihn verursacht? Wie wird er behoben? Das muss protokolliert sein – für Audit und für Betriebsprozesse. Die Aufwandsabschätzung für ein solches System liegt typischerweise bei 40-60 Personentagen Entwicklung, abhängig von Komplexität und Integrationstiefen.
Jetzt wird es konkret: Du erzeugst aus deinen Daten das XML und validierst es. Fehlerhafte Rechnungen müssen in eine Quarantäne-Queue, damit sie nicht versehentlich versendet werden. Wenn du eine DLL nutzt: Importiere die COM-Komponente in Delphi, erstelle eine Instanz, fülle die Eigenschaften mit deinen Daten und rufe die Export-Methode auf. Wenn du eigenes XML schreibst: Nutze Delphi-XML-Komponenten (TXMLDocument) und baue die Struktur nach EN 16931 auf.
Achtung: Die interne Validierung prüft nur Syntax und Format. Die fachliche Korrektheit (z. B. ob Steuersätze für das Land korrekt sind) musst du selbst sicherstellen. Ein XML kann syntaktisch perfekt sein, aber inhaltlich falsch. Für den Produktivbetrieb ist außerdem ein XRechnung Validator sinnvoll, damit fachliche Fehler früh auffallen.
Compliance und Kontrolle sind zentral. Du musst definieren, wer Rechnungen freigibt, wie Fehler behandelt werden und wie alles protokolliert wird – das ist GoBD-Anforderung. Definiere einen Freigabeprozess: Wer prüft Rechnungen vor Erzeugung? Gibt es ein 4-Augen-Prinzip für große Beträge oder öffentliche Auftraggeber? Implementiere ein Audit-Trail: Jede Aktion (Erzeugung, Validierung, Freigabe, Export, Fehler) wird mit Benutzer, Zeitstempel, Status und Details protokolliert.
Praxis-Tipp: Ein einfaches Audit-Trail-System reicht oft aus: Eine Tabelle mit Rechnungsnummer, Aktion (erzeugt, validiert, freigegeben, fehlerhaft), Benutzer, Zeitstempel, Status und Fehlertext. Das ist GoBD-konform und hilft später bei Audit-Fragen. Für Betrieb und Monitoring solltest du 2-4 Personentage pro Monat einplanen.
Rechnungen müssen unveränderbar und nachvollziehbar archiviert werden – das ist Steuerrecht (GoBD). Du musst sicherstellen, dass Rechnungen und Validierungsergebnisse nicht verändert werden können und dass die Archivierung dokumentiert ist. Speichere jede erzeugte Rechnung (XML) in einem Archiv-System mit Zeitstempel und Hashwert (z. B. SHA-256) zur Integritätsprüfung. Speichere auch Validierungsergebnisse und Fehlerprotokolle mit jeder Rechnung – das ist Nachweis für Compliance.
Merke: GoBD-Konformität ist nicht optional – es ist Steuerrecht. Wenn du Rechnungen nicht korrekt archivierst und nachvollziehbar dokumentierst, riskierst du Audit-Vorwürfe und Bußgelder. Eine einfache Dateiablage reicht nicht aus – du brauchst Metadaten, Zeitstempel und Integritätsprüfung. Der Aufwand für eine vollständig GoBD-konforme Archivierungslösung liegt bei 60-100 Personentagen, abhängig von Skalierung und Infrastruktur-Integration. Wer die Prozesse sauber aufsetzen will, sollte frühzeitig eine E-Rechnung-Roadmap definieren.
Die Lösung muss in deine bestehenden Prozesse passen: P2P (Procurement-to-Pay) oder O2C (Order-to-Cash). Gleichzeitig brauchst du Monitoring, um Fehler früh zu erkennen. Definiere, wann Rechnungen erzeugt werden: Nach Freigabe? Nach Versand? Automatisch in der Nacht? Entscheide, ob die Lösung mit oder ohne UI läuft: Backend-Jobs brauchen keine Oberfläche, manueller Export schon. Richte Fehlerbehandlung ein: Wenn eine Rechnung fehlerhaft ist, soll sie in eine Quarantäne-Queue, damit jemand sie prüfen und korrigieren kann.
Kontrollpunkt: Dein Monitoring sollte Probleme früh erkennen und Prozesse optimieren. Typische Testaufwände liegen bei 30-50 Personentagen für Unit-Tests, Integrationstests und Abnahmetests mit realen Sonderfällen.
Stellen wir uns ein Unternehmen vor, das Rechnungen in einem Delphi-basierten ERP-System verwaltet. Die Rechnungsdaten liegen in einer SQL-Datenbank vor: Rechnungsnummer, Datum, Positionen mit Preisen und Steuern, Käufer- und Verkäuferinformationen, Leitweg-ID für öffentliche Auftraggeber. Der Prozess: Ein Sachbearbeiter klickt auf einen Button „XRechnung erzeugen". Das System lädt die Rechnungsdaten, prüft Datenqualität (Pflichtfelder, Summen-Konsistenz, Stammdaten). Wenn alles ok ist, wird die Rechnung transformiert und validiert. Wenn die Validierung erfolgreich ist, wird das XML erzeugt, mit Hashwert versehen und in das Archiv gespeichert. Die Rechnung wird als „bereit zum Versand" markiert. Alle Aktionen werden im Audit-Trail protokolliert: Benutzer, Zeitstempel, Status, Validierungsergebnis. Wenn Fehler auftreten (z. B. fehlende Leitweg-ID für einen öffentlichen Auftraggeber), wird die Rechnung in eine Fehler-Queue verschoben. Der Fehler wird kategorisiert und protokolliert. Ein Verantwortlicher wird benachrichtigt mit konkretem Hinweis: „Rechnungsnummer 12345: Käufer ist öffentlicher Auftraggeber, aber Leitweg-ID fehlt. Bitte ergänzen und erneut versuchen." Der Sachbearbeiter korrigiert die Daten und startet die Erzeugung erneut. Der Fehler wird im Audit-Trail dokumentiert. Nach 30 Tagen generiert das System einen Compliance-Report: 1.000 Rechnungen erzeugt, 98% erfolgreich validiert, 2% in Fehler-Queue, durchschnittliche Bearbeitungszeit 2 Minuten, Fehler nach Kategorie: 15 Datenqualität, 5 Validierung.
Statt manuell Rechnungen zu erzeugen, kannst du einen automatisierten Job einrichten, der nachts oder stündlich alle neuen Rechnungen verarbeitet. Der Job lädt alle Rechnungen mit Status „bereit zum Export", erzeugt XMLs, validiert sie, archiviert sie und exportiert sie automatisch. Fehlerhafte Rechnungen landen in einer Queue für manuelle Nachbearbeitung. Wenn die Fehlerquote einen Schwellwert überschreitet, wird ein Alert gesendet. Typische Implementierungsdauer: 20-30 Personentage. Für größere Organisationen mit vielen Schnittstellen ist oft eine E-Rechnung-Beratung sinnvoll, um Architektur und Betriebsmodell sauber zu definieren.
Wenn du zusätzlich zu reinem XML auch sichtbare PDFs mit eingebettetem XML brauchst, kannst du die XML in PDF/A-3 einbetten. Das erfordert zusätzliche Tools, bietet aber Vorteile: Empfänger sehen ein lesbares PDF, Systeme können die strukturierten Daten auslesen. Die Archivierung wird einfacher, weil eine Datei alle Informationen enthält. Aufwand: 30-40 Personentage.
Wenn du später auch in Österreich (ebInterface) oder anderen EU-Ländern arbeiten musst, brauchst du zusätzliche Standards. Eine modulare Architektur ermöglicht es dir, weitere Format-Module hinzuzufügen, ohne die Kern-Logik zu verändern. Das spart Entwicklungsaufwand und reduziert Fehlerrisiken. Aufwand pro Standard: 40-60 Personentage. Wer perspektivisch auch andere Zahlungs- und Rechnungsprozesse anbinden will, sollte den Kontext von Request to Pay und ähnlichen Standards mitdenken.
Nein. XRechnung folgt strengen Regeln (EN 16931 und Syntaxbindungen). Dein eigenes XML-Format ist wahrscheinlich nicht kompatibel. Du musst deine Daten in die XRechnung-Struktur transformieren und validieren – mit Kontrollpunkten und Fehlerbehandlung.
Beides ist möglich. Mit einer DLL sparst du Entwicklungszeit und bekommst Unterstützung. Selbst programmieren ist günstiger, erfordert aber tieferes Verständnis von EN 16931 und XML. Für kleinere Projekte kann Selbstprogrammierung sinnvoll sein. Berücksichtige Wartungsaufwand und Testaufwand bei der Entscheidung.
GoBD (Grundsätze ordnungsmäßiger Buchführung) ist deutsches Steuerrecht. Es verlangt, dass Rechnungen unveränderbar archiviert, Validierungsergebnisse dokumentiert und Verantwortlichkeiten nachvollziehbar sind. Wenn du das nicht einhältst, riskierst du Audit-Vorwürfe und Bußgelder. GoBD ist nicht optional – es ist eine Compliance-Anforderung.
Für Steuer- und Compliance-Gründe sollten Rechnungen mindestens 10 Jahre aufbewahrt werden. Das gilt für das XML, Validierungsergebnisse und Fehlerprotokolle. Dein System sollte eine dokumentierte Archivierungsstrategie haben – mit Speicherort, Backup, Zugriffskontrolle und Integritätsprüfung.
Leitweg-IDs sind eindeutige Kennungen für öffentliche Auftraggeber in Deutschland. Wenn du an eine Behörde rechnest, musst du die Leitweg-ID in das Feld BT-10 (Buyer Reference) eintragen. Diese wird dir vom Auftraggeber mitgeteilt. Wenn du die Leitweg-ID vergisst, wird die Rechnung von der Behörde abgelehnt.
Du brauchst zwei Ebenen von Validierung: Interne Validierung (Pflichtfelder, Datentypen, Regeln) und externe Validierung (KoSIT-Validator). Die interne Validierung prüft Syntax und Format. Die externe Validierung prüft auch fachliche Korrektheit. Speichere beide Validierungsergebnisse im Audit-Trail – das ist ein Nachweis für Compliance.
Nächster Schritt: Starten Sie mit Schritt 1 dieser Anleitung: Prüfen Sie Ihre Datenquellen und dokumentieren Sie Pflichtfelder. Danach erstellen Sie die Mapping-Tabelle mit Kontrollpunkten und Verantwortlichkeiten – das ist die Grundlage für alles Weitere. Wenn diese Basis steht, wird die Implementierung deutlich klarer und fehleranfälliger. Definieren Sie auch früh, wer für Datenqualität, Freigabe und Fehlerbehandlung verantwortlich ist – das ist eine Compliance-Anforderung und schützt vor Audit-Risiken.