The Peppol five-corner model explained, one invoice at a time

Peppol is an international network and set of standards for exchanging business documents between accredited access points, managed by OpenPeppol. The UAE's model builds on it. The Ministry of Finance notes that using this proven standard allows e-invoices to be exchanged with businesses outside the UAE too.

Inside the UAE, the data format is PINT AE, the UAE's specification of the Peppol international invoice model. Suppliers submit invoice data in PINT AE format to their provider, or the provider converts it.

Our supplier, Gulf Pack LLC in Al Quoz, sells AED 42,000 of cartons plus AED 2,100 VAT to Emirates Foods in Sharjah. Its accounting system prepares the invoice data: both parties' TRNs and electronic identifiers, the invoice type, currency, lines with quantities, units of measure, VAT category and rate, and totals.

That data, not a PDF, is what leaves Gulf Pack's system for its provider.

Gulf Pack's accredited service provider, corner two, validates the data against the UAE requirements and converts it into the UAE XML format if needed. If something is missing, such as the buyer's electronic address, it returns a negative status message and stops.

If the data passes, corner two transmits the e-invoice over the network to Emirates Foods' provider, corner three. Corner three receives it and makes it available to its client. The two providers do not need to be the same company.

Emirates Foods receives the e-invoice through its provider and loads it into its own systems for approval and payment. Because it arrives as structured data, it can be matched against the purchase order without retyping.

Status messages, called message level status in the Ministry's material, travel back along the chain so each party knows whether the invoice was delivered or rejected.

Alongside the exchange, Gulf Pack's provider reports a tax data document to the FTA, the fifth corner. This gives the FTA invoice-level tax data from in-scope transactions close to the time they happen, rather than only as totals in a VAT return weeks later.

If validation fails at corner two, no tax data document is reported, which is why rejections must be fixed promptly. An invoice stuck at the provider is, for compliance purposes, not yet issued.

• Corner 1: supplier prepares invoice data
• Corner 2: supplier's provider validates, converts and sends
• Corner 3: buyer's provider receives
• Corner 4: buyer receives and processes
• Corner 5: FTA receives the tax data document

Day to day, the model shows itself through rejections. A supplier's provider rejects an invoice for a missing or malformed field, and someone has to fix and resend it. Early in any rollout, rejection rates are higher, mostly from customer master data rather than from the invoice itself.

Example: in its first week live, Gulf Pack sends 310 invoices and gets 14 rejections. Nine are missing buyer electronic identifiers, three have a unit of measure the format does not accept, and two have a VAT category that does not match the rate. Fixing the customer and product records stops the same errors recurring the following week.

Corner one is the only corner you control directly, so data quality starts there. HelloBooks keeps the invoice records corner one depends on, with customer TRNs, addresses and per-line VAT treatment, and the AI agent flags invoices missing a required customer detail before they are finalised.

HelloBooks is not a Peppol access point or an accredited provider and does not transmit invoices; your appointed provider does. Firms that want additional customer fields, such as electronic identifiers, captured in a consistent way can request a customisation by emailing hello@hellobooks.ai.