12. Known Limitations

These are capability gaps — things the framework does not do — as distinct from the code-level defects in Chapter 11 — Technical Debt. None of these are bugs to fix in isolation; each is a design/scope question for a future phase (see § 12.7).

12.1 Not Wired Into Any ERP Business Workflow

No Sales/Purchase invoice service in Shumoul.Saas.Api calls into the E-Invoicing SDK. The only way to submit an invoice to ZATCA is a direct call to POST /api/EInvoicing/Generate with an already-built UblInvoiceDto — whoever does this (a frontend, a POS integration, or a manual test) is responsible for building that DTO correctly; there is no ERP-owned mapping service doing this today.

12.2 No Background Jobs, No Retry

Submission and onboarding are fully synchronous, in-request. There is:

• No certificate-renewal job watching ExpiresOn and proactively renewing before expiry — renewal is a manual, on-demand controller call.
• No invoice-status polling job — consistent with ZATCA Phase 2's synchronous-response model, but also means no server-side safety net if the synchronous call fails partway.
• No retry of a rejected or failed submission — the original caller must retry manually.
• No cleanup/archive job for the local-filesystem invoice archive.

The platform has a proven, generic, channel-agnostic background retry pattern already (the Notification Framework's retry pipeline, used by Email/SMS/WhatsApp/Push dispatch failures). E-Invoicing has no dependency on it and does not use it.

12.3 No Notification Integration

No "invoice cleared," "invoice rejected," or "certificate expiring" alert exists anywhere. Concretely:

Scenario	Notification exists?
Invoice cleared (ZATCA accepted the submission)	No — no event, no NotificationEventKeys entry, no handler
Invoice rejected (ZATCA rejected the submission)	No — the closest analogues (OtpIsRejectedEvent, CompilanceChecksFailureEvent) concern OTP/compliance rejection during onboarding, not invoice clearance rejection, and their handlers only mutate app settings, never alert anyone
Certificate expiring soon	No — ProductionCsidSettings.SetExpiration() stores an expiry value, but nothing reads it and fires a notification

A tenant admin has no way to learn — via email, SMS, WhatsApp, or in-app notification — that an invoice was rejected, that a certificate is about to expire, or that onboarding compliance checks failed, unless they are actively watching the synchronous HTTP response or polling the settings endpoints manually.

12.4 No Repository of Its Own

E-Invoicing is the only one of the platform's four ZATCA/Notification/BackgroundJobs/WhatsApp-scale subsystems that has never been split into its own repository. It lives inside Shumoul.Framework alongside the platform's other generic base packages.

12.5 No ADR, No Certification

No architecture decision record documents E-Invoicing's boundary, and no Golden Reference certification process has started. See Chapter 1 — Overview § 1.6.

12.6 Internal Fork Duplication

The Tenancy fork is a duplicated copy of the core SDK, not a shared-core-plus-adapter design, and has already drifted from its source in several confirmed ways. See Chapter 11 — Technical Debt § 1.

12.7 What a Future Phase Would Need to Decide

These are open questions carried forward from the Phase 0 discovery, not decisions made by this documentation:

• Does E-Invoicing become a certified Framework (its own repository, an ADR, an ERP-owned integration layer, retry/notification wiring), or does it stay packaged-but-not-extracted, with the ERP building a thin business layer on top of the existing SDK?
• If extracted, the Tenancy fork duplication needs resolving first, or as part of the extraction — carrying a drifted fork into a new repository would perpetuate the problem rather than solve it.
• If a real Sales/Purchase invoice workflow is meant to use ZATCA compliance, a future phase needs to design where the SalesInvoice/PurchaseInvoice → UblInvoiceDto mapping lives, whether invoice approval should block on synchronous ZATCA submission or move to an async/queued model with retry, and how the submission outcome gets persisted against the invoice entity.
• Whether failure/rejection/certificate-expiry notifications should route through the existing Notification Framework rather than building bespoke e-invoicing-specific notification logic.

None of this is scheduled or started by the current documentation effort.