E-Rechnungs-Pflicht 2025: Kompletter Guide für Entwickler

Ab dem 1. Januar 2025 ist die elektronische Rechnung (E-Rechnung) für B2B-Transaktionen in Deutschland verpflichtend. Diese fundamentale Änderung betrifft jede Software, die Rechnungen erstellt oder verarbeitet – von ERP-Systemen über Buchhaltungssoftware bis hin zu E-Commerce-Plattformen.

In diesem umfassenden Guide erfährst du alles, was du als Entwickler wissen musst: rechtliche Grundlagen, technische Anforderungen, Code-Beispiele und eine praktische Implementierungs-Checkliste.

Rechtlicher Hintergrund

EU-Richtlinie 2014/55/EU

Die europäische Richtlinie 2014/55/EU verpflichtet öffentliche Auftraggeber seit 2020, elektronische Rechnungen zu empfangen und zu verarbeiten. Deutschland setzt diese Richtlinie mit der E-Rechnungs-Verordnung (ERechV) um.

Das Wachstumschancengesetz

Das am 27. März 2024 verabschiedete Wachstumschancengesetz erweitert die E-Rechnungs-Pflicht auf den gesamten B2B-Bereich. Die wesentlichen Änderungen im Überblick:

• §14 UStG wurde angepasst und definiert nun verbindliche Anforderungen an elektronische Rechnungen
• Eine E-Rechnung muss in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen werden
• Das Format muss die automatische Verarbeitung ermöglichen
• PDF-Dateien gelten nicht mehr als E-Rechnung (außer ZUGFeRD mit eingebettetem XML)

Stufenweise Einführung

Wichtig: Die Empfangspflicht gilt bereits ab 2025 für alle Unternehmen – unabhängig von der Größe.

Was ändert sich konkret?

Bisher konnten Unternehmen Rechnungen in beliebigen Formaten austauschen: PDF, Papier, oder proprietäre Formate. Ab 2025 müssen B2B-Rechnungen in einem strukturierten elektronischen Format vorliegen, das maschinell verarbeitbar ist.

Das bedeutet für deine Software:

1. Empfang: Du musst E-Rechnungen im XRechnung- oder ZUGFeRD-Format entgegennehmen können
2. Verarbeitung: Die strukturierten Daten müssen korrekt geparst und in dein System übernommen werden
3. Archivierung: E-Rechnungen müssen GoBD-konform aufbewahrt werden (10 Jahre, unveränderbar). Die Archive API unterstützt dich dabei.

Teste jetzt im Playground, wie E-Rechnungen aussehen und wie die API funktioniert.

XRechnung vs. ZUGFeRD vs. Peppol

Als Entwickler stehst du vor der Frage: Welches Format soll ich implementieren? Hier ein Entscheidungsbaum:

Entscheidungsbaum

1Rechnungsempfänger?
2├─ Öffentliche Verwaltung (Bund/Land/Kommune)
3│   └─ → XRechnung (Pflicht!)
4├─ Internationaler Geschäftspartner (EU)
5│   └─ → Peppol BIS Billing
6└─ Deutsche B2B-Unternehmen
7    ├─ Empfänger möchte PDF-Ansicht?
8    │   └─ → ZUGFeRD
9    └─ Nur strukturierte Daten nötig?
10        └─ → XRechnung

Technische Unterschiede

UBL vs. CII – Was ist der Unterschied?

UBL (Universal Business Language) und CII (Cross Industry Invoice) sind zwei XML-Syntaxen für den gleichen semantischen Standard EN 16931:

• UBL 2.1: Verwendet von XRechnung (Deutschland), Peppol, FatturaPA (Italien)
• CII: Verwendet von ZUGFeRD, Factur-X (Frankreich)

Beide enthalten dieselben Geschäftsinformationen, nur die XML-Struktur unterscheidet sich. Mit der Converter API kannst du zwischen Formaten wechseln.

Technische Anforderungen

1. E-Rechnungen empfangen (XML-Parsing)

Der erste Schritt ist das Parsen eingehender E-Rechnungen. Die Parser API macht dies einfach. Hier ein Beispiel für das Auslesen einer XRechnung:

