AP eInvoicing in the UAE: how to receive, match and process invoices

Guide11 min read | Posted on September 25, 2026 | By Ashish Abraham
An inbox tray labelled Invoices holding a received invoice with a verification tick and a settings gear

An invoice for 100 units lands in your accounts payable (AP) queue at 09:14. It came through your Accredited Service Provider (ASP), the company that sends and receives eInvoices for you under the UAE rules. The file passed every technical check, and the readable view opens without a problem.

But the purchase order was for 100 units at AED 500 each, and the goods receipt note shows only 98 units delivered. Nothing is wrong with the technical delivery. The invoice still cannot be paid as it stands.

That gap, between a valid invoice file and an approved payable, is where AP work sits under UAE eInvoicing. The new rules change how invoices arrive and how they must be stored. They do not remove AP's judgement. This guide walks through receipt, validation, matching, approval, posting and exceptions on the buyer's side of the UAE 5-corner model.

What changes for a buyer under UAE eInvoicing?

A UAE buyer receives Tax Invoices, Tax Credit Notes and out-of-scope Commercial Invoices through its own ASP. Under step 6 of section 5.1 of the UAE Electronic Invoicing Guidelines, version 1.1 (Guidelines v1.1), the buyer's ASP passes the invoice to the buyer "in a format that has been agreed between the two parties". Usually that is the XML file plus a readable PDF or online view.

The structured file is the invoice. The readable view is a copy for people to read.

Three decisions that used to happen at once are now separate:

• Technical delivery: your ASP received a valid file.

• Business acceptance: the invoice matches the real purchase.

• Payment approval: the invoice has passed your internal sign-off.

The network settles only the first. The other two stay with AP, on the same commercial and control basis as before.

The deadlines depend on revenue. Businesses with revenue of AED 50 million or more must appoint an ASP by 30 October 2026, following the Ministry of Finance's May 2026 amendment, and go live on 1 January 2027. Businesses below AED 50 million must appoint an ASP by 31 March 2027 and go live on 1 July 2027, under Ministerial Decision No. 244 of 2025.

What does a UAE buyer receive through its ASP?

What arrives with each eInvoice?

The supplier's ASP (Corner 2, or C2) sends the invoice file to the buyer's ASP (Corner 3, or C3). The buyer's ASP validates it and passes it to the buyer. The buyer receives three things:

• The XML file. This is the legal invoice, built to the PINT AE specification. It carries a document type code: 380 for a Tax Invoice, 381 for a Tax Credit Note, 480 for a Commercial Invoice outside the scope of tax, 81 for its credit note, 389 for a self-billed Tax Invoice or 261 for a self-billed Tax Credit Note.

• A readable view. This is usually a PDF or HTML page created from the XML. It is a convenience copy, not the invoice.

• Your own reporting confirmation. Your ASP also reports the invoice's tax data to the Federal Tax Authority (FTA). When the FTA confirms it, your ASP forwards that confirmation to you. The Ministry of Finance (MoF) calls these confirmations Message Level Status (MLS) messages.

Section 5.3 of Guidelines v1.1 states that UAE eInvoices "will not feature a QR code or barcode". If an AP procedure mentions scanning or verifying a QR code, it comes from a different country's system and should be removed.

Does a technically delivered invoice mean AP has accepted it?

No. When your ASP validates an invoice, the file was structurally valid and could be delivered. That says nothing about whether you expected the invoice, whether it matches a purchase order, whether it reflects what you received, whether the VAT treatment is right, or whether you should pay it.

The same applies in reverse. If the buyer's ASP cannot validate an invoice, it sends a negative MLS to the supplier's ASP and to the FTA. That is a technical rejection. It is not the same as a buyer rejecting an invoice for commercial reasons. Keep the two separate in your AP process.

Event

Where it happens

Who decides

What it means for AP

Positive exchange confirmation

Buyer's ASP to supplier's ASP

Buyer's ASP (C3)

The invoice was validated and delivered. It is stored and enters AP.

Supplier's reporting confirmation

FTA to supplier's ASP

FTA (Corner 5)

The supplier's tax data reached the FTA. This goes to the supplier only.

Buyer's reporting confirmation

FTA to buyer's ASP

FTA (Corner 5)

Your own tax data reached the FTA. Your ASP forwards it to you.

Negative exchange confirmation

Buyer's ASP to supplier's ASP and FTA

Buyer's ASP (C3)

The invoice failed validation and never reaches AP. The supplier fixes the data and resends it. No credit note is needed.

Your reporting confirmation has not arrived

Between your ASP and the FTA

Your ASP

The invoice may still be valid in AP. Ask your ASP to resolve the reporting and track it until confirmed.

Commercial dispute

After delivery

Buyer (AP or procurement)

Delivery stands. The supplier corrects the invoice with a credit note (code 381) or an additional invoice.

 

Many ASPs show exchange results using the response codes in OpenPeppol's MLS specification: AP or AB when delivery succeeded, and RE when it failed, with a reason code such as SV (schema error), BV (business rule error) or FD (delivery failure).

