Inhaltsverzeichnis
0. Schnellstart: Was brauche ich als Einsteiger wirklich?

1. E-Rechnung in Deutschland: Was ist XRechnung – und was brauche ich wirklich?
2. Grundbegriffe & Formate: XRechnung, ZUGFeRD, EN 16931, UBL/CII, Leitweg-ID …
3. Validieren & KoSIT-Validator: Was ist das – und warum ist „grün“ so wichtig?
4. XRechnung prüfen: Was bedeutet „grün/gelb/rot“ – und was tun bei Fehlern?
5. XRechnung-Bundle: herunterladen, importieren, aktivieren – was passiert dann?
6. Eingehende XRechnungen lesen: Viewer & typische Inhalte (ohne XML-Stress)
7. ZUGFeRD verstehen: Hybrid-Rechnung, Profile & Abgrenzung zur XRechnung
8. Entscheidungs-Guide: Bin ich betroffen? (E-Rechnungspflicht ab 2025 – kurz erklärt)
9. Mini-Lexikon & Formate (Buyer Reference, Leitweg-ID, …)
10. KoSIT-Validator für Einsteiger: Report lesen, Fehler beheben
11. Bundles & Versionen: Update-Sicherheit, Impact, Best Practices
12. E-Rechnung empfangen & prüfen: Prozess, Checkliste, Archivierung

Offizielle Quellen & weiterführende Links

0) Schnellstart: Was brauche ich als Einsteiger wirklich?

Wenn du nur 5 Minuten hast, nimm diese Checkliste:

• 1. **Klären, ob du E‑Rechnungen im B2B/B2G brauchst** (und welche Übergangs-/Ausnahmeregeln gelten).
• 2. **Ein Format wählen**, das EN 16931 erfüllt: häufig **XRechnung** oder **ZUGFeRD (Profil XRECHNUNG)**.
• 3. **Stammdaten sauber pflegen** (Adresse, USt‑ID, IBAN, Ansprechpartner) – das vermeidet 80% der Validierungsfehler.
• 4. **XML erzeugen + validieren**, bevor du versendest (Validator = „TÜV“ für die Datei).
• 5. **Lesbarkeit sichern:** Eingehende XML‑Rechnungen brauchst du 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.

1) E‑Rechnung in Deutschland: Was ist XRechnung – und was brauche ich wirklich?
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**, sodass eine elektronische Verarbeitung möglich ist.
**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“**. Du kannst XRechnung auch im **B2B** nutzen, wenn dein 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 dein 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 dich strukturiert durch die Eingaben, erzeugt die XRechnung lokal und ermöglicht die Prüfung, bevor du versendest.
**Lokal-first:** Kein Upload deiner Daten „nur fürs Erstellen/Prüfen“.
*SPRechnung entdecken*

2) Grundbegriffe & Formate: XRechnung, ZUGFeRD, EN 16931, UBL/CII, Leitweg‑ID …

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 dich 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 du B2B startest, kläre mit deinem Kunden, ob er 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 du häufig siehst (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).

3) Validieren & KoSIT‑Validator: Was ist das – und warum ist „grün“ so wichtig?
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 dir 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 du XML nicht erst „irgendwo hochladen“ musst.
Das unterstützt dein Offline‑/Datenschutz‑Prinzip: **Prüfen lokal, keine Datenabgabe nur fürs Validieren.**

4) XRechnung prüfen: Was bedeutet „grün/gelb/rot“ – und was tun bei Fehlern?
Wenn du nach „XRechnung prüfen“ suchst, bist du meist an der Stelle: **XML erzeugt – Validator meckert.**
Die gute Nachricht: Fehler lassen sich systematisch beheben, wenn du die Fehlerart richtig einordnest.
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.

5. XRechnung‑Bundle: herunterladen, importieren, aktivieren – was passiert dann?
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 (klar!)
Offline‑freundlich und kontrolliert: Bundle wird **manuell** von offizieller Quelle geladen (kein „stiller Download“ im Hintergrund).
Import/Aktivierung im Tool
Der typische Ablauf:
1. Bundle‑ZIP herunterladen
2. Im Tool **importieren**
3. Bundle **aktivieren**
4. 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 du offline und kontrolliert auf dem offiziellen Stand bleiben kannst.
*Bundle‑Seite / Anleitung* 

6) Eingehende XRechnungen lesen: Viewer & typische Inhalte (ohne XML‑Stress)
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/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

7) ZUGFeRD: PDF + strukturierte Daten – das Hybridformat 
**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 Datei**:
- ein PDF/A-3 als Sichtbeleg (für Menschen)
- eine XML-Struktur als Datenteil (für Systeme) :contentReference[oaicite:1]{index=1}
Für viele Unternehmen ist das praktisch, weil:
- der Empfänger die Rechnung **ohne extra Viewer** sofort lesen kann (PDF),
- Buchhaltung/ERP trotzdem **strukturierte Daten** nutzen kann (XML),
- man in der Umstellung auf E-Rechnung **weniger Medienbruch** hat.
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 (welches Format im Prozess gewünscht ist). 
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). :

