How does UAE eInvoicing change accounts payable, accounts receivable and month-end close?

For most finance teams in the UAE, an invoice is still a document. It arrives as a PDF or an email attachment. Someone keys it into the ledger, matches it to a purchase order, gets it approved and pays it. If an auditor asks a question, the answer is a file on a shared drive and a line in the general ledger.

UAE eInvoicing replaces that document with structured data. Businesses with revenue of AED 50 million or more must go live on 1 January 2027, and smaller businesses follow on 1 July 2027. Every in-scope invoice is exchanged between Accredited Service Providers (ASPs) and reported to the Federal Tax Authority (FTA). The Ministry of Finance (MoF) calls this the Decentralized Continuous Transaction Control and Exchange (DCTCE) model.

This means each invoice now lives in three places at once: your accounting system, the exchange between ASPs, and the tax data reported to the FTA. Each place has its own status. A "sent" flag in your billing system no longer proves that the buyer received the invoice. A PDF in the AP inbox says nothing about whether the tax data reached the FTA.

This guide explains what the UAE eInvoicing process changes for accounts payable (AP), accounts receivable (AR), month-end close, controls, ownership and metrics. It is written for finance leaders who need to redesign how the team works, not just switch on a new system.

What changes for finance teams under UAE eInvoicing?

Finance stops handling the invoice as a document and starts managing it as data with a status. The controlling record is no longer a PDF. It is a structured XML file, and its progress is proven by confirmations from the exchange and from the FTA.

Close-day work changes too. Instead of checking entries against paper trails, finance reconciles four records: the subledger, the exchange log, the tax data log and the general ledger. It also clears invoices that are stuck between those records.

Controls move earlier, into master data, customer and supplier onboarding, and invoice issue. They also move outward, into monitoring the ASP and its confirmations. Headcount does not disappear. Time moves from data entry and matching to exception handling, master data ownership and control checks.

How does an invoice move through the UAE eInvoicing model?

The UAE model sends structured invoices directly between the two businesses' ASPs and reports the tax data to the FTA at the same time. There is no pre-clearance step: the FTA does not approve an invoice before the buyer receives it.

What are the five corners of the UAE model?

The UAE Electronic Invoicing Guidelines, version 1.1 (Guidelines v1.1), set out the flow in section 5.1. Each party is called a corner:

• Corner 1 (C1): the supplier sends invoice data from its billing system to its ASP.

• Corner 2 (C2): the supplier's ASP validates the data, converts it to the UAE standard XML format if it is not already in that format, and sends it on. The format is the PINT AE specification, the UAE version of the Peppol International (PINT) model.

• Corner 3 (C3): the buyer's ASP receives the XML, validates it and passes it to the buyer.

• Corner 4 (C4): the buyer receives the invoice in a format agreed between the two parties.

• Corner 5 (C5): the FTA receives a Tax Data Document (TDD) from the supplier's ASP and, separately, from the buyer's ASP.

For a full walkthrough of each step, see how the 5-corner model works, end to end.

Why does the order of the steps affect finance?

In the 11-step sequence in section 5.1 of Guidelines v1.1, the buyer receives the invoice at step 6. The FTA's confirmations come later, at steps 8 and 9. So AP can be looking at a valid invoice while the tax data leg is still open.

Two common assumptions are therefore wrong. AP cannot assume that "we received it, so the FTA received it". AR cannot treat a confirmation from the buyer's ASP as proof that the tax data was reported.

The invoice itself is an XML file built to PINT AE. A document type code in the file tells both sides what it is: 380 for a Tax Invoice, 381 for a Tax Credit Note, 389 for a self-billed Tax Invoice, 261 for a self-billed Tax Credit Note, 480 for a Commercial Invoice outside the scope of tax, and 81 for its credit note. Section 5.3 of Guidelines v1.1 states that UAE eInvoices are issued in XML and will not feature a QR code or barcode.

Which confirmations become part of your audit trail?

Every invoice now produces confirmation messages. The MoF calls them Message Level Status (MLS) messages and describes two kinds on its eInvoicing overview page:

