EU Peppol Retry Queue
Automatic exponential-backoff retry queue for failed Peppol transmissions, with dead-letter handling and threshold alerting
Stop losing e-invoices to flaky access points
A Peppol transmission can fail for many reasons: the access point timed out, the network blipped, the recipient SMP returned a 5xx, or the document was rejected by validation. Without a disciplined retry strategy, those failures either silently disappear or hammer your access point until it blocks you. EU Peppol Retry Queue turns every failed transmission into a tracked, auto-retried queue entry that backs off politely, escalates intelligently, and never gets lost. When a document truly cannot be delivered, it lands in a dedicated dead-letter queue for a human to fix and replay.
Exponential backoff with jitter
Each retry waits longer than the last (capped exponential backoff). A deterministic, bounded jitter de-synchronises a wave of simultaneous failures so your access point is never stampeded. Base delay, growth factor, cap and jitter are all configurable per company.
Transient vs permanent
Failures are classified automatically. A timeout or 503 is transient and retried; a Schematron/validation error, a 404 "not registered" or an unroutable recipient is permanent and dead-lettered immediately - because it will never self-heal by retrying.
Dead-letter queue
Documents that exhaust their retry budget, or fail permanently, move to a dedicated dead-letter queue. Fix the upstream problem, then replay the entry with a fresh budget - or abandon it. Every dead-letter raises an Odoo activity so it is never forgotten.
Threshold alerting
The scheduler watches your queue health and raises alerts when the retry queue grows too deep, when the dead-letter backlog or rate climbs, when a single recipient keeps failing, or when an entry has been stuck too long. Alerts are e-mailed to your configured recipients and logged on each run.
What you get
| Capability | Detail |
|---|---|
| Retry policy engine | Capped exponential backoff with deterministic jitter, configurable base / factor / cap / max-retries. |
| Failure classification | Transient (retried) vs permanent (dead-lettered) based on the access-point / AS4 error vocabulary. |
| Dead-letter handling | Dedicated queue, replay with fresh budget, abandon, and an automatic to-do activity per dead entry. |
| Scheduled runner | A cron pass plans the due entries, rate-caps the run, re-attempts each, and records an auditable run log. |
| Alerting | Queue depth, dead-letter count & rate, repeated-recipient failures, stuck retries - with warning / critical severities and e-mail notification. |
| Peppol participant validation | EU ISO 6523 EAS scheme validation (VAT / org-number schemes) so you never replay to a malformed identifier. |
| Invoice integration | Retry entries link back to the originating invoice with a smart button and per-invoice retry count. |
| Idempotent ingestion | Re-feeding the same transmission ID updates the existing entry instead of creating duplicates. |
Bring your own access point (BYOK)
This module is a retry / dead-letter orchestration layer over your own Peppol access point. It does not transmit on your behalf, is not a certified access point, and never stores or impersonates anyone else's accreditation. You feed it the failures reported by your access point - manually through a wizard, or programmatically through a single public method - and it drives the retry lifecycle. A clean transmission hook lets your integration re-POST documents to your own access point using your own credentials; the retry, backoff, dead-letter and alerting behaviour is identical regardless of transport.
Built for operations
- Per-company retry policy and alert thresholds.
- Searchable, stored status / due / dead / exhausted filters.
- Group failures by status, failure type or recipient.
- Full chatter history and activities on every entry.
- Multi-company aware with record-level security rules.
- Comprehensive unit and integration test coverage.
Screenshots
Dead Letter Queue
Record Failure
Retry Queue
Retry Runs
Update date: 2026-07-02