E-Rechnung, XRechnung und ZUGFeRD verständlich einordnen.

Wenn Sie nur fünf Minuten haben, nutzen Sie diese Checkliste:

• Klären, ob Sie E-Rechnungen im B2B/B2G benötigen (und welche Übergangs-/Ausnahmeregeln gelten).
• Ein Format wählen, das EN 16931 erfüllt: häufig XRechnung oder ZUGFeRD (Profil XRECHNUNG).
• Stammdaten sauber pflegen (Adresse, USt-ID, IBAN, Ansprechpartner) – das vermeidet 80% der Validierungsfehler.
• XML erzeugen + validieren, bevor Sie versenden (Validator = „TÜV“ für die Datei).
• Lesbarkeit sichern: Eingehende XML-Rechnungen benötigen Sie in einer Viewer-Ansicht (HTML-Visualisierung).

SPRechnung ist ein lokales Windows-Tool, das genau diesen Ablauf lokal/offline abbildet: Stammdaten → Dokument → XRechnung → KoSIT-Validierung → Viewer für eingehende XRechnungen.

Was ist eine E-Rechnung – und was ist sie nicht?

Viele sagen „E-Rechnung“ und meinen „PDF per E-Mail“. Das ist verständlich – aber seit 2025 ist die Begrifflichkeit deutlich schärfer:

• E-Rechnung: Rechnung in strukturiertem elektronischem Format, das elektronische Verarbeitung ermöglicht.
• PDF: Ein normales PDF ist (seit 2025) keine E-Rechnung, sondern eine „sonstige Rechnung“.
• Hybridformate (z. B. ZUGFeRD): Kombination aus PDF-Ansicht + strukturiertem Datenteil; maßgeblich sind die strukturierten Daten.

XRechnung als Standard: wofür genutzt, wer braucht es?

XRechnung ist ein EN-16931-konformes Format, das in Deutschland besonders verbreitet ist – historisch stark im Kontext öffentlicher Auftraggeber (B2G).
Wichtig für Einsteiger: XRechnung ist nicht „nur für Behörden“. Sie können XRechnung auch im B2B nutzen, wenn Ihr Empfänger das akzeptiert (und viele Systeme tun das).

Typische Stolperfallen (Praxis)

Die meisten „rot“-Validierungen entstehen nicht durch exotische Sonderfälle, sondern durch Klassiker:

• Buyer Reference / Leitweg-ID: Im B2G häufig Pflicht; im B2B oft nicht erforderlich – aber Felder dürfen nicht „leer“/inkonsistent werden.
• Parteien / Rollen: Verkäufer, Käufer, Payee, Delivery müssen sauber abgebildet sein (sonst Folgefehler in Validierung/Steuern).
• Steuern & Summenlogik: Steuerkategorie, Steuersatz, Netto-/Brutto-Summen, Rabatte/Zuschläge müssen rechnerisch zusammenpassen.
• Pflichtangaben: Ein fehlendes Pflichtfeld reicht für „rot“, auch wenn Ihr PDF „gut aussieht“.
• Aufbewahrung (GoBD-Kontext): Der strukturierte Datenteil muss unverändert aufbewahrt werden (Nachvollziehbarkeit/Unveränderbarkeit).

„So lösen wir’s in SPRechnung“

SPRechnung führt Sie strukturiert durch die Eingaben, erzeugt die XRechnung lokal und ermöglicht die Prüfung, bevor Sie versenden.

• Lokal-first: Kein Upload Ihrer Daten „nur fürs Erstellen/Prüfen“.

Dieses Kapitel ist für absolute Neueinsteiger gedacht – als „Übersetzer“ für die wichtigsten Begriffe.

2.1 EN 16931 – warum dieser Begriff überall auftaucht

EN 16931 ist die europäische Norm für den Kerninhalt einer elektronischen Rechnung. Wenn ein Format EN 16931 erfüllt, kann es grundsätzlich als E-Rechnung im Sinne der gesetzlichen Vorgaben dienen (je nach Kontext/Übergangsregelungen).
Praxis: Viele Anbieter werben mit „EN-16931-konform“. Das ist ein gutes Signal, ersetzt aber keine Validierung.

2.2 XRechnung – was ist das genau?

