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.