What EInvoiceCheck checks

EInvoiceCheck is an independent UAE e-invoice preflight validator. It checks an invoice against the validation layers currently supported by its engine before the file reaches your Accredited Service Provider.

What a pass means

A pass means the invoice passed the checks that EInvoiceCheck actually ran. It does not mean FTA approval, legal filing, complete official artifact parity, or guaranteed ASP, buyer-system or authority acceptance.

Three layers, in the order they matter

1. Format

Checks whether the XML is well-formed enough to parse. Mismatched tags and other parser failures are reported as blocking format issues before deeper validation is attempted.

2. Structure

For the supported XML path, checks UBL 2.1 Invoice or CreditNote structure with the currently wired XSD validation layer, including namespace and schema-shape failures.

3. Semantic

Checks the invoice data and business relationships currently implemented by the engine, including required terms, UAE TRN shape, currencies and code lists, VAT category/rate consistency, line arithmetic, tax breakdowns and document totals. The XML path also runs the currently wired Schematron layer.

What the current product does

SurfaceCurrent behavior
XML validator / APIRuns the supported format, UBL structure and semantic validation layers and returns machine-readable issues.
Canonical JSON preflightChecks supported invoice data and arithmetic rules, but does not prove final XML structure.
XML GeneratorBuilds XML from the current template set, computes supported totals and lets you validate the generated result.
Validator safe repairOffers at most two metadata-only repairs (encoding declaration, missing cbc/cac declaration) behind an explicit action, always re-judged by the full validation pipeline. Forbidden characters, wrong namespace URIs, structure and semantics are diagnosed but never rewritten.
APIExposes the same preflight capability programmatically for ERP, integration and CI workflows.

What EInvoiceCheck does not claim

  • No guarantee of ASP, buyer-system or authority acceptance.
  • No claim of complete official XSD/Schematron artifact parity or version coverage unless that exact coverage has been separately verified.
  • No FTA registration or taxpayer-registry lookup.
  • No legal transmission, filing or statutory archival.
  • No legal or tax advice.
  • Canonical JSON preflight checks invoice data; it does not prove that a final XML rendering is structurally valid UBL/PINT-AE XML.

Your ERP or accounting system creates the invoice. EInvoiceCheck preflights the supported checks. Your ASP remains responsible for the official exchange/transmission workflow.

Version and rule claims

The repository currently contains UBL/XSD and PINT-AE/Schematron resources used by the validation pipeline. Public claims about exact official package parity, total rule counts, specific invoice-type-code provenance or complete conformity are intentionally withheld unless the exact deployed artifact and coverage have been verified.

For endpoint-level behavior, payload contracts and response shapes, see the API documentation.

Scope questions

Does a passing EInvoiceCheck result guarantee ASP or authority acceptance?

No. A pass means the invoice passed the validation checks currently implemented and executed by EInvoiceCheck. It is not a guarantee of ASP, buyer-system or authority acceptance.

Is EInvoiceCheck an Accredited Service Provider?

No. EInvoiceCheck is an independent preflight validator. It does not transmit legal e-invoices, replace an ASP, perform statutory filing or provide statutory archival.

Does EInvoiceCheck run XML structure checks?

The current XML pipeline includes XML well-formedness, UBL 2.1 XSD structure checks for supported Invoice and CreditNote documents, and semantic checks including currently implemented rules and Schematron evaluation. Exact official artifact parity and version coverage should only be claimed where separately verified.

What happens when XML is malformed?

Malformed XML fails at the format layer. Deeper checks are skipped where the document cannot be parsed meaningfully, so syntax errors are not presented as fabricated business-rule failures.