XRechnung ist ein deutscher Standard, der auf EN 16931 basiert (CIUS-Ausprägung).
Wichtig für die Praxis:
XRechnung ist rein strukturiert (XML) – kein „sichtbares PDF“ ist automatisch enthalten.
XRechnung gibt es in zwei technischen Syntax-Varianten:

• UBL 2.1 (Universal Business Language)
• UN/CEFACT CII (Cross Industry Invoice)

Für Sie als Anwender ist weniger wichtig, welche Syntax es ist – wichtiger ist: Die Datei muss valide sein und beim Empfänger korrekt verarbeitet werden.

2.3 ZUGFeRD / Factur-X – kurz erklärt (Hybridformat)

ZUGFeRD kombiniert eine PDF-Ansicht mit einem eingebetteten strukturierten Datenteil. Je nach Profil kann ZUGFeRD EN-16931 erfüllen. Für Einsteiger ist das attraktiv, weil man „PDF + Daten“ hat.
Wichtig: Nicht jedes ZUGFeRD-Profil ist automatisch eine „vollwertige E-Rechnung“ im jeweiligen Kontext. Für B2G wird häufig das Profil XRECHNUNG genannt.

2.4 Leitweg-ID vs. Buyer Reference – was ist der Unterschied?

Leitweg-ID: Behördenspezifische Routing-ID im B2G-Umfeld.
Buyer Reference (Käuferreferenz): Referenzfeld, das je nach Empfängerprozess genutzt wird (B2G oft Pflicht / B2B abhängig vom Empfänger).
Einsteiger-Tipp: Wenn Sie B2B starten, klären Sie mit Ihrem Kunden, ob dieser eine Buyer Reference erwartet (z. B. Bestellnummer/Kostenstelle).

2.5 „B2G, B2B, B2C“ – und warum das für E-Rechnung entscheidend ist

B2G: Unternehmen → öffentliche Hand (Behörden). Oft sind konkrete Vorgaben (Portale, Leitweg-ID) zu erfüllen.
B2B: Unternehmen → Unternehmen. Hier wird E-Rechnung ebenfalls relevant (Pflicht/Übergänge), aber die Umsetzung ist oft flexibler.
B2C: Unternehmen → Privatkunden. Hier gelten i. d. R. andere Regeln.
Praxis: Viele Firmen fangen im B2B an (weil es absehbar Pflicht wird/ist) – und nutzen XRechnung bewusst, um eine stabile, maschinenlesbare Basis zu haben.

2.6 Weitere Begriffe, die Sie häufig sehen (Kurzglossar)

• Validator: Prüft XML gegen Schema/Schematron-Regeln und erstellt einen Prüfbericht.
• Schematron: Regelwerk für Business-Logik (z. B. Summen, Pflichtfelder abhängig vom Kontext).
• Schema/XSD: „Formprüfung“ der XML-Struktur.
• CIUS: „Country/Context-Specific Usage Specification“ – länderspezifische Ausprägung der EN 16931.
• Codelists: Erlaubte Wertelisten (z. B. Steuerkategoriecodes).
• Visualisierung/Viewer: Macht XML für Menschen lesbar (HTML-Ansicht).

Viele Einsteiger hören „KoSIT-Validator“ zum ersten Mal, wenn es bei der ersten XRechnung „rot“ wird. Dabei ist der Validator ein zentraler Erfolgsfaktor.

3.1 Was ist der KoSIT-Validator?

Der KoSIT-Validator ist eine Open-Source-Validierungs-Engine, die XML-Dokumente in verschiedenen Formaten prüfen kann. Vereinfacht gesagt macht er:

1. Format erkennen
2. XML-Struktur prüfen (Schema/XSD)
3. Business-Regeln prüfen (Schematron)
4. Prüfbericht erzeugen + Status ableiten

3.2 Validator vs. XRechnung-Konfiguration – warum es zwei Bausteine sind

In der Praxis gibt es zwei Teile:

• Validator (Engine): Das eigentliche Prüfwerkzeug.
• Validator-Konfiguration für XRechnung (Bundle/Config): Die Regeln/Artefakte speziell für XRechnung.

Merksatz: Der Validator ist das „Prüfgerät“, die Konfiguration ist der „Prüfplan“.

