Limites et délais légaux
Débits de requêtes, plafonds des réseaux, nouvelles tentatives et délais légaux.
- Dans le bac à sable
En termes simples
Certains systèmes nationaux limitent la vitesse d’envoi des factures, et certaines lois fixent un délai après la date de facture. Cette page liste les limites que nous comptabilisons et les délais légaux que nous surveillons, pour qu’une entreprise puisse planifier la taille d’un lot et le dernier jour où une facture peut être envoyée. Les dates et les plafonds proviennent de sources officielles et doivent être revérifiés avant que quiconque ne s’y fie.
Quatre éléments fixent le rythme : la taille d’une requête, la fréquence à laquelle un client peut appeler l’API, le plafond de chaque client sur les envois vers un réseau, et le délai légal sur les canaux qui en ont un.
Taille des requêtes
Pour un corps de plus de 5 Mo (5 000 000 octets), la réponse est 413, avec un corps de problème (payload-too-large). Cela couvre POST /invoices, POST /invoices/xml, POST /validate et POST /credentials.
Débit des requêtes
Chaque client a un budget pour chaque portée de clé. Il est compté pour le client, et non pour la clé : davantage de clés n’achètent donc pas davantage de requêtes.
| Portée | Appels par seconde | Appels par minute |
|---|---|---|
submit | 20 | 600 |
read | 50 | 3 000 |
admin | 20 | 600 |
En outre, la liste de suivi peut être lue 30 fois par minute et les preuves du suivi 10 fois par minute. Au-delà d’une limite, la réponse est 429 avec un en-tête Retry-After en secondes. Attendez ce délai et renvoyez le même appel. Un essai à blanc qui trouve tous les validateurs occupés répond 503 (busy) avec Retry-After de la même façon.
La recherche Peppol d’un acheteur est limitée elle aussi : 30 recherches par minute et 300 par heure pour chaque client. Une réponse déjà conservée ne coûte rien.
Plafonds des réseaux
Le service comptabilise les appels de chaque client vers un réseau par rapport au plafond publié par ce réseau. Un client correspond au client indiqué sur la facture. Une facture sans client est comptée sous local. Les compteurs sont conservés dans la base de données : un redémarrage ne les remet donc pas à zéro.
| Canal | Appel | Plafond |
|---|---|---|
PL-KSEF | Envoyer une facture | 10 par seconde, 30 par minute, 180 par heure |
PL-KSEF | Lire un statut | 30 par seconde, 120 par minute, 1 200 par heure |
RO-EFACTURA | Tout appel | 1 000 par minute |
DE-XRECHNUNG, PEPPOL, FR-PA | Aucun publié, aucun appliqué |
Quand un client dépasse un plafond, sa facture reste en file d’attente et est retentée une seconde plus tard. Rien n’est rejeté et rien n’apparaît comme une erreur.
Sources, consultées le 2 oct. 2026 : les limites de l’API KSeF et la procédure OAuth de l’ANAF. KSeF compte séparément chaque couple formé d’un contexte et d’une adresse IP. L’ANAF indique 1 000 requêtes par minute pour son API et répond 429 au-delà, sans préciser sur quelle base.
Les envois polonais s’additionnent : à 180 par heure, 1 000 factures pour un client prennent environ cinq heures et demie. Le mode offline24 polonais laisse jusqu’à la fin du jour ouvré suivant pour envoyer. Les sessions par lots sont prévues et non développées.
Nouvelles tentatives après une erreur de réseau
Seule une erreur temporaire d’un réseau donne lieu à une nouvelle tentative. Un rejet, non : il va sur la liste de suivi.
| Échec | Attente avant la tentative suivante |
|---|---|
| 1er | 30 secondes |
| 2e | 2 minutes |
| 3e | 10 minutes |
| 4e | 30 minutes |
| 5e | 1 heure |
| 6e | Aucune. La facture devient dead_letter et va sur la liste de suivi. |
Une tâche qui s’arrête au milieu d’un envoi demande au canal s’il détient déjà la facture avant de l’envoyer à nouveau. Les nouvelles tentatives des webhooks suivent leur propre calendrier (voir webhooks).
Délais légaux
Deux canaux imposent un délai à partir de la date de la facture. Le service le calcule pour chaque facture à l’entrée.
| Canal | Échéance | Source |
|---|---|---|
RO-EFACTURA | La fin du cinquième jour ouvré après la date d’émission. | OUG 89/2025 et un avis de l’ANAF. |
PL-KSEF | La fin du jour ouvré suivant la date d’émission, qui correspond à l’échéance offline24. Le service l’applique à toutes les factures polonaises. | La loi sur la TVA, art. 106nda, modifiée par Dz.U. 2025 poz. 1203. |
Les autres canaux n’ont pas de délai. Pour une facture encore queued, le service consigne une alerte quand la moitié du temps entre le début de la date d’émission et l’échéance s’est écoulée, puis à nouveau aux quatre cinquièmes.
Attention
Deux limites du calcul du délai
- Il compte du lundi au vendredi. Il n’a pas de calendrier des jours fériés nationaux : un jour férié compte donc comme un jour ouvré, et l’échéance réelle peut tomber plus tard que celle qu’utilise le service.
- Il compte les jours en UTC. Les administrations comptent en heure locale : la limite du jour diffère donc d’une heure ou deux.
Les alertes sont consignées dans le service et ne sont pas envoyées (voir supervision et alertes). Les échéances sont aussi indiquées par facture sous deadline_at, pour la Roumanie et la Pologne, quand la facture porte une date d’émission (voir lire une facture). Les deux échéances ont été vérifiées pour la dernière fois par rapport à ces sources le 27 sept. 2026 ; elles sont revérifiées avant la publication de la documentation.