PINT-AE XML Format Mandatory Fields: Mapping a UAE Chart of Accounts Without Breaking Reporting

The PINT-AE XML format mandatory fields fall into four blocks: header (invoice number, issue date, document type code, currency), parties (legal name, postal address, PEPPOL electronic address, TRN), lines (description, quantity, unit code, unit price, line net amount, tax category code, tax rate) and totals with the tax breakdown. Your chart of accounts has to feed every one of them.

The hardest part of UAE e-invoicing readiness is not the legal text and not the PINT-AE specification. It is the quiet work of mapping a chart of accounts that grew organically for ten years to an envelope demanding eight specific field positions per line. Most finance teams discover this late, usually in week four of an Accredited Service Provider (ASP) integration, when the sandbox starts rejecting 30% of submissions for reasons that read like a foreign language: BR-CO-10, UBL-CR-561, PEPPOL-EN16931-R053.

This guide is the missing middle layer. It focuses on the engineering question: how do you take the GL accounts, item master, customer master and TRN master you already have, and translate them into PINT-AE without breaking the management reporting your finance director relies on every month?

How to scope an e-invoicing ERP mapping project in the UAE

Before any e-invoicing ERP mapping work begins in the UAE, size the job honestly. The effort scales with four numbers, not with your revenue: how many revenue GL accounts you post to, how many active SKUs or service items sit in your item master, how many customers you bill, and how many distinct tax scenarios you actually run. A firm with eight revenue accounts, three tax treatments and a few hundred customers has a light mapping job. A trading group with forty revenue accounts, imports, exports, designated-zone sales and reverse charge has a heavy one — the same mandate, a very different workload.

Two further questions decide whether the project runs long. First, does your current ERP edition include the UAE localisation, or does the vendor gate PINT-AE support behind an upgrade? Second, is your master data clean enough to trust, or has it drifted over years of quick fixes? Answer those early. A short discovery pass — counting accounts, sampling the item master, checking a batch of customer TRNs against the FTA verification portal — tells you within a week whether you are looking at a twelve-week sprint or a longer haul. Scoping first, in advisory terms, is the difference between a plan and a scramble.

Why your CoA won’t map 1:1 to PINT-AE

Before you start mapping, print the chart of accounts list you actually run — not the sample chart of accounts your software shipped with, and not a chart of accounts PDF pulled off the internet. The mapping work is done against live GL codes with live posting history behind them, and a generic chart of accounts example will hide exactly the accounts that cause trouble: the ones somebody created mid-year for a single client and never documented. A typical UAE SME chart of accounts grows around internal reporting: revenue split by service line or client tier, expenses split by department, tax accounts split by jurisdiction. The chart is rich vertically but thin horizontally. Each account carries only a few attributes — GL code, name, normal balance, sometimes a department.

PINT-AE expects the opposite shape. Each invoice line carries a fixed horizontal attribute set: item name, description, quantity, unit price, line extension amount, classification code, tax category code, tax rate, optionally an allowance or charge, and identifiers tying back to a contract or purchase order. The vertical depth of your GL is invisible in the envelope. The horizontal attribute set is what the ASP validates against.

The mismatch shows up in three predictable places:

1. Revenue is too granular on the wrong axis. You may have 14 revenue GL accounts for the same product family because they were created over time for different reporting cuts. The ASP only sees one item per line and does not care which GL the credit posts to.
2. Tax accounts are too coarse on the wrong axis. A single Output VAT 5% account covers standard-rated supplies, deemed supplies and adjustments. PINT-AE wants the supply type tagged at the line level using UN/CEFACT codes — S for standard, Z for zero-rated, E for exempt, AE for VAT reverse charge.
3. Allowances and charges live in the GL, not the line. Discounts, freight and handling are often booked to separate GL accounts. PINT-AE expects them attached to the line as AllowanceCharge elements with reason codes, not as separate postings.

PINT-AE XML format mandatory fields: what the ASP actually expects in the envelope

Before mapping anything, your team needs a shared mental model of the envelope. PINT-AE is the UAE jurisdiction profile of the PEPPOL International (PINT) model, which builds on EN 16931, the European semantic standard for electronic invoicing. If your group already runs PEPPOL e-invoicing in Europe or Singapore, the semantic model will look familiar and the integration work is smaller — what changes is the national layer, not the envelope shape. The UAE adds a national layer for TRN handling and VAT category specifics.

At a structural level the envelope has four blocks:

• Header — invoice number, issue date, due date, document type code, currency, document references (contract, PO, despatch advice), payment terms and means.
• Parties — supplier, customer, tax representative if applicable, delivery party if different. Each party carries a name, postal address, electronic address (the PEPPOL routing identifier), legal registration ID and TRN.
• Lines — one line per item or service, each with description, quantity, unit code, unit price, line net amount, tax category, tax rate, classification codes and optional allowance/charge elements.
• Totals and tax breakdown — sum of line amounts, allowance total, charge total, tax-exclusive amount, tax totals by category, tax-inclusive amount, prepayments, rounding adjustment, payable amount.