3.3 Warum Validierung unverzichtbar ist (auch im B2B)

• Vermeidet Zurückweisungen beim Empfänger (B2G sowieso, B2B zunehmend).
• Reduziert interne Nacharbeit („Warum stimmt die Steuer nicht?“).
• Gibt Ihnen Sicherheit, dass die XML-Rechnung maschinell korrekt verarbeitet werden kann.

3.4 Was bedeutet „grün“ in der Praxis?

„Grün“ heißt: Die XRechnung ist formal und regelbasiert konsistent, sodass eine technische Verarbeitung möglich ist.
„Gelb“ sind typischerweise Hinweise, „rot“ sind Fehler (Details siehe Kapitel 4).

3.5 SPRechnung-Bezug (kurz)

SPRechnung integriert die KoSIT-Prüfung im Tool (separater Tab), damit Sie XML nicht erst „irgendwo hochladen“ müssen. Das unterstützt Ihr Offline-/Datenschutz-Prinzip: Prüfen lokal, keine Datenabgabe nur fürs Validieren.

Wenn Sie nach „XRechnung prüfen“ suchen, sind Sie meist an der Stelle: XML erzeugt – Validator meckert.
Die gute Nachricht: Fehler lassen sich systematisch beheben, wenn Sie die Fehlerart richtig einordnen.

Bedeutung Prüfergebnis (grün/gelb/rot)

• Grün: Keine blockierenden Fehler – formal/regelbasiert konsistent.
• Gelb: Hinweise/Warnungen – oft sinnvoll zu korrigieren, aber nicht zwingend blockierend.
• Rot: Fehler – mindestens eine Regel ist verletzt (Pflichtfelder, Logik, CodeLists, Summen).

Fehlerkategorien (typisch)

• Pflichtfeld fehlt: leer oder falscher Kontext → „sofort rot“
• Format/CodeList: ungültige Werte, z. B. Steuerkategorie oder Datumsformat
• Rechenlogik: Summen/Steueraufschlüsselung passen nicht (häufig bei Rabatten/Zuschlägen)
• Kontextregeln: „Wenn A, dann muss B“ (z. B. bestimmte Angaben nur bei bestimmten Steuerfällen)

Vorgehen: schnell von rot zu grün

1. Fehler lesen: Regel-ID + Kurztext notieren.
2. Zuordnen: Welche Eingabe (Feld/Abschnitt) ist gemeint?
3. Korrigieren: logisch passenden Wert setzen (nicht raten).
4. Neu prüfen: nach jeder Änderung erneut validieren (nicht 20 Änderungen sammeln).
5. Mini-Checkliste: wiederkehrende Fehler als Team-Routine dokumentieren.

Lokal-first Hinweis: Validierung kann lokal erfolgen – ohne Upload sensibler Daten. Genau das ist für viele Unternehmen ein entscheidender Vertrauenspunkt.

Warum Bundles existieren

XRechnung entwickelt sich weiter. Damit Generator, Prüfung und Viewer korrekt bleiben, arbeiten professionelle Tools mit „Bundles“ – Paketen aus offiziellen Artefakten/Regeln für eine bestimmte Version.

Vorteile in der Praxis:

• Rechtssicherheit & Kompatibilität: Arbeiten gegen aktuelle/definierte Regeln.
• Reproduzierbarkeit: Nachvollziehbar, mit welcher Version erzeugt/geprüft wurde.
• Weniger Bauchgefühl: Offizielle Regeln statt „selbst zusammengestellte“ Prüfungen.

Manuell von offizieller Quelle laden

Offline-freundlich und kontrolliert: Das Bundle wird manuell von der offiziellen Quelle heruntergeladen (kein „stiller Download“ im Hintergrund).

Import / Aktivierung im Tool

Der typische Ablauf:

1. Bundle-ZIP herunterladen
2. Im Tool importieren
3. Bundle aktivieren
4. Das Tool stellt alle abhängigen Komponenten konsistent um

Automatische Umstellung (Generator / Prüfung / Viewer)

Mit der Aktivierung arbeitet SPRechnung durchgehend gegen das aktivierte Bundle – für:

• XML-Generierung
• KoSIT-Validierung
• Viewer/Visualisierung eingehender XRechnungen

