Selbst bauen lohnt sich, wenn E-Rechnung zu deinem Kernprodukt gehört und du die laufende Formatpflege dauerhaft tragen willst. Einbinden lohnt sich, wenn Rechnung ein Nebenschauplatz ist: Eine API kapselt Codelisten, EN-16931-Geschäftsregeln, Profilversionen, Validierung, atomare Nummernvergabe und Archivierung — Arbeit, die nie fertig wird, weil die Formate ein bewegliches Ziel sind.

Wenn deine Software im Namen deiner Kunden abrechnet, kommt die Frage spätestens mit der Ausstellungspflicht (ab 2027 bzw. 2028 — siehe die Einordnung der E-Rechnungspflicht): Baust du XRechnung und ZUGFeRD selbst, oder bindest du eine API ein? Dieser Beitrag legt die Abwägung offen — ohne die Eigenbau-Option künstlich schlechtzurechnen.

Was “bauen” wirklich bedeutet

Die erste valide XRechnung ist in überschaubarer Zeit gebaut. Der Aufwand steckt im Dauerbetrieb:

  • Formatpflege — die EN 16931 und ihre Profile (XRechnung, ZUGFeRD/Factur-X) sind ein bewegliches Ziel: Codelisten, Geschäftsregeln und Profilversionen ändern sich.
  • Validierung — well-formed reicht nicht; die Schematron-Regeln müssen aktuell bestehen (KoSIT-Validierung erklärt).
  • Nummernkreise & Unveränderlichkeit — lückenlose, atomare Vergabe; ausgestellte Belege müssen eingefroren sein.
  • Archivierung — die strukturierten Originale unveränderbar und langfristig vorhalten.

Keiner dieser Punkte ist einmalig. Sie sind der Grund, warum “wir bauen das schnell selbst” oft teurer wird als gedacht — nicht im Sprint, sondern über die Jahre.

Wann Eigenbau die richtige Wahl ist

Bauen ist sinnvoll, wenn E-Rechnung ein Kern-Differenzierungsmerkmal deines Produkts ist, du dediziertes Compliance-Know-how im Team hast und die laufende Pflege bewusst einplanst. Dann willst du die volle Kontrolle über jedes Feld — und die Formatpflege ist Teil deiner Wertschöpfung, kein Nebenschauplatz.

Wann Einbinden die richtige Wahl ist

Für viele Vertical-SaaS-, ERP- und Plattform-Anbieter ist Rechnung eine Pflichtfunktion neben dem eigentlichen Produkt. Dann ist der stabilste Schnitt: Dein System kennt den Geschäftsfall, die API kennt das Format. Du schickst, was du ohnehin hast (wer, was, wie viel, welcher Steuersatz); alles Formatspezifische bleibt hinter der Schnittstelle. Ändert sich eine Profilversion, ziehst du nichts nach.

Wie dieser Schnitt konkret aussieht, zeigen E-Rechnung per API und der Drei-Schritt-Flow in XRechnung per API erzeugen.

Die ehrliche Zwischenposition

Es muss kein Entweder-oder für immer sein: Viele Teams binden zunächst eine API ein, um die Pflicht termingerecht zu erfüllen, und behalten die Option, später Teile selbst zu übernehmen. Entscheidend ist ein sauberer Schnitt, der beide Wege offenhält — Daten und Prozess bei dir, Format und Validierung kapselbar.

Kontrolle behalten

Einbinden heißt nicht Kontrolle abgeben. Mit einem White-Label-Ansatz bleibt die Marke deine, und die rechtlich heikle Mathematik (Summen, USt, Rundung) liegt an genau einer autoritativen Stelle statt verstreut in jedem Client.

Genau diese Abwägung ist die Entscheidung, die wir in Discovery-Calls am häufigsten hören. Wenn du sie für dein Produkt konkret durchgehen willst: 30 Min, technisch, mit dem Gründer →

Häufige Fragen

Was kostet der Eigenbau einer E-Rechnung wirklich?
Nicht die erste XRechnung, sondern die laufende Pflege: Codelisten und Geschäftsregeln der EN 16931 ändern sich, Profilversionen (XRechnung, ZUGFeRD) ziehen nach, die KoSIT-Validierung muss aktuell bleiben. Dazu kommen atomare Nummernkreise und die unveränderbare Archivierung der strukturierten Originale. Das ist Dauerbetrieb, kein Projekt.
Wann ist Eigenbau die richtige Wahl?
Wenn E-Rechnung ein Kern-Differenzierungsmerkmal deines Produkts ist, du dediziertes Compliance-Know-how hast und die Formatpflege dauerhaft einplanst. Für viele Vertical-SaaS-Anbieter ist Rechnung dagegen eine Pflichtfunktion neben dem eigentlichen Produkt — dann bindet man sie ein.
Verliere ich mit einer API die Kontrolle über meine Rechnungen?
Nein, wenn der Schnitt sauber ist: Dein System kennt den Geschäftsfall, die API kennt das Format. Du behältst Daten und Prozess; ausgelagert wird nur die formatspezifische Erzeugung und Validierung — und die Marke bleibt bei White-Label deine.