The five-corner model, corner by corner

In the five-corner model, an invoice does not travel directly from supplier to buyer. It moves from the supplier to the supplier's accredited service provider, across the Peppol network to the buyer's accredited service provider, and on to the buyer — while the Federal Tax Authority, the fifth corner, receives the tax data from the exchange. The model is decentralised: many accredited providers connect to one shared network, rather than every firm filing into a single government portal.

• Corner 1 — the supplier: the business issuing the invoice
• Corner 2 — the supplier's Accredited Service Provider: validates the invoice, converts it to the UAE format and sends it over Peppol
• Corner 3 — the buyer's Accredited Service Provider: receives the invoice over Peppol for the buyer
• Corner 4 — the buyer: the business receiving the invoice
• Corner 5 — the Federal Tax Authority: receives the tax data from the exchange

Corner 1, you, creates the invoice from your invoicing as usual. Corner 2, your provider, is where the mandate's machinery sits: it validates the invoice, converts it to PINT AE — the UAE format — and sends it over Peppol. Corner 3, your customer's provider, receives it on their side and delivers it to corner 4, your customer. Your customer does not need the same provider as you; the two providers meet on the shared network.

Corner 5 is the Federal Tax Authority. Its place in the model is receiving: the tax data reaches it from the exchange between the providers. It is not a mailbox you send invoices to, and businesses may not send invoices to the FTA directly.

A decentralised model spreads the exchange across accredited service providers on an existing international network, instead of making one government system the single doorway every invoice must pass through. Firms keep their own invoicing and choose their own provider; providers compete on service while working to one format and one set of rules. Because the network is Peppol, the same connection pattern used in Europe, Singapore, Australia and elsewhere carries UAE invoices too.

The practical effect for a small firm is simple: your one decision is which accredited provider to appoint. Everything else — validation, conversion, routing — happens at corners 2 and 3, not on your phone.

A PDF emailed to a customer is a picture of an invoice: a person can read it, but no system can check it field by field, and nothing about it reaches the tax authority. An e-invoice in this model is structured data in the PINT AE format, validated by your provider before it moves, delivered through your customer's provider, with the tax data reported to the FTA from the exchange. The document your customer reads may look similar — what changed is everything underneath it. How providers connect to the network is covered on the Peppol and access points page.

Two artefacts travel with a structured invoice, and they do different jobs. The data artefact is the XML file in UBL 2.1 (the UAE's PINT AE profile of it): the machine-readable invoice that access points validate, route and report — the legally operative version in the five-corner exchange. The human artefact is the rendered document your customer reads; where a single file must carry both, the PDF/A-3 archival format can embed the XML inside the PDF, so one file is simultaneously the readable invoice and the structured record.

For a small firm the takeaway is practical: never accept a system whose only output is a picture of an invoice (a plain PDF or an image), because pictures cannot be validated or routed; and never fear that "structured" means your customer receives raw XML — the human copy still looks like the invoice you know. Your software should be able to show you both artefacts for any invoice: the PDF your customer saw, and the XML the system exchanged.