Appointed Your UAE ASP? Let’s prepare the ERP behind it.

UAE e-invoicing / From appointment to operation

Your Accredited Service Provider is selected. The contract is signed. Now comes the work that determines whether your finance team can issue, receive and track electronic invoices reliably.

By the Craft Interactive team · Updated 27 October 2026

What should happen after ASP appointment?

Confirm onboarding, assign owners, map invoice data, agree the integration contract, test outgoing and incoming documents, and establish reconciliation and exception handling. Finish with a joint go-live decision based on evidence—not simply a successful API connection.

For many UAE businesses, ASP appointment closes a procurement milestone and opens an implementation project. Your ERP team, finance team and provider now need to turn a commercial agreement into a dependable working process.

Whether you use ERPNext, another ERP platform or accounting software, the next steps should connect three things: accurate source data, a tested exchange process and clear responsibility when something needs attention.

ASP appointment and implementation are separate milestones

The Federal Tax Authority’s September 2026 announcement distinguishes the appointment deadline from mandatory implementation. For in-scope persons with annual revenue of AED 50 million or more, these dates are 30 October 2026 and 1 January 2027, respectively. Below AED 50 million, the corresponding dates are 31 March 2027 and 1 July 2027.

Do not use “provider appointed” as a synonym for “ERP ready.” Ask for a shared implementation plan covering onboarding, data preparation, development, testing, user training and production support.

Under the Ministry of Finance’s published exchange model, the supplier’s ASP validates invoice data, handles the required exchange and reporting flow, and returns exchange and reporting statuses. Those are distinct outcomes your ERP team needs to track.

1. Confirm onboarding and agree who owns each decision

Ask your ASP to confirm what is complete, what remains outstanding and which party must act next. A signed contract does not establish that production access, entity details, identifiers or the provider’s activation checks are complete.

Bring finance, tax, IT and the provider into the same planning conversation. Our recommended ownership split is below; use your contracts and internal responsibilities to confirm the final allocation.

Workstream	Suggested owner	Evidence to agree
Entity and transaction scope	Finance and tax leads	Approved list of entities, transaction categories and exceptions.
ERP configuration and connector	ERP team or implementation partner	Versioned mapping, deployment plan and technical test results.
Provider onboarding and interfaces	ASP with your authorised business contact	Confirmed activation steps, documentation and environment access.
User acceptance and reconciliation	Finance process owner	Signed test results and a repeatable reconciliation procedure.
Incident response	Named support leads across all parties	Escalation contacts, ownership boundaries and response arrangements.

Deliverable: one plan with named owners, dependencies and acceptance criteria.

2. Build a field mapping from your ERP to the ASP

Obtain the provider’s current input specification and agree the applicable PINT AE billing specifications. OpenPeppol publishes semantic models, syntax bindings, code lists and validation rules for invoices and credit notes. Agree the supported versions before development.

Your mapping should explain where each value comes from, how it is transformed and who approves the treatment. Do not assume every provider expects your ERP to supply a finished XML document: the agreed interface may support provider-side conversion.

Data area	ERP review	Question to resolve
Seller and buyer records	Legal names, addresses and relevant identifiers.	Which record is authoritative, and how are missing values handled?
Invoice identity	Document number, dates and references.	Can every transmission be traced back to its original transaction?
Lines and totals	Quantities, units, prices, allowances and charges.	Are calculations consistent across ERP and provider validation?
Currency and tax	Currency codes, exchange information and tax treatment.	Which rules has finance approved for each transaction category?
Credit notes	Original document references and adjustment details.	Does the correction process retain a clear audit trail?

This is a mapping framework, not the complete mandatory field list. Validate your actual documents against the current requirements available through the Ministry of Finance portal.

Deliverable: an approved mapping with sample payloads and documented exceptions.

3. Fix master data before it becomes an integration problem

A connector can transmit a record quickly without making that record correct. Review active customer and supplier data before testing at scale. Start with the accounts that generate the most invoices, then cover unusual transaction patterns.

Identify duplicate records and agree the authoritative account.
Assign responsibility for legal details and relevant identifiers.
Review item descriptions, units and tax settings with finance.
Make agreed checks part of record creation and maintenance.

Keep a register showing the issue, owner, affected documents and resolution. Avoid fixing values only in the ASP portal while leaving the ERP unchanged; otherwise the same issue may return on the next invoice.

4. Agree the integration contract and document lifecycle

Technical documentation should cover more than the submission endpoint. Confirm authentication, environments, supported payloads, response formats, rate limits, timeouts and how changes will be communicated.

Separate accounting and exchange states

An invoice posted in the ERP, accepted by an API and successfully exchanged are different events. Keep the ERP’s accounting status distinct from integration progress and the provider’s exchange and reporting results.

Make retries safe

Agree a stable document reference and the provider’s duplicate-handling behaviour. A timeout may leave the outcome uncertain. Check status before resending and prevent two workers from submitting the same document concurrently.

Plan how responses reach the ERP: callbacks, polling or another agreed mechanism. Retain the provider reference, timestamps, relevant status history and actionable error messages. Your team should be able to investigate a document without searching through several unrelated systems.

Design the inbound route too. Confirm how supplier invoices and credit notes enter your workflow, how duplicate receipts are detected and when accounts payable must review a document before posting it.

Deliverable: a documented lifecycle covering submission, responses, exceptions, corrections and receipt.

