Oracle Fusion to PINT-AE: A Practical Field-Mapping Approach for UAE E-Invoicing
One of the first technical questions in a UAE e-invoicing project is simple to ask but difficult to answer: where will every required invoice field come from? For Oracle Fusion customers, field mapping should happen before the interface is built.
If it is delayed, the integration team may finish development only to discover that important information is missing, inconsistent or owned by another application
PINT-AE is not just an XML exercise
UAE electronic-invoice requirements define the data carried in a structured invoice, while PINT-AE provides the semantic model for interoperable Peppol exchange. The better approach is to start from business meaning, not XML tags.
- What does the field mean in the UAE context?
- Which business process creates it?
- Where is it stored today and who owns its accuracy?
- Is it available before invoice completion?
- Does it change by legal entity, transaction type or customer?
Only after these questions are answered should the technical mapping be finalised.
Build a mapping matrix
A useful mapping workbook contains at least these columns:
| Column | Purpose |
|---|---|
| PINT-AE business term and UAE requirement | Defines the target business meaning and scenario obligation. |
| Oracle source and object/field | Identifies where the data is stored in Oracle Fusion. |
| Transformation and default | Documents derivations, permitted defaults and mapping rules. |
| Scenario, owner and test case | Records when the field is mandatory, data ownership and test evidence. |
This structure separates data availability from transformation logic. Invoice number, date, currency and line values are usually straightforward; party identifiers and references can be harder when legal entities use different customer-setup standards.
Standard field, extension or enrichment?
- Standard Oracle field: The data already exists in the required transaction or master record and can be extracted directly.
- Oracle extension: The value is known but not stored in a suitable standard field. A descriptive flex field or another supported extension may be appropriate.
- External enrichment: The value belongs to a CRM, project application, e-commerce platform or customer-onboarding solution. The integration layer enriches the invoice before it goes to the ASP.
- Process gap: The organization does not capture the information consistently today. This is a process or master-data-governance issue, not an integration problem.
Customer and supplier data deserve special attention
ERP implementations often contain years of accumulated master data. Review customer legal names, tax identifiers, addresses, endpoint or routing identifiers where applicable, and the relationship between account, site and legal entity. Apply the same discipline to suppliers where inbound e-invoicing is in scope.
Do not assume a tax registration number appearing on a printed PDF is stored in a clean, reusable Oracle field.
Line-level information can be harder than header data
Header fields receive attention, but e-invoicing requirements can depend on accurate line-level values and references:
- Item or service descriptions, quantities and units.
- Taxable amounts, tax category and rate.
- Discounts and charges.
- Purchase-order, contract, project or service-period references.
If upstream systems summarise transactions before sending them to Oracle, confirm enough detail remains available for the e-invoice.
Avoid excessive hard-coding
A mapping based on many legal-entity-specific if/else rules is difficult to maintain. Use configuration tables for entity-level parameters, mappings and defaults where possible. A central mapping service can support common logic while allowing controlled entity-level variation.
Validate mapping with real invoices
Test production-like samples, not just clean examples:
- Normal domestic invoice and credit note.
- Invoice with multiple tax rates or foreign currency.
- Invoice linked to a purchase order or contract.
- Advance-related, retention or project-billing scenario.
- Manual and interface-created invoices.
Trace every required data element back to its source.
Keep the mapping as a controlled project asset
The mapping workbook should remain controlled documentation after go-live, with ownership, versioning and change approval. It will make future ASP changes or integration redesign easier because the organisation retains its own semantic mapping rather than relying on vendor-specific code.
Final thought
The strongest UAE e-invoicing integrations are built on good data mapping, not clever transformation code. For Oracle Fusion customers, this workstream brings Tax, Finance and IT together around the same invoice and should start early in the project.