• An exchange MLS, sent by the buyer's ASP to the supplier's ASP once it has validated the invoice.

• A reporting MLS, sent by the FTA to an ASP once that ASP's tax data has been reported successfully.

The supplier's ASP forwards both its exchange MLS and its reporting MLS to the supplier. The buyer's ASP forwards the buyer's own reporting MLS to the buyer. If the buyer's ASP cannot validate an invoice, it sends a negative MLS to the supplier's ASP and to the FTA.

For finance, "the invoice reached the buyer" and "the tax data reached the FTA" are now two different events, proven by two different messages. Both need to be visible, retrievable and reconcilable. An invoice can be delivered but not yet reported, or sit in retry at either ASP. Close-day accounting has to tell these states apart, not just check the ledger balance.

Agree one set of internal status names with your ASP and use them in every report. A simple set works: submitted, delivered, reported, in retry, rejected and corrected.

How does accounts payable change under UAE eInvoicing?

AP receives a validated, structured invoice from its ASP. It matches the invoice against purchase records, approves it and posts it. The difference is that the exchange and reporting status sits alongside the ledger entry. For the step-by-step buyer workflow, see AP eInvoicing in the UAE.

What are the three biggest changes for AP?

Invoices arrive in a new way. In-scope invoices arrive from the buyer's ASP. Under step 6 of section 5.1, the ASP delivers the invoice "in a format that has been agreed between the two parties". In practice, that is usually the XML file plus a readable view. Supplier master data must be right before the first invoice arrives. That includes the supplier's Tax Registration Number (TRN), Tax Identification Number (TIN) and Peppol Participant Identifier, which is scheme 0235 followed by the 10-digit TIN. Data quality work moves into supplier onboarding instead of invoice-by-invoice correction.

Validation now happens in three layers. The ASPs validate the file against PINT AE. The ASPs report tax data to the FTA. AP then runs its own business checks: matching, coding and approval. The layers are independent. An invoice can pass the first two and still fail a three-way match. An invoice that fails ASP validation never reaches AP at all. Keep a separate exception queue for each layer, because each has a different owner and a different fix.

Nobody can quietly edit an invoice after it is exchanged. Guidelines v1.1 describes no way to edit or cancel an exchanged invoice. Corrections are made with an electronic credit note (code 381, or 81 for an out-of-scope supply) or an additional invoice. The old habit of asking a supplier to "resend it with the right amount" no longer works. An invoice rejected before exchange is different: the supplier fixes the data and sends it again, and no credit note is needed.

How does accounts receivable change under UAE eInvoicing?

AR issues a structured invoice through its ASP, tracks its exchange and reporting status, corrects it with a credit note when needed, and collects payment. Confirmations, not documents, become the evidence. For the step-by-step supplier workflow, see AR eInvoicing in the UAE.

Which five stages does AR now manage?

Issue. The billing system sends the invoice to the supplier's ASP as structured data. Fields that used to be free text must now follow PINT AE. Each line carries one of the six tax categories in section 10.5 of Guidelines v1.1: standard rate, exempt, outside the scope of VAT, reverse charge, zero rated or margin scheme.

Transmit. The supplier's ASP validates the invoice and sends it to the buyer's ASP. Most transmission failures happen between "sent to our ASP" and "confirmed by the buyer's ASP".

Monitor. AR watches for two confirmations on its own side: the exchange MLS from the buyer's ASP, and the reporting MLS from the FTA for the supplier's own tax data. The buyer's reporting MLS goes to the buyer, not to the supplier.

Correct. If an exchanged invoice is wrong, AR issues an electronic credit note (code 381) or, under a self-billing arrangement, a self-billed credit note (code 261). If an invoice is rejected before exchange, AR fixes the data and resends it.

Collect. Collections should look at the exchange confirmation, not the "sent" flag in the billing system. UAE eInvoicing rules do not set payment terms or the date when ageing starts. Those remain commercial terms agreed between the parties. The confirmation tells collections that the invoice reached the buyer. It does not set the due date.

Which sales are in scope for AR?

