Eine Rechnung stoppen, die noch nicht übermittelt wurde
- In der Sandbox
In einfachen Worten
Funktioniert nur, solange die Rechnung received, validated oder queued ist. Seit 0.18.3 gilt: Wurde ein Versand versucht
und ging seine Antwort verloren (ein Timeout oder ein 5xx), steht die Rechnung auf submitting, und ein Stornieren wird mit 409
send-in-progress beantwortet, weil der Übermittlungsweg sie haben kann; der Worker setzt sie dann auf submitted oder dead_letter. Hat
der Übermittlungsweg sie, ist eine Stornierung ein Geschäftsdokument (eine Gutschrift, oder in Polen eine KOR), kein API-Aufruf.
Seit 0.18.5 beantwortet ein Stornieren einer bereits stornierten Rechnung mit 200 und der Rechnung, damit eine Wiederholung nach einer verlorenen
Antwort sicher ist. Seit 0.18.6 darf der Schlüssel des Betreibers eine dead_letter-Rechnung stornieren, wenn für sie nie ein Aufruf an den Übermittlungsweg
gemacht wurde: Dort kann nichts liegen, daher kann dasselbe Dokument danach erneut gesendet werden. Wurde ein Aufruf gemacht,
lautet die Antwort 409 dead-letter-reached-rail, weil ein Versand mit verlorener Antwort dort liegen kann: Prüfen Sie
zuerst beim Übermittlungsweg. Ein Kundenschlüssel erhält 409 dead-letter; der Betreiber entscheidet.
apiKeyAuthorizationBearer <token>Senden Sie Ihren Schlüssel als Bearer-Token: Authorization: Bearer <your-api-key>. Der Systemzustand ist der einzige Aufruf, der keinen Schlüssel braucht.
id*stringDie ID der Rechnung, die der Übermittlungsaufruf zurückgegeben hat.
^inv_[A-Za-z0-9]{16,40}$Idempotency-Key*stringEin eindeutiger Schlüssel je logischer Anfrage (eine UUID genügt). Er wird so lange aufbewahrt, wie die Daten des Kunden aufbewahrt werden. Mit dem Schlüssel des Betreibers darf er nicht mit client: beginnen (400), der Form, unter der Kundenschlüssel gespeichert werden.
8 <= length <= 100Vor der Übermittlung storniert, eine Dead Letter, die den Übermittlungsweg nie erreicht hat (Schlüssel des Betreibers), oder bereits storniert.
application/json- response
id*stringinvoice_ref*stringinvoice_number?stringroute*RouteDer Übermittlungsweg. Dieselben Werte wie country_route in Statusereignissen.
"PEPPOL""PL-KSEF""RO-EFACTURA""FR-PA""DE-XRECHNUNG"environment*string"sandbox""production"state*InvoiceStateDer eigene Zustand des Service für eine Rechnung. Statusereignisse melden den Lebenszyklus aus Sicht des Partners;
queued und submitting sind interne Schritte zwischen validated und submitted. validation_failed bedeutet, dass die offiziellen Regeln das Dokument abgelehnt haben; seit
0.18.4 wird eine Prüfung, die nicht lief (KOSIT-RUN, EI-PDF-CHECK), wiederholt und endet dann als dead_letter mit diesem
Code. Eine dead_letter hält ihr Dokument fest, sodass dieselbe Datei mit duplicate_of beantwortet wird; seit 0.18.6 kann der
Betreiber eine stornieren, für die kein Aufruf an den Übermittlungsweg gemacht wurde, und die Datei kann dann erneut gesendet werden.
"received""source_error""validated""validation_failed""queued""submitting""submitted""ready""accepted""rejected""delivered""cancelled""dead_letter"legal_id?|KSeF-Nummer, ANAF-Upload-Index, Dokument-ID des Access Points, Rechnungs-ID der französischen Plattform.
buyer_status?string|nulldocument_sha256?|^[a-f0-9]{64}$attempts?array<>Frühere Übermittlungen derselben invoice_ref (zum Beispiel nach einer Ablehnung und einer Korrektur).
errors?array<>documents?array<>created_at*stringdate-timeupdated_at*stringdate-timedeadline_at?stringEine Richtfrist für diese Rechnung, als letzter Moment ihres letzten zulässigen Tages in UTC (lesen Sie den Datumsteil als diesen Tag): das Ausstellungsdatum plus fünf Werktage für Rumänien (e-Factura), der nächste Geschäftstag für Polen (KSeF offline24). Die Tage werden von Montag bis Freitag gezählt, gesetzliche Feiertage werden nicht berücksichtigt, die tatsächliche Frist kann also später liegen, nie früher; es ist keine Rechtsberatung. In jedem Zustand der Rechnung angegeben; sie sagt nicht, ob die Rechnung rechtzeitig oder verspätet war. Nur für diese beiden Übermittlungswege vorhanden, und nur wenn die Rechnung ein Ausstellungsdatum trägt: POST /invoices mit einem invoice.issue_date, oder seit 0.19.2 eine UBL-Datei (cbc:IssueDate) oder eine FA(3)-Datei (Fa/P_1), als XML gesendet oder im Ordner abgelegt. Ein PDF trägt keines, und sein Fehlen heißt nicht, dass keine Frist gilt. Seit 0.19.1.
date-timecurl -X POST "https://example.com/invoices/inv_bd8bc8b276f38643f1c0f24f/cancel" \ -H "Authorization: Bearer <your-api-key>" \ -H "Idempotency-Key: order-2026-0001"{ "invoice_ref": "FRESH-mux3dlqm-0", "environment": "sandbox", "document_sha256": "b341c81da6fe297787829a8c26fd4b25106b5b34e67482d38c1039651bbfed65", "route": "DE-XRECHNUNG", "updated_at": "2026-10-06T19:49:10.992Z", "client": "acme-srl", "created_at": "2026-10-06T19:49:10.816Z", "id": "inv_ae4d9834bf251353532fe5ee", "state": "cancelled", "invoice_number": "FRESH-mux3dlqm-0"}Zugangsdaten verschlüsselt speichern; der Wert wird nie zurückgegeben POST
Ein Prozess speichert Zugangsdaten nur für seine eigene Umgebung. legal_entity bindet sie an die Verkäufer-ID, für die sie gelten (USt-IdNr., NIP, SIREN oder Unternehmens-ID); ohne Angabe gelten sie für die übrigen Rechnungen des Kunden. Der Admin-Schlüssel eines Kunden speichert nur für den eigenen Kunden.
Den aktuellen Zustand einer Rechnung abrufen GET
Weiter