E-Rechnung API für XRechnung und ZUGFeRD: Architektur, Felder und Validierung

E-Rechnung API für XRechnung und ZUGFeRD: Architektur, Felder und Validierung

Wenn Rechnungen täglich aus einem ERP, einem B2B-Shop, einer SaaS-Anwendung oder einem eigenen Abrechnungssystem entstehen, reicht ein Datei-Export allein nicht aus. Die Rechnungsdaten müssen in ein passendes Format überführt, vollständig zugeordnet, geprüft und zuverlässig an den nächsten Prozessschritt übergeben werden.

Genau hier setzt eine E-Rechnung API an. Sie verbindet das bestehende Quellsystem mit den strukturierten Formaten XRechnung und ZUGFeRD. Dabei geht es nicht nur um die Erzeugung einer XML-Datei. Eine brauchbare Schnittstelle muss auch Pflichtfelder, Steuerlogik, Referenzen, Validierung, Fehlerbehandlung und den späteren Versand oder die Archivierung berücksichtigen.

Seit dem 1. Januar 2025 liegt nach der Einordnung des Bundesfinanzministeriums nur dann eine E-Rechnung vor, wenn sie in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht. Ein einfaches PDF ist deshalb nicht automatisch eine E-Rechnung. Für Übergangsfristen und Ausnahmen gelten weitere gesetzliche Vorgaben; maßgeblich bleibt die aktuelle BMF-FAQ zur E-Rechnung.

Die kurze Antwort: Was leistet eine E-Rechnung API?

Eine E-Rechnung API nimmt Rechnungsdaten aus einem vorhandenen System entgegen und liefert daraus eine strukturierte, geprüfte Rechnung für den gewünschten Empfängerprozess. Typischerweise übernimmt sie diese Aufgaben:

1. Daten entgegennehmen: Ein ERP, CRM, Shop, eine SaaS-Anwendung oder ein Fachverfahren übermittelt strukturierte Daten, meist als JSON. Bei älteren Systemen können auch PDF-, CSV- oder XML-Exporte der Ausgangspunkt sein.
2. Daten zuordnen: Rechnungsnummer, Datum, Verkäufer, Käufer, Positionen, Steuern, Zahlungsdaten und Referenzen werden den passenden Geschäftsbegriffen der EN 16931 und dem gewählten Zielformat zugeordnet.
3. Ausgabe erzeugen: Je nach Empfänger entsteht eine XRechnung als XML oder eine ZUGFeRD-Rechnung als PDF/A-3 mit eingebetteten XML-Daten.
4. Vor der Übergabe prüfen: Syntax, Pflichtfelder, Codelisten, Beträge, Steuerlogik und formatspezifische Regeln werden validiert.
5. Ergebnis zurückgeben: Die Schnittstelle liefert die fertige Datei, einen Prüfbericht, einen Status oder eine strukturierte Fehlermeldung zurück. Bei größeren Volumen kann sie zusätzlich mit Webhooks, Freigaben und Wiederholungslogik arbeiten.

Eine API ersetzt dabei nicht die fachliche Verantwortung für die Rechnung. Sie sorgt aber dafür, dass die Regeln nicht in jedem angeschlossenen System neu und unterschiedlich umgesetzt werden müssen.

E-Rechnung, XRechnung und ZUGFeRD: Was ist der Unterschied?

E-Rechnung ist der Oberbegriff für strukturierte elektronische Rechnungen. XRechnung und ZUGFeRD sind unterschiedliche Ausprägungen, die auf gemeinsamen europäischen Rechnungsanforderungen aufbauen, aber in der Praxis unterschiedliche Empfänger und Abläufe bedienen.

XRechnung und ZUGFeRD sind deshalb keine austauschbaren Dateiendungen. Bei XRechnung steht die strukturierte XML-Rechnung im Mittelpunkt. Bei ZUGFeRD kommen eine sichtbare PDF-Darstellung und der strukturierte Datenteil zusammen. Bei einer hybriden Rechnung muss der strukturierte Teil fachlich mit der sichtbaren Darstellung übereinstimmen. Das BMF weist außerdem darauf hin, dass bei Abweichungen die strukturierten Rechnungsdaten maßgeblich sind.

