ASP Integration Support

It is the technical and data work that connects your accounting or ERP system to the Accredited Service Provider you have chosen, so that invoices you issue are automatically validated against the UAE's e-invoicing data standard, transmitted to your buyer's ASP, and reported toward the FTA — and so that invoices from your suppliers can be received back into your accounting system the same way. It covers field mapping, master data cleansing, technical connector configuration, and thorough testing before you rely on the process for live invoicing.

You can start directly with integration if you have already completed a robust impact assessment and confidently selected an ASP on your own, but most businesses benefit from running the sequence in order, because integration decisions (field mapping priorities, connectivity model, timeline) depend directly on findings from the earlier phases. Starting integration without that groundwork tends to surface the same gaps mid-project, at higher cost and often under greater time pressure.

PINT-AE is the UAE-specific data standard invoices must be structured against under the national e-invoicing programme, built on the international Peppol International (PINT) framework. Integration work has to ensure every field this standard requires — from Tax Registration Numbers to line-item tax treatment codes — is correctly populated from your accounting system's data before an invoice can pass ASP validation and be successfully transmitted.

The 5-corner model describes how e-invoices move under the UAE's decentralised Continuous Transaction Control approach: your system (Corner 1) generates the invoice, your ASP (Corner 2) validates and transmits it, the buyer's ASP (Corner 3) receives it, the buyer's system (Corner 4) receives the invoice, and the FTA (Corner 5) receives reported transaction data. Integration work connects Corner 1 (your system) to Corner 2 (your ASP) reliably in both directions — outbound invoices you issue, and inbound invoices you receive as a buyer from suppliers who are also on the network.

For a single-entity business on one modern accounting platform with reasonably organised master data, integration from kickoff to go-live sign-off typically runs several weeks to a couple of months. Businesses with multiple invoicing systems, multiple legal entities, or master data that has never been reviewed for completeness will take longer, since data cleansing and multi-system testing extend the timeline materially.

Where a native plug-in is not available, integration can proceed through the ASP's API, a middleware layer that bridges the two systems, or, as a fallback, a structured file upload process. PNPC assesses which option is realistic given the client's system, technical capability, and budget, and manages whichever route is chosen, though API or middleware-based connections generally offer more reliable, lower-effort ongoing operation than manual file uploads.

The most common issues are missing or inconsistently formatted customer and supplier Tax Registration Numbers, product or service catalogues that were never classified for tax treatment (standard-rated, zero-rated, exempt), and the same customer or product being coded differently across multiple source systems such as a POS and an ERP. Any of these can cause an otherwise correctly configured integration to fail validation on a meaningful share of transactions.

Testing covers every invoice type the business genuinely issues or receives — standard tax invoices, simplified B2C invoices, credit notes, debit notes, self-billed invoices, and any zero-rated or export invoices — run through the full outbound or inbound path and confirmed end-to-end, not just configured. It also deliberately includes edge cases, such as a credit note referencing a prior invoice or a multi-currency export transaction, since these are where validation failures concentrate in practice.

This depends on the exception handling process designed during integration, but generally a failed or rejected invoice needs to be identified quickly, its cause diagnosed (a data error, a mapping gap, or an ASP-side issue), corrected, and resubmitted through the ASP's proper correction mechanism rather than simply re-issued as a fresh invoice, which risks double-reporting the same transaction to the FTA.

Once live, the reconciliation process built during integration compares what your accounting system recorded as issued or received against what the ASP confirms was actually transmitted and delivered. This reconciliation should run before each VAT return is prepared, since a mismatch between what your books show and what the ASP reported toward the FTA is a discrepancy you want to catch and explain proactively, not discover during an FTA review.

Every system that issues or receives invoices in scope of the e-invoicing mandate needs to be integrated, or its invoicing consolidated through a system that is. A business running a POS at retail locations alongside an ERP for B2B trade, for example, generally needs both connected, either directly or by routing POS transactions through the ERP before they reach the ASP.

Yes. We routinely sit between the client's ERP vendor or internal IT team and the ASP's implementation team, translating accounting and VAT compliance requirements into terms the technical teams can build against, and translating technical constraints back into terms the client's finance team can evaluate. We do not replace the vendor's or ASP's own implementation resources, but we project-manage the overall integration and hold both sides accountable to the agreed field mapping and test plan.

Yes, in practice. Each legal entity has its own Tax Registration Number and its own invoicing profile, and while the technical connector and field mapping approach can often be templated across entities on the same accounting platform, each entity's data still needs to be validated and tested independently before it goes live, particularly where entities span both mainland and free zone licensing.

Credit and debit notes need to reference the original invoice they relate to, using the identifiers the PINT-AE standard expects, so the FTA and the buyer's ASP can correctly link the correction to the original transaction. Integration testing specifically validates this linkage, since a credit note that transmits successfully but fails to reference its original invoice correctly can distort both parties' VAT positions even though the document itself was technically accepted.

Peppol is the international network standard the UAE's e-invoicing programme uses to exchange structured invoice data between ASPs. As the business, you generally do not interact with Peppol directly — your ASP handles the Peppol-network exchange on your behalf as part of its accreditation. Your integration work focuses on the connection between your system and your ASP; the ASP-to-ASP exchange over Peppol is the ASP's responsibility under its FTA accreditation.

Until your mandatory go-live date under the FTA's phased rollout, you continue invoicing as you currently do. Integration and testing typically run in parallel with normal operations, using test or sandbox environments where the ASP provides them, so live invoicing is not disrupted during the build and test phases — only the actual cutover to production e-invoicing is a planned, monitored event.

Cost depends on the number of source systems requiring integration, the complexity and current state of master data, the number of legal entities in scope, and the connectivity model the chosen ASP supports for your system. PNPC scopes and quotes a fixed project fee after the initial kickoff and master data review, once these variables are understood, rather than quoting a generic number upfront.

Integration support formally concludes at go-live sign-off, with full handover of the field mapping, test evidence, exception handling procedure, and reconciliation process. Many clients transition directly into PNPC's Post Go-Live Support service for ongoing monitoring, exception resolution, and ASP relationship management, particularly through the stabilisation period in the first weeks after cutover, but this is a distinct, separately scoped engagement.