Every field has a cardinality rule and a business rule attached. BR-CO-10 requires that the sum of line amounts equals the tax-exclusive amount. BR-S-08 requires a tax category code of S whenever the rate is greater than zero and the supply is standard-rated. Get one wrong and the ASP rejects the entire envelope.

Which fields are genuinely mandatory is the question every mapping project has to settle before it writes a line of code, and the honest answer is that the definitive list lives in the PINT-AE specification and the EN 16931 ruleset it inherits, not in any summary. What is safe to say is where UAE teams get caught. Four fields account for most first-pass rejections in the sandbox:

• Unit code on every line. Service lines in most ERPs carry no unit of measure at all. PINT-AE expects a code from UN/ECE Recommendation 20 — HUR for an hour of consulting, EA for each, MTK for square metres. Blank fails.
• Electronic address for both parties. Not the TRN dropped into a free-text field. For UAE businesses the routing identifier is the scheme code 0235: followed by the 10-digit TIN, which is the first ten digits of the TRN.
• Tax category code at line level. S, Z, E or AE on each line — not inferred from which output-VAT GL account the credit happens to post to.
• Document type code in the header. Invoices, credit notes and prepayment invoices carry different codes, and an ERP that models a credit note as a negative invoice fails here every time.

Put those four through the sandbox before you run the wider UAT script. They are cheap to fix in the mapping table and expensive to find in week one of live — and with ASP appointment due by 30 October 2026 for businesses at or above AED 50M revenue, the schedule has no room for a late discovery.

The mapping table that does the work

This is the artefact your team needs to build, version and maintain. Below is a worked chart of accounts sample for a typical UAE professional services SME, showing how each GL account maps across to its PINT-AE fields on a mid-market ERP.

A few things to notice. The mapping is many-to-one in some places (multiple GL accounts for the same product family map to one UNSPSC classification) and one-to-many in others (a single GL account may need different tax categories depending on the customer’s location or the supply context). This is why the mapping cannot be a flat lookup. It has to be a small rule engine, even if all that means in practice is a few nested CASE statements in a SQL view. Nothing exotic — just logic, not a spreadsheet.

The accounts that fall outside the mandate entirely

Before you map an account, check whether it needs mapping at all. Article 4 of Ministerial Decision 243 of 2025 sets out the excluded transactions, and chapter 7 of the UAE Electronic Invoicing Guidelines expands on them. Tag these accounts in the ERP so the extract never picks them up, rather than filtering them downstream at the ASP.

Two accounts get mis-tagged constantly on this list. The airway-bill exclusion is temporary, so an airline or freight business in the UAE that hard-codes it as permanent will be non-compliant on a date nobody diarised. And the financial-services line is drawn by VAT treatment, not by business type — an exempt UAE financial service is out, a standard-rated one is in.

There is also a scope point that catches holding structures. The Guidelines confirm at section 6.3.1 that an investment holding company recharging management or operational costs to third parties or related parties is carrying out business transactions, so it must register for e-invoicing and issue electronic invoices on the phased timeline — passive income alone does not keep it out. Section 6.3.3 adds that a person without a place of residence in the UAE, where obliged to issue tax invoices under the VAT Decree-Law, must issue those as electronic invoices too.

What each ERP handles, and what needs middleware

The PINT-AE generation responsibility splits between the ERP and the ASP middleware. Most ERPs export a structured payload (JSON, XML or CSV) and the ASP translates. A few attempt native PINT-AE generation. Here is what to expect from the platforms most common in the UAE SME and mid-market.

SAP S/4HANA. Native eDocument framework with a UAE country version. Generates a structured payload that hands off to the ASP via SAP Cloud Integration. Mapping is configured in EDOC_COCKPIT plus customising tables EDOMAPPING and EDOTAXCAT. Strong for multi-entity groups; expensive for SMEs.

Oracle Fusion Cloud ERP. UAE localisation pack includes a PINT-AE schema mapper. Field-level mapping under Setup and Maintenance > Manage Tax Reporting Configuration. ASP integration via Oracle Integration Cloud or a third-party connector.

NetSuite. Relies on a SuiteApp from your service provider for the PEPPOL handoff, with the SuiteTax engine carrying the UAE tax category logic. Fastest path for mid-market UAE businesses already on NetSuite. Check the provider you intend to use against the Ministry of Finance list of Accredited Service Providers before you scope the build, because only an accredited provider can transmit for you under Ministerial Decision 243 of 2025.