Versionen und technische Prüfregeln

Die zugrunde liegenden Normen, Codelisten und Prüfregeln werden fortgeschrieben. Zum Zeitpunkt der Überarbeitung dieses Beitrags sind unter anderem XRechnung 3.0.2 sowie ZUGFeRD 2.5 / Factur-X 1.09 relevant. Für eine produktive Integration ist aber nicht die im Artikel genannte Versionsnummer allein entscheidend, sondern das mit dem Empfänger vereinbarte und aktuell geprüfte technische Bundle.

Eine API sollte deshalb Versionen ausdrücklich behandeln. Test- und Produktivumgebung müssen mit festgelegten Prüfregeln arbeiten, statt stillschweigend immer die neueste verfügbare Regel einzusetzen. So bleiben bestehende Rechnungsprozesse nachvollziehbar, wenn sich Codelisten oder Validierungsartefakte ändern. Die Versionsübersicht der XRechnung und die aktuellen Veröffentlichungen des FeRD zu ZUGFeRD/Factur-X sind dafür gute Ausgangspunkte.

Wann lohnt sich eine E-Rechnung API?

Eine Schnittstelle ist besonders sinnvoll, wenn Rechnungen regelmäßig entstehen oder mehrere Systeme beteiligt sind. Typische Anzeichen sind:

• Rechnungen werden täglich oder monatlich aus ERP, Warenwirtschaft, CRM, Shop oder SaaS erzeugt.
• Dasselbe Rechnungsdatum muss je nach Empfänger als XRechnung oder ZUGFeRD ausgegeben werden.
• Die Rechnungsdaten sollen nach der Prüfung automatisch zurück ins ERP, ins Archiv oder in einen Versandprozess fließen.
• Gutschriften, Abschläge, Schlussrechnungen, Reverse Charge oder mehrere Steuersätze kommen regelmäßig vor.
• Manuelle Uploads, Downloads und erneute Übertragungen verursachen Wartezeit und Fehler.
• Mehrere Mandanten, Kundenprofile oder Empfängeranforderungen müssen getrennt verwaltet werden.

Für einzelne Rechnungen ist eine API häufig unnötig. Dann reichen je nach Ausgangslage ein E-Rechnung-Konverter, der XRechnung-Generator, der ZUGFeRD-Generator oder ein Validator. Eine API wird interessant, sobald aus einer einzelnen Datei ein wiederholbarer Geschäftsprozess wird.

Architektur einer stabilen E-Rechnung API

Eine gute E-Rechnung API ist eine Verarbeitungskette mit klaren Zuständigkeiten. Der wichtigste Grundsatz lautet: Das Quellsystem bleibt für die kaufmännischen Daten verantwortlich, die E-Rechnungsstrecke übernimmt Zuordnung, Formatlogik und Prüfung.

Die Trennung ist wichtig, weil sich ein einzelnes ERP-Feld selten direkt auf ein XML-Element abbilden lässt. Beispielsweise können Zahlungsbedingungen, Steuerkategorien oder Referenzen aus mehreren Quellfeldern entstehen. Umgekehrt muss ein Pflichtfeld im Zielstandard möglicherweise aus einer Datenquelle ergänzt werden, die das ursprüngliche System nicht als eigenes Feld führt.

JSON-zu-E-Rechnung: Ein neutrales Eingabemodell

Das angeschlossene System sollte nicht die komplette XML-Struktur von UBL oder CII kennen müssen. Besser ist ein stabiles Eingabemodell, das kaufmännische Fakten beschreibt. Die API entscheidet anschließend, wie diese Fakten im gewünschten Format abgebildet werden.

Ein vereinfachtes Beispiel sieht so aus:

{
  "document": {
    "number": "2026-10045",
    "issueDate": "2026-07-03",
    "type": "invoice",
    "currency": "EUR",
    "buyerReference": "04011000-12345-67",
    "purchaseOrder": "PO-98441"
  },
  "seller": {
    "name": "Muster GmbH",
    "street": "Musterstraße 1",
    "postalCode": "10115",
    "city": "Berlin",
    "country": "DE",
    "vatId": "DE123456789",
    "email": "rechnung@muster-gmbh.de"
  },
  "buyer": {
    "name": "Beispiel AG",
    "street": "Beispielweg 5",
    "postalCode": "80331",
    "city": "München",
    "country": "DE",
    "vatId": "DE987654321"
  },
  "items": [
    {
      "description": "Technische Beratung im Juli 2026",
      "quantity": 10,
      "unitCode": "HUR",
      "netUnitPrice": 120.00,
      "vatRate": 19.00
    }
  ],
  "output": {
    "format": "xrechnung",
    "syntax": "ubl"
  }
}

Für ZUGFeRD kann im Ausgabeabschnitt beispielsweise format: "zugferd" mit dem vereinbarten Profil stehen. Die fachlichen Rechnungsdaten bleiben weitgehend gleich, die technische Ausgabe und die zusätzlichen Anforderungen an PDF/A-3, eingebettete XML-Daten und Profilprüfung unterscheiden sich jedoch.

Ein solches Modell sollte nicht nur die Standardrechnung abbilden. Von Anfang an sollten auch Korrekturrechnungen, Gutschriften, Anzahlungen, Abschläge, Schlussrechnungen, abweichende Zahlungsempfänger und mehrere Steuergruppen vorgesehen werden. Nicht jeder Sonderfall braucht ein eigenes API-Format, aber jeder Sonderfall braucht eine eindeutige fachliche Bedeutung.

Welche Felder müssen zuverlässig übertragen werden?

Die häufigsten Integrationsprobleme entstehen nicht bei der Dateierzeugung, sondern bei unvollständigen oder uneindeutigen Eingangsdaten. Die folgende Übersicht zeigt die wichtigsten Gruppen:

Käuferreferenz und Leitweg-ID

Bei Rechnungen an öffentliche Auftraggeber ist die Käuferreferenz besonders wichtig. Häufig wird dort die Leitweg-ID eingetragen. Im fachlichen Modell sollte sie deshalb nicht als beliebiger Freitext neben der Rechnung gespeichert werden, sondern als eigene, validierbare Referenz mit klarer Zuordnung zum Empfänger.

Für B2B-Rechnungen kann der Empfänger ebenfalls eine Käuferreferenz, Bestellnummer, Projekt- oder Kostenstellenangabe verlangen. Ob eine Leitweg-ID benötigt wird, hängt vom jeweiligen Empfängerprozess ab. Eine API darf diese Information daher nicht pauschal für jede Rechnung erzwingen, sollte aber Empfängerprofile mit eigenen Pflichtfeldregeln unterstützen.

Rechnungstypen und Sonderfälle

Eine Standardrechnung ist der einfachste Testfall. In der produktiven Integration sollten mindestens diese Belegarten geprüft werden:

• Gutschrift und Korrekturrechnung
• Anzahlungs-, Abschlags- und Schlussrechnung
• Storno und Berichtigung
• Reverse Charge und steuerfreie Umsätze
• mehrere Steuersätze in einer Rechnung
• abweichender Zahlungsempfänger oder Factoring
• Bau- und Projektabrechnungen mit Vorgängerrechnungen
• rechnungsbegründende Anlagen

Gerade Abschlags- und Schlussrechnungen zeigen, warum die Zuordnung der PDF-Daten nicht nur Beträge ablesen darf. Bereits gezahlte Beträge, Vorgängerbelege und der offene Zahlbetrag müssen im strukturierten Datensatz zusammenpassen. Für solche Fälle können spezialisierte Enterprise-Prozesse wie Schlussrechnung als E-Rechnung, Abschlagsrechnung als E-Rechnung oder Gutschrift und Storno sinnvoll sein.

