Wenn Ihr Produkt mit Rechnungen zu tun hat — ERP, DMS, Buchhaltung, Beschaffung — werden Sie gefragt werden, ob Sie E-Rechnung unterstützen. Von dort aus gibt es zwei ehrliche Wege. Diese Seite vergleicht sie, ohne den Eigenbau schlechter zu machen als er ist, und ohne zu behaupten, dass Kaufen jeden Trade-off beseitigt.
| Aufgabe | Laufend, nicht einmalig |
|---|---|
| EN-16931-Semantikmodell parsen & validieren (UBL- und CII-Syntax) | Ja — der Standard selbst bekam 2026 eine neue Version |
| XRechnung-CIUS-Regeln (BR-DE-*) zusätzlich zu den Basis-EN-16931-Regeln | Ja — separat vom Basisstandard versioniert |
| ZUGFeRD/Factur-X: eingebettete CII-XML korrekt in einen PDF/A-3-Container ein-/auslesen | Ja — die Pflichtprofilversion änderte sich zuletzt im Januar 2026 |
| PEPPOL-BIS-3.0-Schematron, aktuell gehalten mit OpenPeppol-Releases | Ja — Hotfix-Releases mehrmals im Jahr |
| Jedes nationale Format, in das Sie expandieren (KSeF, FatturaPA, Facturae, VeriFactu, ...) | Ja — jedes ist eine eigene Spezifikation mit eigenem Release-Takt |
| Einen Referenzvalidator pflegen (oder Testabdeckung dagegen aufbauen), damit Sie wirklich wissen, dass Ihre Ausgabe korrekt ist — nicht nur "stürzt nicht ab" | Ja |
Nichts davon ist ein einmaliges Integrationsprojekt. Es ist eine dauerhafte Verpflichtung — jemand in Ihrem Team muss CEN, OpenPeppol, KoSIT und jede nationale Behörde dauerhaft im Blick behalten, solange Sie das Feature verkaufen.
| Selbst bauen | INVOX integrieren | |
|---|---|---|
| Zeit bis zur ersten funktionierenden Validierung | Wochen bis Monate, je nach Formaten/Ländern | Minuten — Sandbox-Key, erster Aufruf |
| Wer verantwortet Korrektheit | Ihr Team, gegen welche Testdaten auch immer verfügbar sind | INVOX, erneut verifiziert gegen die offizielle Konformitäts-Suite/XSD jedes Standards |
| Wer verfolgt Standard-Änderungen | Ihr Team, dauerhaft | INVOX, dauerhaft |
| Abdeckung mehrerer Formate (national) | Jedes ein eigenes Projekt | Bereits abgedeckt — eine Integration |
| Nachweis/Audit-Trail für ein validiertes Dokument | Müssten Sie separat bauen | Signierte, offline-verifizierbare Attestation inklusive |
| Was Sie unter Kontrolle behalten | Alles | Ihr Produkt, Ihre Oberfläche, Ihre Kundenbeziehung — die Compliance-Engine wird delegiert, nicht Ihre Geschäftslogik |
| Datenresidenz / On-Prem | Standardmäßig vollständig in Ihrer Kontrolle | Als vollwertige Deployment-Option verfügbar, nicht nur SaaS |
Ehrlich: Wenn E-Rechnungs-Compliance Ihr Kernprodukt ist — Sie bauen eine dedizierte E-Rechnungs-Plattform, nicht Compliance als Feature von etwas anderem — kann der vollständige Eigenbau der Engine strategisch richtig sein. Die Build-vs-Buy-Frage dreht sich eigentlich darum, ob die Validierungs-Engine Ihr Differenzierungsmerkmal oder Ihr Kostenblock ist. Für einen ERP-, DMS- oder Buchhaltungsanbieter ist es fast immer Letzteres.
INVOX ist kein ERP, kein DMS, und versendet standardmäßig keine Rechnungen in Ihrem Namen — es validiert, erzeugt, konvertiert und unterstützt (wo an einen Partner-Access-Point angebunden) die Übertragung. Ihr Produkt, Ihre Kundenbeziehungen und Ihre Oberfläche bleiben vollständig Ihre eigenen. Das technische Gerüst für die echte PEPPOL-Vier-Ecken-Übertragung existiert; es läuft über einen Partner-Access-Point statt dass INVOX selbst als akkreditierter AP auftritt — fragen Sie uns direkt zu Ihrem konkreten Übertragungsbedarf, bevor Sie etwas annehmen.