Under sections 6 and 7 of Guidelines v1.1, business-to-business (B2B), business-to-government (B2G), government-to-business (G2B) and government-to-government (G2G) sales are in scope, whether or not the seller is registered for VAT. Business-to-consumer (B2C) sales are out of scope. Three further exclusions apply: airline passenger transport where an electronic ticket is issued, VAT-exempt financial services, and certain government activities carried out in a sovereign capacity. AR routing rules must split the customer book along these lines.

What changes at month-end close?

At month-end, finance must reconcile the general ledger against the subledger, the exchange log and the tax data log. It must also clear invoices that appear in one of those records but not the others. The old question, "is the paper file in order?", becomes a four-way tie-out.

Which event should drive cut-off and accruals?

Three events can fall on either side of a period end. The invoice is issued. The buyer's ASP confirms receipt. The FTA confirms the tax data.

Recognition still follows the substance of the transaction: goods delivered or services performed. The invoice is the evidence. UAE eInvoicing changes how reliable and how fast that evidence is. It does not change the recognition principle under your accounting framework.

Accruals for goods received not invoiced (GRNI) and services performed but not yet billed still exist. They become better informed, because the exchange log shows which invoices exist and which are still expected.

How should stuck and rejected invoices be treated at close?

Two groups of invoices need explicit handling on close day.

Invoices in exception queues. Some invoices failed ASP validation, are waiting for tax data confirmation, or are still in internal approval. Recognition does not wait for the confirmation. If the supply is complete, recognise it and report the invoice's exchange status alongside it.

Invoices rejected before exchange. An invoice rejected by the buyer's ASP was never delivered as a valid eInvoice. There is nothing to reverse, so the fix is not a credit note. Correct the data, resubmit through the normal exchange and track it until the confirmation arrives. Any accrual for the supply stays in place. The exception log records that the eInvoice is still outstanding. Credit notes are only for invoices that were exchanged successfully and later need to change.

Which four records must reconcile at month-end?

Each business reconciles its own side of the exchange. The table shows what each record holds and who can see it.

Under section 5.1 of Guidelines v1.1, the supplier's ASP and the buyer's ASP each report their own TDD to the FTA, and each receives its own confirmation. The supplier does not see the buyer's reporting confirmation, and the buyer does not see the supplier's.

So reconciliation runs in two halves. The supplier reconciles its subledger, exchange log, tax data log and general ledger. The buyer does the same on its side. The exchange itself is the shared record that both sides can see.

On each side, the tie-out has four pairs:

1. Subledger to general ledger, as before.

2. Subledger to exchange log.

3. Subledger to tax data log.

4. Exchange log to tax data log.

Each pair should match on count, value and invoice identifier.

The most common breaks, and what to do about them:

• The subledger has an invoice that the exchange log does not. For a supplier, the submission failed. For a buyer, the invoice has not arrived. Investigate, then resubmit or query. If the supply is complete, keep the accrual in place.

• The exchange log has an invoice that the subledger does not. Either someone issued an invoice outside the billing system, or the entry was reversed in the subledger without a credit note in the exchange. Investigate.

• The exchange log has an invoice that the tax data log does not. Your own reporting leg failed. Ask your ASP to report it again. Do not assume the other party's report covers you.

• All three agree, but the general ledger does not. Check posting rules and cut-off timing for the period.

What should the close-day exception checklist include?

On the AR side, check that:

• Every invoice issued in the period has an exchange confirmation, or is marked "in retry" with a named owner.

• Every invoice issued has a reporting confirmation for the supplier's own tax data.

• Every credit note issued in the period is exchanged and reported.

• Every invoice rejected in the period has a documented root cause and either a corrected resubmission tracked to confirmation, or a documented decision that no invoice is due.

• Deemed-supply invoices use the fixed buyer address 0235:9900000097.

• Export invoices to a buyer with no Peppol ID use 0235:9900000099.

• Tax Invoices to a buyer that has not yet joined eInvoicing use 0235:9900000098, and the buyer also receives a regular Tax Invoice by PDF or paper.

On the AP side, check that:

