MINSEONG.com
MINSEONG / GUIDES

UAE eInvoicing month-end reconciliation: matching electronic invoice records to the general ledger

Published · Official sources last reviewed 22 October 2026 · 10 min read

Once electronic invoices start flowing through Accredited Service Providers (ASPs), a finance team holds two versions of the same commercial reality: the records in its own accounting system and the records exchanged through the eInvoicing network. In a well-run month the two agree. In practice they drift apart because of rejected transmissions, late credit notes, timing cut-offs, manual journals and supplier invoices that arrive electronically but are never posted. A month-end reconciliation is the routine that finds those gaps before they reach the VAT return, the management accounts or an auditor’s sample.

This guide is written for accountants, financial controllers and finance systems owners. It explains how to design that reconciliation: which populations to compare, which checks to run, how to classify differences and who should own them. It builds on the field mapping described in our data mapping and system integration guide and the counterparty data work in the master data readiness guide. For the distinct bank-to-receivables process of matching receipts, allocating customer payments and resolving unidentified cash, use our AR cash application and reconciliation guide.

Legal requirement or good practice? The binding rules are in Ministerial Decision No. 243 of 2025 on the Electronic Invoicing System, as amended by Ministerial Decision No. 197 of 2026, and in Ministerial Decision No. 244 of 2025 on implementation, as amended by Ministerial Resolution No. 66 of 2026. Those instruments set out who must issue and receive Electronic Invoices and Credit Notes and the role of ASPs. They do not prescribe a month-end reconciliation procedure. The checks below are operational recommendations designed to support compliance with those rules and with ordinary accounting controls; they are not quotations of a legal requirement.

1. Why eInvoicing Records and the Ledger Drift Apart

Before designing checks, it helps to list the reasons the two populations can disagree. Each cause points to a specific test.

Causes on the sales (issuer) side

  • Transmission failures: an invoice is posted to receivables but the ASP rejected the payload, so no valid electronic invoice exists yet.
  • Documents outside the integration: invoices raised in a secondary billing tool, a spreadsheet or a manual journal never pass through the eInvoicing interface.
  • Corrections: a credit note is posted in the ledger but not issued electronically, or the reverse.
  • Cut-off timing: an invoice is dated on the last day of the month but transmitted after the period closes.

Causes on the purchase (recipient) side

  • Unprocessed receipts: supplier invoices delivered by the ASP sit in an inbox or approval queue and are not booked as liabilities.
  • Duplicate capture: the same supplier invoice arrives electronically and as a PDF by email and is posted twice.
  • Counterparty identity: an invoice is matched to the wrong supplier record because identifiers were inconsistent in master data.

The obligations behind these flows are explained in our guides to the issuer and accounts receivable process and the recipient and accounts payable process.

2. Define the Populations Before You Compare Them

A reconciliation is only as good as the definition of what is being reconciled. Agree, in writing, the three data sets that will be compared each month:

  1. Ledger population: all sales and purchase documents posted to the general ledger in the period, extracted from the sub-ledgers rather than from summary balances, with document number, date, counterparty, net amount, VAT amount and document type.
  2. eInvoicing population: all documents your ASP reports as sent or received for your business in the same period, with their status (for example accepted, rejected or pending) and the identifiers that link them back to the source document.
  3. Out-of-scope population: documents that should not appear in the eInvoicing data, such as transactions you have assessed as excluded. Our transaction scope guide explains how to reach that assessment and record it.

Use the same period definition for every data set. If the ledger is closed on posting date and the ASP report is filtered on transmission date, the reconciliation will show timing noise every month. Pick one basis, document it, and treat the other date as an attribute for cut-off review.

3. The Five Core Monthly Checks

Most finance teams can cover the main risks with five checks. Run them in this order, because each one narrows the population for the next.

Check 1: Completeness of issued documents

Match every sales invoice and credit note in the ledger to an accepted electronic document using a stable key, ideally the internal document number carried in the payload. Anything posted but not transmitted, or transmitted but rejected, goes to the exception list.

Check 2: Existence of issued documents

Run the match the other way. Every electronic document reported by the ASP should exist in the ledger. An electronic invoice with no ledger posting may mean a test transaction reached production, a document was cancelled in the ERP after transmission, or a duplicate was sent.

Check 3: Value agreement

For matched pairs, compare net amount, VAT amount, currency and document type. Small differences often reveal rounding logic that differs between line-level and total-level calculations, which is a mapping issue rather than an accounting one.

Check 4: Completeness of received documents

Compare supplier documents delivered through the ASP with the purchase ledger. Unposted receipts at month end may need an accrual and should be reviewed against the processing duties described in our Article 6 issuer and recipient obligations guide.

Check 5: Status and ageing of open items

List every document still pending, rejected or in a retry queue, with its age in days and an owner. The aim is a short, explained list rather than a long, silent one.

4. Classifying and Clearing Differences

