E-Rechnung per API — selbst bauen oder Schnittstelle nutzen? Der Build-vs-Buy-Guide

E-Rechnung per API: aus "kurz selbst gemacht" werden Wochen

Das Ticket klingt harmlos: "E-Rechnung in unser ERP / unseren Shop / die Buchhaltung einbauen." Ein Entwickler schätzt zwei Tage — ein XML erzeugen, fertig. Drei Wochen später steht er noch immer im Code: Aus "ein XML" sind zwei gleichberechtigte Syntaxen geworden, aus "valide" rund 200 Geschäftsregeln plus deutsche Zusatzregeln, aus "verschicken" ein zertifizierter Übertragungsweg — und die erste neue Spezifikationsversion ist auch schon angekündigt. Das ist kein schlechtes Schätzen. Das ist der Normalfall, wenn man den Aufwand von E-Rechnung am sichtbaren Teil misst.

Genau hier fällt eine Entscheidung, die viele Teams beiläufig treffen, obwohl sie strategisch ist: selbst bauen oder eine Schnittstelle nutzen. Beiläufig fällt sie, weil sie sich als technische Detailfrage tarnt ("brauchen wir dafür wirklich einen Dienstleister?") — strategisch ist sie, weil an ihr ein Stück Software hängt, das über Jahre gepflegt werden will. Dieser Artikel macht die Build-vs-Buy-Frage explizit. Er zeigt den ehrlichen Selbstbau-Aufwand, wo Peppol den Selbstbau praktisch beendet, eine Entscheidungstabelle ohne Verkaufspitch — und die Fälle, in denen Selbstbau die richtige Wahl ist.

Wichtige Abgrenzung vorab: Wer das Wie des Selbstbaus im Detail sucht (XML-Struktur, UBL/CII, Validierung in Code), findet das in XRechnung implementieren. Dieser Artikel beantwortet die vorgelagerte Frage — ob man überhaupt selbst bauen sollte. Beide ergänzen sich: Build-Artikel als Entscheidung, der Implementierungs-Artikel als Vertiefung des Selbstbau-Pfads.

Was "E-Rechnung per API" technisch bedeutet

"E-Rechnung per API" ist kein einzelner Aufruf, sondern eine Kette aus vier Bausteinen. Wer Build-vs-Buy bewerten will, muss sie sauber trennen — jeder Baustein ist eine eigene Aufwandsquelle mit eigenen Fallstricken.

• Erzeugen. Aus den Auftrags- oder Buchhaltungsdaten ein valides strukturiertes Dokument bauen — als XML nach UBL 2.1 oder UN/CEFACT CII (D16B), bei ZUGFeRD als CII-Schicht eingebettet in ein PDF/A-3.
• Validieren. Das erzeugte Dokument gegen die Geschäftsregeln der EN 16931 und die deutsche XRechnung-CIUS prüfen — Referenz ist der KoSIT-Validator mit seiner Konfiguration.
• Konvertieren. Zwischen den Ausprägungen wechseln — XRechnung ↔ ZUGFeRD, UBL ↔ CII —, weil der Empfänger das Format und die Syntax vorgibt, nicht der Sender.
• Übertragen. Das Dokument zum Empfänger bringen — als E-Mail-Anhang, über ein Behördenportal oder über das Peppol-Netz via AS4.

Erst alle vier zusammen ergeben "E-Rechnung per API". Der häufigste Schätzfehler: Nur den ersten Baustein sehen ("wir generieren das XML") und die anderen drei für Details halten. Tatsächlich liegt der Aufwand fast vollständig in Validierung, Konvertierung und Übertragung.

Wichtig ist außerdem die Richtung: Jeder Baustein existiert ausgehend (eigene Rechnung erzeugen und senden) und eingehend (fremde Rechnung empfangen, lesen, prüfen). Wer nur den Ausgang baut, hat die halbe Strecke. Die Empfangspflicht trifft jeden inländischen Unternehmer bereits heute — der Eingang ist also kein optionaler Zusatz, sondern Teil derselben API-Aufgabe. Deshalb muss ein Selbstbau die Syntaxen nicht nur schreiben, sondern auch robust parsen, inklusive der optionalen Felder, die ein fremdes System gesetzt hat und das eigene nie verwendet.

Selbstbau: der wahre Aufwand

