On this page
Kodowo connects to your FTA-accredited Access Service Provider by acting as the validation and mapping layer that sits between your ERP or accounting system and your chosen ASP. Before any invoice leaves Kodowo, it is ingested in whatever format your system produces, normalized into a single internal schema, validated against the PINT-AE structure required by the UAE e-invoicing framework, and only then handed off to your ASP for transmission. Nothing reaches your ASP in an unchecked state. If an invoice fails validation, Kodowo surfaces the specific reason so your team can correct and resubmit, rather than receiving a generic rejection from the ASP after the fact. The handoff itself requires no manual intervention. Once an invoice passes validation, it moves forward automatically, and every status change from received through cleared is recorded in a full audit trail.
Why the Layer Between Your ERP and Your ASP Is the Problem Most Businesses Underestimate
The UAE e-invoicing mandate, governed by the Federal Tax Authority and built on the PINT-AE standard developed through the Peppol network, requires invoices to conform to a precise structure before an accredited ASP will accept and transmit them. The accreditation framework means ASPs are responsible for what they forward to the FTA, which means most ASPs will reject invoices that do not already meet the specification.
That rejection point is where most businesses discover their ERP or accounting system does not produce PINT-AE-compliant output on its own. Some ERPs offer a local plugin for a specific ASP, but that only works if your ERP is already on the supported list and your ASP is the one the plugin targets. The gap between what a general-purpose ERP exports and what a PINT-AE-compliant ASP requires is the core problem Kodowo is built to close.
Businesses running SAP, Oracle, Microsoft Dynamics, Zoho Books, or any number of regional accounting platforms face the same issue: their system was not designed around the PINT-AE schema, and retrofitting it directly is expensive, brittle, and locks you to one ASP.
What Actually Happens to an Invoice Inside Kodowo
Kodowo does not replace your ERP and it is not itself an accredited ASP. It occupies the space between those two systems, and the process that happens inside that space is what makes ASP handoff reliable.
Ingestion
Kodowo accepts invoice data in whatever format your existing system produces. API calls, CSV exports, XLSX files, and JSON payloads are all valid inputs. This matters because most businesses running multiple entities or multiple systems cannot standardize their export format without a significant internal project. Kodowo removes that requirement.
Normalization to One Canonical Schema
Once ingested, every invoice from every source is normalized into a single internal schema. This is not a per-ERP translation table bolted onto one system. It is a consistent internal representation that all subsequent processing runs against. The canonical schema step is what makes Kodowo genuinely ERP-agnostic rather than just ERP-compatible with a long asterisk.
PINT-AE Validation and Mapping
With the invoice in canonical form, Kodowo validates and maps it to the exact PINT-AE structure your accredited ASP requires. Validation happens before the invoice is ever transmitted. If something is wrong, your team sees the specific field or rule that failed, not a downstream rejection from the ASP with no actionable detail.
This is a meaningful operational difference. An ASP rejection after transmission means your invoice has already missed its window in some workflows, and diagnosing the cause requires communication between your finance team, your IT team, and potentially the ASP's support queue. A pre-transmission failure in Kodowo means the issue is visible, labeled, and correctable before any of that happens.
ASP Handoff and Status Tracking
Once an invoice passes validation, Kodowo hands it to your accredited ASP. From that point, every status change is tracked in real time. The invoice lifecycle runs from received through cleared, and the current status is visible in the Kodowo dashboard at any point. Nothing sits in an unknown state.
For credit notes, the same lifecycle applies: draft through submission and acceptance, with the option to cancel before the credit note is transmitted.
Why ERP-Agnostic Middleware Beats a Single-ASP Plugin
The single-ASP plugin model has a fundamental constraint: it ties your compliance workflow to one ASP and one ERP. If your ASP changes its integration requirements, or if you migrate ERP systems, the plugin breaks or requires re-implementation. If you run more than one ERP across your entities, the plugin only covers the ERP it was built for.
A middleware layer like Kodowo makes your ASP relationship a configuration detail, not an architectural dependency. You can connect to any accredited ASP, because Kodowo handles the PINT-AE mapping on its end before the handoff. Your ERP side is equally abstracted: adding a new source system means pointing a new data feed at Kodowo, not rebuilding a compliance integration.
For businesses like distributors, freight groups, or retail holdings managing multiple legal entities with different back-office systems, this is the difference between a compliance solution that scales and one that only works for the entity it was implemented for.
You can read more about the reasoning behind this architectural choice on Kodowo's why middleware page.
The Audit Trail: What It Covers and Why It Matters
FTA audits in the UAE context require businesses to demonstrate that their invoicing records are complete and tamper-evident. Kodowo maintains an append-only audit trail that records every status change and every account action. This is not a log you can edit after the fact, which is precisely what makes it useful as audit evidence.
The trail covers the full lifecycle of every invoice and every credit note processed through the platform. If an invoice was rejected, corrected, and resubmitted, all three events are in the record with timestamps. For a CFO or finance manager facing an FTA inquiry, having that trail already in structured form is considerably less stressful than reconstructing it from ERP logs and email chains.
For teams that need to review specific invoices, the dashboard shows exactly where each invoice stands at any point, without requiring a support request to the ASP to find out.
Who Kodowo Is Built For
Kodowo is built for UAE businesses that are not edge cases. Trading companies, freight groups, retail holdings, distribution businesses, and manufacturers, specifically the kinds of organizations that run real invoice volumes across multiple entities or source systems, are the intended users.
These are not businesses that can absorb a failed ASP submission and manually investigate the cause. They need a layer that catches problems before transmission, tracks everything automatically, and does not require a dedicated compliance engineer to operate.
Teams with specific integration needs, including product and engineering teams building invoice flows into their own platforms, can find integration documentation and a Postman collection on the developers page.
For finance and tax teams, the AR and AP workflow does not change materially. Invoices go out the same way they always did, and Kodowo handles the compliance layer in between. For IT and ERP admins, the integration is an API or file feed pointing at Kodowo, not a per-ERP plugin that requires ongoing maintenance.
The Real-World Stakes of Getting This Wrong
The Federal Tax Authority has published detailed requirements for the UAE e-invoicing rollout, and non-compliance carries financial penalties. Beyond penalties, an invoice that fails ASP transmission is an invoice that has not been legally issued under the mandate, which creates downstream exposure for revenue recognition and VAT reporting.
Getting invoices to your ASP in the correct PINT-AE format, reliably and on every run, is not a technical nicety. It is the baseline requirement for operating legally under the mandate. Middleware that validates before transmission is the mechanism that makes that baseline achievable without turning it into a daily manual process.
FAQ
Frequently asked questions
- What does Kodowo actually do before an invoice reaches my accredited ASP?
- Kodowo ingests your invoice data in whatever format your ERP or accounting system produces, normalizes it into a single internal schema, and then validates and maps it to the PINT-AE structure your ASP requires. The invoice is only handed off to your ASP once it has passed that validation, so your ASP never receives a malformed submission.
- Does Kodowo work with any FTA-accredited Access Service Provider, or only specific ones?
- Kodowo is designed to work with any accredited ASP, because it handles the PINT-AE mapping on its own side before the handoff. Your ASP relationship is a configuration detail rather than an architectural constraint, which means you are not locked to one provider.
- What happens if an invoice fails validation inside Kodowo?
- Kodowo surfaces the specific reason for the failure, not a generic error code. Your team can see exactly which field or rule caused the rejection and correct it before resubmission, rather than receiving an opaque downstream rejection from the ASP and having to investigate from there.
- Does Kodowo require us to change our ERP or accounting system?
- No. Kodowo accepts invoice data via API, CSV, XLSX, or JSON, so it works with whatever system you are already running. The whole point of the middleware layer is that your existing systems do not need to be rebuilt or replaced to achieve PINT-AE compliance.