REST-Endpunkte und Verarbeitungsmodelle

Eine E-Rechnung API kann synchron oder asynchron arbeiten. Bei einer kleinen Rechnung mit vollständig strukturierten Daten ist eine sofortige Antwort praktisch. Bei PDF-Verarbeitung, großen Stapeln, manuellen Freigaben oder mehreren Validierungsschritten ist ein asynchroner Ablauf robuster.

Beispiele für eine ressourcenorientierte Schnittstelle:

POST /api/v1/e-invoices
GET  /api/v1/e-invoices/{id}
GET  /api/v1/e-invoices/{id}/status
GET  /api/v1/e-invoices/{id}/document
GET  /api/v1/e-invoices/{id}/validation-report
POST /api/v1/e-invoices/{id}/release

Bei einer asynchronen Verarbeitung kann die API zunächst 202 Accepted und eine Vorgangs-ID zurückgeben. Das Quellsystem ruft den Status ab oder erhält eine Benachrichtigung per Webhook. Wichtig sind dabei:

• Idempotenz: Derselbe Auftrag darf bei einem Netzwerkfehler nicht versehentlich zwei Rechnungen erzeugen.
• Versionierung: Änderungen am Eingabemodell und an der Ausgabe müssen kontrolliert eingeführt werden.
• Eindeutige Vorgangs-ID: Jeder Auftrag muss bis zur fertigen Datei und zum Prüfbericht nachvollziehbar bleiben.
• Wiederholbarkeit: Ein technischer Übertragungsfehler muss erneut versucht werden können, ohne eine fachlich neue Rechnung zu erzeugen.
• Klare Zustände: received, processing, validation_failed, validated, released und failed sind verständlicher als eine einzige allgemeine Statusmeldung.

Die genauen Pfade sind immer ein Beispiel. Entscheidend ist die Trennung zwischen Auftrag, erzeugtem Dokument, Validierungsbericht und Übergabe. Ein einzelner Endpunkt, der bei jedem Fehler nur „XML konnte nicht erstellt werden“ zurückgibt, ist für angeschlossene Systeme kaum nutzbar.

Validierung: XRechnung und ZUGFeRD getrennt prüfen

Die Aussage „XML wurde erzeugt“ bedeutet noch nicht, dass eine E-Rechnung angenommen wird. Eine belastbare Prüfstrecke betrachtet mehrere Ebenen.

XRechnung

Bei XRechnung gehören typischerweise dazu:

1. XML-Syntax: Ist die Datei wohlgeformt und entspricht sie der verwendeten UBL- oder CII-Syntax?
2. EN-16931-Regeln: Sind die europäischen Geschäftsregeln für Pflichtfelder, Summen und Beziehungen erfüllt?
3. XRechnung-Regeln: Passen deutsche Konkretisierungen, Käuferreferenz, Profilkennung und weitere nationale Anforderungen?
4. Codelisten: Sind Währung, Länder, Einheiten, Steuerkategorien und Zahlungsarten gültig?
5. Rechenlogik: Stimmen Positionsnetto, Steuerbetrag, Brutto, Zu- und Abschläge sowie Zahlbetrag überein?

Für XRechnung ist die KoSIT-Validierung ein wichtiger Bestandteil vieler automatisierter Prozesse. Einzelne Dateien lassen sich mit dem XRechnung Validator prüfen. Ein Validatorbericht sollte dabei nicht nur „gültig“ oder „ungültig“ liefern, sondern Regel, Feld, Schweregrad und Korrekturhinweis zurückgeben.

ZUGFeRD

Bei ZUGFeRD kommt neben den strukturierten Daten die PDF-Seite hinzu. Zu prüfen sind unter anderem:

• PDF/A-3-Konformität und technische Eigenschaften der Datei
• korrekt eingebettetes XML und passendes Profil
• CII-Syntax und EN-16931-Geschäftsregeln
• Übereinstimmung von PDF-Darstellung und strukturierten Rechnungsdaten
• zulässige Anlagen und deren Zuordnung