Der Selbstbau scheitert selten am ersten Tag — er scheitert über die Jahre. Vier Realitäten machen aus "ein XML erzeugen" ein dauerhaftes Stück Software. Sie sind einzeln machbar; in Summe und über Zeit bilden sie den Posten, den die anfängliche Zwei-Tage-Schätzung systematisch verfehlt.

Zwei Syntaxen, nicht "eine XML"

Die EN 16931 erlaubt zwei gleichberechtigte Syntaxen: UBL 2.1 und UN/CEFACT CII (D16B). XRechnung schreibt für den Empfang die Unterstützung beider vor; ZUGFeRD bettet die CII-Schicht in ein PDF/A-3 ein. Wer selbst baut, muss beide Syntaxbäume beherrschen — erzeugen und lesen, nicht ein Format. Der häufigste Unterschätzungsfehler: "Wir generieren halt das XML" — und dann trifft eine Eingangsrechnung in der jeweils anderen Syntax ein. Format-Differenzierung im Detail: XRechnung vs. ZUGFeRD.

~200+ Geschäftsregeln plus deutsche CIUS — und sie ändern sich

Eine valide E-Rechnung erfüllt die EN-16931-Geschäftsregeln (Typ BR-* und BR-CO-*) plus die deutschen Zusatzregeln der XRechnung-CIUS (Typ BR-DE-*). Die Referenzvalidierung läuft über den KoSIT-Validator mit seiner Validator-Konfiguration. Diese Regelwerke und die XRechnung-Spezifikation werden versioniert fortgeschrieben — in der Regel mit regelmäßigen neuen XRechnung-Versionen. Die Validierung selbst nachzubauen ist deshalb keine einmalige Aufgabe, sondern laufende Spec-Pflege: der am stärksten unterschätzte Treiber der Gesamtkosten. Wie diese Validierung im Code aussieht, zeigt XRechnung implementieren.

Die Regeln sind dabei nicht nur "Feld vorhanden ja/nein". Die BR-CO-*-Regeln sind Konsistenzbedingungen, die Beträge, Steuersätze und Summen gegeneinander rechnen — eine Rundungsdifferenz von einem Cent zwischen Positionssumme und Belegsumme kippt die Validierung. Die BR-DE-*-Regeln der CIUS verschärfen das deutsche Profil zusätzlich, etwa bei Routing-Angaben oder verpflichtenden Kontaktfeldern. Wer das selbst abbildet, baut nicht eine Prüfung, sondern ein kleines Regelwerk-System — und muss es bei jeder neuen Spezifikationsversion gegen die offizielle Konfiguration abgleichen, damit es nicht unbemerkt hinter der Referenz herläuft.

Box: Der Erstbau ist nicht das Problem — die Wartung ist es

Der erste valide XRechnung-Export ist in Tagen machbar. Was über Jahre Aufwand bindet, sind nicht die ersten Zeilen Code, sondern alles danach: neue Spezifikationsversionen, neue Regelstände, geänderte Pflichtfelder, die Konversion zwischen den Formaten und die Edge-Cases echter Eingangsrechnungen. Wer den Selbstbau am ersten validen Export misst, misst die kleinste Zahl der ganzen Rechnung. Mehr dazu in der TCO-Sektion weiter unten.

Ehrlich bleibt festzuhalten: Mit XML-Erfahrung, Standard-Kenntnis und sauberem Test-Setup ist der Selbstbau machbar — das ist keine Raketentechnik. Die Frage ist nicht, ob ein Team es kann, sondern ob es die laufende Spec-Pflege über Jahre tragen will.

Übertragung & Peppol: wo Selbstbau praktisch endet

Beim Übertragen entscheidet sich, wie weit der Selbstbau trägt. Drei Wege sind in der Praxis relevant — mit stark unterschiedlichem Aufwand.

• E-Mail-Anhang. Niedrigschwellig: Das valide XML oder ZUGFeRD-PDF geht als Anhang raus. Für die reine Zustellung im B2B oft ausreichend, ohne eigene Infrastruktur.
• Behördenportal. Im B2G werden E-Rechnungen über zentrale Portale eingereicht (Weberfassung oder Upload). Mehr zum Behördenweg: E-Rechnung an Behörden (B2G).
• Peppol via AS4. Der skalierbare, automatisierbare Weg — und der mit Abstand anspruchsvollste im Selbstbau.