1// TypeScript/Node.js - XRechnung parsen
2async function processIncomingInvoice(xmlContent: string) {
3  const response = await fetch("https://api.invoice.xhub.io/api/v1/invoice/de/xrechnung/generate/parse", {
4    method: "POST",
5    headers: {
6      "Authorization": `Bearer ${process.env.XHUB_API_KEY}`,
7      "Content-Type": "application/xml"
8    },
9    body: xmlContent
10  });
11 
12  const invoice = await response.json();
13  console.log("Rechnungsnummer:", invoice.invoiceNumber);
14  console.log("Gesamtbetrag:", invoice.totalAmount);
15 
16  return invoice;
17}

1# Python - XRechnung parsen
2import requests
3 
4def process_incoming_invoice(xml_content: str):
5    response = requests.post(
6        "https://api.invoice.xhub.io/api/v1/invoice/de/xrechnung/generate/parse",
7        headers={
8            "Authorization": f"Bearer {API_KEY}",
9            "Content-Type": "application/xml"
10        },
11        data=xml_content
12    )
13 
14    invoice = response.json()
15    print(f"Rechnungsnummer: {invoice['invoiceNumber']}")
16    print(f"Gesamtbetrag: {invoice['totalAmount']}")
17 
18    return invoice

2. E-Rechnungen validieren

Bevor du eine E-Rechnung verarbeitest, solltest du sie validieren. Die KoSIT (Koordinierungsstelle für IT-Standards) stellt Schematron-Regeln bereit.

1# cURL - E-Rechnung validieren
2curl -X POST https://api.invoice.xhub.io/api/v1/invoice/de/xrechnung/generate/validate \
3  -H "Authorization: Bearer $XHUB_API_KEY" \
4  -H "Content-Type: application/xml" \
5  --data-binary @rechnung.xml
6 
7# Response
8{
9  "valid": true,
10  "format": "XRechnung 3.0.2",
11  "schematronPassed": true,
12  "warnings": [],
13  "errors": []
14}

Die vollständige API-Dokumentation findest du unter /docs/api/validator.

3. E-Rechnungen erstellen und versenden

Das Erstellen konformer E-Rechnungen ist der komplexeste Teil. Du musst alle Pflichtfelder korrekt befüllen und die Schematron-Regeln einhalten.

1// TypeScript/Node.js - E-Rechnung erstellen
2const response = await fetch("https://api.invoice.xhub.io/api/v1/invoice/de/xrechnung/generate", {
3  method: "POST",
4  headers: {
5    "Authorization": `Bearer ${process.env.XHUB_API_KEY}`,
6    "Content-Type": "application/json"
7  },
8  body: JSON.stringify({
9    type: "xrechnung-3.0",
10    invoiceNumber: "RE-2025-001",
11    issueDate: "2025-01-15",
12    seller: {
13      name: "Meine Firma GmbH",
14      vatId: "DE123456789",
15      address: {
16        street: "Musterstraße 1",
17        city: "Berlin",
18        postalCode: "10115",
19        country: "DE"
20      }
21    },
22    buyer: {
23      name: "Kunde AG",
24      vatId: "DE987654321",
25      leitweg: "991-12345-67", // Für öffentliche Auftraggeber
26      address: {
27        street: "Kundenweg 42",
28        city: "München",
29        postalCode: "80331",
30        country: "DE"
31      }
32    },
33    items: [
34      {
35        description: "Softwareentwicklung",
36        quantity: 40,
37        unit: "Stunden",
38        unitPrice: 120.00,
39        vatRate: 19
40      },
41      {
42        description: "Server-Hosting (Januar 2025)",
43        quantity: 1,
44        unit: "Monat",
45        unitPrice: 299.00,
46        vatRate: 19
47      }
48    ],
49    paymentTerms: {
50      dueDate: "2025-02-15",
51      iban: "DE89370400440532013000",
52      bic: "COBADEFFXXX"
53    }
54  })
55});
56 
57const invoice = await response.json();
58console.log("E-Rechnung erstellt:", invoice.id);
59console.log("Download XML:", invoice.downloadUrl);

