The UAE PINT-AE billing specification does not map cleanly onto the standard invoice output of any ERP system. Every SAP S/4HANA, SAP ECC, and Oracle Fusion or EBS instance used by a UAE Phase 1 business requires targeted development, configuration, or both to generate PINT-AE compliant electronic invoices. The specific gaps — and the remediation paths available — differ between SAP and Oracle, and between the on-premise and cloud versions of each. This post maps the key requirement areas and what each means for implementation planning.
The Core Technical Challenge: PINT-AE Is Not a Print Format
Every major ERP system can produce invoice output in PDF format. Many can produce structured output in legacy EDI formats or proprietary XML schemas. The UAE PINT-AE specification requires UBL 2.1 XML — a specific, internationally standardised structure with a precise field hierarchy, namespace declarations, and schematron validation rules. Generating PINT-AE compliant UBL 2.1 from an ERP invoice is not a configuration task alone; it involves XML mapping, field extraction, and the population of UAE-specific extension fields that have no native equivalent in standard ERP invoice structures.
The schematron validation rules — 302 fatal rules in the PINT-AE specification — run against the XML before the ASP accepts the document for transmission. Validation failures return to the Issuer as a rejection that the business must resolve and resubmit. An ERP that generates invalid PINT-AE XML at go-live is not merely inconvenient; it means invoices fail to transmit, the 14-day issuance clock continues running, and penalty exposure under CD 106 accumulates on every rejected document.
SAP-Specific Requirements
S/4HANA and the Native E-Invoicing Framework
SAP S/4HANA includes a native e-invoicing framework — the Advanced Compliance Reporting (ACR) module — that supports country-specific e-invoicing requirements. SAP has developed UAE-specific content for this framework, but as of the Phase 1 go-live preparation window, the available standard content must be assessed carefully against the PINT-AE V1.0.0 specification to identify gaps, particularly around the UAE extension fields (BTAE fields) that extend beyond the standard PINT billing specification.
The BTAE fields — UAE-specific business terms that do not exist in the core PINT standard — include fields for Free Trade Zone beneficiary identity (BTAE-01), transaction type flags in the eight-position binary format (BTAE-03), Central Bank exchange rate (BTAE-04), AED-equivalent line amount fields (BTAE-08, BTAE-10), disclosed agent principal identity (BTAE-14), and export-specific fields including customs reference numbers (BTAE-21) and Incoterms (BTAE-22). These fields must be populated from data sources that may not be linked to the standard SD billing document in S/4HANA. Custom development or configuration enhancement is typically required.
SAP ECC — The Legacy Constraint
For businesses still running SAP ECC (R/3 or ECC 6.0), the native e-invoicing framework does not exist. ECC is a maintenance-only product; SAP is no longer developing new e-invoicing country content for it. The practical paths for ECC users are: middleware-based XML transformation where the ECC billing output is extracted in a structured format and transformed to PINT-AE by a middleware layer or the ASP; or migration to S/4HANA before the go-live date.
The middleware transformation path is viable where ECC produces structured output (iDoc or XML) that carries all the mandatory PINT-AE field data. Where ECC output lacks BTAE field data — because the UAE extension fields do not exist anywhere in the ECC data model — the transformation cannot fabricate that data from the billing document alone. The missing data must be sourced from master data objects or custom enhancements, and the integration architecture must be designed to pass that data through to the PINT-AE XML.
SAP Field Location Reference
For SAP implementations, the PINT-AE mandatory fields map to SAP data objects across multiple modules. Customer master data (TIN, Peppol Participant Identifier, legal registration details, emirate subdivision code) sits primarily in the Customer Master or Business Partner object. Transaction data (delivery date, payment terms, charge and discount line items) comes from the Sales Order and Billing Document. Item data (item type code, item classification codes for goods, service accounting codes for services) resides in the Material Master and Service Master objects. Configuration values (tax category codes, billing frequency codes, credit note reason codes) are maintained in condition types and output determination configuration.
Oracle-Specific Requirements
Oracle Fusion (Cloud) — Transaction Business Intelligence and DFFs
Oracle Fusion Cloud users have access to a configurable e-invoicing architecture through Transaction Business Intelligence (OTBI) for reporting and Descriptive Flexfields (DFFs) for extending standard transaction attributes with UAE-specific data. The BTAE extension fields that have no standard Oracle Fusion equivalent must be captured through DFFs on the relevant transaction objects — the invoice header and invoice lines in Receivables.
Oracle Fusion's Receivables module supports configurable output through Business Intelligence Publisher (BIP) or Oracle's Financials Cloud E-Invoicing features. The UAE-specific content available through standard Oracle channels must be assessed against PINT-AE V1.0.0 for completeness, particularly for BTAE fields that have no standard Oracle attribute. Customer master data in Oracle Fusion is held in the Trading Community Architecture (TCA) — the party, account, and site hierarchy through which customer TINs, Peppol identifiers, and address data must be maintained.
Oracle E-Business Suite
Oracle EBS (11i or R12) presents similar challenges to SAP ECC: a mature, maintenance-mode product without native PINT-AE support. The EBS AR module's invoice output can be configured through BIP templates, but generating a PINT-AE compliant UBL 2.1 XML structure from EBS requires custom BIP template development or middleware transformation. UAE extension field data not captured in standard EBS attributes must be held in DFFs and passed through the output generation process.
The Data That ERP Systems Do Not Currently Hold
Across both SAP and Oracle implementations, the PINT-AE fields that require the most significant pre-go-live remediation work are in the customer master data domain. Peppol Participant Identifiers for every UAE B2B customer are a new data category — no ERP system holds this data today because it did not exist as a requirement before the UAE e-invoicing mandate. Trade License numbers and issuing authority names, emirate subdivision codes per customer billing address, and Legal Registration Types (TL, EID, PAS, CD) are similarly absent from most customer master records at the level of completeness PINT-AE requires.
The enrichment programme for customer master data is therefore both a data governance task and a customer outreach task. Peppol Participant Identifiers are provisioned through each customer's ASP — the business cannot determine these from the Peppol directory without the customer's cooperation or directory lookup tools. For Phase 1 businesses with thousands of B2B customers, the enrichment programme needs to begin well before the ASP appointment deadline.
Practitioner Insight: The most consistent finding in UAE e-invoicing readiness assessments of SAP and Oracle implementations is that the standard invoice print report is a misleading baseline. The print report shows what the ERP presents to the user — not what it stores at field level, and not what it can output in structured XML. Fields that appear on the invoice print may be generated by concatenation logic or lookup functions that do not translate directly to PINT-AE field mappings. The assessment must go to the table and field level, not the print template level.
Cloud and Mid-Market Systems
For businesses using cloud accounting systems — Xero, Zoho Books, QuickBooks, Sage, or similar — the native PINT-AE generation capability depends entirely on whether the vendor has developed a UAE e-invoicing connector. Where a native connector exists, the path is configuration. Where it does not, the ASP transformation path applies — but only where the system produces structured output that contains all mandatory field data.
Mid-market ERP systems present a spectrum of readiness. The key question is whether the system is under active development — in which case UAE e-invoicing content can be built — or in maintenance mode, in which case the remediation options are limited to ASP-side transformation or system replacement. The development status of the source system, not its market positioning, is the defining characteristic for e-invoicing readiness.
Building the ERP Integration Architecture
For Phase 1 businesses with SAP or Oracle ERP systems, the e-invoicing integration programme should begin with a field-level gap assessment: for every mandatory PINT-AE field, determine whether the data exists in the ERP at the required level of completeness and conformance, whether it can be extracted in a structure that supports PINT-AE XML generation, and whether the XML output would pass the 302 schematron validation rules. This assessment — done properly at field level per transaction type per source system — is the technical foundation for the entire implementation programme. Without it, the integration build proceeds on assumptions that almost invariably produce validation failures at the testing stage.