On this page
The UAE's e-invoicing architecture has three real parties in it: your ERP or accounting system, an accredited Access Service Provider (ASP), and the Federal Tax Authority (FTA). It is tempting to assume invoice data can move directly between the first and the last, with the ASP as a simple pass-through. In practice, there is a real gap in the middle, and neither an ERP vendor nor an ASP is built to own it.
ERP / Accounting System -> Kodowo -> Accredited ASP -> FTA
That is the actual shape of the pipeline, stated plainly. Kodowo does not connect directly to the FTA and is not itself an accredited ASP. It is the layer that sits between your existing systems and whichever accredited ASP you use, and it exists because of three specific problems neither side of it solves on its own.
Your ERP was not built for PINT-AE
Whatever system your business runs on today, whether that is Oracle, QuickBooks, Sage, SAP, Xero, Zoho, or something else entirely, it was not built with the UAE's PINT-AE structure in mind. That is not a criticism of the ERP. It is simply not the job it was designed to do. Most businesses also run more than one system across different parts of finance and operations, and none of them speak PINT-AE natively.
A middleware layer's first job is ingestion that does not care which system the data came from. Kodowo accepts invoice data via API, or via CSV, XLSX, or JSON import, and normalizes whatever arrives into one canonical schema before anything else happens to it. That is the difference between a single-ERP plugin, which breaks the moment you add or switch a system, and an ERP-agnostic normalization layer, which does not.
Your ASP handles submission, not your data quality
An accredited ASP's job is to take correctly structured invoice data and get it in front of the FTA. That is a real, necessary, and narrowly scoped job. It is not an ASP's job to fix invoice data that arrives malformed, incomplete, or mapped incorrectly to the PINT-AE structure, and most ASPs are not built to do that kind of upstream correction at scale.
That means validation and mapping have to happen before data reaches the ASP, not after. Kodowo validates invoice data and maps it into the required PINT-AE structure as a distinct step, so what your ASP receives is already correct. When something does not validate, the point of failure is visible and actionable on your side, not discovered as a rejection days later.
A failure should never be a black hole
The most common failure mode in a hand-rolled integration is not that invoices fail. Some invoices will always fail, for a hundred reasonable reasons. The failure mode is that a rejection disappears into a generic error state with no detail, and someone has to manually reconstruct what happened.
Every invoice Kodowo processes moves through a real, visible lifecycle: received, validated, pending transmission, transmitted, and cleared by the FTA, with rejected, failed, and needs-review as real states you can see and act on, not a single undifferentiated "failed" bucket. Failures surface with enough detail to actually fix the underlying issue. Alongside that, every status change and account action is recorded in a full, append-only audit trail, so nothing about an invoice's history is reconstructed after the fact.
What this buys you that a direct integration does not
Building a direct integration from your ERP to a specific ASP is possible. It is also brittle in a specific way: it couples your compliance path to one system and one ASP relationship at a time. If you add a second ERP, acquire a company running a different accounting system, or need to change ASPs, a direct integration means redoing the work.
An ERP-agnostic normalization schema does not have that problem, because the schema, not the connection, is the thing that stays constant. That is the mechanism a single-ERP plugin or an ASP-side integration cannot casually replicate: it is not a plan, it is the layer Kodowo already runs invoice data through today, independent of which system the data started in or which accredited ASP it ends up going through.
The layer, not a replacement
None of this is about replacing your ERP or replacing your ASP relationship. It is about owning the step neither of them is positioned to own: making sure what moves between them is normalized, validated, and structured correctly, with full visibility when it is not. That is what a middleware layer means in the context of UAE e-invoicing, and it is why the architecture above has three real parties in it, not two.