• Every eInvoice received in the period is in AP and matched, or is in a named exception state.

• Every credit note received is posted against the original invoice.

• No received invoice is missing your own reporting confirmation. Under Article 6(6) of Ministerial Decision No. 243 of 2025, both the issuer and the recipient must report eInvoices and electronic credit notes to the FTA. Each duty is separate.

• Duplicate invoices, with the same supplier and document number, are blocked before posting.

On both sides, check that:

• Exchange log and tax data log counts for the period reconcile to the subledger. Any breaks have an age and an owner.

• Any system-failure notification sent to the FTA is logged with its date and reference.

Which controls move earlier or run continuously?

Under UAE eInvoicing, most controls move earlier in the invoice's life, into master data, onboarding and issue. Others become continuous, because the exchange produces evidence in real time rather than at month-end.

Which preventive controls stop bad invoices entering the exchange?

• Correct Participant Identifiers. Every customer and supplier needs a valid Participant Identifier: scheme 0235 plus a 10-digit TIN. The TIN is the first 10 digits of any TRN the FTA has issued, for VAT, Corporate Tax or Excise. A business with no FTA tax registration gets a TIN through EmaraTax, the FTA's online portal. If a counterparty is onboarded without its identifier, its first invoice will fail.

• VAT group members as separate participants. Each member of a tax group has its own TIN and its own Participant Identifier, not the group representative's. Each member onboards separately and can choose a different ASP. Keep master data at member level, not group level.

• Duplicate checks at issue. Each eInvoice creates its own exchange and reporting events. A duplicate therefore creates a second invoice that the buyer must reject or that you must credit. Block duplicate keys in the billing system, and check against the exchange log if duplicates keep appearing.

• Scope routing. B2C invoices are out of scope, so routing rules should stop them before they reach the ASP. The airline and financial services exclusions in sections 7.2 and 7.3 of Guidelines v1.1 need the same routing logic.

Which detective controls should run every day?

• Completeness. Every invoice and credit note in the billing system has a matching submission in the exchange log.

• Status ageing. Invoices in an in-between state, such as sent but not confirmed, or delivered but not reported, have an age and an owner. Anything stuck past an agreed limit becomes an incident.

• Daily reconciliation. Run the full four-way tie-out at close, but run the subledger-to-exchange check daily or per batch. A break should be found within one business day.

• System failure. Article 12 of Ministerial Decision No. 243 of 2025 requires every issuer and every recipient to 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 any service disruption in a timely manner. ASPs do this by email to e-invoicingsupport@tax.gov.ae. Your own duty remains even when the ASP sends the notice, so agree the incident route with your ASP in advance and keep your own record of every notice. When service resumes, make sure the ASP exchanges and reports every delayed invoice.

• Retention. Under Article 11 of Ministerial Decision No. 243 of 2025 and section 5.4 of Guidelines v1.1, 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. An FTA audit notice adds four years, and a voluntary disclosure adds one year. "Within the State" means the FTA can retrieve the records in a complete, readable form on request. It does not mean the servers must be in the UAE, so cloud storage works. The general VAT record-keeping rules still apply alongside these periods, and they are longer for capital assets and real estate. See UAE eInvoice retention periods and audit records for the detail.

Structured, reported exchange makes some kinds of invoice manipulation harder. It does not replace your own checks on whether a supplier and a supply are genuine.

Who owns each part of the UAE eInvoicing process?

No single team owns the invoice from start to finish in the UAE eInvoicing process. Finance, tax, IT, sales, procurement and the ASP all touch it. The RACI below is a practical starting point.

R = responsible for doing the work. A = accountable for the outcome. C = consulted. I = informed.

Treat the ASP as a delivery partner. It does not take over your legal duties. Article 12 places the system-failure notification duty on the business, and Appendix 4 of Guidelines v1.1 states that handing storage to an ASP does not transfer the storage obligation. Write this into the ASP contract: evidence retrieval, incident notification support, service levels for exchange and reporting confirmations, and audit support.

Which metrics should finance track after go-live?

