E-Rechnung selbst implementieren oder API nutzen? Eine Entscheidungshilfe

Selbst entwickeln lohnt sich, wenn Sie Fachlogik, Regelpflege und Betrieb dauerhaft verantworten können. Eine API passt, wenn Sie klar abgegrenzte Aufgaben einkaufen und diese über einen überprüfbaren Vertrag integrieren möchten. Häufig ist eine Kombination sinnvoll: Rechnungsdaten und Freigaben bleiben im eigenen System, Erzeugung oder technische Validierung werden angebunden.

Die Entscheidung lässt sich nicht seriös allein am Preis pro Rechnung treffen. Ein erster gültiger XML-Export beantwortet noch nicht, wer nach einem Regelupdate einen Fehler behebt, wie ein Ausfall behandelt wird oder ob Ihre Schlussrechnungen korrekt abgebildet werden. Vergleichen Sie deshalb denselben fachlichen Umfang über denselben Zeitraum.

Dieser Beitrag führt von der Aufgabenabgrenzung über eine Entscheidungsmatrix zu einem ausdrücklich hypothetischen Kostenbeispiel und einem konkreten Abnahmetest. Die E-Rechnung-API-Seite beschreibt das Angebot von RechneX; hier geht es darum, welche Aufgaben Sie selbst behalten und welche Sie vergeben sollten.

Zuerst den Auftrag in sechs Aufgaben zerlegen

Erzeugung: Aus welchen Daten entsteht die Rechnung? Liegen strukturierte Positionen vor oder nur eine PDF? Wer berechnet Steuerbeträge, Zu- und Abschläge, Vorauszahlungen und den offenen Betrag? Die technische Ausgabe darf fehlende fachliche Angaben nicht stillschweigend erfinden.

Normpflege: Wer beobachtet Änderungen an Spezifikationen, Codelisten und Prüfregeln? Wer bewertet ihre Auswirkungen und stellt eine neue Version rechtzeitig bereit? Eine unveränderte Versionskennung im Rechnungs-XML bedeutet nicht, dass sämtliche technischen Prüfarbeitsmittel ebenfalls unverändert bleiben.

Validatorbetrieb: Wer installiert, aktualisiert und überwacht den Prüfdienst? Wer legt Speichergrenzen, Zeitlimits und Parallelität fest? Die offizielle KoSIT-Software liefert die Prüfwerkzeuge; Ihre Betriebsumgebung und Ihre fachlichen Prozesse entstehen dadurch nicht automatisch.

Monitoring: Welche Störungen müssen bemerkt werden, bevor Rechnungen liegen bleiben? Ein erreichbarer Server kann trotzdem fehlerhafte Antworten liefern. Deshalb braucht es neben Erreichbarkeit auch einen wiederkehrenden Test mit bekanntem Ergebnis und eine getrennte Sicht auf technische und fachliche Fehler.

Support: Wer hilft einer Mitarbeiterin, die eine Käuferreferenz nicht kennt? Wer erklärt dem Softwareteam eine unerwartete Regelmeldung? Fachliche Unterstützung, technische Entstörung und die Kommunikation mit dem Rechnungsempfänger sind unterschiedliche Aufgaben. Sie brauchen jeweils eine zuständige Person oder eine vereinbarte Leistung.

Sonderfälle: Welche Vorgänge kommen tatsächlich vor? Denken Sie an Gutschriften, Storno, Vorauszahlungen, Schlussrechnungen, Reverse Charge, mehrere Steuersätze und Anhänge. Priorisieren Sie anhand Ihrer eigenen Belege. Eine lange Liste angeblich unterstützter Formate ersetzt keinen Test Ihres konkreten Geschäftsvorfalls.

Entscheidungsmatrix: Wer übernimmt welche Verantwortung?

Die Matrix beschreibt typische Verantwortungsgrenzen, keine garantierte Leistung eines beliebigen API-Anbieters. Auch bei einer API müssen die gekauften Aufgaben ausdrücklich im Angebot stehen. Manche Projekte benötigen nur Validierung, andere zusätzlich Erzeugung, Datenzuordnung oder Unterstützung bei bestimmten Sonderfällen.

Markieren Sie pro Zeile einen Verantwortlichen und einen Nachweis. Bleibt eine Zeile offen, ist das Angebot oder die interne Planung noch nicht vollständig. Diese Lücken sind meist entscheidender als kleine Unterschiede beim Stückpreis. Besprechen Sie sie, bevor Sie eine Architektur verbindlich auswählen.