Peppol ist der härteste Selbstbau-Blocker. Wer automatisiert über Peppol überträgt (der skalierbare Weg, unter anderem für B2G und EU-grenzüberschreitend), braucht einen zertifizierten Access Point: das AS4-Protokoll, die SMP/SML-Adressierung, eine OpenPeppol-Mitgliedschaft und eine Zertifizierung. Der Aufwand bemisst sich in der Regel in Monaten, dazu kommen laufende Kosten. Das ist praktisch nicht "mal eben selbst gebaut" — hier endet der Selbstbau für die meisten Teams, und ein zertifizierter Dienst oder eine API gewinnt fast immer. Hintergrund und deutscher Rollout: Peppol B2B in Deutschland 2026.

Der Grund für den hohen Aufwand liegt im Modell: Peppol funktioniert nach dem Vier-Ecken-Prinzip. Sender und Empfänger sprechen jeweils nur mit ihrem eigenen Access Point; die beiden Access Points tauschen das Dokument über AS4 aus. Damit ein Sender überhaupt weiß, wohin ein Empfänger adressiert ist, schlägt er die Empfänger-ID über SMP/SML nach — die Verzeichnisschicht des Netzes. Ein eigener Access Point heißt also: AS4-Endpunkt sicher betreiben, Zertifikate verwalten, die SMP-Registrierung pflegen, die OpenPeppol-Vorgaben einhalten und die Zertifizierung bestehen — und das dauerhaft, nicht zum Start. Genau deshalb mieten selbst Teams mit eigener XML-Pipeline den Peppol-Zugang meist zu, statt ihn zu bauen.

Build-vs-Buy: die Entscheidungstabelle

Es gibt kein pauschales "kauf immer". Ob Build oder Buy die richtige Wahl ist, hängt an fünf Faktoren — und die ehrliche Tabelle ist hier wertvoller als jeder Verkaufspitch.

Wann Build: hohes Volumen und vorhandene In-House-Expertise und ein strategisches Interesse an Kontrolle über den Stack — etwa wenn die Rechnungslogik selbst Teil des Produkts ist oder regulatorische Gründe die Datenhaltung im eigenen Haus verlangen. Dann schlagen die Stückkosten die Fixkosten, und das Team kann die laufende Spec-Pflege tragen. Typische Build-Kandidaten sind Software-Häuser, die E-Rechnung als Funktion an ihre eigenen Kunden weiterreichen, sehr große Rechnungssteller mit sechs- oder siebenstelligen Belegmengen pro Jahr, oder Organisationen, die aus regulatorischen Gründen keine Rechnungsdaten an Dritte geben dürfen. Für sie ist der eigene Stack kein Kostenposten, sondern ein Aktivposten — die Fixkosten verteilen sich auf so viele Belege, dass die Schnittstellengebühr teurer käme.

Wann Buy: Standard-Anforderung, schnelle Integration, keine Lust und kein Anlass, EN-16931- und XRechnung-Versionen im eigenen Team mitzuziehen. Für die meisten Unternehmen ist E-Rechnung eine Pflicht, kein Differenzierungsmerkmal — dann ist die Schnittstelle der direktere Weg. Das gilt besonders dort, wo Time-to-Market zählt: Die Sendepflicht greift ab 2027 stufenweise, die Empfangspflicht gilt bereits. Wer erst dann anfängt, Peppol-Zertifizierung und Validator-Pflege aufzubauen, wenn der erste große Kunde eine XRechnung erwartet, kommt zu spät. Eine Schnittstelle ist in Tagen integriert; ein eigener Access Point nicht.

Eine dritte Option wird oft übersehen: der Mittelweg. Man kann das Erzeugen im eigenen System behalten (volle Kontrolle über das Feld-Mapping aus dem ERP) und nur die teuren, beweglichen Teile zukaufen — Validierung gegen die jeweils aktuelle Spezifikation und die Peppol-Einreichung. Das hält die Stack-Hoheit dort, wo sie strategisch zählt, und lagert genau die zwei Bausteine aus, die im Selbstbau am stärksten driften. Build-vs-Buy ist also keine Alles-oder-nichts-Entscheidung pro Baustein, sondern eine Entscheidung je Baustein.

Hier der Produkt-Tie-in, offen gesagt: Eine fertige E-Rechnungs-API liefert genau die vier Bausteine als Schnittstelle — Erzeugen valider XRechnung in UBL/CII, Validierung gegen EN 16931 und CIUS, sowie die Peppol-Einreichung —, und die Wartung samt Versionspflege ist eingeschlossen. Das ist der Unterschied zwischen einer einmaligen Integration und einem dauerhaften eigenen Entwicklungsstrang. Wer Endprodukte für Anwender vergleichen will (statt die Entwickler-Integration), findet das im E-Rechnung Software-Vergleich 2026.