8) Entscheidungs-Guide: Bin ich betroffen? (E-Rechnungspflicht ab 2025 – kurz erklärt)

**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):
https://www.bundesfinanzministerium.de/Content/DE/FAQ/faq.html (→ Bereich „E-Rechnung“)
*(Dort sind auch die jeweils aktuellen BMF-Schreiben verlinkt.)*
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 Standardisierung intern (Prozess/Archiv).

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

• Du solltest **E-Rechnungen empfangen können**.
• Für den Versand gelten **Übergänge/Ausnahmen** – Details immer offiziell im 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 (Kurzüberblick – bitte immer offiziell prüfen)
Je nach Fall gibt es Ausnahmen/Erleichterungen (z. B. Kleinbetragsrechnungen, bestimmte steuerfreie Umsätze, einzelne Sonderfälle).
➡️ **Wichtig:** Bitte **immer** die BMF-FAQ für die konkrete Fallgruppe referenzieren (keine pauschalen Marketing-Behauptungen).
### 8.4 Was du „wirklich“ brauchst (Einsteiger-Toolset)
Wenn du E-Rechnungen in deinem Unternehmen bisher nicht brauchtest, 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**: Du erstellst Dokumente (PDF) und kannst 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 du ohne XML-Stress prüfen kannst.
„Jetzt SPRechnung ansehen – in 10 Minuten zur ersten geprüften E-Rechnung.“

9) Mini-Lexikon & Formate: XRechnung, ZUGFeRD, EN 16931, UBL/CII, Leitweg-ID, Buyer Reference
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, maschinell verarbeitbar
„Sonstige Rechnung“: Papier oder unstrukturiertes Format (z. B. PDF)
➡️ Für Einordnung/Definition immer BMF heranziehen (FAQ + verlinkte Schreiben).
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“. Du kannst 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 + eingebettete strukturierte Daten).
Wichtig ist: 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“:

• UBL
• 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: Adressierungsmerkmal in der öffentlichen Verwaltung (B2G-Kontext, Praxisinfos u. a. e-Rechnung Bund).
• 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
XRechnung Deutsches Profil/Standard (EN-16931-konform im Regelwerk) Häufig B2G, aber auch B2B nutzbar
ZUGFeRD Hybrid (PDF + strukturierte Daten) Menschenlesbar + maschinenlesbar
EN 16931 EU-Norm für Rechnungsdaten Basis vieler Formate
UBL / CII XML-Syntaxen „Schreibweise“ – Inhalt muss passen
KoSIT Koordinierungsstelle IT-Standards Validator-Ökosystem
Validator Prüft Regeln/Schemata Liefert grün/gelb/rot
Bundle Offizielle Artefakt-Pakete Update-Sicherheit

10) KoSIT-Validator für Einsteiger: Validierung verstehen, Report lesen, Fehler beheben
Ziel dieses Kapitels: „Was ist KoSIT, was ist der Validator, was wird da geprüft – und wie gehe ich bei Fehlern vor?“
Primärquellen (technisch, offiziell):
KoSIT Validator (Engine): https://github.com/itplr-kosit/validator
XRechnung-Konfiguration: https://github.com/itplr-kosit/validator-configuration-xrechnung
Releases (Impact-Hinweise): https://github.com/itplr-kosit/validator-configuration-xrechnung/releases
10.1 Was ist der KoSIT-Validator – in einem Satz?
Der KoSIT-Validator ist ein Prüfwerkzeug, das XML-Dokumente anhand von Schemas und Schematron-Regeln validiert – z. B. für XRechnung.
10.2 Engine vs. Konfiguration – warum du beides brauchst
Validator (Engine): das Programm, das prüft
Validator-Konfiguration (XRechnung): das Regel-/Artefaktpaket, das sagt was geprüft werden soll (Profil/Versionen/Regeln)
➡️ Praxis: Wenn du „nur“ den Validator hast, aber nicht die passende Konfiguration, prüfst du am Ziel vorbei.
10.3 Was bedeutet „grün / gelb / rot“ wirklich?
Grün: keine blockierenden Fehler gefunden
Gelb: Warnungen/Hinweise (oft sinnvoll zu beheben)
Rot: mindestens eine Regel verletzt (Pflichtfeld/Logik/Codelist/Summe)
10.4 So liest du einen Report (ohne Frust)
Fehler-ID (z. B. BR-… / BT-…) notieren
Kurztext verstehen („Was fordert die Regel?“)
Betroffene Business Terms (BT-Nummern) / Gruppen (BG) identifizieren
Im Tool das Feld finden, das den Wert liefert
Korrigieren → erneut validieren (kleine Schritte)
Typische Fehlerklassen:
Pflichtfeld fehlt
Format/Codelist falsch
Rechenlogik (Summen/Steueraufschlüsselung)
Kontextregel („wenn A, dann B“)
10.5 Offline/Lokal-first & Datenschutz
Validierung kann vollständig lokal stattfinden – keine sensiblen Rechnungsdaten müssen hochgeladen werden.
10.6 SPRechnung-Nutzen (produktnah, ohne Technik-Overload)
SPRechnung führt dich von „Daten erfassen“ → „XML erzeugen“ → „prüfen“ bis zur sauberen Fehlerliste – alles lokal, nachvollziehbar und ohne Cloud-Umwege.