Tally Prime. The most common ERP in the UAE SME market. Tally’s extension exports JSON to the ASP, which translates to PINT-AE. Mapping happens at the ledger group and stock item level — clean ledger discipline pays off here.

Zoho Books. The UAE edition works through partnered service providers for the PEPPOL handoff. Largely automatic for standard UAE transactions; the awkward cases — intra-group inside a UAE VAT group, supplies in or from a UAE designated zone, reverse charge on imported services — need manual review per invoice during the first few weeks. Confirm the current integration status with the vendor rather than from a comparison article, because UAE support across all these platforms is still being built out ahead of the 2027 dates.

QuickBooks Online. UAE PINT-AE support runs through a service provider integration rather than natively. Mapping is at the item and customer level; the QuickBooks chart of accounts is intentionally shallow, which simplifies the mapping table but constrains management reporting depth for a UAE group running multiple licences.

Odoo. The account_edi module supports PEPPOL natively, and the UAE localisation module adds PINT-AE-specific fields. Configured via fiscal positions and product tax templates. Strong for businesses wanting control without SAP pricing.

Wafeq. UAE-native cloud accounting platform with PINT-AE generation built into the core. Default for very small businesses (<20 invoices per month) where dedicated middleware is overkill — Wafeq partners with an ASP at the back end and routes transparently.

“

The PINT-AE envelope does not care about your management reporting. The ASP does not care about your cost centres. The trick is to keep both intact while you translate.

The three data tables that break first

Mapping the GL is the visible work. The invisible work is master data cleanup, and three tables cause most of the trouble on a UAE implementation.

The item master comes first, because every line in a PINT-AE invoice references an item. The ASP validates that the item has a name, a description, a unit code (from UN/ECE Recommendation 20 — EA for each, HUR for hour, MTK for square metre), and ideally a classification code. Most ERPs happily accept blank item codes for service lines, which the ASP will then reject, so audit the item master before you map the GL and create a default fallback item for ad hoc charges.

The customer master is next. PINT-AE requires every customer to carry a legal name, a postal address with country code, an electronic address (the PEPPOL identifier — for UAE businesses, the scheme code 0235: followed by the 10-digit TIN, which is the first ten digits of the TRN), and a TRN where they’re VAT-registered. The characteristic UAE failure is a Bill To address pointing at the operating site of a subsidiary — a Dubai branch office, an Abu Dhabi project site — rather than the legal address of the contracting entity on its trade licence. Reconcile the customer master against the FTA’s TRN verification portal before integration testing, and reconcile the legal name against the licence at the same time, because the FTA cross-checks names the same way it does at VAT registration.

The TRN master is the awkward one, because in most ERPs it isn’t a single table at all — it’s a field on the customer record and another on your own company record. Run as a UAE VAT group and you also have to manage the representative member’s TRN alongside the member-level TRNs, which is exactly the population the intra-group grace period touches. The service provider needs to know which TRN to assert in which field, and getting it wrong means your UAE customer cannot recover input VAT on the invoice — a commercial problem long before it becomes an FTA problem.

Common e-invoicing ERP mapping mistakes UAE teams make

Most e-invoicing ERP mapping projects in the UAE fail in the same handful of places, and every one of them is avoidable. The first is hardcoding a tax rate against a GL account instead of tagging the tax category at the line. A single output-VAT account carries standard-rated, zero-rated and exempt supplies; bake 5% into the account and the zero-rated export lines break at validation.

The second is keeping the mapping in a spreadsheet that one person maintains. When a new revenue account appears and nobody updates the sheet, invoices for that product line fail quietly. A versioned mapping table with a named owner removes that whole class of failure.

The third is testing only the happy path. Standard-rated invoices pass easily; the rejections come from credit notes, prepayments, reverse charge on imported services and multi-rate invoices. If those are not in the sandbox script, they surface in week one of go-live instead.

The fourth is the PEPPOL electronic address. Teams reuse the TRN as free text rather than the prescribed identifier format, and the routing fails. Reconcile the customer master and the identifier scheme before integration testing — the same discipline our UAE tax invoice format guide applies to the invoice face itself.

Will this expose our management reporting?

A common worry from finance directors is that mapping the CoA to PINT-AE will expose internal management reporting to customers, the FTA or competitors. It will not. The envelope is intentionally narrow.

Here is what stays inside your ERP and never leaves:

• Cost centres
• Profit centres
• Departments
• Projects
• Product hierarchies beyond the line item
• Account groups beyond the GL leaf
• Internal account names (the GL name does not appear in the envelope — only the line description does)

Here is what does leave, in the envelope:

• The line description (which you control)
• The item classification code (which you choose from a public catalogue)
• The tax category and rate
• The line net amount and the totals