Integration einer E-Rechnungs-API in der Praxis

Entscheidet sich ein Team für Buy, verschiebt sich die Arbeit von "Standard nachbauen" zu "Schnittstelle sauber einbinden". Das ist deutlich kleiner — aber kein Selbstläufer. Wie sieht eine API-Integration in ERP, Shop oder Buchhaltung konkret aus?

Erzeugen und Validieren: der Ausgangs-Flow

Im einfachsten Fall ist es ein REST-Aufruf: Die Auftrags- oder Buchungsdaten gehen als strukturierte Nutzlast an die API, zurück kommt das valide Dokument — XRechnung in der passenden Syntax oder ZUGFeRD als hybrides PDF. Validierung gegen EN 16931 und CIUS läuft serverseitig mit; das Ergebnis ist ein deterministisches "valide / nicht valide" samt Fehlerliste, ohne dass der KoSIT-Validator im eigenen Stack betrieben werden muss.

Ein typischer Flow von den Auftragsdaten bis zur Einreichung:

1. Mapping. Auftrags-/Rechnungsfelder aus ERP oder Shop auf das API-Schema abbilden (Positionen, Steuersätze, Beträge, Empfänger, Routing-IDs).
2. Erzeugen + Validieren. Ein Aufruf erzeugt das Dokument und validiert es gegen EN 16931 und die deutsche CIUS; ungültige Belege werden vor dem Versand gestoppt.
3. Übertragen. Bei Peppol übernimmt der Dienst die Einreichung über den zertifizierten Access Point; bei E-Mail/Portal liefert die API das fertige Dokument.
4. Statusrückmeldung. Die Übertragung meldet zurück (angenommen, abgewiesen, Fehler) — der Status wird im Quellsystem am Beleg vermerkt.

Empfang: Webhook oder Pull

Die Gegenrichtung — eingehende E-Rechnungen — läuft über einen Webhook (die API meldet einen neuen Beleg) oder über Pull (das Quellsystem fragt periodisch ab). In beiden Fällen liefert die Schnittstelle das Original-Dokument plus die ausgelesenen Felder als strukturierte Nutzlast — der Empfänger muss das XML nicht selbst parsen, bekommt aber das Original für die GoBD-konforme Archivierung mit. Welche Variante passt, hängt am Volumen: Webhook für ereignisgetriebene Verarbeitung in nahezu Echtzeit, Pull für planbare Batch-Läufe. Die fachliche Empfangs- und Verarbeitungsseite — Vorsteuer, Verbuchung, GoBD — behandelt E-Rechnung empfangen & verarbeiten im Detail.

Was die Integration robust macht

• Idempotenz. Jeder Erzeugungs- und Sende-Aufruf trägt einen eindeutigen Schlüssel, damit ein wiederholter Aufruf (Timeout, Retry) keine Dublette erzeugt.
• Fehlerbehandlung. Validierungsfehler sind fachliche Ereignisse, keine technischen Ausnahmen — sie gehören in den Workflow (Berichtigung anfordern), nicht in ein verschlucktes Log.
• Statusverfolgung. Übertragungsstatus am Beleg führen — angenommen, abgewiesen, zugestellt — als Audit-Trail und für die Wiedervorlage.

Ein konkretes Beispiel, warum das zählt: Eine Bestellung läuft im Shop durch, der Erzeugungs-Aufruf an die API quittiert ein Timeout, das Quellsystem versucht es erneut. Ohne Idempotenzschlüssel entstehen jetzt zwei Rechnungen mit zwei Nummern für denselben Vorgang — ein Fehler, der erst Wochen später in der Buchhaltung auffällt und mühsam storniert werden muss. Mit Schlüssel erkennt die API den Wiederholungsaufruf und gibt dasselbe Dokument zurück. Solche Details entscheiden, ob eine Integration im Alltag trägt — und sie sind dieselben, ob man baut oder kauft. Der Unterschied: Bei einer Schnittstelle löst der Anbieter sie einmal für alle Kunden, im Selbstbau löst sie jedes Team für sich.

TCO & Wartung über drei Jahre

Die Build-vs-Buy-Rechnung kippt fast immer über die Wartung — nicht über die Erstentwicklung. Das ist der typische Kostenfehler im Selbstbau: kalkuliert wird der erste valide Export, bezahlt wird über Jahre die Spec-Pflege.