Troubleshooting (kurz)

• Bundle wird nicht erkannt: Prüfen, ob es das offizielle ZIP ist (nicht „irgendwie neu verpackt“).
• Aktivierung klappt, aber Regeln fehlen: Bundle-Version & Tool-Version prüfen.
• Nach Update neue Fehler: Regeln wurden evtl. verschärft → Datenmodell entsprechend nachziehen.

„So lösen wir’s in SPRechnung“

Import und Aktivierung sind in SPRechnung bewusst einfach gehalten, damit Sie offline und kontrolliert auf dem offiziellen Stand bleiben können.

Was steckt in eingehenden XRechnungen?

XRechnungen sind XML-Dateien – maschinenlesbar, aber für Menschen oft unübersichtlich. Typische Inhalte:

• Rechnungsnummer, Datum, Zahlungsbedingungen
• Parteien (Verkäufer/Käufer inkl. IDs)
• Positionen (Menge, Preis, Rabatte/Zuschläge)
• Steuerdaten (Steuerkategorien, Steuersätze, VAT Breakdown)
• Anlagen (z. B. Leistungsnachweise, PDFs)

Welche Daten sind für Buchhaltung/Prüfung relevant?

Für die tägliche Praxis sind besonders wichtig:

• Korrekte Zuordnung (wer ist Käufer/Empfänger?)
• Zahlungsziel und Bankdaten
• Summen & Steueraufschlüsselung
• Plausibilität der Positionen

Warum HTML-Visualisierung hilft

Eine HTML-Visualisierung macht aus XML eine lesbare Darstellung:

• Schneller prüfen
• Intern weitergeben (Buchhaltung/Einkauf/Projektleitung)
• Weniger Fehlinterpretationen

In SPRechnung: Übersicht + Vollansicht

SPRechnung zeigt eingehende XRechnungen zweistufig:

1. Übersicht: der wichtigsten Daten
2. Vollansicht: (HTML Viewer) für Detailprüfung

Kurzidee: ZUGFeRD (auch im Kontext „Factur-X“) kombiniert ein menschenlesbares PDF mit eingebetteten XML-Rechnungsdaten. Dadurch ist die Rechnung sofort lesbar – und gleichzeitig maschinenverarbeitbar.

7.1 Was ist ZUGFeRD – und warum nutzen das so viele Unternehmen?

ZUGFeRD ist ein Hybrid-Rechnungsformat. Es steckt beides in einer einzigen Datei:

• Ein PDF/A-3 als Sichtbeleg (für Menschen)
• Eine XML-Struktur als Datenteil (für Systeme)

Für viele Unternehmen ist das in der Praxis sehr attraktiv:

• Der Empfänger kann die Rechnung ohne separaten Viewer sofort lesen (PDF).
• Buchhaltung und ERP-Systeme können trotzdem die strukturierten Daten nutzen (XML).
• Es gibt weniger Medienbrüche im Umstellungsprozess.

7.2 Gilt ZUGFeRD als „E-Rechnung“?

Nach den Vorgaben rund um die verpflichtende E-Rechnung gilt (vereinfacht):
ZUGFeRD kann ein zulässiges E-Rechnungsformat sein, wenn das Format auf der EN-16931 basiert (und die passenden Profile verwendet werden). In einem zentralen BMF-Schreiben wird dazu explizit genannt: ZUGFeRD ab Version 2.0.1 – ausgenommen die Profile MINIMUM und BASIC-WL – beruht auf EN 16931 und fällt damit unter zulässige E-Rechnungsformate.
Zusätzlich ist die BMF-FAQ zur E-Rechnung die maßgebliche Einstiegsquelle für Einordnung und Praxisfragen.

7.3 ZUGFeRD vs. XRechnung – was ist der Unterschied?

• XRechnung ist im Alltag häufig das „klassische“ XML-Format (ohne PDF-Sichtbeleg).
• ZUGFeRD liefert den PDF-Beleg direkt mit (plus XML-Datenteil).

Wichtig für die Praxis: Für öffentliche Auftraggeber (B2G) wird teils explizit auch das ZUGFeRD-Profil „XRECHNUNG“ genannt/akzeptiert (je nach Einreichweg/Plattform). Für B2B ist entscheidend: EN-16931-konforme Daten und Abstimmung mit dem Empfänger.

