The sending pipeline and Job Queue
Every e-invoice the app produces is processed by a fixed, seven-stage pipeline. Documents are enqueued automatically when they are posted, and a recurring Job Queue entry works through the queue in the background. This page explains the stages, when documents are enqueued, and how retries and dead-lettering work.
The seven stages
- Stage 1 - Source-data validation: the raw document data is validated (SourceData rules).
- Stage 2 - Business validation: business-level constraints are validated (BusinessValidation rules).
- Stage 3 - Invoice-model validation: the assembled invoice model is validated (InvoiceModel rules).
- Stage 4 - Serialize & persist artifact: the validated payload is serialized and persisted as an immutable artifact.
- Stage 5 - Generate XML/PDF: the e-invoice XML (and PDF) is generated via the Digivoice API.
- Stage 6 - KoSIT pre-validation: when Enable XML Validation is switched on in the setup, the generated document is checked against the official KoSIT validator before it leaves the system. A KoSIT rejection is a permanent failure.
- Stage 7 - Release & transmit: the artifact is released (becoming immutable) and the e-invoice is transmitted to the recipient by e-mail.
Documents that are enqueued only to be attached to the posted document or e-mail (rather than auto-sent) stop after generation at status Generated - they are not transmitted in stage 7.
Stages 1-3 must all pass before generation. If any Error-severity finding is raised, the document does not proceed - review the Validation Findings and correct the data.
When are documents enqueued?
A document is enqueued automatically at posting time for the following document types:
- Sales Invoice and Sales Credit Memo
- Service Invoice and Service Credit Memo
- Purchase Credit Memo
The recurring Job Queue
Processing is driven by a recurring Job Queue entry:
- Category: DXPEINV
- Schedule: Monday to Friday, 08:00-18:00
- Frequency: every 30 minutes
On each run the Job Queue picks up all Pending entries and moves them through the pipeline.
Retry, backoff and dead-lettering
If a stage fails with a recoverable error, the entry goes to Error and is retried on a rising backoff schedule with added jitter to avoid bunching:
- Attempt delays: 5 minutes → 15 minutes → 1 hour → 6 hours → 24 hours, plus a small deterministic jitter (up to 59 seconds, derived from the entry number) so retries do not all fire at the same instant.
- Max Attempts: default 5. When attempts are exhausted, the entry is moved to Failed (dead-letter).
Permanent errors and authentication failures do not wait for retries - they dead-letter immediately. A dead-lettered (Failed) entry is never picked up again automatically; fix the cause and use Re-queue on the Document Status page to reset the attempt counter and return it to Pending.