INVOX vs. KoSIT selbst betreiben — was kostet die DIY-Validierung wirklich?
Die ehrliche Vorab-Aussage: **Du kannst XRechnung-Validierung komplett selbst betreiben.** Alle Bausteine sind Open Source (Apache-2.0). Wenn du ein starkes JVM-Team hast und Validierung Teil deines Kernprodukts ist, kann das der richtige Weg sein. Dieser Vergleich hilft dir zu entscheiden, ob das auf dich zutrifft — nicht, dich zu etwas zu überreden.
Was „selbst betreiben" konkret bedeutet
Eine konforme XRechnung-/ZUGFeRD-Prüfung besteht nicht aus einem Schema-Check. Du betreibst und pflegst dann:
| Baustein | Aufgabe | Lizenz |
|---|---|---|
| KoSIT Standalone Validator | Schematron-Prüfung XRechnung/EN16931 | Apache-2.0 |
| XRechnung-Konfiguration (Schematron) | die eigentlichen Regeln, versioniert | Apache-2.0 |
| Saxon (XSLT) | führt die Schematron-Regeln aus | Abhängigkeit |
| Mustang | XML aus ZUGFeRD/Factur-X-PDF extrahieren | Apache-2.0 |
| veraPDF | PDF/A-Konformität prüfen | MPL/GPL |
Dazu kommt der eigentliche Aufwand, der selten eingeplant wird:
Änderung musst du einspielen, testen und ausrollen — sonst validiert dein System irgendwann falsch, ohne dass es jemand merkt.
Absicherung gegen bösartige XML (XXE, Billion-Laughs, riesige Dateien).
(siehe unser Beitrag zum signierten Nachweis).
- Regel-Updates nachziehen. XRechnung-Versionen erscheinen regelmäßig. Jede
- JVM betreiben. Speicher, Start-Latenz, Prozess-Isolation, Timeouts,
- Beweisbarkeit selbst bauen. Ein „valide"-Log beweist gegenüber Dritten wenig
Der direkte Vergleich
| Dimension | KoSIT selbst betreiben | INVOX-API |
|---|---|---|
| Time-to-first-validation | Tage bis Wochen (Setup, JARs, Tuning) | Minuten (ein API-Key) |
| Regel-Updates | dein Betriebsthema, dauerhaft | inklusive, governter Workflow + Regressionstests |
| ZUGFeRD-PDF | Mustang + veraPDF zusätzlich betreiben | ein Aufruf, integriert |
| Fehlermeldungen | rohe Regel-Codes (z. B. BR-DE-1) | Klartext + BT-Nummer, 7 Sprachen |
| Beweis/Audit | selbst bauen | Ed25519-signierter, offline prüfbarer Nachweis inkl. |
| Betrieb/Sicherheit | JVM, XXE-/Replay-/Größen-Schutz selbst | gekapselt, fail-closed |
| Daten | bleibt bei dir | Zero-Retention (nur Hash), EU-Hosting |
| Kosten | „kostenlos" + deine Entwickler-/Betriebszeit | kostenloser Plan, dann ab €19/Mo — 4 Rechenbeispiele |
Die ehrliche Total-Cost-Rechnung
Die Software ist gratis — deine Zeit nicht. Realistisch fallen beim Selbstbetrieb an: initiales Setup, laufende Regel-Pflege, JVM-Betrieb und das Bauen einer Beweis-/Fehlerhilfe-Schicht. Schon wenige Entwicklerstunden pro Monat an laufender Pflege übersteigen den Starter-Plan (€19/Mo) deutlich — bevor ein einziger Audit-Nachweis gebaut ist.
Faustregel: Ist E-Rechnungs-Validierung dein Kernprodukt? Dann betreibe sie selbst. Ist sie eine Pflichtfunktion neben deinem Kernprodukt? Dann ist eine API fast immer günstiger — an Zeit und an Risiko.
Wann INVOX nicht die richtige Wahl ist
zero-retention) — dann ist Selbst-Hosting unumgänglich.
- Du hast bereits ein eingespieltes JVM-Validierungs-Team und -Betrieb.
- Strenge Vorgabe, dass kein externer Dienst im Pfad sein darf (auch nicht
- Du brauchst keinen unabhängigen Nachweis und keine mehrsprachige Fehlerhilfe.
Selbst ausprobieren
Der kostenlose Plan (50 Validierungen/Monat, ohne Karte) reicht, um deine echten Rechnungen einmal durch beide Wege zu schicken und den Unterschied bei Fehlermeldungen und Nachweis selbst zu sehen.
INVOX nutzt dieselbe KoSIT-Referenz-Engine wie der Selbstbetrieb — du bekommst also kein anderes Validierungs-Urteil, sondern denselben Standard ohne den Betriebsaufwand, plus Nachweis und Fehlerhilfe obendrauf.
Hinweis: INVOX ist ein technisches Prüfwerkzeug, keine Rechts- oder Steuerberatung.