7.4 Profile – warum das relevant ist (ohne Technik-Overload)

Bei ZUGFeRD gibt es unterschiedliche „Profile“ (z. B. einfache bis sehr ausführliche Datentiefe). Für die E-Rechnung-Einordnung ist wichtig, dass nicht jedes Profil automatisch als E-Rechnung im Sinne der Vorgaben gilt. Das BMF-Schreiben nennt hier explizit Einschränkungen (MINIMUM und BASIC-WL ausgenommen).

7.5 Prüfen/Validieren: Was wird bei ZUGFeRD eigentlich geprüft?

Auch bei ZUGFeRD gilt: Entscheidend ist nicht „ob ein PDF da ist“, sondern ob die eingebetteten strukturierten Daten regelkonform sind. In der Praxis heißt das: man prüft den XML-Datenteil (und je nach Umfeld zusätzlich formale Anforderungen).

Ziel dieses Kapitels: In 3 Minuten Klarheit: Muss ich E-Rechnungen empfangen? Muss ich sie schon senden? Welche Ausnahmen/Übergänge gibt es?
Primärquelle: BMF (FAQ „E-Rechnung“, laufend gepflegt): BMF FAQ E-Rechnung.

8.1 Empfang vs. Versand – zwei unterschiedliche Pflichten (wichtig!)

Viele verwechseln „E-Rechnungspflicht“ mit „ich muss sofort E-Rechnungen versenden“. In der Praxis gibt es zwei Perspektiven:

• Empfang: Unternehmen müssen technisch in der Lage sein, E-Rechnungen zu empfangen (z. B. per E-Mail/Datei) und revisionssicher aufzubewahren.
• Versand (Ausgangsrechnungen): Hier greifen Übergangsregelungen; in vielen Fällen dürfen bis zu einem Stichtag weiterhin „sonstige Rechnungen“ (z. B. PDF) genutzt werden – abhängig vom Szenario.

➡️ Merksatz: Empfangsfähig sein ist der erste Schritt. Versand wird stufenweise verpflichtend.

8.2 Schnell-Entscheidung (B2B / B2G / B2C)

A) Rechnungen an Privatpersonen (B2C)

• Häufig nicht das Kernziel der B2B-E-Rechnungspflicht.
• Trotzdem lohnt sich eine Standardisierung intern (Prozess/Archiv).

B) Rechnungen zwischen Unternehmen in Deutschland (B2B, inländisch)

• Sie solltest E-Rechnungen empfangen können.
• Für den Versand gelten Übergänge/Ausnahmen – Details immer offiziell beim BMF prüfen.

C) Rechnungen an öffentliche Auftraggeber (B2G)

• Hier ist XRechnung in der Praxis meist Standard.
• Häufig relevant: Buyer Reference / Leitweg-ID und je nach Empfänger auch spezifische Einreichwege.

8.3 Typische Ausnahmen

Je nach Fall gibt es Ausnahmen/Erleichterungen, zum Beispiel für Kleinbetragsrechnungen (bis 250 EUR), bestimmte steuerfreie Umsätze und einzelne Sonderfälle. Bitte prüfen Sie dies immer in den offiziellen Quellen.

8.4 Was Sie „wirklich“ brauchen (Einsteiger-Toolset)

Wenn Sie E-Rechnungen in Ihrem Unternehmen bisher nicht gebraucht haben, reichen für den Start vier Bausteine:

1. Empfangen: (Datei/Anhang) + saubere Ablage
2. Lesbar machen: (Viewer/Visualisierung)
3. Validieren: (prüfen, ob es technisch/regelkonform ist)
4. Archivieren: (Original + strukturierte Daten langfristig nachvollziehbar)

8.5 So löst SPRechnung das

SPRechnung ist ein lokales Windows-Tool: Sie erstellen Dokumente (PDF) und können E-Rechnungen (z. B. XRechnung) strukturkonform erzeugen und lokal prüfen – ohne Cloud-Upload. Offizielle Artefakte (Bundles/Regeln/Viewer-Komponenten) werden manuell von der offiziellen Quelle bezogen und im Tool aktiviert. Eingehende E-Rechnungen werden im Viewer verständlich dargestellt, sodass Sie ohne XML-Stress prüfen können.

