What to test before UAE e-invoicing goes live
Build an acceptance matrix for invoice data, buyer exchange, FTA reporting, receiving, retries and evidence before approving your UAE e-invoicing rollout.
An invoice appearing in a provider dashboard is a starting observation. Before finance approves launch, it needs evidence that the right document was exchanged, the relevant reporting outcome is visible and the ledger can be reconciled. It also needs a safe response when the outcome is unknown.
Use this acceptance plan alongside the UAE e-invoicing readiness guide. The cases below are proposed tests. They are not tests Nesaku has executed or proof that a particular accounting package or ASP is production ready.
Rules checked on 30 September 2026. This is informational operational guidance, not legal advice. Your tax adviser owns scope and tax classification. Finance approves expected business results; technical suppliers demonstrate system behaviour.
Give the test plan a deadline and a boundary
For in-scope businesses with revenue equal to or exceeding AED 50 million, Decision 66 sets ASP appointment by 30 October 2026 and implementation by 1 January 2027. Below AED 50 million, consolidated Decision 244, Article 5 sets 31 March 2027 and 1 July 2027. Confirm your phase with the scope worksheet.
Record the accounting edition and version, customisations, connector release, ASP environment and API version. Add the legal entities and transaction types included. The OpenPeppol UAE catalogue lists Billing, Self-Billing and Tax Data Document specifications at version 1.0.4 on the checked date. Record the exact validation artefacts used, and repeat affected cases when versions change.
Keep the outcomes separate
The MoF exchange model distinguishes client submission, provider validation, exchange to the buyer’s ASP, delivery to the buyer and reporting to the FTA. It describes separate exchange and reporting statuses returned to the business.
Your provider’s status names may differ. Ask for a written mapping showing what each label establishes, which acknowledgement supports it and what remains pending. An API success response can mean the provider accepted a job; its documented semantics determine what it proves. Do not equate network validation with buyer approval for payment.
Create finance-approved fixtures
Use anonymised representative invoices and credit notes, with expected amounts and tax treatments approved before execution. Start with the data-readiness mapping sheet. Include scenarios the business actually uses: foreign currency, discounts or mixed tax categories where applicable. Add agency or self-billing only with its own reviewed scope.
Decision 243, Articles 6 and 7 addresses recipient processing and electronic credit notes. Include purchasing and corrections in the plan. Use the PINT AE invoice rules for technical validation; well-formed XML alone does not demonstrate conformity to those rules.
Copy this acceptance matrix
For every row, record the approved fixture, expected result, observed result, evidence reference, failure owner and resolution date. Keep unexecuted cases visibly pending. These expectations are proposed engineering controls to agree with your suppliers, not extra statutory rules.
| Case | Expected result to agree | Evidence to retain | First investigation owner |
|---|---|---|---|
| Ordinary outbound invoice | Correct content, traceable exchange and reporting outcomes | Source record, payload, document ID and acknowledgements | Connector supplier and ASP |
| Missing required buyer data | Actionable validation failure without an unexplained success label | Failed field or rule, source reference and error detail | Finance data owner |
| Credit note | Approved adjustment links to the intended invoice | Original reference, adjusted amounts and statuses | Finance, then connector supplier |
| Timeout after submission | Operator checks outcome before any safe retry | Request identity, provider lookup and retry history | Technical operator and ASP |
| Repeated submission | Agreed duplicate control prevents unintended second issuance | Original and repeated request correlation | Connector supplier and ASP |
| Missing or late status | Reconciliation exposes the pending outcome | Polling or reconciliation evidence and alert | Technical operator |
| Reporting failure after exchange | Reporting remains unresolved and visible | Separate exchange and reporting history | ASP with finance oversight |
| Buyer route unavailable | Provider-specific handling is documented and escalated | Routing response and approved next action | ASP and finance |
| Inbound invoice and credit note | Correct entity receives documents for controlled review | Incoming content, duplicate check and ledger linkage | Finance and inbound implementer |
| Archive retrieval | Documents and related outcomes remain readable and linked | Exported records and retrieval result | Records owner |
Where the sandbox cannot reproduce a reporting rejection or buyer-route failure, document that limitation. Ask which assurance the ASP can provide and which controlled check remains necessary. Do not mark a simulation as a real FTA response.
Test recovery without changing the business event
Arrange failure exercises with the ASP in an isolated environment. Simulate a connector restart, lost response or delayed notification. Agree identifiers and duplicate behaviour beforehand. Never create a fresh invoice number just to make a retry look successful; any legal correction requires finance and adviser approval.
Set a reconciliation expectation for each test: source invoices and credit notes should match the provider’s known documents, with pending exchange or reporting outcomes listed separately. Include duplicate inbound notifications and confirm they do not create extra bills. Define who investigates a mismatch through the errors and ownership runbook.
Make approval depend on evidence
Use separate review stages for local validation, provider sandbox behaviour and authorised production verification. Mocks test your own logic. Sandbox results test the interfaces available there. Production checks require approved onboarding and controlled transactions with actual exchange and reporting evidence; sandbox success does not establish those outcomes.
Finance should sign the expected totals, correction workflow and receiving controls. The implementer signs the tested technical boundary. The business owner approves residual risk and confirms an operator can obtain evidence and escalate failures. Leave required cases with unknown outcomes open, with an owner and next step.
Include this plan in the ASP contract scope and rehearse record export and retrieval. If you need help defining acceptance for your installed system, discuss the test boundary with Nesaku. Bring the version list and unresolved cases rather than sensitive raw invoices.
Sources and review date
Primary sources checked on 30 September 2026: MoF Decisions 244 and 66 for the amended timetable; Decision 243, Articles 6 and 7, for recipients and credit notes; the MoF programme hub for exchange/reporting stages; and the OpenPeppol UAE catalogue and PINT AE invoice rules for technical validation. Inline links identify the relevant documents. The matrix is a proposed acceptance worksheet, not an executed result or compliance certification.