Häufige Fragen (FAQ)

Jede Validierung erzeugt eine Ed25519-signierte, gehashte Attestierung, die jeder Dritte **offline** mit unserem öffentlichen Schlüssel prüfen kann — inkl. Zeitstempel und Regelwerk-Version. Die Nachweise sind hash-verkettet (manipulationsevident). Ein Log in eurer eigenen Datenbank beweist nichts (selbst geschrieben, jederzeit änderbar). Ein unabhängig signierter Nachweis schon — auch in der nächsten Betriebsprüfung, auch wenn die Geschäftsführung bis dahin gewechselt hat.

Nein. Der Nachweis ist ein **technischer Beleg** über Konformität gegen ein Regelwerk zu einem Zeitpunkt. Er stärkt deine Beweisposition, ersetzt aber keine Rechts- oder Steuerberatung und garantiert kein Prüfungsergebnis.

Auf dem **KoSIT Standalone Validator** (der amtlichen Referenz-Implementierung des Bundes) für XRechnung/EN16931 und auf **Mustang** für ZUGFeRD/Factur-X — beide Apache-2.0. Du bekommst also dasselbe Validierungs-Urteil wie beim Selbstbetrieb, ohne die JVM-Toolchain pflegen zu müssen.

Nein — und das behauptet niemand. INVOX *nutzt* die KoSIT-Referenz-Engine, ist aber nicht eigenständig durch KoSIT zertifiziert. Das ist eine ehrliche Klarstellung, kein Nachteil: das Validierungs-Ergebnis stammt aus derselben Engine, die auch die Behörden einsetzen.

XRechnung (UBL + CII), ZUGFeRD 2.x, Factur-X, EN16931, PEPPOL BIS. Eine ZUGFeRD-/Factur-X-PDF kann zusätzlich in eine konforme XRechnung gebrückt werden.

Verständliche Klartext-Hinweise mit BT-Nummer der Norm (z. B. „BT-24 Spezifikationskennzeichen fehlt") in 7 Sprachen — nicht nur rohe Regel-Codes — plus konkrete AutoFix-Vorschläge.

Nein. **Zero-Retention:** die Rechnungsbytes werden vor der Antwort wieder gelöscht. Persistiert wird nur ein SHA-256-Hash und Metadaten — kein Rechnungsinhalt. Das ist eine Architektur-Eigenschaft, keine reine Zusage.

EU-Hosting. Die Validierungs-Engines (KoSIT/Mustang) laufen lokal in der INVOX-Infrastruktur — kein externer Sub-Auftragsverarbeiter für Inhalte.

Ja, ein Auftragsverarbeitungsvertrag (Art. 28 DSGVO) liegt vor. Da nur Hashes gespeichert werden, ist die Verarbeitung personenbezogener Daten auf das technische Minimum reduziert.

Ein vorgelagertes Gate prüft auf XXE, Replay, Über­größe und Dateityp; das System ist **fail-closed** (im Zweifel blockieren). Details im Security-Brief.

Zwei-Faktor-Authentifizierung (TOTP, jede Standard-Authenticator-App), eine Sitzungsübersicht mit gezieltem Beenden einzelner Geräte oder „alle anderen abmelden", und ein Aktivitätsprotokoll, das sicherheitsrelevante Kontoänderungen (Login, 2FA-Umschaltung, Sitzungswiderruf, API-Key-Erstellung) nachvollziehbar macht — unabhängig von der Rechnungs-Nachweiskette.

Ja, direkt im Portal: ein vollständiger, maschinenlesbarer JSON-Export (Art. 15/20 DSGVO) sowie eine Selbstbedienungs-Löschfunktion (Art. 17 DSGVO). Die Löschung anonymisiert unwiderruflich statt physisch zu löschen — Abrechnungsdaten müssen aus gesetzlichen Aufbewahrungspflichten (§147 AO) pseudonymisiert erhalten bleiben; Details in der Datenschutzerklärung.

Kostenloser Plan: 50 Validierungen/Monat, ohne Karte (inkl. Nachweis). Danach Starter €19, Pro €49, Business €149 pro Monat — mit gestaffelter, planbarer Overage. Transparente Preise, keine versteckten Posten.

Nein lange Bindung — monatlich oder jährlich (jährlich ≈ 2 Monate günstiger). Kündbar zum Ende des Abrechnungszeitraums.

Eine `POST /v1/validate`-Anfrage. AutoFix-Vorschläge, Erklärungen und alle GET-Endpunkte kosten nichts.

Ein API-Key, ein `POST /v1/validate` mit der Datei als `multipart/form-data` — in Minuten. Mandanten-Sub-Keys mit Rechte-Scoping sind möglich. SDKs für Java, PHP, Ruby, TypeScript und Python liegen bereit.

Ja. Jeder Kern-Endpunkt unterstützt einen `Idempotency-Key`-Header (wie bei Stripe): eine Wiederholung mit demselben Schlüssel liefert das ursprüngliche Ergebnis zurück, statt die Rechnung erneut zu validieren und erneut zu belasten. Ohne Header greift ein Content-Hash-Fallback für identische Wiederholungen.

Ja — die generierte API-Dokumentation (`/docs`, `/redoc`, `/openapi.json`) listet für jeden Kern-Endpunkt die tatsächlich möglichen Statuscodes (401/402/409/413/429/503) mit Beispiel-Antworten, nicht nur den Erfolgsfall.

Gering: Du sendest Standard-Rechnungen rein und bekommst Standard-konforme Verdicts + Nachweise zurück. Die Nachweise gehören dir und sind offline prüfbar — auch unabhängig von INVOX.

Außerhalb einer vereinbarten SLA gilt Best-Effort. Für kritische Pfade empfehlen wir, das Verdict in deinem Workflow als „blockierend/nicht-blockierend" bewusst zu behandeln — wir beraten gern zur Integration.