How to Integrate SAP with UAE FTA E-Invoicing

SAP Customers Are the Heart of Phase 1

Phase 1 of the UAE e-invoicing mandate, which becomes mandatory on 1 January 2027, applies to businesses with annual revenue of AED 50 million or more. A large share of those businesses run SAP - usually SAP ECC or, increasingly, S/4HANA. The mandate is one of the biggest integration projects most UAE SAP teams will face this year.

This post explains the integration pattern that works for SAP, regardless of whether you are on ECC, S/4HANA (on-premise), or S/4HANA (Cloud, public or private edition).

What SAP Already Has

Every SAP environment carries the data you need:

• Sales orders and billing documents in SD (VBRK, VBRP and related tables)
• Customer master in KNA1, KNB1, KNVV - including TRN held in a tax number field
• Tax configuration in FTXP, mapped to UAE 5 percent standard, zero-rated, and exempt categories
• Multi-currency revaluation with the company code currency typically set to AED
• Credit and debit memos as distinct document types

What SAP does not give you out of the box is PINT AE XML, a Peppol Access Point, or a connection to the FTA. Those gaps are what the Accredited Service Provider (ASP) covers.

The Integration Pattern

The cleanest pattern - and the one we recommend - is to keep SAP as the system of record and let the ASP handle the format conversion and exchange. SAP does what it does well; the ASP does the rest.

Three Options to Move Data Out of SAP

1. OData / RAP services on S/4HANA. Native, real-time, and ideal for S/4HANA customers. Expose a billing document service and let the ASP poll or subscribe.
2. IDoc out (INVOIC02 or INVOIC03) on ECC. The traditional approach. Configure partner profiles, set up an output type that triggers an IDoc on billing, and route to the ASP via SAP PI/PO, CPI, or a direct AS2/SFTP relay.
3. BAPI / RFC pull. Useful where neither OData nor IDoc is workable. The ASP calls BAPI_BILLINGDOC_GETLIST and BAPI_BILLINGDOC_GETDETAIL on a polled basis.

For S/4HANA Cloud, OData with API key plus communication arrangements is the standard. For on-premise ECC, IDocs remain reliable and widely understood by SAP teams.

What the ASP Does

Once invoice data leaves SAP, the ASP performs the steps that turn it into a compliant UAE tax invoice:

1. Maps SAP fields to PINT AE elements - supplier party, customer party, line items, tax category codes, totals.
2. Validates against PINT AE cardinality and FTA business rules.
3. Applies a XAdES digital signature with a trusted timestamp.
4. Routes the document through the Peppol network to the customer's ASP.
5. Reports invoice metadata to the FTA in near real-time.
6. Returns acknowledgement and status back to SAP via the same interface.

Common SAP-Specific Decisions

Where Do You Hold the Customer TRN?

The cleanest place is the Tax Number field on the customer master (KNA1-STCD1 or the appropriate slot in the new tax classification tables). Many UAE SAP implementations historically stored TRN in a description field, which makes mass mapping painful. Clean this up before go-live.

Where Do You Hold the Peppol Participant ID?

A new field on the customer master or a Z-table is typical. The participant ID is what the ASP uses to route the invoice to the correct customer ASP.

How Do You Handle Free Zones?

PINT AE recognises designated free zones with specific tax treatment. Most SAP setups use a customer classification or region key to mark free zone customers. Make sure your tax determination produces the right VAT category code in the PINT AE output.

What About Foreign Currency Invoices?

SAP can invoice in USD or EUR and post in AED at the document exchange rate. PINT AE requires AED-equivalent reporting fields. The ASP fills these from the SAP document, but your exchange rate types and rounding rules must produce values that reconcile.

Inbound (AP) for SAP

Inbound is the mirror of outbound. The supplier's ASP delivers a signed PINT AE invoice over Peppol; your ASP verifies it, then creates an MIRO-friendly invoice record in SAP. The structure depends on your AP setup:

• Direct MIRO upload via BAPI_INCOMINGINVOICE_CREATE for high-volume scenarios
• Workflow inbox for review-and-post for lower volumes
• Vendor master matching by TRN with fallback to Peppol participant ID

A Realistic Implementation Timeline

1. Weeks 1-2 - Discovery. Confirm SAP version, integration channel (OData/IDoc/BAPI), tax setup, customer master state.
2. Weeks 3-4 - Configuration. Partner profiles, output types, communication arrangements, ASP credentials.
3. Weeks 5-7 - Mapping and master data. Clean TRNs, set Peppol IDs, validate free zone categorisation.
4. Weeks 8-10 - Sandbox testing. End-to-end invoice flows including credit notes, multi-currency, free zone customers.
5. Weeks 11-12 - Go live and hypercare.

Twelve weeks is comfortable for a single company code and one country. Multi-company-code or multi-country SAP environments need additional time.

Risks Worth Planning For

• Customer master quality - TRN coverage is often below 90 percent in older SAP environments
• Output determination conflicts when a parallel print/email flow already exists
• Tax category mismatches between SAP's tax codes and PINT AE's expected category codes
• Free zone treatment that has been managed via Z-tables outside standard tax determination
• Currency rounding when AED equivalents are recalculated for FTA reporting

How InvoiceNet Integrates with SAP

InvoiceNet supports SAP ECC and S/4HANA (on-premise and Cloud) through all three patterns - OData, IDoc, and BAPI. We provide the mapping layer to PINT AE, the Peppol Access Point, and the FTA reporting integration as a single managed pipeline. Talk to us about a fixed-scope readiness assessment for your SAP landscape.