1# Python - E-Rechnung erstellen
2import requests
3import os
4 
5response = requests.post(
6    "https://api.invoice.xhub.io/api/v1/invoice/de/xrechnung/generate",
7    headers={
8        "Authorization": f"Bearer {os.environ['XHUB_API_KEY']}",
9        "Content-Type": "application/json"
10    },
11    json={
12        "type": "xrechnung-3.0",
13        "invoiceNumber": "RE-2025-001",
14        "issueDate": "2025-01-15",
15        "seller": {
16            "name": "Meine Firma GmbH",
17            "vatId": "DE123456789",
18            "address": {
19                "street": "Musterstraße 1",
20                "city": "Berlin",
21                "postalCode": "10115",
22                "country": "DE"
23            }
24        },
25        "buyer": {
26            "name": "Kunde AG",
27            "vatId": "DE987654321",
28            "address": {
29                "street": "Kundenweg 42",
30                "city": "München",
31                "postalCode": "80331",
32                "country": "DE"
33            }
34        },
35        "items": [
36            {
37                "description": "Softwareentwicklung",
38                "quantity": 40,
39                "unit": "Stunden",
40                "unitPrice": 120.00,
41                "vatRate": 19
42            }
43        ]
44    }
45)
46 
47invoice = response.json()
48print(f"E-Rechnung erstellt: {invoice['id']}")

Die vollständige API-Dokumentation für das Erstellen von E-Rechnungen findest du unter /docs/api/creator.

Implementierungs-Checkliste

Nutze diese Checkliste, um sicherzustellen, dass deine Software bereit für die E-Rechnungs-Pflicht ist:

Empfang (Pflicht ab 01.01.2025)

• XRechnung (UBL) parsen können
• XRechnung (CII) parsen können
• ZUGFeRD 2.x (PDF mit eingebettetem XML) parsen können
• Validierung eingehender Rechnungen implementiert
• Fehlermeldungen bei ungültigen Rechnungen anzeigen
• GoBD-konforme Archivierung implementiert

Versand (Pflicht ab 01.01.2027/2028)

• XRechnung-Export implementiert
• ZUGFeRD-Export implementiert (falls PDF gewünscht)
• Leitweg-ID für öffentliche Auftraggeber unterstützt
• Validierung vor dem Versand implementiert
• Alle Pflichtfelder nach EN 16931 befüllt
• Unit-Tests für E-Rechnungs-Generierung

Allgemein

• API-Integration getestet (Sandbox-Umgebung)
• Fehlerbehandlung für API-Ausfälle implementiert
• Retry-Logik für fehlgeschlagene Requests
• Logging und Monitoring eingerichtet – nutze Webhooks für Echtzeit-Benachrichtigungen

Häufige Fehler und Lösungen

Bei der Implementierung von E-Rechnungen treten bestimmte Validierungsfehler besonders häufig auf:

BR-DE-01: Leitweg-ID fehlt

Fehler: BR-DE-01: Eine Rechnung an öffentliche Auftraggeber muss eine Leitweg-ID enthalten.

Lösung: Wenn der Rechnungsempfänger eine öffentliche Verwaltung ist, musst du die Leitweg-ID angeben:

1{
2  "buyer": {
3    "name": "Bundesministerium für Digitales",
4    "leitweg": "991-12345-67"
5  }
6}

Die Leitweg-ID besteht aus drei Teilen: Grobadressierung (3-stellig), Feinadressierung (bis zu 8-stellig) und Prüfziffer (2-stellig).

BR-DE-15: Bankverbindung fehlt

Fehler: BR-DE-15: Eine Rechnung muss Informationen zur Zahlung enthalten.

Lösung: Zahlungsinformationen sind in Deutschland Pflicht:

1{
2  "paymentTerms": {
3    "dueDate": "2025-02-15",
4    "iban": "DE89370400440532013000",
5    "bic": "COBADEFFXXX"
6  }
7}

BR-CO-10: Summen stimmen nicht

Fehler: BR-CO-10: Die Summe der Positionsbeträge entspricht nicht dem Gesamtbetrag.

