1. Zweck und Sinn der E-Rechnung

Eine E-Rechnung ist keine PDF-Datei und kein eingescanntes Papier. Sie ist eine Rechnung in einem strukturierten, maschinenlesbaren XML-Format, das eine vollständig automatisierte Verarbeitung durch IT-Systeme ermöglicht – ohne Medienbrüche, ohne manuelle Erfassung.

Vorteile auf einen Blick

• ⏱️ Zeitersparnis durch automatisierte Verarbeitung
• 💰 Kostensenkung – keine Druck-, Porto- oder Archivkosten
• ✅ Höhere Datenqualität durch strukturierte, validierte Felder
• 🔍 Bessere Nachvollziehbarkeit bei Prüfungen
• 🌱 Umweltfreundlich – kein Papier, keine Logistik
• ⚖️ Rechtssicherheit durch normierte Pflichtangaben

2. Rechtlicher Hintergrund

Seit dem 1. Januar 2025 ist die E-Rechnung im B2B-Bereich in Deutschland gesetzlich verankert (Wachstumschancengesetz). Es gelten gestaffelte Übergangsfristen:

3. Wie wir die E-Rechnung umgesetzt haben

Unsere Lösung ist ein vollständiger E-Rechnungs-Viewer und -Validator, der eingehende E-Rechnungen aller gängigen Formate liest, prüft und übersichtlich darstellt.

Unterstützte Formate

• ✅ ZUGFeRD / Factur-X ab Version 2.0.1 (Profile: MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG)
• ✅ XRechnung in UBL-Syntax (ubl:Invoice)
• ✅ XRechnung in CII-Syntax (rsm:CrossIndustryInvoice)
• ✅ PDF/A-3 mit eingebetteter XML (automatische Extraktion)

Technologische Basis

• XML-Parser mit XPath-basierter Navigation
• Schema-Validierung gegen die offiziellen XSDs der Norm EN 16931
• Geschäftsregelprüfung (BR-Regeln) gemäß Spezifikation
• PDF/A-3-Extraktion zur Trennung von visueller Anzeige und strukturierten Daten

4. Was das Programm konkret macht

1. Datei einlesen – akzeptiert PDF (mit eingebetteter XML) oder reine XML-Dateien.
2. Format erkennen – identifiziert automatisch UBL vs. CII und ZUGFeRD-Profil.
3. XML extrahieren – bei PDF/A-3 wird die eingebettete factur-x.xml oder xrechnung.xml gezogen.
4. Felder auslesen – über fest definierte XPath-Pfade werden alle BT-/BG-Felder extrahiert.
5. Validieren – Schema-Konformität und Geschäftsregeln (BR) werden geprüft.
6. Aufbereiten – Datumswerte werden formatiert (z. B. „20260401" → „01.04.2026"), Beträge mit Währung versehen.
7. Anzeigen – strukturierte Darstellung in Blöcken: Dokumentinformationen, Verkäufer, Käufer, Positionen, Summen, Zahlungsinformationen.
8. Fehler/Warnungen melden – Validierungsergebnisse werden klar gekennzeichnet ausgegeben.

5. Bedeutung der Kennungen

In der EN 16931 ist jedes Feld eindeutig nummeriert. Diese Kennungen erscheinen im Viewer und ermöglichen die genaue Zuordnung zur Norm:

6. Implementierte Felder im Detail

📋 Dokumentinformationen (Header)

📅 Abrechnungs-/Leistungszeitraum

🏢 Verkäufer (BG-4)

🏬 Käufer (BG-7)

🚚 Lieferinformationen (BG-13)

💰 Zahlungsinformationen (BG-16)

📦 Rechnungspositionen (BG-25)

🧮 Summenblock (BG-22)

💸 Steueraufschlüsselung (BG-23)

7. Lastschrift- vs. normale Rechnungen

Beide Rechnungstypen verwenden die gleiche Norm – sie unterscheiden sich aber in den Pflichtfeldern für die Zahlungsinformationen.

Rechtliche Anforderungen an Lastschrift-Rechnungen

• Es muss ein gültiges SEPA-Mandat des Zahlers vorliegen.
• Die Rechnung muss als Vorabankündigung (Pre-Notification) dienen oder darauf verweisen.
• Die Frist (mindestens 1 Bankarbeitstag bei COR1) ist einzuhalten.
• Mandatsreferenz und Gläubiger-ID müssen mit den im Mandat hinterlegten Werten übereinstimmen.

8. Zeiträume: Header (BG-14) vs. Position (BT-134/135)

Eine häufige Frage: Warum stehen manchmal zwei unterschiedliche Zeiträume in einer Rechnung?

Beispiel: Eine Wartungsrechnung deckt den Monat April (BG-14: 01.04.–30.04.2026) ab, der Techniker war aber nur vom 01.04.–04.04.2026 vor Ort (BT-134/135).

Die Werte werden direkt aus der XML gelesen – das Programm berechnet oder rät nichts:

<ram:ApplicableHeaderTradeSettlement>
						  <ram:BillingSpecifiedPeriod>
						    <ram:StartDateTime>
						      <udt:DateTimeString format="102">20260401</udt:DateTimeString>  <!-- BT-73 -->
						    </ram:StartDateTime>
						    <ram:EndDateTime>
						      <udt:DateTimeString format="102">20260430</udt:DateTimeString>  <!-- BT-74 -->
						    </ram:EndDateTime>
						  </ram:BillingSpecifiedPeriod>
						</ram:ApplicableHeaderTradeSettlement>

9. Validierung & Geschäftsregeln (BR)

Das Programm prüft die Rechnung auf drei Ebenen:

Ebene 1: Schema-Validierung

Prüfung der XML gegen die XSD-Schemata der Norm – stellt sicher, dass die Struktur formal korrekt ist.

Ebene 2: Geschäftsregeln (BR)

Inhaltliche Regeln, z. B.:

Ebene 3: Rechnerische Konsistenz

Plausibilitätsprüfungen, z. B. ob die Summe der Positionsbeträge mit dem Nettogesamtbetrag übereinstimmt, ob die Steuerberechnung korrekt ist und ob der Zahlbetrag schlüssig ist.

10. Praktische Hinweise für Anwender

Was tun bei…

… einer fehlerhaften Rechnung?

• Genaue Fehlermeldung im Validierungsbereich beachten (BR-Nummer angeben).
• Verkäufer kontaktieren und korrekte Rechnung anfordern.
• Bei Pflichtfeld-Verstößen: Rechnung kann formal abgelehnt werden.

… abweichenden Beträgen zwischen XML und PDF?

• Bei ZUGFeRD ist die XML rechtlich verbindlich, nicht das visuelle PDF.
• Differenzen sind ein Indiz für eine fehlerhafte Erstellung.

… einer Gutschrift?

• Rechnungstyp-Code BT-3 = 381 erkennen.
• Beträge sind in der Regel positiv ausgewiesen, der Typ-Code dreht das Vorzeichen.

Empfohlener Workflow

1. Rechnung in den Viewer laden (PDF oder XML).
2. Validierungsstatus prüfen (grün ✅ / gelb ⚠️ / rot ❌).
3. Stammdaten (Verkäufer, Käufer) gegen interne Daten abgleichen.
4. Positionen und Summen sichten.
5. Bei Lastschrift: Mandatsreferenz mit hinterlegten Mandaten abgleichen.
6. Rechnung freigeben oder zur Klärung markieren.