Limits und gesetzliche Fristen
Anfrageraten, Obergrenzen der Netze, Wiederholungen und gesetzliche Fristen.
- In der Sandbox
In einfachen Worten
Manche Systeme der Länder begrenzen, wie schnell Rechnungen gesendet werden dürfen, und manche Gesetze setzen eine Frist ab dem Rechnungsdatum. Diese Seite listet die Limits auf, die wir zählen, und die gesetzlichen Fristen, die wir überwachen, damit ein Unternehmen die Größe eines Stapels und den letzten Tag für den Versand einer Rechnung planen kann. Termine und Obergrenzen stammen aus offiziellen Quellen und müssen erneut geprüft werden, bevor sich jemand darauf verlässt.
Vier Dinge bestimmen das Tempo: die Größe einer Anfrage, wie oft ein Kunde die API aufrufen darf, die Obergrenze je Kunde für Sendungen an ein Netz und die gesetzliche Frist auf den Übermittlungswegen, die eine haben.
Größe der Anfrage
Auf einen Body über 5 MB (5.000.000 Bytes) lautet die Antwort 413, mit einem Problem-Body (payload-too-large). Das gilt für POST /invoices, POST /invoices/xml, POST /validate und POST /credentials.
Anfragerate
Jeder Kunde hat für jeden Scope eines Schlüssels ein Kontingent. Es wird für den Kunden gezählt, nicht für den Schlüssel, mehr Schlüssel bringen also nicht mehr Anfragen.
| Scope | Aufrufe pro Sekunde | Aufrufe pro Minute |
|---|---|---|
submit | 20 | 600 |
read | 50 | 3.000 |
admin | 20 | 600 |
Zusätzlich darf die Betreuungsliste 30-mal pro Minute und der Betreuungsnachweis 10-mal pro Minute gelesen werden. Über einem Limit lautet die Antwort 429 mit einem Header Retry-After in Sekunden. Warten Sie so lange und senden Sie denselben Aufruf erneut. Ein Probelauf, bei dem jeder Validator ausgelastet ist, antwortet mit 503 (busy) und Retry-After auf dieselbe Weise.
Auch die Peppol-Abfrage eines Käufers ist begrenzt: 30 Abfragen pro Minute und 300 pro Stunde je Kunde. Eine bereits gespeicherte Antwort kostet nichts.
Obergrenzen der Netze
Der Service zählt die Aufrufe jedes Kunden an ein Netz und gleicht sie mit der veröffentlichten Obergrenze des Netzes ab. Als Kunde gilt der client auf der Rechnung. Eine Rechnung ohne client zählt unter local. Die Zähler liegen in der Datenbank, deshalb setzt ein Neustart sie nicht zurück.
| Übermittlungsweg | Aufruf | Obergrenze |
|---|---|---|
PL-KSEF | Eine Rechnung senden | 10 pro Sekunde, 30 pro Minute, 180 pro Stunde |
PL-KSEF | Einen Status lesen | 30 pro Sekunde, 120 pro Minute, 1.200 pro Stunde |
RO-EFACTURA | Jeder Aufruf | 1.000 pro Minute |
DE-XRECHNUNG, PEPPOL, FR-PA | Keine veröffentlicht, keine angewendet |
Liegt ein Kunde über einer Obergrenze, bleibt seine Rechnung in der Warteschlange, und eine Sekunde später folgt ein neuer Versuch. Nichts wird abgelehnt, und nichts erscheint als Fehler.
Quellen, gelesen am 2. Okt. 2026: die KSeF-API-Limits und das OAuth-Verfahren der ANAF. KSeF zählt jedes Paar aus Kontext und IP-Adresse für sich. ANAF nennt 1.000 Anfragen pro Minute für ihre API und antwortet darüber mit 429, sagt aber nicht, worauf sich die Zahl bezieht.
Polnische Sendungen summieren sich: Bei 180 pro Stunde dauern 1.000 Rechnungen für einen Kunden etwa fünfeinhalb Stunden. Der polnische Modus offline24 lässt Zeit bis zum Ende des nächsten Geschäftstags, um zu senden. Batch-Sitzungen sind geplant und nicht gebaut.
Wiederholungen bei einem Fehler des Netzes
Nur nach einem vorübergehenden Fehler eines Netzes folgt ein neuer Versuch. Nach einer Ablehnung nicht: Sie kommt auf die Betreuungsliste.
| Fehlschlag | Wartezeit bis zum nächsten Versuch |
|---|---|
| 1. | 30 Sekunden |
| 2. | 2 Minuten |
| 3. | 10 Minuten |
| 4. | 30 Minuten |
| 5. | 1 Stunde |
| 6. | Keine. Die Rechnung erhält den Zustand dead_letter und kommt auf die Betreuungsliste. |
Ein Job, der mitten in einem Versand abbricht, fragt den Übermittlungsweg, ob er die Rechnung schon hat, bevor er erneut sendet. Wiederholungen von Webhooks folgen einem eigenen Zeitplan (siehe Webhooks).
Gesetzliche Fristen
Zwei Übermittlungswege haben eine Frist ab dem Datum auf der Rechnung. Der Service berechnet sie für jede Rechnung beim Eingang.
| Übermittlungsweg | Frist | Quelle |
|---|---|---|
RO-EFACTURA | Das Ende des fünften Arbeitstags nach dem Ausstellungsdatum. | OUG 89/2025 und eine Mitteilung der ANAF. |
PL-KSEF | Das Ende des nächsten Geschäftstags nach dem Ausstellungsdatum, also die Frist von offline24. Der Service wendet sie auf jede polnische Rechnung an. | Das polnische Umsatzsteuergesetz, Art. 106nda, in der durch Dz.U. 2025 poz. 1203 geänderten Fassung. |
Die anderen Übermittlungswege haben keine Frist. Für eine Rechnung, die noch queued ist, erfasst der Service eine Warnmeldung, wenn die Hälfte der Zeit vom Beginn des Ausstellungstags bis zum Fristende verstrichen ist, und erneut bei vier Fünfteln.
Warnung
Zwei Grenzen der Fristberechnung
- Sie zählt Montag bis Freitag. Sie hat keinen Kalender nationaler Feiertage, deshalb zählt ein Feiertag als Arbeitstag, und das tatsächliche Fristende kann später liegen als das vom Service verwendete.
- Sie zählt Tage in UTC. Die Behörden zählen in Ortszeit, deshalb weicht die Tagesgrenze um ein oder zwei Stunden ab.
Warnmeldungen werden im Service erfasst und nicht versendet (siehe Monitoring und Warnmeldungen). Die Fristen werden auch je Rechnung als deadline_at angezeigt, für Rumänien und Polen, wenn die Rechnung ein Ausstellungsdatum trägt (siehe Eine Rechnung lesen). Die beiden Fristen wurden zuletzt am 27. Sept. 2026 mit diesen Quellen abgeglichen; sie werden erneut geprüft, bevor die Dokumentation veröffentlicht wird.