Wann eine Eigenentwicklung gut passt

Eine eigene Implementierung kann sinnvoll sein, wenn strukturierte Rechnungsdaten bereits zuverlässig vorliegen, Ihr Team ähnliche Fachmodule betreut und Sie Regeln sowie Sonderfälle langfristig selbst kontrollieren möchten. Besonders wichtig ist eine Vertretung: Eine Lösung, die nur eine Person versteht, ist bei Urlaub oder Personalwechsel schwer zu betreiben.

Sie müssen nicht sämtliche technischen Grundlagen neu schreiben. Vorhandene XML-Bibliotheken und offizielle Prüfartefakte können Teile der Arbeit abdecken. Prüfen Sie trotzdem Lizenz, Wartungszustand, unterstützte Profile und die Einbindung in Ihren Releaseprozess. Die EN-16931-Validierungsartefakte zeigen beispielsweise, dass europäische Geschäftsregeln als eigene technische Komponenten gepflegt werden.

Eine gute interne Entscheidung nennt deshalb nicht nur „Entwicklung: vier Wochen“. Sie benennt auch regelmäßige Pflegezeit, einen Testbestand, die Betriebsrolle und einen Freigabeweg für Updates. Lassen sich diese Aufgaben verbindlich besetzen, ist Eigenentwicklung eine ernsthafte Option, selbst wenn ein externer Dienst zunächst bequemer erscheint.

Wann eine API gut passt

Eine API kann passen, wenn Sie eine klar umrissene Funktion anbinden möchten und im eigenen Team andere Aufgaben Vorrang haben. Dazu gehören etwa die Erzeugung eines vereinbarten Rechnungsformats oder die technische Prüfung vor dem Versand. Der Nutzen liegt in der übernommenen Aufgabe, nicht im Wort „API“.

Prüfen Sie, welche Arbeit trotzdem bei Ihnen bleibt. Daten aus dem ERP müssen zugeordnet werden. Fehlende Pflichtangaben benötigen einen Korrekturweg. Berechtigungen, fachliche Freigaben und der Umgang mit Wiederholungen müssen in Ihrer Anwendung funktionieren. Ein ausgelagerter Validator nimmt Ihnen diese Entscheidungen nicht ab.

Klären Sie außerdem, ob Standardfälle sofort unterstützt werden und welche Sonderfälle eine gesonderte Umsetzung benötigen. Bei RechneX werden solche Integrationsprojekte über Enterprise beziehungsweise die E-Rechnung API konkretisiert. Leiten Sie daraus keine pauschale Zusage für jedes ERP, jedes Format oder jeden Belegtyp ab.

Häufig sinnvoll: Fachmodell behalten, Prüfung auslagern

Wenn Ihr System bereits korrekte XML-Rechnungen erzeugt, müssen Sie nicht automatisch die Erzeugung ersetzen. Eine eigenständige KoSIT-Validierungsintegration kann als zusätzlicher Prüfschritt vor Versand oder Übergabe dienen. Ihre Rechnungslogik bleibt dabei im vorhandenen System.

Umgekehrt kann eine API die Ausgabe übernehmen, während Sie Stammdaten, Berechnung und Freigabe behalten. Dokumentieren Sie dann genau, ob Beträge übernommen oder neu berechnet werden und wer Differenzen zurückmeldet. Ein unklarer Übergang zwischen zwei Berechnungsmodellen erschwert die Fehlersuche erheblich.

Bei PDF als einziger Quelle ist die Aufgabe größer. Zunächst müssen Angaben ausgelesen und fachlich kontrolliert werden. Für bestehende Systeme ohne geeigneten strukturierten Export beschreibt die ERP-PDF-Anbindung einen möglichen Ansatz. Vergleichen Sie diesen Umfang nicht mit einer reinen XML-Validierung: Eingangsqualität und Prüfbedarf unterscheiden sich.

Transparentes Rechenbeispiel für 24 Monate

Die folgenden Zahlen sind frei gewählte Planungsannahmen, keine Betriebswerte von RechneX, kein Angebot und kein gemessener Branchendurchschnitt. Sie zeigen, wie Sie die Rechnung aufbauen können. Ersetzen Sie jede Annahme durch Ihre internen Aufwände oder ein schriftliches Angebot. Alle Beträge werden hier netto betrachtet.

