E-invoicing compliance, built into the product

The client is an accounting software provider whose product runs daily finance for small and mid-sized businesses across the UAE. Invoicing sat at the heart of the product: customers created invoices in the app, sent them as PDFs, and filed VAT returns from the same ledger. The invoice was a document, generated for a human to read, and the product was built around that assumption.

The UAE's move to mandatory e-invoicing broke that assumption. Under the FTA regime, an invoice is a structured PINT AE data exchange that travels through Accredited Service Providers on the Peppol five-corner model, with a tax data document reported to the authority as part of the flow. The provider's invoice engine produced human-readable output with free-text tax fields and no guaranteed mapping to the mandated structure. It had no Peppol connectivity, no validation layer, and customers were starting to ask whether the product would keep them compliant when the mandate took effect.

Kentro was engaged to make the product mandate-ready: transform legacy invoice data into valid PINT AE, connect the platform to the regime through an Accredited Service Provider, and build the validation, error handling, and retry machinery that keeps invoices flowing when the data or the network pushes back. Kentro runs its own e-invoicing platform, InvoiceX, so the team was applying patterns it already operates in production.

Retrofitting a live accounting product for a clearance-style regime is harder than building for it from scratch. Every gap was already in production, in front of paying customers.

• Legacy data with no clean mapping.: Invoices lived as internal records with optional fields, free-text tax treatments, and customer-defined templates. PINT AE requires structured, code-listed values in every mandated field, and the gap between the two looked different for every customer.
• A product that could not pause.: Customers issued invoices every day from the existing workflows. The compliance layer had to slot in behind the product's invoice engine without interrupting billing or forcing users into a new tool.
• A regime still hardening.: Data dictionary updates, ASP onboarding requirements, and validation rules kept evolving while the build progressed. The integration had to absorb specification change as configuration, not rework.
• No room for silent failure.: A rejected invoice that nobody notices is a compliance exposure. Every validation or transmission failure had to surface to the right user with a reason and a path to fix it.

Kentro built a compliance layer between the product's invoice engine and the Peppol network: a canonical invoice model, a transformation and validation pipeline, ASP connectivity, and an operational error handling loop, drawing directly on the architecture Kentro runs in InvoiceX.

• Canonical model before format.: The product's internal invoice records were mapped to a canonical invoice model, and UBL-based PINT AE documents are generated from that model. Free-text tax treatments were normalized against the mandated code lists, so template quirks stopped leaking into the compliance path.
• Validation before transmission.: PINT AE rule packs run as a Schematron validation gate inside the pipeline. A document that would be rejected at the ASP or the receiving corner fails early, with field-level errors translated into language an accountant can act on.
• ASP connectivity on the five-corner model.: The platform connects to an Accredited Service Provider over authenticated APIs, resolves receivers through Peppol directory lookup, and exchanges documents through the provider's access point, with the tax data document flowing to the FTA as part of the same transaction.
• Delivery as a state machine.: Every invoice moves through explicit states, from queued through validated, transmitted, acknowledged, or rejected. Retries are idempotent with backoff, and documents that exhaust their retries land in a dead-letter review queue instead of disappearing.
• Rejection analytics for the support team.: Message-level statuses from the network map back onto the invoice record, and rejection causes are aggregated by customer, template, and tax scenario, so the provider's team fixes root causes in the product rather than handling failures ticket by ticket.

The provider stopped watching the mandate approach and started shipping compliance as part of its product.

• Compliance became a product feature.: Customers issue invoices in the workflow they already know. Transformation, validation, clearance, and FTA reporting happen behind the same action they have always used.
• Manual submission work disappeared.: Finance teams on the platform no longer export invoices for separate handling or chase rejected documents over email. Failures appear in-product with a stated cause and a fix.
• Failures turned into signals.: Recurring rejection causes surface as patterns tied to templates and tax scenarios, so fixes land in the product and the same error stops repeating across the customer base.
• Regulatory change lands as configuration.: Rule packs, code lists, and dictionary updates ship without touching the invoice engine, which keeps the product current as the regime tightens.