Lösung: Stelle sicher, dass deine Berechnungen exakt sind. Verwende Decimal-Typen statt Float:

1// ❌ Falsch - Float-Ungenauigkeit
2const total = 0.1 + 0.2; // = 0.30000000000000004
3 
4// ✅ Richtig - Integer-Cent-Berechnung
5const totalCents = 10 + 20; // = 30
6const total = totalCents / 100; // = 0.30

Eine vollständige Liste aller Fehlercodes findest du in der Dokumentation.

FAQ – Häufig gestellte Fragen

Muss ich E-Rechnungen empfangen können, auch wenn ich noch keine senden muss?

Ja. Ab dem 1. Januar 2025 muss jedes B2B-Unternehmen in Deutschland E-Rechnungen empfangen können – unabhängig vom Umsatz. Die Sendepflicht greift später (2027/2028), aber empfangen musst du sofort können.

Sind PDF-Rechnungen ab 2025 verboten?

Nicht ganz. PDF-Rechnungen ohne strukturierte Daten gelten nicht mehr als E-Rechnung. Du kannst sie aber bis zur Übergangsfrist (2027/2028) noch als "sonstige Rechnungen" akzeptieren, wenn dein Geschäftspartner keine E-Rechnung senden kann. Das ZUGFeRD-Format enthält ein PDF, gilt aber als E-Rechnung, weil die XML-Daten eingebettet sind.

Was passiert, wenn ich die Pflicht ignoriere?

Rechtlich drohen bei Verstößen gegen die Rechnungsstellungspflichten nach §14 UStG Bußgelder. Praktisch relevanter: Ohne E-Rechnungsfähigkeit kannst du keine Rechnungen an öffentliche Auftraggeber stellen und verlierst möglicherweise Geschäftspartner, die nur noch E-Rechnungen akzeptieren.

Muss ich die E-Rechnung selbst implementieren oder kann ich eine API nutzen?

Du kannst beides. Die Eigenimplementierung erfordert das Verarbeiten der 247-seitigen KoSIT-Spezifikation, Schematron-Validierung und regelmäßige Updates bei Formatänderungen. Mit einer API wie invoice.xhub sparst du diese Komplexität und kannst in wenigen Stunden live gehen. Keine API-Erfahrung? Nutze unsere No-Code Integrationen mit Zapier, Make oder n8n.

Wie archiviere ich E-Rechnungen GoBD-konform?

E-Rechnungen müssen 10 Jahre unveränderbar aufbewahrt werden. Das bedeutet:

• Original-XML speichern (nicht nur die verarbeiteten Daten)
• Zeitstempel der Eingangszeit dokumentieren
• Manipulationsschutz gewährleisten (z.B. durch Hashwerte)
• Lesbarkeit über die gesamte Aufbewahrungsfrist sicherstellen

Nächste Schritte

Du hast jetzt einen umfassenden Überblick über die E-Rechnungs-Pflicht 2025. Hier sind deine nächsten Schritte:

1. Playground testen: Experimentiere mit der API im Playground – ohne Anmeldung, ohne Kosten.

2. API-Key holen: Registriere dich kostenlos und erhalte deinen API-Key für die Sandbox-Umgebung.

3. Integration starten: Nutze unsere Quickstart-Anleitung oder die SDKs für Node.js, Python oder die REST API direkt.

4. Dokumentation lesen: Tiefere technische Details findest du in der Validator-Dokumentation und Creator-Dokumentation.

Fazit

Die E-Rechnungs-Pflicht 2025 ist keine Option, sondern Realität. Mit dem richtigen Werkzeug musst du aber nicht Wochen mit der Implementierung verbringen.

invoice.xhub nimmt dir die Komplexität ab:

• ✅ Alle Formate (XRechnung, ZUGFeRD, Peppol) aus einer API
• ✅ Automatische Validierung gegen aktuelle KoSIT-Schemas
• ✅ Einfache JSON-API statt XML-Handling
• ✅ SDKs für alle gängigen Sprachen

Fragen? Kontaktiere uns.

Starte jetzt – die ersten 100 E-Rechnungen pro Monat sind kostenlos.