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: the e-invoice is generated as XRechnung XML via the Digivoice API and stored as the artifact. This applies to every sending profile, because the XRechnung is what the KoSIT check validates; with the ZUGFeRD sending profile, the ZUGFeRD PDF is created when the email is sent.
• 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 first re-checks recently rejected entries (see below), then picks up all Pending entries and the Error entries whose retry is due, and moves them through the pipeline. Each entry is processed in its own transaction, so an error in one entry does not undo or stop the others.

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 Retry 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 not retried on the backoff schedule; fix the cause and use Re-queue on the Document Status page (or, for several selected entries at once, on the document queue page) to reset the attempt counter and return it to Pending. The only exception is a recent content rejection, described below.

Corrected rejections are re-queued automatically

Before it processes the queue, every Job Queue run re-checks the Failed entries of the last 30 days that were rejected for their content - by the checks of stages 1-3 or by KoSIT. If the document now passes stages 1-3 and produces a different e-invoice than the rejected one, for example because the data was corrected, the entry goes back to Pending and is processed in the same run. An unchanged document is left as it is and costs no call to the Digivoice service.

Not re-queued automatically are entries that failed on an authentication error or on a permanent error reported by the Digivoice service, and rejections older than 30 days. Use Re-queue for these.

With automatic sending switched on, an entry re-queued this way is sent to the recipient without any further action. This also applies after an app update that changes the generated e-invoice: content rejections of the last 30 days are then generated again and, if they now pass, sent.

A document that is sent outside the queue with the standard Email action closes its Pending, Error and Failed entries as Sent, so the Job Queue does not send it a second time.