Every difference should receive a reason code. A consistent set of codes turns a monthly spreadsheet into management information that shows where the process is weak. A practical starting list:

  • T – Timing: transmitted or posted in the adjacent period; clears automatically next month and should be confirmed.
  • R – Rejected: the ASP or the network rejected the document; correct and resend.
  • M – Missing from integration: created outside the connected system; route the source through the integration or document why it is out of scope.
  • V – Value mismatch: amounts disagree; investigate mapping, rounding or manual edits after transmission.
  • D – Duplicate: posted or sent twice; reverse in the correct system and record the evidence.
  • S – Scope: correctly excluded; keep the scope assessment on file.

Set a materiality threshold for investigation, but never for completeness: a missing document matters regardless of amount because it may indicate a control gap that will repeat. Track the count of differences by code over several months. A rising number of value mismatches usually points to a mapping or master-data change that was not tested.

5. Credit Notes, Corrections and the VAT Return

Corrections are where reconciliations most often fail. Under the amended Decision 243/2025, Credit Notes are electronic documents in their own right, so a correction made only in the ledger is not enough. For each credit note in the period, confirm that it was issued electronically, that it references the original invoice where your system supports that link, and that the ledger posting matches its value.

For Registrants, VAT reporting still follows the VAT legislation. The eInvoicing reconciliation is therefore a useful input to, but not a substitute for, the VAT return reconciliation. A sensible sequence is to clear eInvoicing differences first, then reconcile the VAT control accounts to the return. Where differences remain at the filing date, document how each one was treated. Confirm the treatment of specific cases with a qualified tax adviser; this guide does not give tax advice.

6. Controls, Ownership and Evidence

A reconciliation that depends on one person’s spreadsheet will not survive staff turnover. Build it into the close calendar with clear roles:

  • Preparer: extracts the populations, runs the checks and proposes reason codes.
  • Reviewer: a different person who challenges unexplained items and signs off the reconciliation with a date.
  • Systems owner: resolves rejections and mapping defects and liaises with the ASP.
  • Master data owner: fixes counterparty records behind identification errors.

Keep the extracts, the matched results, the exception list and the sign-off together for each period, in line with your existing record-keeping obligations under the tax legislation. Our record keeping and archiving guide explains the retention rule in the replaced Article 11 and how to design the archive. Where the ASP provides status reports, store the version used for the reconciliation, because later reports may show updated statuses. Your service agreement with the ASP should state which reports are available and for how long; the accreditation framework is summarised in our Decision 168/2026 guide and the Ministry of Finance announcement.

7. Testing the Reconciliation Before Go-Live

Do not wait for the first live month to discover that the ASP report lacks the field you need for matching. Include the reconciliation in your pre-go-live test plan: generate a test month of invoices, credit notes, rejections and received documents, then run all five checks end to end. Confirm that the internal document number survives the round trip, that statuses are available in a usable format, and that the exception report can be produced within your close timetable. Our go-live testing checklist lists the related scenarios, and the free readiness assessment helps you see where reconciliation fits in your wider plan. Check your category’s milestones in the home page key dates.

8. Month-End Reconciliation Checklist

  • Ledger, eInvoicing and out-of-scope populations are defined and documented.
  • One period basis (posting or transmission date) is used consistently.
  • Issued documents are matched both ways: ledger to ASP and ASP to ledger.
  • Matched pairs are compared for net, VAT, currency and document type.
  • Received supplier documents are matched to the purchase ledger and accrued where needed.
  • Every open item has a reason code, an owner and an age.
  • Credit notes are confirmed as issued electronically and linked where supported.
  • eInvoicing differences are cleared before the VAT control account reconciliation.
  • Preparer and reviewer sign-off and supporting extracts are retained.
  • Trends in difference codes are reported to the financial controller.

9. Frequently Asked Questions

Is a monthly eInvoicing reconciliation legally required?

The decisions cited above do not prescribe a reconciliation procedure. It is a control we recommend so that you can show your Electronic Invoices and Credit Notes were issued and processed as the rules require and that your books agree with them.

Should we reconcile daily instead of monthly?

Rejections and stuck transmissions are best monitored daily by the systems owner. The monthly reconciliation is the formal, reviewed control that confirms the period is complete. Many teams use both.

What key should we match on?

Use an identifier that is created in your ERP and carried unchanged into the electronic document, such as the internal invoice number combined with your own registration identifier. Avoid matching on amount and date alone, which produces false matches.

Who should own unresolved rejections?

Assign them to the systems owner for technical fixes and to the billing or payables team for business decisions, with the financial controller reviewing anything older than your agreed threshold.

Summary and Next Steps

A month-end reconciliation turns eInvoicing from a technical interface into a controlled part of the close. Define the populations, run the five checks, code every difference, treat credit notes carefully and keep evidence of review. For official updates, follow the Ministry of Finance eInvoicing programme page and Federal Tax Authority communications such as its awareness meeting announcement for ASPs and persons subject to the system. Browse all topics in the guides hub.