The mapping table is a one-way translation. Internal richness stays internal; only externally-relevant attributes cross the boundary. This is one of the few good engineering properties of PEPPOL — it forces a clean separation between “what we tell ourselves” and “what we tell counterparties and regulators”.

The practical implication: do not flatten your CoA to fit the envelope. Keep your cost centres, profit centres and management reports unchanged. Build the translation in the ASP middleware or a thin ERP add-on, and version it like any other piece of compliance code. The same separation of concerns applies to our VAT services in Dubai and corporate tax advisory engagements.

Sandbox testing before you go live

Every ASP provides a sandbox that mirrors the production PEPPOL Access Point but routes to a mock FTA endpoint. Use it. The discipline that separates smooth go-lives from messy ones is the willingness to run a representative volume of invoice types through the sandbox over a sustained period, not a token handful in the final week.

A practical UAT script covers at least these scenarios:

• A standard-rated B2B invoice to a mainland customer
• A standard-rated B2B invoice to a free zone (non-designated) customer
• A zero-rated export of services to a customer outside the GCC
• A reverse-charge invoice for imported services
• An invoice with multiple lines at different tax rates
• An invoice with a line-level discount expressed as an AllowanceCharge
• An invoice with a line-level charge (freight, insurance) expressed as an AllowanceCharge
• A credit note referencing a previously transmitted invoice
• A prepayment invoice and the subsequent final invoice that consumes it
• An intra-group invoice inside a UAE VAT group (in scope; transmission deferred by the grace period from 1 January 2027)

For each scenario, validate three things: the ASP accepts the payload, the PINT-AE XML produced by the ASP is structurally valid, and the totals in the XML reconcile to your ERP. Any mismatch is a mapping bug, not an ASP bug.

After UAT, run a one-week parallel period where every live invoice is also transmitted to the sandbox in shadow mode. Reconcile both outputs daily. If the parallel period is clean for seven consecutive days, you are ready to cut over. If not, extend until it is.

For deeper guidance on what the final invoice itself must contain on its face, see our companion piece on the UAE tax invoice format. Two mapping cases deserve their own read: getting the zero-rated export invoice fields right under PINT-AE, and tagging line items for a bilingual Arabic and English tax invoice.

Who owns e-invoicing ERP mapping in a UAE finance team

E-invoicing ERP mapping in the UAE sits awkwardly between finance and IT, and unclear ownership is why projects stall. The cleanest split gives each side the part it understands. Finance owns the meaning: which supplies are standard-rated, zero-rated, exempt or reverse charge, which GL accounts feed which invoice lines, and how allowances and charges should be classified. That is tax knowledge, and it should not be handed to a systems integrator who has never read your VAT returns.

IT owns the plumbing: the export format from the ERP, the payload the Accredited Service Provider expects, connectivity, retries and archiving. The ASP owns transmission across the PEPPOL network and validation against PINT-AE rules. Nobody owns the boundary unless you name someone, and the boundary is exactly where mapping bugs live.

The workable pattern in an SME is a single named owner for the mapping table — usually someone in finance who is comfortable reading a rejection code — with IT and the ASP as standing support. Keep the decisions advisory and documented, so that when the spec updates you change one artefact rather than re-arguing the whole design. Ownership is not a formality here; it is what keeps the readiness programme on schedule.

The 12-week sprint, week by week

This timeline assumes an SME with a single operating entity, one ERP, around 200 active customers and 500 active SKUs. Multi-entity groups, businesses on legacy ERPs, or businesses that need to migrate ERP as part of the project should plan 16-24 weeks.

For businesses with revenue at or above AED 50M, the absolute latest start date for this sprint is mid-July 2026 to hit the 30 October 2026 ASP appointment deadline with margin. Smaller VAT-registered businesses can start later, but the same constraint — sandbox time cannot be compressed — applies. For end-to-end help with the readiness programme, see our e-invoicing setup advisory page.

If you do one thing right on this programme, keep the GL-to-PINT-AE mapping in a versioned, code-reviewed artefact rather than in someone’s spreadsheet. Treat it like a piece of compliance code, with pull requests, a change log and a named owner. When PINT-AE v1.1 lands and a new field becomes mandatory, you’ll be glad you did.

Underneath all of it, the mandate is really a forcing function for data discipline finance teams have been putting off for years. CoA cleanup, master data reconciliation, pulling management reporting apart from compliance reporting — it’s overdue work that happens to double as the path to a clean go-live. Do it well and the finance function comes out tighter; do it in a rush and you come out with rejected invoices and stalled receivables. The whole difference, honestly, is starting early and treating engineering work as engineering work rather than a tax problem in disguise.

For our broader view of the UAE rollout, including the 5-corner DCTCE model, ASP selection and penalty exposure under Cabinet Decision 106 of 2025, see the UAE e-invoicing 2026 guide.