Map the Fields Your ASP Will Test

The field map begins with legal identity

The Ministry of Finance document titled Mandatory Fields in a PINT AE Tax eInvoice lists 51 mandatory fields. The first useful question is not whether your spreadsheet has 51 columns. It is whether the seller and buyer fields point to the legal parties that actually made the transaction. A trading name, an internal customer code and an electronic address may all identify different things.

Map each party field to a source column and name the source owner. The seller name, seller electronic address, seller identifier, legal registration details and tax identifier should not be copied from a contact card without checking the legal-entity record. The buyer side needs the same discipline. A clean-looking name cannot repair a tax identifier that belongs to another company.

The PINT AE list is the authority for the required PINT AE field set, not an approval of your internal mapping. The Ministry document does not specify how a particular ERP column maps to the field or validate your transformation rule. That is the boundary. Your file must therefore show the source, the transformation and the person who accepted the result.

Electronic addresses need a decision behind them

An electronic address is not simply the email address used by a salesperson. The June 2026 UAE Electronic Invoicing Guidelines describe a Participant Identifier or End Point ID as a unique reference used to identify a Person or Government Entity on the Peppol network. Keep that exchange identifier separate from email, phone, internal account number and postal address.

Begin with the legal registration record, then reconcile the tax identifier and electronic address to the buyer or seller named on the document. If a customer has branches, billing agents or more than one system record, retain the matching reason. The surviving master record should be chosen by an accountable owner, not by whichever row was edited most recently.

You should be able to take one invoice number and walk back to the exact entity record that supplied its name, identifier and address. If that walk stops at a manually edited spreadsheet, mark the field as a gap. Do not fill it with a default simply because the provider demo accepted a sample value.

• Legal name and registration record
• Tax identifier and identifier type
• Electronic address and endpoint owner
• Source column and transformation rule

Tax codes must follow the supply

The PINT AE field list separates item name, item description, quantity, unit of measure, price, tax category, tax rate, VAT line amount and invoice line amount. A product code is not a tax conclusion. The item master should point to the tax treatment approved for the actual supply, while the invoice record preserves the line values used on that document.

Give every tax mapping an owner and an evidence note. The VAT decision may depend on the service, customer, delivery or another fact that is not contained in the item name. Where a rule has an exception, put the exception beside the mapping. An ASP can map fields technically, but the business still has to own the tax treatment that enters the source data.

Totals deserve the same trail. The document total without tax, total tax, total with tax and amount due should be produced from defined source values. If a payment, discount, surcharge or credit note changes the document, the field map should show where that adjustment enters and which preceding document it references.

Test one document from source to exchange

Choose a representative invoice, not the easiest invoice in the folder. Include the seller, buyer, line, tax, payment and reference fields that the live process uses. Capture the source row, the transformed record and the provider response. That three-part evidence lets finance see the tax values while the systems owner sees the data movement.

Use the same anonymised test record with each shortlisted ASP. Ask each provider to identify missing fields, rejected values, transformations and error messages. Record which answer is a product rule, which is a source-data issue and which requires a tax decision. The comparison is useful only when the providers receive the same input.

Start with the invoice stream that carries the most exceptions, not the one selected for a presentation. A clean sample can hide duplicate customers, old tax codes and manual totals. The difficult record tells you more about the work remaining because it forces the owner to explain each missing field before an ASP turns it into a technical error.

• Select one representative live invoice
• Preserve source and transformed values
• Record the provider response and error
• Assign each gap to an owner

Let the arithmetic expose a bad mapping

The Ministry of Finance June 2026 guidelines include a human-readable sample Electronic Tax Invoice. It shows 2,000 pieces at AED 5 each. The line calculation is 2,000 x AED 5 = AED 10,000. The sample shows AED 500 VAT, producing AED 10,500 including VAT. After an AED 1,000 paid amount, the payable amount is AED 9,500.

That example gives a field owner a short reconciliation test. Quantity and unit price should produce AED 10,000. The tax breakdown should explain AED 500. The gross total should equal AED 10,000 + AED 500, and the amount due should equal AED 10,500 - AED 1,000. If a source system produces another result, the issue is visible before an ASP is asked to hide it in a transformation.

We recommend starting with this arithmetic check before a long field-by-field workshop, because it tests whether the source columns agree with one another. The official field list tells you what must be present. The worked document tells you whether your values can live together without a silent mismatch.