11) Bundles & Versionen: Update-Sicherheit, Impact, Best Practices
Ziel dieses Kapitels: Versionen/Bundles verständlich machen – und erklären, warum „offiziell + manuell + lokal“ ein Vorteil ist.
Offizieller Einstieg: xeinkauf.de (KoSIT) – Dokumente/Links zu XStandards: https://xeinkauf.de/dokumente/
11.1 Was ist ein „Bundle“?
Ein Bundle ist ein offizielles Paket aus Artefakten (z. B. Schemata, Schematron-Regeln, Visualisierungskomponenten), das zu einer XRechnung-Version/Regelbasis passt.
11.2 Warum Versionen wechseln (und warum das gut ist)
Regeln werden präzisiert, Fehler korrigiert, Profile aktualisiert. Das erhöht die Qualität und Rechtssicherheit – kann aber bedeuten:
Validierung wird „strenger“
neue Pflichtfelder/Prüfungen kommen hinzu
bestehende XMLs zeigen plötzlich Warnungen/Fehler, die vorher nicht auftauchten
➡️ Deshalb sind Release Notes wichtig: https://github.com/itplr-kosit/validator-configuration-xrechnung/releases
11.3 Best Practices (KMU-tauglich)
Bundle-Update bewusst durchführen
Kurz testen (1–3 typische Rechnungen validieren)
Impact dokumentieren (falls neue Regeln greifen)
Erst dann produktiv umstellen
11.4 SPRechnung-Prinzip (offline & kontrolliert)
Du beziehst Bundles/Regeln von der offiziellen Quelle und aktivierst sie gezielt. Danach sind Generator, Validator und Viewer synchron – keine „halben Updates“, keine Cloud-Abhängigkeit.

12) E-Rechnung empfangen & prüfen: Prozess, Checkliste, Archivierung
Ziel dieses Kapitels: Eingehende E-Rechnungen (XRechnung/ZUGFeRD) ohne XML-Stress prüfen – und sauber ablegen.
Primärquellen:
BMF (FAQ E-Rechnung): https://www.bundesfinanzministerium.de/Content/DE/FAQ/faq.html
ELSTER E-Rechnungsviewer (Referenz-Viewer): https://www.e-rechnung.elster.de/
e-Rechnung Bund FAQ: https://e-rechnung-bund.de/faq/
12.1 Warum „Empfang“ ein eigener Prozess ist
E-Rechnungen sind nicht nur „eine andere Datei“. Sie sind strukturierte Daten, die sich sehr gut prüfen und intern weiterverarbeiten lassen – wenn du einen klaren Ablauf hast.
12.2 Der einfache Prozess (KMU-tauglich)

1. Eingangskanal definieren (E-Mail-Postfach/Upload-Ordner)
2. Datei identifizieren (XRechnung-XML oder ZUGFeRD-PDF)
3. Lesbar machen (Viewer/HTML-Ansicht)
4. Plausibilitätscheck (Kernfelder)
5. Validieren (optional, aber sehr empfohlen)
6. Archivieren (Original + Prüfstatus + Zuordnung zum Vorgang)

12.3 Checkliste: Was immer prüfen?

• Absender/Lieferant (Name, Adresse, USt-ID)
• Rechnungsnummer, Datum, Leistungszeitraum
• Zahlungsziel & Bankdaten
• Positionen (Menge/Preis/Rabatte plausibel)
• Steuersätze/Steuerkategorie & Steueraufschlüsselung
• Referenzen (Bestellnummer/Projekt/Buyer Reference)

12.4 Viewer-Vorteil: „Ohne XML-Stress“
XML ist für Maschinen. Für Menschen ist eine Visualisierung/HTML-Ansicht ideal, um schnell zu entscheiden: stimmt das – oder muss ich nachfragen?
ELSTER ist ein bekannter Referenz-Viewer; SPRechnung integriert die Visualisierung direkt in den lokalen Workflow.
12.5 SPRechnung-Praxisnutzen 
Mit SPRechnung kannst du eingehende XRechnungen im Tool anzeigen: erst eine kompakte Übersicht, dann eine vollständige HTML-Ansicht. Zusammen mit lokaler Prüfung/Validierung entsteht ein klarer, nachvollziehbarer Prozess für Buchhaltung und Einkauf.

SPRechnung Übersicht
Download & Testversion
Funktionsübersicht
Preise & Lizenzen
Datenschutz & Offline-Prinzip
XRechnung-Bundles importieren
Häufige Fragen
Wissensseite E-Rechnung & XRechnung