Why middleware?
Your ERP wasn’t built for PINT-AE. It doesn’t have to be.
The case for a compliance layer between your ERP (Corner 1) and your Accredited Service Provider (Corner 2), instead of wiring the mandate directly into either one.
Two paths
Every team facing this mandate picks one of two paths.
Build it yourself
Building and maintaining your own integration into your Accredited Service Provider’s API is real, ongoing engineering work. Every time the PINT-AE spec changes, someone has to find and rewrite the ERP code that talks to it, and that cost repeats for as long as the mandate exists.
Ongoing engineering cost, repeats on every spec changeDo nothing
Miss the ASP-appointment deadline and the penalty meter starts: AED 5,000 for every month you’re not connected, once your business is in a mandatory phase.
AED 5,000 / month, and countingThe mandate is a network, not a file format
The 5-corner model, explained once.
UAE e-invoicing runs on the Peppol 5-corner Decentralized CTC and Exchange model. Your invoice never goes straight to the tax authority: it moves seller → your Access Point → the network → the buyer’s Access Point → buyer, with the FTA receiving its copy from the network side. Getting a validated, audited path into that network is the actual integration problem. That path is what we built.
We sit in front of your Accredited Service Provider, in every submission: the layer that decides whether an invoice is ready before it ever reaches the network.
Architecture
The 5-Corner DCTCE Network
What Kodowo does
Ledger, validation, audit.
What your ASP does
Signing, exchange, FTA reporting.
Decoupled ERP
When the spec changes, your ERP doesn’t.
The Ministry of Finance amends the PINT-AE spec, and a direct-API client has to find and rewrite the ERP code that built the old field set. A Kodowo client’s ERP stays untouched: we absorb the schema translation in our layer, not yours.
Direct API
Spec changes → ERP code changes
With Kodowo
Spec changes → our layer changes
The messy-data reality
Legacy exports in. Canonical fields out.
Most invoicing data doesn’t start out clean. It starts as a CSV or Excel export from a legacy system, with inconsistent column names and no PINT-AE structure at all. Our AI ingestion maps that mess to the 51 official MoF fields (62 once you include everything else the spec separately requires) in hours, not weeks.
Legacy CSV / Excel export
Unstructured62 fields validated (51 official MoF + 11 more)
Hours, not weeksASP-agnostic, by design
We don’t replace your ASP. We feed it clean data.
Bring whichever Accredited Service Provider you’ve already chosen. Kodowo’s BYOK bridge connects to it directly, and your ASP credentials are encrypted end-to-end and never leave your control. Your ERP or POS only ever talks to Kodowo: if you switch ASPs later, that’s a routing change on our side, not a rewrite of your integration.
Real-time validation vs. periodic reporting
The FTA sees invoices near-real-time. Your error checking should too.
PINT-AE isn’t a return you file at quarter-end. The network reports each invoice as it moves. Catching an error before it’s transmitted is a different problem than catching one after the fact, and it needs a different kind of tool.
Periodic reporting
Errors surface at filing time, long after the invoice already went out.
Kodowo’s validation sandbox
Every check runs before the network ever sees the invoice, the same pipeline as submission, with zero persistence.
Every document type, not just the easy one
Standard invoices are the easy case. We validate the rest too.
Kodowo validates every invoice type the mandate defines: standard invoices (both the taxable kind and the exempt kind), credit and debit notes with their preceding-invoice reference properly linked, and self-billed documents issued on a seller’s behalf under a registrant-to-registrant agreement. It also catches the easy-to-miss inconsistency of an invoice that mixes taxable and exempt line items, flagging it for review before it ever reaches your ASP.
Invoices, credit notes, debit notes
Credit and debit notes are checked for a valid link back to the original invoice, not just accepted at face value.
Self-billed documents
Recognized as the same document types under a different authorization arrangement, not treated as a special case.
Mixed taxable / exempt lines
Flagged for a second look before submission, since that combination on one document is unusual.
One intake layer, any source
We don’t care where the invoice starts.
A corporate finance team runs invoicing through an ERP. An operations team running a wholesale or retail floor often runs a fleet of POS terminals instead, sometimes both at once. Our intake is a standard API, so it makes no difference to our engine whether a submission originates from a central ERP or a checkout terminal: it gets normalized, validated, and routed the same way either time.
ERP
Central ledger, corporate B2B invoicing, contract terms
POS
High-volume, real-time transactions at the point of sale
Either way
Same validation, same normalization, same route to your ASP