Invoice
Used when the supplier issues the billing document to the buyer under the applicable business and tax scenario.
PARTIES · SUPPLIER → BUYERTechnical field guide · United Arab Emirates
Turn PINT AE into a governed enterprise data contract.
A practical guide to UAE Invoice, Credit Note and Self-Billing data: what the specification controls, which fields depend on the scenario, where ERP ownership ends, how validation works and what must be proven before activation.
Business and technical viewVersion-aware implementationNo production-status implication
ERP / Billing / APAuthoritative business records
→
Canonical data contractOwned mappings and rules
PINT AE PREPARATIONTransform · validate · classify
Apply the effective syntax binding, code lists, semantic rules and UAE specialisation.
PINT AEInvoice / Credit Note
TDD / TDSTax-data interaction
MLSLifecycle status
This diagram explains a target implementation pattern. It does not represent a live UAE production connection or accredited-provider status.
Document boundaries
Start with the transaction type—not the XML.
PINT AE provides structured billing and self-billing specifications. The business event determines the correct document and role model before any field is mapped.
Credit Note
Used for supported downward adjustments or reversals, with the required relationship to the affected transaction.
CONTROL · REFERENCE & REASONSelf-Billed Invoice
Used where the buyer issues the invoice on behalf of the supplier under an applicable self-billing arrangement.
PARTIES · ROLE REVERSALSelf-Billed Credit Note
Used for the corresponding supported credit adjustment in the self-billing model, with its own process context.
CONTROL · AGREEMENT & TRACEBoundary rules: PINT AE does not create a separate Debit Note transaction. Upward adjustments are handled through an additional or supplementary Invoice as applicable. “Provisional” or “pro forma” commercial documents are not a separate PINT AE transaction category; the regulated document path begins when the applicable Invoice or Credit Note is issued. B2C transactions remain outside the current statutory system until determined otherwise by ministerial decision.
Version discipline
Never treat a version number as permanent.
PINT AE defines business terms and rules with syntax bindings to structured UBL XML. OpenPeppol publishes versioned UAE specifications, release notes, semantic models, syntax bindings, code lists and Schematron rules. Implementation must bind every test and release to the version effective for the target environment.
As of this review, OpenPeppol documentation includes published version directories and an upcoming channel that may contain a later candidate release. “Latest” is not enough: the project must record which version is accepted by the applicable environment.
DESIGN
Target specification setBilling, Self-Billing and TDD versions approved for build.
TEST
Environment-supported versionExact artefacts, identifiers, code lists and rules used in validation.
RELEASE
Effective-date controlActivation date, compatibility window, regression evidence and rollback decision.
OPERATE
Change governanceMonitor release notes, classify impact and retain evidence of controlled adoption.
Do not publish or contract a hard-coded PINT AE version without confirming its production applicability. A release visible in an “upcoming” documentation channel may not yet be the operative production baseline.
Field-classification map
Every data element needs a rule and an owner.
This simplified I/C/O lens is for readiness workshops. The authoritative semantic model, cardinality and business rules for the active release always prevail.
IMandatory in the applicable base transactionCConditional by scenario, value or ruleOOptional where permitted
DATA GROUP
CLASS
TYPICAL CONTENT
READINESS QUESTION
Document controls
I
Specification and process identifiers, document number, issue date, document type and currency.
Can the source create a unique, immutable document identity and correct process context?
Supplier identity
I
Legal name, electronic address, postal address and applicable legal or tax identifiers.
Does the record resolve to the correct legal entity—not merely a trading name or branch label?
Buyer identity
I
Legal name, endpoint, address and applicable identifiers needed for exchange and tax treatment.
Can the buyer master distinguish group companies, registrations, endpoints and locations?
Invoice lines
I
Line ID, quantity, unit, item description, price, line amount and tax-category information.
Can line values be reproduced from the authoritative transaction without manual enrichment?
Tax breakdown
C
Category, rate, taxable amount, tax amount and exemption or reason data where the scenario requires it.
Is tax logic explicit at line and document level, with controlled codes and supporting reasons?
Allowances and charges
C
Line or document-level discounts, surcharges, reason codes, bases, percentages and amounts.
Can every commercial adjustment be allocated and reconciled without distorting tax or totals?
Monetary totals
I
Line-extension, allowance, charge, tax-exclusive, tax-inclusive, tax and payable amounts.
Does one rounding policy reproduce all reported totals at the required precision?
Payment information
C
Due date, payment means, account or card references, terms and remittance information where applicable.
Which values are regulatory, which support automation and which must not expose sensitive data?
Document references
C
Preceding invoice, purchase order, contract, project or other reference required by the process.
Can the system retrieve the correct reference across corrections, returns and multi-system flows?
Delivery and notes
O
Delivery details, supporting notes and other permitted contextual information.
Is the content genuinely needed, allowed by the active specification and free of uncontrolled data?
I/C/O is a workshop shorthand—not a substitute for the official field model. A field shown here as conditional may become mandatory under a specific document type, tax category, party role or business rule.
ERP-to-PINT transformation
Build a canonical contract between business systems and regulation.
A robust design avoids burying every UAE rule inside each ERP connector. Source systems provide authoritative facts; a governed mapping layer applies consistent semantics and generates the target documents.
ERP, billing and AP
Own the commercial transaction, party master, tax determination, quantities, prices, approvals and accounting state.
- Legal-entity context
- Customer and supplier masters
- Lines, tax and totals
- References and approvals
→
Canonical data contract
Normalise field names, formats, ownership, transformations, default rules, code mappings and quality checks.
- Source-to-target map
- Transformation decisions
- Conditionality matrix
- Version and change control
→
PINT AE and lifecycle data
Generate and validate the applicable structured document, correlate reporting data and return statuses to the enterprise workflow.
- Invoice or Credit Note XML
- Self-Billing where applicable
- TDD/TDS correlation
- MLS and evidence trail
Correct business facts, tax/VAT treatment, party master data, source values, approvals, document intent and exception decisions remain with the business and its authoritative systems.
Configured mapping, syntax generation, validation, exchange preparation, tax-data interaction, status forwarding and retained technical evidence operate within the agreed and authorised service scope.
Layered validation
A valid XML file can still be an invalid business document.
Validation should progress from structure to meaning, arithmetic, identity and lifecycle consistency. Each failure must return a stable rule reference and an actionable owner.
XML and schema
Confirm the payload is well formed, uses the expected namespaces and conforms to the required UBL schema.
FAILURE OWNER · INTEGRATIONSyntax binding
Check that business terms appear in permitted XML elements with the required cardinality and data representation.
FAILURE OWNER · MAPPINGCode lists
Validate currencies, countries, units, tax categories, document types, identifier schemes and other controlled values.
FAILURE OWNER · MASTER DATASemantic rules
Apply PINT and UAE-specific Schematron rules, including conditional fields and relationships between values.
FAILURE OWNER · TAX / FUNCTIONALArithmetic and tax
Reconcile line extensions, allowances, charges, category subtotals, tax amounts, rounding and payable totals.
FAILURE OWNER · ERP / FINANCEExchange and lifecycle
Validate participant identity, routing capability, duplicate controls, references and correlation across PINT, TDD/TDS and MLS.
FAILURE OWNER · OPERATIONSFailure-prevention register
Design for the errors your landscape can actually create.
These are common implementation risk areas—not a ranked claim about UAE production rejection volumes. The correct priority comes from profiling your own data and interfaces.
Wrong entity or identifier
Trading names, branches, group companies, tax registrations and participant endpoints are conflated.
PREVENTION
Create an entity-identity register and reconcile every identifier to its owner and effective dates.
Conditional fields omitted
A field appears optional in the base model but becomes required for the chosen tax, payment or reference scenario.
PREVENTION
Maintain a scenario-to-field matrix and test every conditional branch, not only the happy path.
Tax category inconsistency
Line category, rate, exemption reason and document-level tax breakdown do not describe the same treatment.
PREVENTION
Map approved ERP tax codes to controlled PINT outcomes and prohibit free-text workarounds.
Totals and rounding drift
Source systems round at different points, causing lines, tax subtotals and document totals not to reconcile.
PREVENTION
Approve one calculation and rounding policy, then regression-test boundary values and mixed-tax documents.
Broken correction chain
Credit Notes or supplementary Invoices cannot reliably identify the document or business event they adjust.
PREVENTION
Persist immutable references and test cancellations, partial credits, returns and upward adjustments end to end.
Status without business action
A technical rejection reaches a queue, but no owner, correction rule or resubmission decision is defined.
PREVENTION
Map every status to a severity, owner, response time, correction path and evidence requirement.
PINT, TDD/TDS and MLS
Three artefact families tell one transaction story.
The enterprise record is incomplete if the invoice XML, tax-data interaction and message statuses cannot be correlated to the same document and lifecycle.
PINT AE
Business document
The structured Invoice or Credit Note exchanged between supplier and buyer through the provider model.
Control focus
Document identity, parties, lines, tax, totals, references, syntax and semantic validity.
TDD / TDS
Tax-data interaction
TDD reports applicable issued or received invoice data. The specification also describes a status form used for the failed-validation scenario.
Control focus
Reporter role, source-document correlation, document function, extracted data and authority response.
MLS
Message status
Conveys validation and reporting outcomes between the relevant corners so business systems can update lifecycle state.
Control focus
Stable status mapping, correlation IDs, timestamps, negative paths, retry decisions and evidence.
Buyer-side negative path: the current UAE flow overview states that when Corner 3 validation is unsuccessful, Corner 3 reports a negative MLS to Corners 2 and 5 and does not report a normal TDD to Corner 5 for that path. The runbook must preserve the rejected payload, rule results, status messages and resubmission relationship.
Acceptance test pack
Prove the document and the operating response.
A test passes only when the expected XML, validation result, exchange state, reporting interaction, ERP status and retained evidence all agree.
Positive scenarios
Demonstrate that supported business flows complete with correct documents, statuses and evidence.
✓
Standard taxable InvoiceOne tax category, valid parties, balanced totals and successful lifecycle.
✓
Mixed or conditional tax scenarioCorrect category breakdown, rate and supporting reason fields.
✓
Credit NoteValid reference, reason and corrected monetary relationship.
✓
Self-BillingCorrect issuer/receiver roles, process identifiers and source-system posting.
✓
Allowance, charge and roundingLine and document adjustments reconcile across tax and payable totals.
Negative scenarios
Demonstrate deterministic rejection, actionable diagnostics and controlled recovery.
!
Missing mandatory termCorrect rule ID, severity, owner and prevention of onward processing.
!
Invalid conditional combinationTax category, rate or exemption data intentionally conflicts.
!
Totals mismatchLine, tax or payable arithmetic fails at a controlled validation layer.
!
Unknown or invalid endpointRouting failure returns an operationally meaningful state.
!
Buyer-side validation failureNegative status path, evidence retention and no normal receiver-side TDD.
Minimum exit gate
Every in-scope entity and document type has approved mappings, representative positive and negative scenarios, reconciled source and target values, named exception owners, repeatable regression results and retained evidence linked to the exact specification version.
PINT AE readiness sequence
Move from field inventory to controlled release.
The technical programme should produce evidence at four gates, not one large “integration complete” statement.
Scope confirmed
Entities, transaction types, business scenarios, versions, owners and external dependencies are documented.
EVIDENCE · SCOPE REGISTERData contract approved
Every target term has a source, rule, owner, quality check, conditionality and change-control path.
EVIDENCE · MAPPING MATRIXValidation proven
Positive and negative documents pass the intended layers with reconciled statuses and actionable diagnostics.
EVIDENCE · TEST PACKOperations rehearsed
Queues, correction, retry, resubmission, reconciliation, retention and support paths have named owners.
EVIDENCE · RUNBOOKInvocor implementation boundary
Technical readiness does not equal production authorisation.
Invocor is Abzer DMCC’s global Peppol-based e‑Invoicing platform. The UAE implementation includes PINT AE, Self-Billing, tax-data and status-processing architecture in accreditation and pre-production scope.
Data assessment, mappings, integration preparation, validation and operating-model design may proceed before activation—but every output must retain its environment, version and dependency qualifiers.
Primary technical sources
Build against the official, effective artefacts.
Use this guide for programme structure. Use OpenPeppol and UAE Ministry of Finance materials for the normative specification and current regulatory position.
UAE electronic document specifications
Versioned PINT AE Billing, Self-Billing and UAE Tax Data Document documentation.
Open OpenPeppol documentation ↗Upcoming UAE specifications
Later candidate documentation that must not be assumed to be the active production baseline.
Review upcoming channel ↗UAE Ministry of Finance eInvoicing
Official programme definition, legislation, mandatory-field materials and five-corner overview.
Open official portal ↗Last content review: 22 September 2026. This field guide is educational and does not replace the active semantic model, syntax binding, code lists, Schematron rules, implementation decisions or professional tax advice. The official artefacts effective for the target environment prevail.
Convert your ERP data into a PINT AE-ready implementation plan.
Assess entity scope, document types, source fields, conditional rules, tax mappings, identities, validation gaps, test scenarios and operational ownership.