Ziel dieses Kapitels: Neueinsteiger verstehen die Begriffe so, dass sie Entscheidungen treffen können (ohne XML/IT-Studium).
Primärquellen: BMF (FAQ E-Rechnung), e-Rechnung Bund (FAQ, Praxisbezug z. B. Leitweg-ID).

9.1 Was ist eine „E-Rechnung“ – und warum reicht ein PDF nicht?

Im steuerlichen Kontext wird unterschieden:

• E-Rechnung: strukturiertes elektronisches Format, das eine automatische und elektronische Verarbeitung ermöglicht.
• „Sonstige Rechnung“: Papier oder unstrukturiertes elektronisches Format (z. B. ein normales PDF per E-Mail).

➡️ Für die genaue steuerliche Einordnung/Definition ziehen Sie bitte immer die offiziellen Veröffentlichungen des BMF heran.

9.2 XRechnung – was genau ist das?

XRechnung ist ein in Deutschland weit verbreiteter Standard für E-Rechnungen. Er bildet die Anforderungen der europäischen Norm EN 16931 ab (als Profil/CIUS im jeweiligen Regelwerk).
Wichtig: XRechnung ist nicht nur „für Behörden“. Sie können XRechnung auch im B2B einsetzen, wenn Sender und Empfänger das Format akzeptieren – für viele Unternehmen ist das der robusteste Weg zu prüfbaren, sauberen Rechnungsdaten.

9.3 ZUGFeRD (Hybridformat) – kurz erklärt

ZUGFeRD steht für ein Hybridformat (typischerweise PDF/A-3 mit eingebetteten strukturierten XML-Daten).
Wichtig: Ob es als E-Rechnung gilt, hängt davon ab, ob die strukturierten Daten den Anforderungen entsprechen (BMF-FAQ).

9.4 UBL vs. CII – „Syntax“, nicht „Inhalt“

Zwei häufige XML-„Schreibweisen“ (Syntaxen):

• UBL (Universal Business Language)
• CII (Cross Industry Invoice)

Beide können im XRechnung-Kontext vorkommen. Entscheidend ist nicht die Syntax, sondern dass das Dokument im Zielprofil valide ist.

9.5 Leitweg-ID vs. Buyer Reference (warum es oft verwechselt wird)

• Leitweg-ID: Eindeutiges Adressierungsmerkmal in der öffentlichen Verwaltung (B2G-Kontext).
• Buyer Reference: Referenzfeld, das je nach Prozess gefordert sein kann (auch außerhalb B2G).

9.6 Mini-Glossar

Begriff	Bedeutet	Warum wichtig?
E-Rechnung	Strukturierte, maschinenlesbare Rechnung	Prozessgrundlage für die automatisierte Verarbeitung.
XRechnung	Deutsches Profil/Standard (EN-16931-konform)	Häufig im B2G-Bereich gefordert, aber auch im B2B nutzbar.
ZUGFeRD	Hybrid (PDF + strukturierte XML-Daten)	Menschenlesbar und gleichzeitig maschinenlesbar.
EN 16931	EU-Norm für Rechnungsdaten	Die gemeinsame europäische Basis vieler E-Rechnungsformate.
UBL / CII	XML-Syntaxen („Schreibweisen“)	Technische Ausprägungen des XML. Der Inhalt muss passen.
KoSIT	Koordinierungsstelle für IT-Standards	Verantwortlich für das XRechnungs- und Validator-Ökosystem.
Validator	Technisches Prüfwerkzeug	Liefert das technische Prüfergebnis (grün/gelb/rot).
Bundle	Offizielle Artefakt-Pakete	Sichert die update-sichere Einhaltung aktueller Versionen.

Ziel dieses Kapitels: „Was ist KoSIT, was ist der Validator, was wird da geprüft – und wie gehe ich bei Fehlern vor?“
Primärquellen: KoSIT Validator (Engine) und XRechnung-Konfiguration auf GitHub.

10.1 Was ist der KoSIT-Validator – in einem Satz?