5. Test the exceptions as carefully as the successful invoice

Use representative transactions and record the expected outcome before running each test. The scenarios below are recommended engineering and user acceptance checks; add your sector-specific cases with finance and the ASP.

Scenario	What a useful test proves
Complete invoice	Amounts remain consistent and exchange/reporting outcomes are traceable.
Missing or invalid data	The error is visible, assigned and corrected at the appropriate source.
Timeout after submission	The team can determine the outcome and recover without creating a duplicate.
Repeated submission or response	The connector handles repetition without repeating the business action.
Credit note	References, amounts and the correction workflow behave as agreed.
Incoming supplier document	Receipt, duplicate checks and finance review work together.
Peak transaction volume	Queues, provider limits and monitoring remain workable under expected demand.

Where relevant, include foreign currencies, discounts, partial transactions and the tax categories your business actually uses. Use separate test credentials and appropriate test data. Keep sensitive production data out of unrestricted development environments.

Deliverable: signed test evidence, an unresolved-issue list and a decision on every launch blocker.

6. Give finance a reconciliation and exception workflow

A single “sent” flag is too coarse for day-to-day control. Design a view that helps finance answer three questions: which documents were expected, what happened to them and what requires action?

Compare the ERP’s expected documents with the integration register.
Identify items with missing, failed or uncertain exchange/reporting outcomes.
Review amounts and references where mismatches occur.
Assign each exception to a named owner and retain the resolution history.

Agree the reconciliation frequency around volume and applicable deadlines. Do not treat a green API response as proof of every downstream outcome. Ask the ASP to explain exactly what each response means.

Keep records accessible

The October 2026 amendments announced by the Ministry of Finance removed the specific UAE storage-location requirement in the amended e-invoicing provision while preserving retention and access obligations. That does not remove other applicable data requirements.

Agree how you will retrieve invoices, credit notes and associated data, including after a provider change. Test access and recovery rather than relying only on a promise that records are backed up.

What should an ERPNext team check specifically?

Start with the installed ERPNext version, custom apps, existing invoice workflows and hosting arrangement. Identify which requirements can be met through configuration and which require an additional app, connector or custom development.

Frappe’s REST API documentation describes supported API and authentication mechanisms. These provide integration building blocks; they do not establish that a particular UAE ASP connector is installed, tested or compliant.

Review how Sales Invoices and credit-note workflows provide the required source data.
Agree whether mapping belongs in ERPNext, middleware or the ASP service.
Separate test and production credentials and limit integration permissions.
Check queue processing, response updates and duplicate protection.
Retest the connector when ERPNext, custom apps or provider interfaces change.

A submitted accounting document should not silently become a new transmission every time it is edited or synchronised. Agree the trigger and correction process explicitly.

We approach ERPNext implementation and customisation around that full workflow, so the integration has a clear operational owner after development finishes.

7. Make go-live a joint decision

Before production launch, ask the ERP lead, finance owner and ASP contact to review the same evidence. Do not approve deployment while key parties are working from different definitions of “ready.”

Provider onboarding and production access are confirmed.
Transaction scope, mapping and data ownership are approved.
Representative outgoing and incoming documents have passed testing.
Retry, duplicate, failure and correction scenarios are understood.
Finance can reconcile documents and investigate exceptions.
Records can be retrieved and recovery arrangements have been tested.
Support contacts, escalation and deployment responsibilities are documented.
A cutover plan addresses pending documents and avoids duplicate transmission.

Plan business continuity with your ASP. If a technical release is paused or rolled back, do not assume that suspends a legal obligation or permits a return to PDF-only invoicing. Agree the permitted operational response before an incident occurs.

During the initial operating period, monitor exceptions closely, record recurring causes and improve the process. The useful measure is whether finance can trust the document trail and resolve problems promptly.

Questions after appointing a UAE ASP

Does appointing an ASP make our ERP compliant?

No. Appointment, activation, data readiness, integration, testing and ongoing operation are separate parts of the work. Confirm each against your applicable requirements and agreed service scope.

Must we replace our existing ERP for UAE e-invoicing?

Not automatically. Assess whether it can provide the required data and support a reliable integration. Replace it only where the functional or operational case justifies the change.

Must our ERP generate PINT AE XML itself?

Agree the interface with your ASP. The Ministry’s published model allows the supplier’s ASP to convert a different agreed input format into the UAE-standard invoice XML. Your source data must still satisfy the applicable requirements.

How long will post-appointment integration take?

That depends on data quality, ERP customisation, provider interfaces, transaction complexity and testing capacity. Establish a dependency-based plan after reviewing the actual system rather than relying on a universal timeline.

Can an API success response be our only acceptance check?

No. Confirm the meaning of that response and track the relevant exchange and reporting outcomes separately. Include reconciliation, error recovery and user acceptance in the launch decision.

Your ASP is appointed. Let’s prepare the ERP behind it.

We help assess source data, ERPNext workflows and integration requirements, then define the configuration, development and testing needed with your selected provider. Start with the gaps that could slow your finance team down at go-live.

Discuss your ERP and ASP integration

hello@craftinteractive.ae · +971 56 259 8881

Official and technical references

Reviewed on 27 October 2026. The implementation controls in this article are practical recommendations; your transaction treatment, obligations and operating procedures should be confirmed against current official requirements and your provider agreement.