How should the AP workflow run under UAE eInvoicing?

Step 1: How should received invoices be routed?

Your accounting system should route each received XML file into an AP queue automatically, using your Participant Identifier. That identifier is scheme 0235 followed by your 10-digit Tax Identification Number (TIN).

If your business holds any tax registration with the FTA, for VAT, Corporate Tax or Excise, your TIN is the first 10 digits of that Tax Registration Number (TRN). A business with no FTA tax registration gets a TIN separately through EmaraTax, the FTA's online portal. So do not assume that every buyer holds a TRN.

Store every received document from the moment it arrives, whether it is later approved, disputed or replaced. At this step the system is the owner, not the AP team.

Step 2: What should AP validate before matching?

Before an invoice reaches the person who matches it, your system should check four things:

  1. The supplier's TIN matches a known supplier record.

  2. The document type code is one of the six invoice categories in section 10.1 of Guidelines v1.1.

  3. Each line carries one of the six tax categories in section 10.5: standard rate, exempt, outside the scope of VAT, reverse charge, zero rated or margin scheme.

  4. For Free Zone transactions, the invoice includes the beneficiary details required by the Free Zone scenario in section 10.4.

Bring new suppliers through your onboarding process before their first eInvoice arrives. Otherwise the supplier record check becomes your exception queue.

Step 3: How should AP check for duplicates and related documents?

Block any invoice with the same supplier TIN and invoice number as one already received. Link each credit note to its original invoice by document reference.

Guidelines v1.1 recognises two ways to correct an exchanged invoice: an electronic credit note to reduce the amount, or an additional eInvoice to increase it. Some corrections use both, for example a credit note that reverses a wrongly priced invoice followed by a new invoice. Keep the whole chain visible on one supplier record, not spread across separate queues.

Step 4: Should AP use two-way or three-way matching?

Two-way matching compares the invoice with the purchase order (PO). Three-way matching also compares it with the goods receipt note (GRN) or a service completion record.

Decide which to use by category. Inventory goods usually need three-way matching. Catalogue services often use two-way matching with a signed service acceptance. Match each line on quantity, unit price, currency, tax category and total. Set tolerances in writing, for example price rounding within 0.5%, instead of leaving them to judgement.

Step 5: What should AP do when an invoice fails a check?

Invoices that fail validation, duplicate checks or matching go on hold, with an owner and a time limit. Write down AP's options in advance:

Exception

AP action

Result

Price higher than the PO

Query the supplier and ask for a credit note if the price is wrong

Invoice held and a commercial dispute raised

Quantity higher than the GRN

Query the supplier and the warehouse, then short-pay or ask for a credit note

Partial approval possible

No PO reference

Return to procurement to raise a PO, if your policy allows

Invoice held

Wrong tax category

Ask the supplier for a credit note and a new invoice with the right category

Invoice held until the new invoice arrives

Wrong buyer TIN on the invoice

Do not post. Ask the supplier for a credit note and a new invoice with the right details

Invoice held

Failed technical validation

None. The supplier's ASP resends after the data is fixed

The invoice never reaches AP

 

Record a commercial dispute in your ledger. A technical rejection is recorded in the ASP's status log. You need both records, for different reasons.

Step 6: What should AP keep when it posts and pays an invoice?

Once the invoice is matched and approved, post it to the ledger. Keep this evidence with the entry: the XML file, the confirmation messages, the PO and GRN references, and the approval trail.

Input tax recovery on a received eInvoice is still a VAT decision. Keep the full evidence set, and do not claim input tax on an invoice that failed business acceptance until your tax team has reviewed it.

How does a three-way match catch a short delivery?

Here is a simple example. A retail buyer raises a PO for 100 units of a standard-rated stock item at AED 500 each. The warehouse records a GRN for 98 units. The supplier issues an electronic Tax Invoice (code 380) for 100 units at AED 500 each, plus VAT at 5%.

Line

PO

GRN

Invoice

Match result

Quantity

100

98

100

Fails the three-way match: 2 units more than received

Unit price

AED 500

Not applicable

AED 500

Matches the PO

Net value

AED 50,000

Not applicable

AED 50,000

AED 1,000 too high

VAT at 5%

AED 2,500

Not applicable

AED 2,500

AED 50 too high

Total

AED 52,500

Not applicable

AED 52,500

AED 1,050 too high

 

AP should hold the invoice and query the supplier. There are two ways to resolve it. AP can approve 98 units and ask the supplier for a credit note for the 2 missing units. Or AP can reject the invoice commercially, and the supplier issues a credit note for the full invoice and a new invoice for 98 units. Either way, the technical delivery does not need to be repeated. The correction is between the two businesses.

Which exceptions should AP teams plan for?

What happens when the buyer has not yet joined eInvoicing?