Traditional AP and AR metrics still apply: days payable outstanding (DPO), days sales outstanding (DSO), invoice cycle time, exception rate and cost per invoice. UAE eInvoicing adds a layer of exchange and reporting metrics.

DSO, DPO, days to invoice and payment cycle time may improve as structured invoices reduce re-keying and lost documents. Record a baseline for each before your go-live date, so you can measure the real change afterwards.

What should a 30-day finance redesign plan include?

This plan assumes the ASP integration is being handled as a separate project.

• Days 1 to 5: set the baseline. Record AP and AR invoice volumes, rejection and dispute rates, current cut-off and accrual practice, and current control owners. Capture the KPI baseline.

• Days 6 to 10: sort by scope. Split the customer book and supplier book by transaction type (B2B, B2G, G2B, G2G, B2C) and by exclusion. Confirm every counterparty's Participant Identifier and flag any that are missing or wrong.

• Days 11 to 15: design the exception queues. Create queues for ASP validation, tax data reporting, business approval and rejection. Give each an owner, a time limit and an escalation path. Write the system-failure procedure required by Article 12 of Ministerial Decision No. 243 of 2025.

• Days 16 to 20: redesign the close. Add the two-sided reconciliation, the exception checklist and exception ageing reports to the close checklist. Update the accrual policy for stuck and rejected invoices. Update cut-off rules to separate issue, exchange and reporting.

• Days 21 to 25: set controls and the RACI. Write down the preventive and detective controls. Walk through the RACI with tax, IT, sales, procurement and your ASP account manager. Confirm the ASP contract covers evidence retrieval, incident support and confirmation service levels.

• Days 26 to 30: measure and test. Set up the KPI reports. Run two test cycles through the voluntary phase, which has been open since 1 July 2026 under Ministerial Decision No. 244 of 2025. Check your plan against the ASP appointment deadlines: 30 October 2026 for businesses with revenue of AED 50 million or more, following the MoF's May 2026 amendment, and 31 March 2027 for smaller businesses and government entities.

What penalties apply if the timeline slips?

Cabinet Decision No. 106 of 2025 sets the penalties:

• AED 5,000 per month for failing to implement eInvoicing or appoint an ASP.

• AED 100 per eInvoice not issued and sent on time, up to AED 5,000 per month.

• AED 100 per electronic credit note not issued and sent on time, with its own cap of AED 5,000 per month.

• AED 1,000 per day for late notification of a system failure to the FTA. This applies to the issuer and the recipient separately.

• AED 1,000 per day for failing to tell your ASP about changes to your registered details.

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. A finance operating model built on status tracking, exception queues and four-way reconciliation is easier to run when your accounting system connects directly to your ASP.

Explore UAE eInvoicing with Zoho Books

Frequently asked questions

Does UAE eInvoicing remove month-end accruals?

No. Accruals for goods received not invoiced, services performed but not billed, and invoices sitting in exception queues at period end all remain. The exchange log makes those accruals better informed, because it shows which invoices exist and what state each one is in.

Should cut-off follow the invoice status or the supply?

Follow the supply. Cut-off depends on when goods were delivered or services performed, not on the invoice's exchange status. If an invoice is stuck in an exception queue at period end but the supply is complete, recognise it and resolve the invoice in the next period.

Does UAE eInvoicing automate VAT returns?

No. Keep preparing and filing VAT returns as you do today. The tax data your ASP reports gives the FTA a faster view of your transactions, so make sure your VAT return reconciles to your own eInvoicing records.

Will AP and AR teams need fewer people?

The work changes more than the headcount. Re-keying, PDF handling and document matching shrink. Master data ownership, exception handling and control checks grow. Plan the redesign around what people will do, not how many people you need.

How should rejected invoices appear in close reporting?

Show them as their own line in the exception ageing report, with a root cause, an owner and a next action. An invoice rejected before exchange is corrected and resubmitted, not credited. Keep the line open until the corrected invoice is confirmed and reconciled.

Related guides

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

• UAE eInvoicing glossary

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

• UAE eInvoice retention: periods, storage and audit records

• UAE eInvoicing onboarding through EmaraTax: steps and identifiers