Der ZUGFeRD Validator prüft hybride Rechnungen im Browser. Für automatisierte Abläufe können KoSIT-, Mustang- und PDF/A-Prüfungen als getrennte oder kombinierte Prüfschritte eingerichtet werden. Eine passende Validierungsstrecke für KoSIT, Mustang und veraPDF ist besonders interessant, wenn verschiedene Formate in einem Prozess zusammenlaufen.

Das BMF empfiehlt eine Validierung bereits bei Erstellung und Versand, stellt aber klar, dass die Validierung selbst keine unmittelbare steuerliche Voraussetzung für die Anerkennung ist. Sie ist ein technisches Sicherheitsnetz: Fehler werden sichtbar, bevor Kunden, Behördenportale oder interne Buchhaltungssysteme sie zurückweisen.

Fehlerbehandlung, die ein ERP wirklich nutzen kann

Fehler gehören in einer E-Rechnung API zum normalen Ablauf. Entscheidend ist, ob das angeschlossene System damit arbeiten kann. Ein fehlendes Feld ist kein allgemeiner Serverausfall, sondern ein korrigierbarer Eingabefehler.

Eine strukturierte Antwort kann zum Beispiel so aussehen:

{
  "status": "validation_failed",
  "invoiceId": "inv_123",
  "format": "xrechnung",
  "errors": [
    {
      "severity": "error",
      "ruleId": "BR-DE-15",
      "field": "buyerReference",
      "businessTerm": "BT-10",
      "message": "Die Käuferreferenz fehlt.",
      "hint": "Leitweg-ID oder die vom Empfänger geforderte Referenz ergänzen."
    }
  ]
}

Die Bezeichnungen sind beispielhaft. Für die Integration sind vor allem severity, Regelkennung, Feld, Business Term und ein verständlicher Korrekturhinweis wertvoll. So kann das ERP die Rechnung anhalten, die Buchhaltung informieren oder die fehlenden Daten nachfordern, ohne eine unklare Fehlermeldung analysieren zu müssen.

Sicherheit und Datenschutz bei Rechnungsdaten

Eine E-Rechnung API verarbeitet Kunden-, Zahlungs- und Steuerdaten. Sicherheitsanforderungen gehören deshalb in die erste Architekturentscheidung und nicht erst in die Abnahme.

• Übertragung ausschließlich verschlüsselt per HTTPS/TLS
• sichere Authentifizierung und getrennte Schlüssel für Test und Produktion
• Mandanten- und Rechtekonzept für mehrere Unternehmen oder Anwendungen
• Idempotenz- und Wiederholungslogik gegen doppelte Verarbeitung
• sparsame Protokollierung ohne vollständige Rechnungsinhalte oder Zugangsdaten
• definierte Speicher- und Löschfristen für Uploads, Zwischendateien und Prüfberichte
• AVV und dokumentierte Unterauftragsverarbeiter, wenn personenbezogene Daten verarbeitet werden
• nachvollziehbare Versionierung von Eingabemodell, Datenzuordnung und Prüfregeln
• getrennte Freigabe für technische Validierung und fachliche Weitergabe

Bei ZUGFeRD sollte außerdem klar sein, wo PDF und eingebettetes XML gespeichert werden und welches Dokument als Original archiviert wird. Bei XRechnung muss der strukturierte Datensatz vollständig und unverändert aufbewahrt werden. Für die konkrete Archivierung sind die steuerlichen und organisatorischen Anforderungen des eigenen Unternehmens zu prüfen.

Ein sinnvoller Integrationsplan in acht Schritten

Eine E-Rechnung API muss nicht mit allen Sonderfällen gleichzeitig starten. Ein kontrollierter Pilot spart später Nacharbeit.

1. Reale Belege sammeln

Nehmen Sie repräsentative Rechnungen aus dem echten Prozess: Standardrechnung, Gutschrift, Korrektur, mehrere Steuersätze, eine Rechnung mit Anlage sowie – falls relevant – Abschlag oder Schlussrechnung.