Der KoSIT-Validator ist ein offizielles Prüfwerkzeug, das XML-Dokumente anhand von Schemata (XSD) und Geschäftsregeln (Schematron) validiert – z. B. für XRechnung.

10.2 Engine vs. Konfiguration – warum Sie beides brauchen

• Validator (Engine): Das eigentliche Programm, das die Prüfung durchführt.
• Validator-Konfiguration: Das Regel- und Artefaktpaket, welches festlegt, welche Kriterien und Regeln für das jeweilige Zielprofil gelten.

➡️ Praxis: Wenn Sie nur die Engine haben, aber nicht die passende Konfiguration, prüfen Sie am Ziel vorbei.

10.3 Was bedeutet „grün / gelb / rot“ wirklich?

• Grün: Keine blockierenden Fehler gefunden. Die Rechnung erfüllt alle formalen Anforderungen.
• Gelb: Warnungen oder fachliche Hinweise. Oft sinnvoll zu beheben, führen aber nicht zur direkten Zurückweisung.
• Rot: Mindestens eine Regel wurde verletzt (Pflichtfelder fehlen, falsche Codes, Summenfehler). Die Datei ist ungültig.

10.4 So liest Sie einen Report (ohne Frust)

1. Fehler-ID notieren: Notiere die ID (z. B. BR-CO-04 für Rundungsdifferenzen).
2. Kurztext verstehen: Was wird gefordert (z. B. „Die Summe der Zeilenbeträge muss gleich dem Gesamtnetto sein“)?
3. Business Terms (BT) identifizieren: Welche Felder (z. B. BT-110) sind betroffen?
4. Im Tool korrigieren: Das entsprechende Eingabefeld suchen und den Wert anpassen.
5. Erneut prüfen: Direkt nach der Änderung neu validieren (in kleinen Schritten vorgehen).

Typische Fehlerklassen: Fehlende Pflichtfelder, falsche Ländercodes oder Steuercodes, Rechenlogik-Fehler bei Rabatten sowie bedingte Kontextregeln.

10.5 Offline/Lokal-first & Datenschutz

Die Validierung kann vollständig lokal auf Ihrem PC stattfinden. Es müssen keine Rechnungsdaten im Internet hochgeladen werden.

10.6 SPRechnung-Nutzen

SPRechnung führt Sie von der Datenerfassung über die XML-Erzeugung bis zur lokalen Validierung und listet Fehler klar auf – offline, nachvollziehbar und sicher.

Ziel dieses Kapitels: Versionen und Bundles verständlich machen – und erklären, warum „offiziell + manuell + lokal“ ein klarer Vorteil ist.
Offizieller Einstieg: xeinkauf.de (KoSIT) Dokumente.

11.1 Was ist ein „Bundle“?

Ein Bundle ist ein offizielles Paket aus technischen Artefakten (Schemata, Schematron-Regeln und Visualisierungs-Stylesheets), das exakt zu einer bestimmten XRechnung-Version passt.

11.2 Warum Versionen wechseln (und warum das gut ist)

Die E-Rechnungsregeln werden regelmäßig präzisiert und aktualisiert. Das sorgt für Rechtssicherheit, bedeutet in der Praxis jedoch:

• Die Validierungsregeln können strenger werden.
• Neue Pflichtangaben kommen eventuell hinzu.
• Bestehende XML-Rechnungen werfen nach einem Update plötzlich Warnungen oder Fehler auf.

➡️ Best Practice: Die Release Notes der Konfigurationen auf GitHub studieren.

11.3 Best Practices (KMU-tauglich)

1. Bundle-Update bewusst planen: Nicht unter Zeitdruck aktualisieren.
2. Kurz testen: 1 bis 3 typische Rechnungen probehalber validieren.
3. Auswirkungen prüfen: Prüfen, ob neue Warnungen oder Fehler auftauchen.
4. Produktiv umstellen: Erst nach erfolgreichem Test produktiv mit dem neuen Bundle arbeiten.

11.4 SPRechnung-Prinzip (offline & kontrolliert)

Sie beziehst die XRechnungs-Bundles direkt von der offiziellen Quelle und aktivierst sie gezielt im Tool. Danach arbeiten Generator, Validator und Viewer absolut synchron auf diesem Stand – ohne unvorhergesehene Updates im Hintergrund.