Sometimes a supplier is live before its buyer and the buyer has no Participant Identifier yet. Section 10.2.2 of Guidelines v1.1 covers this for Tax Invoices. The supplier puts the fixed address 0235:9900000098 on the eInvoice, and the invoice is still issued and reported. The supplier also sends the buyer a regular Tax Invoice by PDF or paper, through the usual channel.

During this period, AP processes the regular Tax Invoice as before. Apply the same business checks. The fixed address changes how the eInvoice is routed. It does not change what the buyer owes.

How are self-billing, credit notes and disputed quantities handled?

Under self-billing, the buyer issues the invoice for the supplier, using document codes 389 and 261. The process runs the other way: your system produces the invoice, and you need a self-billing agreement with the supplier first. The UAE eInvoicing self-billing guide covers the conditions.

For a price or quantity dispute on a supplier's invoice, the fix is a credit note or an additional invoice. The XML file is never edited, because an exchanged eInvoice cannot be changed after it is issued.

What should AP do during a system failure?

Under Article 12 of Ministerial Decision No. 243 of 2025, every issuer and every recipient must notify the FTA of a system failure within two business days, using the procedure the FTA sets. Appendix 3 of Guidelines v1.1 asks businesses to make sure their ASP notifies the FTA of a service disruption in a timely manner. Your own duty stays in place even when your ASP sends the notice.

Late notification costs AED 1,000 per day under Cabinet Decision No. 106 of 2025. The supplier's deadline and the buyer's deadline run separately for the same outage. Agree the notification route with your ASP before go-live, and keep your own record of each notice. When service resumes, make sure your ASP exchanges and reports every delayed invoice.

Which controls, owners and service levels should AP set?

Use these targets as a starting point, then adjust them to your invoice volume, supplier base and risk.

Activity

Control

Owner

Target time

Routing received invoices

Automatic queue based on Participant Identifier

Systems

Same business day

Technical checks

Automatic checks on file structure, tax category and document code

Systems

On receipt

Supplier record check

Automatic, plus AP review for new suppliers

AP

1 business day

Duplicate check

Automatic, on supplier TIN and invoice number

AP

On receipt

Two-way or three-way matching

Automatic with tolerance rules; AP reviews exceptions

AP

2 business days

Commercial approval

Written delegation of authority

Approvers

Per approval limits

Posting to the ledger

Approval trail stored with the entry

AP

1 business day after approval

Payment release

Payment terms; blocked while a hold is open

Treasury

Per payment terms

System failure notice to the FTA

Two-business-day legal deadline for both parties

Finance systems and tax

2 business days

 

Which AP metrics should you baseline before go-live?

Measure these before your go-live date, so you can see any drop in performance after the switch:

Metric

What it shows

Source

First-time match rate (%)

Gaps in PO discipline under the new workflow

AP module

Average AP handling time per invoice

New manual steps added by validation

AP module

Held invoice ageing (days)

Exception queues filling up

AP module

Duplicates blocked per 1,000 invoices

Suppliers resending invoices by mistake

AP module and ASP log

Negative confirmation rate

Supplier data problems caught before they become disputes

ASP log

Supplier query time

Delays in agreeing corrections with suppliers

AP and email records

 

Zoho Software Trading LLC is a Ministry of Finance-accredited eInvoicing service provider for the UAE, with accreditation number 121988, as shown on the MoF register of accredited service providers. Buyer-side AP runs best when the accounting system, the ASP connection and your AP controls work together, so received invoices go straight into the ledger workflow without retyping and exceptions carry their evidence with them.

Explore UAE eInvoicing with Zoho Books

Frequently asked questions

Does a buyer have to pay an invoice just because it was delivered?

No. Delivery means the file arrived and was structurally valid. Business acceptance and payment approval are separate decisions for the buyer. Pay only after the invoice passes your checks and sign-off, in line with the payment terms agreed with the supplier.

Can AP accept a PDF invoice during the transition?

Yes, in one case. If the supplier is live but the buyer has not joined eInvoicing yet, the supplier issues the eInvoice with the fixed address 0235:9900000098 and also sends a regular Tax Invoice by PDF or paper. AP processes that regular Tax Invoice. If neither business is live yet, the normal VAT invoice rules apply.

Do the buyer and supplier need to use the same ASP?

No. Each business appoints its own ASP, and the two ASPs exchange invoices over the Peppol network. Using the same ASP is allowed but not required, and it does not change how the invoice is exchanged or reported.

How long must AP keep received eInvoices?

A taxable business keeps eInvoices, credit notes and associated data for five years after the end of the tax period, or seven years for real estate, under section 5.4 of Guidelines v1.1. Records can be stored in the cloud, as long as the FTA can retrieve them in a complete, readable form on request. See UAE eInvoice retention periods and audit records for the detail.

Related guides

• How UAE eInvoicing works: the 5-corner model, end to end

• How UAE eInvoicing changes accounts payable, accounts receivable and month-end close

• UAE eInvoicing glossary

• UAE eInvoicing credit notes: rules for correcting an Electronic Invoice

• UAE eInvoicing self-billing: rules, workflow and what to confirm first