2. Empfänger und Ausgabe festlegen

Klären Sie je Empfänger, ob XRechnung, ZUGFeRD oder ein anderes zulässiges Format verlangt wird, welche Syntax und welches Profil gelten und über welchen Kanal die Datei übergeben wird.

3. Quellsystem dokumentieren

Erfassen Sie, welche Informationen als strukturierte Felder vorhanden sind und welche nur im PDF, in einer Anlage oder in einem Freitext stehen. Fehlende Daten sollten früh sichtbar werden.

4. Gemeinsames Rechnungsmodell definieren

Legen Sie Namen, Datentypen, Pflichtfelder, Codes und die Bedeutung von Sonderfällen fest. Das Modell sollte nicht an eine einzelne XML-Syntax gekoppelt sein.

5. Zuordnungsmatrix erstellen

Dokumentieren Sie für jedes relevante Quellfeld, in welches fachliche Rechnungsfeld es fließt, welche Umrechnung erforderlich ist und wann eine manuelle Prüfung ausgelöst wird.

6. Prüfstrecke vor Versand schalten

Erzeugen Sie zunächst Testdateien und validieren Sie XRechnung und ZUGFeRD mit den jeweils passenden Regeln. Prüfen Sie zusätzlich, ob PDF und XML fachlich übereinstimmen.

7. Fehler- und Freigabeprozess festlegen

Definieren Sie, ob ein Fehler an das ERP zurückgeht, in einer Prüfliste landet, von der Buchhaltung ergänzt wird oder den Versand blockiert. Eine automatische Ausgabe ohne klare Ausnahmebehandlung ist bei Rechnungen riskant.

8. Übergabe und Betrieb beobachten

Binden Sie Download, Archiv, E-Mail, Portal, Peppol oder interne Übergaben erst nach erfolgreicher Prüfung an. Überwachen Sie danach Status, Fehlerraten und Änderungen an Versionen oder Empfängeranforderungen.

RechneX für API-, ERP- und Enterprise-Prozesse

Für einzelne Dateien bietet RechneX browserbasierte Werkzeuge zum Erstellen, Konvertieren, Anzeigen und Validieren. Für wiederkehrende Rechnungen aus einem bestehenden System ist dagegen ein abgestimmter Prozess sinnvoll: mit Datenprüfung, festen Zuordnungen, dem gewünschten Ausgabeformat und einem definierten Umgang mit Fehlern.

Die dedizierte E-Rechnung-API-Landingpage beschreibt diesen Enterprise-Einstieg für XRechnung, ZUGFeRD, Validierung und ERP- oder SaaS-Anbindungen. Je nach Ausgangssystem und Schwerpunkt können weitere Seiten die passende Vertiefung sein:

• ERP zu E-Rechnung für vorhandene ERP-, CSV-, XML- oder PDF-Exporte
• ERP-PDF zu ZUGFeRD für einen pragmatischen Einstieg über bestehende PDF-Ausgaben
• Shopware E-Rechnung für B2B-Shopprozesse
• ZUGFeRD PDF/A-3 und Design für hybride Rechnungen mit eigener Darstellung
• KoSIT, Mustang und veraPDF für kombinierte Prüfstrecken
• Enterprise für automatisierte E-Rechnungen für individuelle Volumen, Freigaben und Systemintegration

Häufige Fragen zur E-Rechnung API

Kann eine API gleichzeitig XRechnung und ZUGFeRD erzeugen?

Ja, wenn das Eingabemodell alle benötigten Rechnungsdaten enthält und die Ausgabe je Empfänger gesteuert wird. Die Formate haben aber unterschiedliche technische Anforderungen. XRechnung ist eine XML-Rechnung, ZUGFeRD kombiniert PDF/A-3 mit eingebettetem XML. Eine gemeinsame API bedeutet daher nicht, dass dieselbe Datei unverändert für jeden Empfänger passt.

Muss eine E-Rechnung API PDF-Dateien akzeptieren?