Was im Selbstbau über drei Jahre Aufwand bindet:

• neue XRechnung- und EN-16931-Versionen einarbeiten (in der Regel regelmäßig);
• KoSIT-Validator-Updates und geänderte Validator-Konfigurationen nachziehen;
• Format-Konversion XRechnung ↔ ZUGFeRD und geänderte Pflichtfelder pflegen;
• Peppol-Gebühren und die laufenden Kosten des Access Points tragen;
• Edge-Cases echter Eingangsrechnungen abfangen — der Langzeit-Posten, den niemand vorab sieht.

Eine grobe Orientierung — ausdrücklich Richtwerte, keine Festpreise: Der Erstbau eines validen Exports ist in Tagen bis wenigen Wochen machbar. Die Wartung läuft dagegen jedes Jahr weiter und summiert sich über drei Jahre typischerweise auf ein Vielfaches des Erstbaus, sobald Peppol, beide Syntaxen und reale Eingangsbelege im Spiel sind. Die konkreten Zahlen hängen stark von Volumen, Team und Anspruch ab — wer rechnet, sollte die Drei-Jahres-Sicht ansetzen, nicht die Tagesschätzung für den ersten Export.

Hinzu kommt ein Posten, der in keiner Schätzung steht: das Wissen im Kopf weniger Entwickler. Wer den E-Rechnungs-Stack selbst baut, bindet Standard-, UStG- und Peppol-Know-how an einzelne Personen. Geht diese Person, wird aus einem laufenden System ein Risiko — neue Spezifikationsversionen verstehen sich nicht von selbst, und ein halb gepflegter Validator fällt erst auf, wenn eine wichtige Rechnung beim Empfänger abgewiesen wird. Diese organisatorische Fragilität ist Teil der echten TCO, auch wenn sie sich schwer in Euro fassen lässt.

Bei Buy verschiebt sich diese Kurve: Die Versionspflege liegt beim Anbieter, planbar als laufende Gebühr statt als unregelmäßiger interner Entwicklungsaufwand. Für die meisten Teams ist das der eigentliche Hebel der Entscheidung — nicht der Preis am Tag 1, sondern wer die Spec-Drift über Jahre trägt.

Fazit & nächster Schritt

E-Rechnung per API ist mehr als XML-Erzeugung. Über Build oder Buy entscheiden vier Bausteine — Erzeugen, Validieren, Konvertieren, Übertragen — und vor allem die Wartung. Zwei Syntaxen statt einer, rund 200 Geschäftsregeln plus deutsche CIUS, der KoSIT-Validator als bewegliches Ziel und Peppol als härtester Selbstbau-Blocker: All das ist machbar, aber als dauerhafte Spec-Pflege, nicht als Einmal-Task. Selbstbau lohnt bei hohem Volumen, vorhandener Expertise und strategischer Kontrolle. Für die meisten gewinnt die Integration einer Schnittstelle — weil die Drei-Jahres-Rechnung über die Wartung kippt, nicht über den Erstbau.

Solytics ist eine E-Rechnungs-API: Erzeugen valider XRechnung in UBL/CII, Validierung gegen EN 16931 und CIUS sowie Peppol-Einreichung als Schnittstelle — Wartung und Versionspflege inklusive. Wer die eigene Build-vs-Buy-Frage konkret durchrechnen will, fängt am besten mit dem Pflicht-Status und dem Automatisierungs-Hebel an:

• E-Rechnungs-Pflicht-Check — klärt Ihren Pflicht-Status (Empfang heute, Versand ab 2027) in unter zwei Minuten.
• KI-Readiness-Check — zeigt, wo strukturierte Rechnungsdaten in Ihrem Workflow den größten ROI heben.
• Persönliche Beratung — von der API-Integration über die Validierung bis zur Peppol-Einreichung; der Digitalbonus Bayern fördert die Einführung mit 50 % (bis zu 7.500 €).

Weiterführende Ressourcen:

• XRechnung implementieren — so geht der Selbstbau im Detail (XML, UBL/CII, Validierung).
• Peppol B2B in Deutschland 2026 — Übertragungsweg und Access Point.
• E-Rechnung empfangen & verarbeiten — die Empfangsrichtung als Gegenstück.
• XRechnung vs. ZUGFeRD — Format- und Syntax-Differenzierung.
• E-Rechnung an Behörden (B2G) — Peppol als skalierbarer Behördenweg.
• E-Rechnung Software-Vergleich 2026 — Endprodukt-Sicht für Anwender.