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://service.invoice-api.xhub.io/api/v1/invoice/de/xrechnung/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 result = await response.json();
13  // result: { success, invoice, format, hash, errors, warnings }
14  console.log("Rechnungsnummer:", result.invoice.invoiceNumber);
15  console.log("Gesamtbetrag:", result.invoice.total);
16 
17  return result.invoice;
18}

1# Python - XRechnung parsen
2import requests
3 
4def process_incoming_invoice(xml_content: str):
5    response = requests.post(
6        "https://service.invoice-api.xhub.io/api/v1/invoice/de/xrechnung/parse",
7        headers={
8            "Authorization": f"Bearer {API_KEY}",
9            "Content-Type": "application/xml"
10        },
11        data=xml_content
12    )
13 
14    result = response.json()
15    # result: {success, invoice, format, hash, errors, warnings}
16    print(f"Rechnungsnummer: {result['invoice']['invoiceNumber']}")
17    print(f"Gesamtbetrag: {result['invoice']['total']}")
18 
19    return result['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://service.invoice-api.xhub.io/api/v1/invoice/de/xrechnung/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://service.invoice-api.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    invoice: {
10      type: "invoice",
11      invoiceNumber: "RE-2025-001",
12      issueDate: "2025-01-15",
13      dueDate: "2025-02-15",
14      currency: "EUR",
15      seller: {
16        name: "Meine Firma GmbH",
17        vatId: "DE123456789",
18        street: "Musterstraße 1",
19        city: "Berlin",
20        postalCode: "10115",
21        countryCode: "DE",
22        bankAccount: {
23          iban: "DE89370400440532013000",
24          bic: "COBADEFFXXX"
25        }
26      },
27      buyer: {
28        name: "Kunde AG",
29        vatId: "DE987654321",
30        street: "Kundenweg 42",
31        city: "München",
32        postalCode: "80331",
33        countryCode: "DE"
34      },
35      countrySpecific: {
36        countryCode: "DE", // Pflicht-Discriminator
37        leitwegId: "991-12345-67" // Für öffentliche Auftraggeber (B2G)
38      },
39      items: [
40        {
41          position: 1,
42          description: "Softwareentwicklung",
43          quantity: 40,
44          unit: "HUR",
45          unitPrice: 120.00,
46          taxRate: 19,
47          netAmount: 4800.00,
48          taxAmount: 912.00,
49          grossAmount: 5712.00
50        },
51        {
52          position: 2,
53          description: "Server-Hosting (Januar 2025)",
54          quantity: 1,
55          unit: "MON",
56          unitPrice: 299.00,
57          taxRate: 19,
58          netAmount: 299.00,
59          taxAmount: 56.81,
60          grossAmount: 355.81
61        }
62      ],
63      subtotal: 5099.00,
64      total: 6067.81,
65      taxSummary: [
66        { taxRate: 19, netAmount: 5099.00, taxAmount: 968.81 }
67      ],
68      paymentTerms: {
69        dueDays: 30,
70        description: "Zahlbar innerhalb von 30 Tagen ohne Abzug"
71      }
72    }
73  })
74});
75 
76const result = await response.json();
77// Response: { success, format, filename, mimeType, hash, data (base64), errors, warnings }
78console.log("Format:", result.format, "Datei:", result.filename);

1# Python - E-Rechnung erstellen
2import requests
3import os
4 
5response = requests.post(
6    "https://service.invoice-api.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        "invoice": {
13            "type": "invoice",
14            "invoiceNumber": "RE-2025-001",
15            "issueDate": "2025-01-15",
16            "dueDate": "2025-02-15",
17            "currency": "EUR",
18            "seller": {
19                "name": "Meine Firma GmbH",
20                "vatId": "DE123456789",
21                "street": "Musterstraße 1",
22                "city": "Berlin",
23                "postalCode": "10115",
24                "countryCode": "DE"
25            },
26            "buyer": {
27                "name": "Kunde AG",
28                "vatId": "DE987654321",
29                "street": "Kundenweg 42",
30                "city": "München",
31                "postalCode": "80331",
32                "countryCode": "DE"
33            },
34            "items": [
35                {
36                    "position": 1,
37                    "description": "Softwareentwicklung",
38                    "quantity": 40,
39                    "unit": "HUR",
40                    "unitPrice": 120.00,
41                    "taxRate": 19,
42                    "netAmount": 4800.00,
43                    "taxAmount": 912.00,
44                    "grossAmount": 5712.00
45                }
46            ],
47            "subtotal": 4800.00,
48            "total": 5712.00,
49            "taxSummary": [
50                { "taxRate": 19, "netAmount": 4800.00, "taxAmount": 912.00 }
51            ],
52            "paymentTerms": { "dueDays": 30 }
53        }
54    }
55)
56 
57result = response.json()
58# Response: {success, format, filename, mimeType, hash, data (base64), errors, warnings}
59print(f"Format: {result['format']}, Datei: {result['filename']}")

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  },
5  "countrySpecific": {
6    "countryCode": "DE",
7    "leitwegId": "991-12345-67"
8  }
9}

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  "seller": {
3    "bankAccount": {
4      "iban": "DE89370400440532013000",
5      "bic": "COBADEFFXXX"
6    }
7  },
8  "paymentTerms": {
9    "dueDays": 30,
10    "description": "Zahlbar innerhalb 30 Tagen auf das genannte Konto"
11  }
12}

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-api.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. Eine Schritt-für-Schritt-Anleitung findest du in unserer n8n E-Rechnungs-Integration mit fertigen Workflow-Templates.

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-api.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.