Angenommen wird ein interner kalkulatorischer Stundensatz von 90 Euro. Die Eigenentwicklung benötigt beispielhaft 160 Stunden für Umsetzung, Tests und Einführung. Für die API-Integration werden 48 Stunden angesetzt. Laufende Pflege wird mit acht beziehungsweise drei Stunden pro Monat angenommen.

Für den Eigenbetrieb werden zusätzlich 80 Euro Infrastruktur pro Monat angesetzt. Das rein hypothetische API-Angebot koste 250 Euro monatlich und decke das betrachtete Volumen ab. Externe Einrichtungsgebühren fallen in diesem Beispiel nicht an. Das ist eine Annahme, die in einem echten Angebot ausdrücklich geprüft werden muss.

Unter genau diesen Annahmen ist die API-Variante um 16.800 Euro günstiger. Das ist kein allgemeines Ersparnisversprechen. Wenn ein internes Modul bereits existiert, die Wartung geringer ausfällt oder ein API-Angebot umfangreiche Zusatzleistungen benötigt, kann sich das Ergebnis deutlich ändern.

Die Rechnung ist auch kein reiner Liquiditätsvergleich. Interne Stunden binden Arbeitskapazität; sie führen nicht zwangsläufig in gleicher Höhe zu zusätzlichen Auszahlungen. Für eine Budgetentscheidung sollten Sie deshalb Ausgaben, gebundene Teamzeit und den Nutzen eines früher verfügbaren Prozesses getrennt betrachten.

Welche Annahmen kippen das Ergebnis?

Bei sonst unveränderten Werten beträgt der rechnerische monatliche Spielraum für den externen Dienst 950 Euro: Von 33.600 Euro werden 4.320 Euro Einführungsarbeit und 6.480 Euro laufende interne Arbeit abgezogen; die verbleibenden 22.800 Euro werden durch 24 Monate geteilt. Bei 950 Euro Dienstkosten wären beide Modellrechnungen gleich teuer.

Diese Schwelle ist kein Preisziel und keine Empfehlung. Sie gilt nur für die genannten Annahmen. Zusätzliche Einrichtungskosten, Überschreitungsgebühren oder mehr interner Support senken den Spielraum. Bereits vorhandener eigener Code kann wiederum den Entwicklungsaufwand stark reduzieren. Rechnen Sie mindestens eine vorsichtige und eine günstige Variante für beide Wege.

Ergänzen Sie außerdem Ausstiegskosten, größere Regelwechsel und seltene Sonderfälle, sofern sie für Ihr Projekt relevant sind. Setzen Sie unbekannte Posten sichtbar auf „noch zu klären“, statt sie mit null zu bewerten. Das verhindert, dass eine unvollständige Variante nur rechnerisch attraktiv aussieht.

Den Testumfang aus echten Geschäftsfällen ableiten

Beginnen Sie mit einer normalen Rechnung und den zwei oder drei wichtigsten Sonderfällen Ihres Unternehmens. Verwenden Sie anonymisierte oder synthetische Daten mit den gleichen fachlichen Eigenschaften. Ein bloßes Umbenennen eines Kunden in einer ansonsten unpassenden Musterrechnung liefert keinen belastbaren Nachweis.

Für die Formatfrage steht dieselbe Rechnung als UBL und CII mit Originalberichten bereit. Prüfen Sie damit, ob Ihre Systeme Daten in beiden Syntaxen fachlich gleich behandeln. Für die Fehlerverarbeitung helfen die vier KoSIT-Referenzzustände.

Fügen Sie einen Wiederholungsfall hinzu: Eine Anfrage läuft in ein Zeitlimit, danach wird dieselbe Datei erneut verarbeitet. Es darf keine zweite fachliche Rechnung entstehen. Ergänzen Sie außerdem eine absichtlich fehlerhafte Käuferreferenz und prüfen Sie, ob die zuständige Person eine verständliche Korrekturaufgabe erhält.

Bei Sonderfällen müssen die Summen und Belegbezüge stimmen. Für Bau- oder Projektabrechnungen kann etwa eine Schlussrechnung entscheidend sein; für andere Unternehmen ist eine Reverse-Charge-Rechnung wichtiger. Wählen Sie die passenden Fälle aus dem Beispiele-Hub und stimmen Sie fehlende Fälle vor Projektbeginn ab.

