What invoice data should you check before connecting an ASP?
Build a field-mapping sheet that connects UAE e-invoice requirements to source records, sample evidence, data gaps and accountable owners.
Open an invoice PDF beside the record that produced it. Can you find every displayed value in a field the proposed integration can read? Check the buyer’s identity, the address and each line’s tax treatment. A value added by the print template or pasted into a description may have no usable structured source.
Before connecting an accredited service provider (ASP), build a field map with evidence and named owners. It should show which data exists and which decisions remain unresolved.
Rules checked: 30 September 2026. This article is educational operational guidance, not legal advice or tax classification approval. The worksheet below is a proposed review method, not evidence that Nesaku has inspected your records or tested a provider integration.
Use the field guide and the current rules together
The MoF Mandatory Fields publication, version 1.0, dated 23 February 2026, separates electronic tax invoices from commercial electronic invoices. Use it to identify business information to investigate, rather than assuming one field count describes every scenario.
The current OpenPeppol PINT AE Billing catalogue shows version 1.0.4. Its release notes date that billing release to 2 June 2026 and describe validation corrections. The catalogue’s publication-tool footer date is not the billing release date.
For an implementation, the technical reviewer must consult the semantic model, syntax bindings, code lists and rules. Record the exact term and applicable condition in the map. A value can be present yet use the wrong code or fail a relationship with another value. Ask the ASP which specification and validation artefacts its proposed route uses.
Collect examples that expose differences
Begin with an anonymised ordinary invoice and the associated customer, item and tax records. Add examples of variations your business actually uses: foreign currency, discounts, different tax categories or a credit note. Do not manufacture an exotic scenario merely to fill a checklist.
Review a supplier invoice too. Identify where its structured values would enter your accounts-payable process, who checks them and how a mismatch is held for review. Keep customer identities, credentials and sensitive descriptions out of public forms or unsecured messages; agree an appropriate evidence-sharing channel first.
For each example, compare the stored record, available export or API response, and rendered document. Note the exact software edition and version. A field visible in the application may still be absent from the interface the supplier intends to use.
Keep these data questions separate
Party identity and routing
Check the formal seller and buyer names, registration information, addresses and electronic endpoints against the relevant official terms. The MoF field guide distinguishes an electronic address based on TIN from tax identifiers and identifies UAE endpoint scheme 0235. Do not assume an email address is the required electronic endpoint, or copy one registration value into every identifier field.
Ask the ASP to confirm the onboarding and counterpart identification route for your cases. If a customer record is incomplete, assign the repair to the person who can verify it with the customer. An integration developer should not invent an identifier to make validation pass.
Lines, tax decisions and totals
Look beyond the final amount. Trace quantities, units, prices, discounts and charges to their source records, then compare line values with document totals. Record who owns each calculation and where rounding occurs.
Keep the tax category decision separate from its technical encoding. Finance and its qualified adviser determine the appropriate treatment; the technical reviewer maps that approved decision to the applicable code and rule. Zero-rated, exempt and outside-scope treatment should not collapse into a single “no tax” label because the current application happens to display zero.
Corrections and references
Check how credit notes are created and related to the documents they correct. Decision 243, Article 6(2) addresses electronic credit notes for specified correction circumstances. The field review should capture the reason and relevant source-document references for the scenario, using the current credit-note specification.
If a clerk currently writes the original invoice number into free text, investigate whether a structured link exists. Decide how that link will survive export before promising automatic correction handling.
A reusable field-mapping sheet
Make one row per official term from the current semantic model. The groups below are not exhaustive. Cardinality 1..1 means exactly one value; 0..1 means optional, at most one. Check applicable rules as well.
| Business meaning | Official reference to record | Required or conditional rule | Source and sample evidence | Gap and owner |
|---|---|---|---|---|
| Invoice identity and issue details | IBT-001 number; IBT-002 date; IBT-168 time | Number/date: 1..1; time: 0..1; also check rules | Source document fields and exported sample | Missing source value or formatting issue; technical owner |
| Seller and buyer identities | Party, tax and endpoint terms | Scenario-specific identity rules | Company/customer records and verification evidence | Unverified identity; finance/customer-record owner |
| Structured addresses | Seller/buyer address terms | Applicable address and country rules | Stored components compared with document | Address exists only as free text; administrator |
| Line data | Quantity, unit, price and item terms | Applicable codes and calculation rules | Item record, invoice line and payload | Display-only unit or inaccessible line; system owner |
| Tax treatment and breakdown | Category, rate and breakdown terms | Adviser-approved scenario plus technical rule | Approved treatment and calculation evidence | Classification unresolved; accountant |
| Totals and currency | Monetary and currency terms | Applicable currency and reconciliation rules | Calculation trace and exported totals | Conflicting calculations; finance and technical leads |
| Credit-note relationship | Current credit-note terms and rules | Applicable correction scenario | Credit note and original-record linkage | Reference is free text; finance/system owner |
Add a review date, specification version and status to each row. Mark a gap as missing, unverified, inaccessible or awaiting a tax decision. Those labels lead to different work: record repair, evidence collection, interface changes or adviser review.
Repair the source, then test the route
Consider a hypothetical consultancy whose buyer address appears correctly on its PDF because finance copies it from an email. Its export contains only the customer name. Correct the customer record and establish how future addresses are verified. Writing a connector that scrapes the PDF would leave the underlying ownership question unresolved.
After repairs, repeat the comparison on new examples and keep the observed evidence. Agree which values come from your software and which the ASP generates or enriches. Record the agreement so support staff can trace a later discrepancy.
Use the resulting map in the keep-or-replace software decision, then carry unresolved scenarios into acceptance testing. A completed map does not prove successful exchange or reporting.
Return to the readiness map if system ownership is unclear. For a data-gap review conversation, start with your software/version and the missing information you have identified. Agree how to share anonymised records before sending them.
Sources and limits
Sources checked on 30 September 2026:
- MoF Mandatory Fields v1.0, 23 February 2026, separate invoice categories and business field guidance.
- OpenPeppol PINT AE Billing 1.0.4 and release notes, 2 June 2026, current billing version at the check date.
- Invoice transaction model and rules and credit-note transaction, technical requirements to expand the worksheet.
- MoF Decision 243 of 2025, Articles 6 and 7.
Recheck specifications before implementation. This worksheet does not establish your scope, tax treatment, provider compatibility or software capability; each requires evidence for the actual business and proposed route.