4. Runtime Flow

4.1 Invoice Creation → Validation → Signing → QR → Hash → XML → Submission (End-to-End)

This is one synchronous, in-request call chain — there is no async handoff anywhere in it.

4.2 Invoice Validation (Three Layers)

A fourth method, SDK_Validation (referencing an external ZATCA validator tool), exists in InvoiceValidaterService but is commented out — dead code, not part of the live chain.

4.3 QR / Hash / XML Generation Detail

No QR image is ever rendered — the framework produces only the base64 TLV payload string ZATCA's QR spec defines; rendering it as a scannable barcode image, if done at all, happens outside this codebase.

4.4 Clearance vs. Reporting Routing

See Chapter 10 — Invoice Lifecycle for what each SubmissionStatus value means in practice.

4.5 Retry / Failure Handling

No retry mechanism exists. This is a confirmed absence, not an undocumented flow.

SubmissionStatus has only Accepted, AcceptedWithWarnings, Rejected — no Pending/Failed/ RetryCount field exists.

4.6 Background Jobs and Notifications

Neither exists. No Hangfire registration, no Background Jobs Framework job, no polling/sync/retry/renewal scheduler, and no notification of any kind fires anywhere in the e-invoicing flow. See Chapter 12 — Known Limitations for the practical consequences.