Betrieb und Vertrag konkret abnehmen

Ein technischer Ansprechpartner sollte nachweisen können, wie ein fehlgeschlagener Prüflauf erkannt und erneut gestartet wird. Ein fachlicher Ansprechpartner sollte erklären können, wie ein Lieferant eine fehlerhafte Rechnung korrigiert. Halten Sie für beide Rollen einen Vertretungsweg fest.

Vereinbaren Sie bei einer API, welche Angaben zur Verfügbarkeit, Reaktionszeit und Wartung tatsächlich gelten. Eine schnelle Antwort im Test ist kein zugesichertes Serviceniveau. Fragen Sie nach Größenlimits, Parallelität, Zeitüberschreitungen, Wiederholungsregeln und dem Verhalten bei Wartungsarbeiten. Für sensible Rechnungsdaten müssen Datenfluss und Löschregeln ebenfalls zum vereinbarten Prozess passen.

Beim Eigenbetrieb gelten dieselben Fragen intern. Wer spielt ein neues Regelpaket ein? Wer entscheidet bei geänderten Warnungen? Wie lässt sich die vorige Version wiederherstellen? Die XRechnung-Komponentenübersicht hilft, Spezifikation und technische Prüfarbeitsmittel auseinanderzuhalten. Beides gehört in die Versionsdokumentation.

Vergessen Sie den Empfänger nicht. Ein Format kann technisch gültig sein und trotzdem nicht zum vereinbarten Einreichungsweg passen. Für einen Peppol-Prozess müssen der unterstützte Dokumenttyp und das Profil geklärt werden; die BIS-Billing-Dokumentation beschreibt den entsprechenden fachlichen Rahmen.

Ein Entscheidungsblatt, das ohne Vermutungen auskommt

Halten Sie die folgenden Angaben auf einer Seite fest. Damit können interne Entwicklung und externer Anbieter denselben Auftrag bewerten:

1. Quellsystem, verfügbare Daten und gewünschte Ausgabeformate.
2. Monatliches Volumen, Spitzenlast und maximal tolerierte Wartezeit.
3. Relevante Sonderfälle mit jeweils einer repräsentativen Testrechnung.
4. Verantwortliche für Datenqualität, Regelpflege, Betrieb und Support.
5. Einmalige und laufende Kosten über einen festen Betrachtungszeitraum.
6. Abnahmekriterien für gültige Rechnung, Fehler, Warnung und Ausfall.
7. Exportmöglichkeiten für Rechnungen, Berichte und notwendige Zuordnungen.

Wählen Sie die Variante, für die Zuständigkeiten, Testnachweise und Kosten nachvollziehbar sind. Wenn nur die Standardrechnung funktioniert, ist die Entscheidung noch nicht reif. Wenn hingegen alle kritischen Fälle abgenommen sind, muss nicht jeder selten denkbare Sonderfall vor dem ersten Einsatz entwickelt werden. Grenzen müssen dann ausdrücklich dokumentiert sein.

Häufige Fragen vor Projektbeginn

Ist eine API automatisch günstiger?

Nein. Kosten hängen vom Umfang, vorhandenen Komponenten, Volumen und Pflegeaufwand ab. Das Rechenbeispiel liefert eine Methode, kein allgemeines Ergebnis. Vergleichen Sie insbesondere nicht eine vollständig betreute Integration mit einer internen Schätzung, die Betrieb und Support auslässt.

Muss ich mein ERP ersetzen?

Nicht zwangsläufig. Prüfen Sie zuerst, welche strukturierten Daten oder Dokumente das vorhandene System bereitstellt. Ein zusätzlicher Erzeugungs- oder Validierungsschritt kann genügen. Ob das für Ihre Version und Ihre Belege funktioniert, muss ein konkreter Exporttest zeigen.

Was brauche ich für eine erste Anfrage?

Quellsystem, Zielformat, ungefähres Volumen und eine Beschreibung der Sonderfälle reichen für eine erste Einordnung. Für die technische Prüfung werden anschließend geeignete Beispielbelege und ein abgestimmter Übertragungsweg benötigt. Senden Sie vertrauliche Rechnungen erst über den dafür vereinbarten Kanal.