Nein. Für neue Integrationen sind strukturierte Eingabedaten meist der sauberste Weg. Bei älteren ERP- oder Branchenlösungen kann die Zuordnung von PDF- oder Exportdaten trotzdem sinnvoll sein. Dann sollte der Prozess unsichere Erkennungen markieren und eine fachliche Prüfung ermöglichen. Mehr dazu zeigt der Beitrag PDF in XRechnung oder ZUGFeRD umwandeln.

Welche Felder führen besonders häufig zu Fehlern?

Typisch sind Käuferreferenz und Leitweg-ID, Verkäufer- und Käuferdaten, Steuerkategorie und Steuersatz, Zahlungsdaten sowie Positions- und Gesamtsummen. Auch der falsche Rechnungstyp bei Gutschriften, Korrekturen oder Schlussrechnungen verursacht häufig Ablehnungen.

Reicht eine erfolgreiche technische Validierung aus?

Nein. Die Validierung prüft technische und definierte fachliche Regeln. Sie ersetzt nicht die Kontrolle, ob Leistung, Empfänger, Referenzen, Steuerfall und Zahlungsbedingungen tatsächlich zum Geschäftsvorgang passen. Für automatisierte Prozesse sollte die technische Prüfung deshalb mit einem fachlichen Freigabeschritt für Ausnahmen verbunden werden.

Wann ist eine Enterprise-Anbindung sinnvoll?

Enterprise ist sinnvoll, wenn Rechnungen automatisch aus ERP, Shop, SaaS oder Fachverfahren verarbeitet werden sollen, wenn größere Volumen oder mehrere Empfängerprofile vorkommen oder wenn Sonderfälle, Freigaben, Fehlerlisten und individuelle Rückgaben benötigt werden. Für einzelne Rechnungen bleiben Browser-Werkzeuge meist der einfachere Einstieg.

Kann eine API auch die Validierung übernehmen?

Ja. Die Validierung kann als fester Schritt vor der Rückgabe, Freigabe oder dem Versand eingebaut werden. Für XRechnung sind KoSIT-Regeln relevant; bei ZUGFeRD kommen Prüfungen für CII, Profil, eingebettetes XML und PDF/A-3 hinzu. Welche Prüfungen konkret eingesetzt werden, hängt von Format, Version und Empfängerprozess ab.

Fazit: Eine E-Rechnung API verbindet Daten, Formate und Prozesse

Eine E-Rechnung API ist mehr als ein XML-Generator. Sie verbindet ERP, Shop, SaaS oder Fachverfahren mit dem passenden E-Rechnungsformat und sorgt dafür, dass Daten vollständig zugeordnet, validiert und kontrolliert weitergegeben werden.

XRechnung eignet sich besonders für strukturierte B2G-Prozesse und Empfänger, die eine XML-Rechnung erwarten. ZUGFeRD verbindet eine lesbare PDF-Darstellung mit eingebetteten XML-Daten und ist deshalb für viele B2B-Abläufe praktisch. Eine gemeinsame API kann beide Formate bedienen, wenn Datenmodell, Empfängerregeln, Versionen und Prüfstrecke sauber getrennt behandelt werden.

Wenn Sie eine vorhandene Rechnung zunächst prüfen oder umwandeln möchten, können Sie mit dem RechneX-Konverter oder dem E-Rechnung-Validator starten. Wenn Rechnungen regelmäßig aus Ihrem System kommen, finden Sie auf der Seite zur E-Rechnung API den passenden Einstieg für eine individuelle Anbindung.

Quellen und weiterführende Informationen

• Bundesfinanzministerium: Fragen und Antworten zur E-Rechnung
• XStandards Einkauf: Standard XRechnung
• XStandards Einkauf: FAQ zur XRechnung
• XStandards Einkauf: Versionen und Bundles
• Forum elektronische Rechnung Deutschland: ZUGFeRD/Factur-X
• FeRD: Neue ZUGFeRD-Version 2.5 veröffentlicht