Ziel dieses Kapitels: Eingehende E-Rechnungen (XRechnung/ZUGFeRD) ohne XML-Stress prüfen – und sauber ablegen.
Primärquellen: BMF FAQ E-Rechnung, ELSTER E-Rechnungsviewer, e-Rechnung Bund FAQ.

12.1 Warum „Empfang“ ein eigener Prozess ist

E-Rechnungen sind strukturierte Daten, die sich hervorragend automatisiert prüfen und verarbeiten lassen – vorausgesetzt, es gibt einen klaren internen Ablauf.

12.2 Der einfache Prozess (KMU-tauglich)

1. Eingangskanal definieren: z. B. ein eigenes E-Mail-Postfach (rechnung@...).
2. Dateityp identifizieren: Handelt es sich um eine reine XML-Datei (XRechnung) oder ein Hybrid-PDF (ZUGFeRD)?
3. Lesbar machen: Nutze die HTML-Visualisierung im Viewer statt den XML-Code zu lesen.
4. Plausibilität prüfen: Stimmen Beträge, Absender und erbrachte Leistungen?
5. Validieren: Die Datei technisch prüfen, um Fehler bei der Weiterverarbeitung zu vermeiden.
6. Archivieren: Das Original (XML-Datei) mitsamt Prüfbericht GoBD-konform und unveränderbar ablegen.

12.3 Checkliste: Was immer prüfen?

• Absender/Lieferant: Name, Anschrift und USt-ID prüfen.
• Rechnungsdaten: Eindeutige Rechnungsnummer, Ausstellungsdatum und Leistungszeitraum.
• Zahlungsinformationen: IBAN, Bankverbindung und Fälligkeit/Skonto.
• Positionen: Plausibilität von Mengen, Einzelpreisen, Aufschlägen und Rabatten.
• Steuerdetails: Steuersätze, Steuerkategorien und die rechnerische Steueraufschlüsselung.
• Referenzen: Bestellnummer, Projekt-ID oder Buyer Reference / Leitweg-ID.

12.4 Viewer-Vorteil: „Ohne XML-Stress“

XML ist für Maschinen. Für Menschen ist eine Visualisierung in eine HTML-Ansicht ideal, um schnell Entscheidungen zu treffen. SPRechnung integriert die Visualisierung direkt in Ihren lokalen Workflow.

12.5 SPRechnung-Praxisnutzen

SPRechnung zeigt Ihnen eingehende Rechnungen zweistufig: Zuerst eine übersichtliche Kompakt-Ansicht der wichtigsten Kennzahlen, gefolgt von einer detaillierten HTML-Vollansicht für die exakte Prüfung – lokal, schnell und ohne Internetpflicht.

Stand der Link-Prüfung: 17.02.2026

1) Rechtliche & steuerliche Einordnung (Deutschland)

• BMF-FAQ „E-Rechnung“ (Pflicht, Übergänge, Formate, Ausnahmen)
• BMF-Schreiben zur obligatorischen E-Rechnung (HTML)
• BMF-Schreiben (PDF-Direktlink)

2) Technische Standards: XRechnung (Versionen, Bundles, Dokumente)

• KoSIT/xeinkauf – XRechnung Versionen & Bundles
• KoSIT/xeinkauf – Dokumente/Übersichten

3) Validator & Regelwerke (KoSIT)

• KoSIT Validator (Engine, GitHub)
• KoSIT Validator-Konfiguration für XRechnung (GitHub)
• Releases/Änderungen (Impact/Updates)

4) Viewer & Visualisierung (eingehende XRechnungen lesbar machen)

• ELSTER E-Rechnungsviewer (kostenlos)
• e-Rechnung Bund – FAQ: XRechnung visualisieren
• e-Rechnung Bund – FAQ-Übersicht (u. a. Leitweg-ID & Praxis)

5) ZUGFeRD / Factur-X (FeRD)

• FeRD – ZUGFeRD/Factur-X (Standard-Übersicht)
• FeRD – Publikationen/Infopakete (Downloads)
• FeRD – Meldungen (News/Versionen)

Optional (weitere offizielle Infos)

• BSI – E-Rechnung
• BMI – Einführung E-Rechnung