UAE E-INCOICING · SAP & ORACLE
E-Invoicing Integration with SAP and Oracle in the UAE
SAP and Oracle systems hold nearly all the data UAE e-invoicing requires — but not in the structure the regulation expects, and not including several fields that do not exist in a standard configuration. This guide covers the reference architecture, the integration patterns available for each platform, the specific field work required, and a realistic implementation sequence.
reading time: 14 min
SOURCES: MOF, FTA OFFICIAL PUBLICATIONS
august 2026
aiverix research
SAP and Oracle are the systems of record for a large share of UAE mid-market and enterprise invoicing. They are also the systems where e-invoicing integration is most often underestimated — not because the connection itself is difficult, but because years of accumulated configuration, custom fields, and locally adapted processes mean that no two installations behave quite the same way. A vendor claim of "SAP compatibility" says very little about whether an integration will work against your specific installation.
“
OFFICIAL SOURCES:
UAE Electronic Invoicing Guidelines V1.0 — Ministry of Finance, 23 February 2026
UAE Electronic Invoice Mandatory Fields V1.0 — Ministry of Finance, 23 February 2026
UAE Peppol 5-Corner E-Invoice Business and IT Impact Scope V1.0
Ministerial Decision No. 243 of 2025 · Ministerial Decision No. 244 of 2025
mof.gov.ae/eInvoicing
UAE Electronic Invoicing Guidelines V1.0 — Ministry of Finance, 23 February 2026
UAE Electronic Invoice Mandatory Fields V1.0 — Ministry of Finance, 23 February 2026
UAE Peppol 5-Corner E-Invoice Business and IT Impact Scope V1.0
Ministerial Decision No. 243 of 2025 · Ministerial Decision No. 244 of 2025
mof.gov.ae/eInvoicing
51
Mandatory fields the integration must supply
5
Fields typically missing from a standard SAP or Oracle setup
1-2
Weeks for the technical connection on a modern instance
8
Special transaction scenarios requiring specific mapping
Why SAP and Oracle Need Specific Attention
Three characteristics make these platforms different from smaller accounting systems in an e-invoicing project.
Configuration depth. A ten-year-old SAP installation carries custom fields, custom document types, locally developed enhancements, and process variations introduced by different teams over time. The integration must work against that configuration, not against a reference implementation.
Volume and concentration. These systems typically sit in organisations issuing hundreds to tens of thousands of invoices monthly, often concentrated around period end. Integration design that works comfortably at 200 invoices a month behaves differently when 4,000 are posted in three days.
Change governance. Modifications to a production SAP or Oracle environment go through formal change control, transport processes, and testing cycles. This does not make the work harder, but it does make the timeline longer and less flexible than in a smaller system where a configuration change is immediate.
Configuration depth. A ten-year-old SAP installation carries custom fields, custom document types, locally developed enhancements, and process variations introduced by different teams over time. The integration must work against that configuration, not against a reference implementation.
Volume and concentration. These systems typically sit in organisations issuing hundreds to tens of thousands of invoices monthly, often concentrated around period end. Integration design that works comfortably at 200 invoices a month behaves differently when 4,000 are posted in three days.
Change governance. Modifications to a production SAP or Oracle environment go through formal change control, transport processes, and testing cycles. This does not make the work harder, but it does make the timeline longer and less flexible than in a smaller system where a configuration change is immediate.
THE CLAIM TO TEST CAREFULLY
"Compatible with SAP" and "we have completed live UAE implementations on SAP S/4HANA version X" are very different statements. Ask any provider for the specific systems and versions where they have live implementations, and how many. On a platform this configurable, prior implementation experience is the single strongest predictor of a smooth project.
"Compatible with SAP" and "we have completed live UAE implementations on SAP S/4HANA version X" are very different statements. Ask any provider for the specific systems and versions where they have live implementations, and how many. On a platform this configurable, prior implementation experience is the single strongest predictor of a smooth project.
Reference Architecture
The architecture below applies to both SAP and Oracle. The source layer differs; everything from the integration layer onward is identical.
-
SOURCE LAYER / CORNER 1
SAP / OracleBilling document or AR invoice posted. Includes header, line items, tax data, partner data. -
SOURCE LAYER / CORNER 1
Secondary systemsDepartmental billing tools, acquired entity ERPs, custom platforms feeding the same layer.
-
INTEGRATION LAYER
Connector / API / SFTPExtraction of invoice data on posting or on schedule. Format-agnostic: JSON, XML, CSV or flat file.
-
COMPLIANCE LAYER / CORNER 2
Accredited Service ProviderField validation against all 51 mandatory fields · transformation to PINT AE · digital signature · participant lookup · routing · retry handling · archive
-
DELIVERY / CORNER 3 → 4
Peppol Network → BuyerSigned document routed to the buyer’s access point and delivered into their AP system as structured data. -
REPORTING / CORNER 5
Federal Tax AuthorityTax Data Document transmitted in real time, simultaneously with delivery — not batched.
-
FEEDBACK LOOP
Status back into SAP / OracleValidation result, transmission status, buyer acknowledgement and FTA confirmation written back against the source document.
THE FEEDBACK LOOP IS NOT OPTIONAL
Many integration designs focus entirely on getting data out of the ERP and neglect writing status back into it. At volume this is a serious weakness: if the invoice status lives only in the provider’s dashboard, your AR team is reconciling two systems manually. Status should be visible against the billing document in SAP or Oracle itself, so a rejected invoice is apparent to the person who owns the receivable.
Many integration designs focus entirely on getting data out of the ERP and neglect writing status back into it. At volume this is a serious weakness: if the invoice status lives only in the provider’s dashboard, your AR team is reconciling two systems manually. Status should be visible against the billing document in SAP or Oracle itself, so a rejected invoice is apparent to the person who owns the receivable.
Integration Patterns by Platform
SAP — S/4HANA, ECC and Business One
What SAP already gives you
The billing document contains the substantial majority of what is required: document number and date, sold-to and bill-to partner data, item-level descriptions, quantities, unit prices, discounts, tax codes and tax amounts, currency, payment terms, and document totals. None of this needs to be created — it needs to be extracted and mapped.
What SAP does not give you without configuration
WHERE SAP PROJECTS MOST OFTEN LOSE TIME
Tax code mapping. Long-running SAP installations accumulate tax codes — some created for a specific customer, some for a discontinued product line, some nobody can fully explain. Every code that can still appear on a live invoice must be mapped to a valid tax category. Extract the full list of tax codes used in the last twelve months at the start of the project rather than discovering an unmapped code during testing.
Tax code mapping. Long-running SAP installations accumulate tax codes — some created for a specific customer, some for a discontinued product line, some nobody can fully explain. Every code that can still appear on a live invoice must be mapped to a valid tax category. Extract the full list of tax codes used in the last twelve months at the start of the project rather than discovering an unmapped code during testing.
Oracle — ERP Cloud, EBS and NetSuite
Oracle ERP Cloud
Native REST services make an event-driven pattern straightforward: the integration triggers on AR transaction completion, extracts the transaction with its lines and tax details, and posts it to the provider. Descriptive flexfields are the standard mechanism for adding the network address and transaction type code. Where volumes are very high and real-time transmission is not required per document, a BI Publisher extract on a schedule is a viable alternative.
Oracle EBS
In heavily customised EBS environments, an extract-based pattern is usually preferable to modifying transaction processing. A concurrent program produces a structured extract of completed AR transactions on a schedule, which is collected by the provider over SFTP. This keeps the change footprint in EBS small — an important consideration where the environment is stable and change control is strict.
Oracle NetSuite
SuiteScript provides a clean trigger on invoice record save, with custom fields at customer and transaction level holding the network address and transaction type code. NetSuite’s multi-subsidiary structure maps well to multi-entity UAE compliance, provided each subsidiary is registered separately and its own network address is used rather than a shared one.
MULTI-ENTITY NOTE FOR BOTH PLATFORMS
Where a group runs several UAE legal entities in one SAP or Oracle instance, each entity requires its own registration and its own network address. The integration must select the correct sending identity based on the company code or subsidiary on the document. Getting this wrong produces invoices that are technically valid but attributed to the wrong entity — a problem that is significantly harder to correct after the fact than to configure correctly at the start.
Where a group runs several UAE legal entities in one SAP or Oracle instance, each entity requires its own registration and its own network address. The integration must select the correct sending identity based on the company code or subsidiary on the document. Getting this wrong produces invoices that are technically valid but attributed to the wrong entity — a problem that is significantly harder to correct after the fact than to configure correctly at the start.
Field Mapping and the Gaps to Close
A field gap analysis performed before any development begins is the most useful single artefact in an SAP or Oracle e-invoicing project. It answers one question per required field: where does this value come from, and what happens if it is absent?
Example Data Flow and Payload Structure
The example below is illustrative rather than a specification for any particular provider. It shows the shape of a typical API-based exchange so that ERP teams can plan the extraction work. Exact endpoint paths, authentication schemes and payload field names differ by provider and are covered in their integration documentation.
1 — Submit an Invoice From the ERP
POST /v1/invoices
Authorization: Bearer <token>
Content-Type: application/json
{
"sourceSystem": "SAP_S4",
"sourceDocumentId": "0090001234", // billing document number
"entityCode": "AE01", // company code → sending entity
"documentType": "INVOICE", // or CREDIT_NOTE
"issueDate": "2026-07-27",
"currency": "USD",
"transactionTypeCode": "10000001", // derived: free zone + export flags
"buyer": {
"name": "Example Trading LLC",
"taxRegistrationNumber": "1234567890",
"participantId": "0235:1234567890", // from customer master custom field
"address": { "country": "AE", "emirate": "Dubai" }
},
"lines": [
{
"lineNumber": 1,
"description": "Consulting services — July 2026",
"quantity": 1,
"unitPrice": 10000.00,
"taxCategory": "S",
"taxRate": 5.0
}
],
"totals": {
"netAmount": 10000.00,
"taxAmount": 500.00,
"grossAmount": 10500.00,
"taxAmountAED": 1836.25, // required for non-AED invoices
"grossAmountAED": 38561.25
}
}
Authorization: Bearer <token>
Content-Type: application/json
{
"sourceSystem": "SAP_S4",
"sourceDocumentId": "0090001234", // billing document number
"entityCode": "AE01", // company code → sending entity
"documentType": "INVOICE", // or CREDIT_NOTE
"issueDate": "2026-07-27",
"currency": "USD",
"transactionTypeCode": "10000001", // derived: free zone + export flags
"buyer": {
"name": "Example Trading LLC",
"taxRegistrationNumber": "1234567890",
"participantId": "0235:1234567890", // from customer master custom field
"address": { "country": "AE", "emirate": "Dubai" }
},
"lines": [
{
"lineNumber": 1,
"description": "Consulting services — July 2026",
"quantity": 1,
"unitPrice": 10000.00,
"taxCategory": "S",
"taxRate": 5.0
}
],
"totals": {
"netAmount": 10000.00,
"taxAmount": 500.00,
"grossAmount": 10500.00,
"taxAmountAED": 1836.25, // required for non-AED invoices
"grossAmountAED": 38561.25
}
}
2— Immediate Response: Accepted for Processing
{
"invoiceId": "inv_01J8XQZ4",
"sourceDocumentId": "0090001234",
"status": "ACCEPTED",
"validation": { "passed": true, "warnings": [] }
}
"invoiceId": "inv_01J8XQZ4",
"sourceDocumentId": "0090001234",
"status": "ACCEPTED",
"validation": { "passed": true, "warnings": [] }
}
3 — Validation Failure Response
{
"sourceDocumentId": "0090001235",
"status": "REJECTED",
"errors": [
{
"field": "buyer.participantId",
"code": "MISSING_REQUIRED",
"message": "Buyer network address not provided and no fallback applicable"
},
{
"field": "lines[2].taxCategory",
"code": "UNMAPPED_VALUE",
"message": "Tax code Z7 has no mapped tax category"
}
]
}
"sourceDocumentId": "0090001235",
"status": "REJECTED",
"errors": [
{
"field": "buyer.participantId",
"code": "MISSING_REQUIRED",
"message": "Buyer network address not provided and no fallback applicable"
},
{
"field": "lines[2].taxCategory",
"code": "UNMAPPED_VALUE",
"message": "Tax code Z7 has no mapped tax category"
}
]
}
4 — Status Callback Written Back to the ERP
POST https://your-erp-endpoint/einvoice-status
Content-Type: application/json
{
"event": "invoice.delivered",
"invoiceId": "inv_01J8XQZ4",
"sourceDocumentId": "0090001234",
"peppolStatus": "DELIVERED",
"ftaReportingStatus": "REPORTED",
"timestamp": "2026-07-27T09:14:22Z"
}
Content-Type: application/json
{
"event": "invoice.delivered",
"invoiceId": "inv_01J8XQZ4",
"sourceDocumentId": "0090001234",
"peppolStatus": "DELIVERED",
"ftaReportingStatus": "REPORTED",
"timestamp": "2026-07-27T09:14:22Z"
}
The important design point is item four. The callback carries sourceDocumentId, which allows the ERP to update the correct billing document. Without that field in the round trip, correlating provider records back to ERP documents becomes a manual reconciliation exercise.
Error Handling and Reconciliation
At low volumes, error handling can be informal. At SAP and Oracle volumes it needs to be designed deliberately, because the cost of an unnoticed rejection is a receivable that never starts ageing correctly.
-
Fail before transmission, not after
Validation should occur at the provider before the document enters the network, so errors return to the ERP within seconds rather than arriving as a buyer rejection days later. -
Group errors by cause, not by document
Four hundred rejections caused by one unmapped tax code is a single fix, not four hundred investigations. Error reporting should aggregate by root cause. -
Route errors to the team that can fix them
A missing network address belongs with the account owner. An unmapped tax code belongs with the finance systems team. A malformed extract belongs with IT. Route accordingly rather than into a single shared queue. -
Define retry behaviour explicitly
A buyer’s access point being temporarily unavailable is a transient condition that should be retried automatically. A validation failure is not — retrying it produces the same result. These need different handling. -
Reconcile daily against the ERP
Every billing document posted should have a corresponding transmission record with a terminal status. A daily reconciliation catches documents that never reached the provider at all — a failure mode that neither system reports on its own.
Implementation Sequence
DATA PREPARATION IS THE CRITICAL PATH
Every activity in this table except data preparation is measured in days. Data preparation is measured in weeks, and it depends on your customers responding to a request. It is also the only phase that can start on day one without waiting for anything else. Projects that finish on time are almost always the ones that began the customer data work before the technical scoping was complete.
Every activity in this table except data preparation is measured in days. Data preparation is measured in weeks, and it depends on your customers responding to a request. It is also the only phase that can start on day one without waiting for anything else. Projects that finish on time are almost always the ones that began the customer data work before the technical scoping was complete.
Implementation Preview
REPRESENTATIVE IMPLEMENTATION PROFILE
Multi-entity distribution group on SAP S/4HANA
Multi-entity distribution group on SAP S/4HANA
-
Profile
Three UAE legal entities — two mainland, one free zone — on a single S/4HANA instance -
Volume
Approximately 3,200 invoices monthly, around 60% issued in the final four business days -
Complexity
AED, USD and EUR invoicing; export transactions; free zone sales requiring beneficiary details -
Pattern
REST API triggered on billing document release, with status write-back to the billing document
What the gap analysis found: 46 of the 51 required fields were available directly from the billing document. Five needed work — buyer network address, transaction type code derivation, beneficiary details for free zone customers, AED conversion values on foreign currency invoices, and two legacy tax codes with no mapping.
Where the time went: ERP configuration and the API connection together took under three weeks including transport through the landscape. Verifying tax numbers across roughly 900 active customers and collecting network addresses took five weeks and ran in parallel throughout.
What the peak-load test changed: Testing against the real month-end concentration rather than an even distribution surfaced the need to batch submissions during the final days of the month. This was a configuration adjustment made before go-live rather than an incident discovered afterwards.
This profile is a composite illustration of typical implementation characteristics for a group of this size and complexity, provided to help teams plan. It does not describe a specific named client.
Where the time went: ERP configuration and the API connection together took under three weeks including transport through the landscape. Verifying tax numbers across roughly 900 active customers and collecting network addresses took five weeks and ran in parallel throughout.
What the peak-load test changed: Testing against the real month-end concentration rather than an even distribution surfaced the need to batch submissions during the final days of the month. This was a configuration adjustment made before go-live rather than an incident discovered afterwards.
This profile is a composite illustration of typical implementation characteristics for a group of this size and complexity, provided to help teams plan. It does not describe a specific named client.
How Aiverix Integrates with SAP and Oracle
AIVERIX – FTA ACCREDITED ASP / CERTIFIED PEPPOL ACCESS POINT / ISO 27001
Configuration, Not Custom Development
Aiverix runs on a low-code integration platform, which means format conversion, validation rules, field mapping and transformation are configured rather than programmed. This is the main reason standard implementations complete in two to four weeks.
Configuration, Not Custom Development
Aiverix runs on a low-code integration platform, which means format conversion, validation rules, field mapping and transformation are configured rather than programmed. This is the main reason standard implementations complete in two to four weeks.
-
SAP coverage
S/4HANA, ECC and Business One via REST API, IDoc to middleware, or scheduled extract. -
Oracle coverage
ERP Cloud, E-Business Suite and NetSuite via REST, SuiteScript, or concurrent program extract. -
Format agnostic input
JSON, XML, CSV, XLSX or flat file. The extract format that suits your system is the one we work with. -
Multiple input channels
REST API, SFTP, file upload and manual entry, usable in combination across different source systems. -
Field gap analysis up front
Full mapping against all 51 requirements including a tax code review, delivered before any build work begins. -
Status write-back
Validation, transmission, delivery and FTA reporting status returned against your source document identifier. -
Multi-entity handling
Company code or subsidiary drives the sending identity, with per-entity registration and consolidated group visibility. -
Peppol framework track record
Underlying platform used by 2,500+ enterprises worldwide, including 500+ implementations under Saudi Arabia’s ZATCA programme on the same framework.
Request an SAP or Oracle integration assessment, including a field gap analysis for your instance, at aiverix.ae · info@aiverix.ae · +971 58 560 3037
Frequently Asked Questions
Any FTA-accredited provider that supports REST API, IDoc or extract-based integration can technically connect to SAP or Oracle. The meaningful distinction is implementation evidence rather than stated capability. Ask each provider which specific SAP or Oracle products and versions they have live UAE or ZATCA implementations on, how many, and which integration pattern was used in each case. On platforms as configurable as these, prior experience with your exact system is a far better predictor of a smooth project than a general compatibility claim. Aiverix supports SAP S/4HANA, ECC and Business One, along with Oracle ERP Cloud, E-Business Suite and NetSuite, through API, middleware and extract-based patterns.
Some configuration is required, but not modification of core processes. In practice the work is: adding custom fields to hold the buyer’s network address and the transaction type code, building derivation logic so the transaction type code is generated automatically rather than entered manually, mapping every tax code in use to a valid tax category, correcting the exchange rate source used for AED conversion on foreign currency invoices, and adding status fields so transmission outcomes are visible against the billing document. This is standard configuration work that goes through your normal change control process — typically one to two weeks of effort including transport through the landscape.
In a real-time pattern the ERP calls the provider’s API when a billing document is released, and receives a validation result within seconds. In a batch pattern the ERP produces an extract on a schedule which the provider collects and processes. Real-time gives faster error feedback and better status visibility, which matters when a rejection delays a receivable. Batch is simpler to implement on legacy systems and adds less load to the source environment. Many organisations run both — real-time from the main ERP, batch from an acquired entity or legacy platform — feeding the same provider account.
Each UAE legal entity requires its own registration with the FTA and its own network address. The integration must therefore select the correct sending identity based on the company code in SAP or the subsidiary in Oracle. This is configuration rather than a technical obstacle, but it must be established at the start: invoices issued under the wrong entity identity are valid documents attributed to the wrong legal person, which is considerably harder to correct afterwards than to configure correctly at the outset. Group-level reporting should then consolidate across entities while keeping per-entity records separate.
This is the load case that matters, and testing against monthly averages will miss it. If a large share of invoices are released in a few days, the integration must handle that concentration without queuing, because a queued invoice is a delayed payment. During implementation, test using your real volume distribution rather than an even spread. Ask your provider about throughput limits, whether batching is applied during peaks, and what the observed behaviour is at your peak-day volume. Adjustments made during testing are configuration changes; the same issue discovered after go-live is an incident during your busiest week.
Yes, and for organisations with established integration governance this is often preferable. The provider connects to your enterprise service bus or integration platform, which handles the exchange with your ERP as it does for other integrations. This keeps e-invoicing within your existing standards for monitoring, security and change control. The trade-off is one additional hop in the chain, which should be reflected in the error handling design — in particular, ensure that validation errors returned by the provider are surfaced through the middleware rather than absorbed by it.
The technical elements — gap analysis, ERP configuration, connection build, testing and cutover — total roughly three to five weeks for a single instance, including time for change control and transport. The overall project timeline is usually determined by data preparation instead: auditing the customer master, verifying tax registration numbers, and collecting network addresses from customers commonly takes four to six weeks and depends on customer responsiveness. Because that work can begin immediately and runs in parallel with everything else, starting it first is the most effective way to compress the total timeline.
Use your own data rather than a sample set. A worthwhile proof of concept covers at least one standard domestic invoice, one foreign currency invoice with AED conversion, one free zone transaction requiring beneficiary details, one export, one credit note referencing an original invoice, and one invoice to a buyer with no network address so that fallback routing can be verified. Also test the status write-back path specifically, since it is the element most often left incomplete. If all of these pass using real documents from your system, the integration design is sound.