Connecting your accounting system
You do not write any code for this. You connect the accounting system you already use, and the platform reads each invoice out of it, converts it to the UAE PINT-AE format and files it. What that costs you is data entry inside your own ERP — mostly on the customer records, once each — and a few habits on the invoices themselves. This section is that list.
The connection flow, start to finish
- 1The entity exists. The entity is your own company: its TRN, trade licence, address and emirate, and what identifies you as the seller on every invoice you file. In production you do not create it — your FTA onboarding creates your account and your entity for you, and you sign in to find the company already there. Creating an account and an entity by hand happens on the development server only, for testing. Set up your account →
- 2Connect the ERP to that entity. Authorise the accounting system you already invoice from — QuickBooks, Xero, Zoho Books, Odoo, Wafeq or Naqood. The connection belongs to the entity, so a second company means a second connection. Connect your system →
- 3Complete the PINT Mapping. Once the ERP is connected, the mapping has to be completed before invoices can be filed. Open PINT Mapping and use Pre-fill defaults at the top to populate the standard mapping for your system in one click. PINT Mapping →
- 4Review every mapped field. Pre-filling is a starting point, not an answer. Go through the fields and confirm each one reads from the right place in your data. Any field your system does not hold can be marked as provided at invoice level instead. Reviewing the mapping →
- 5Fix the customer records inside the ERP. This is the step that catches people out. The platform reads your buyers from the ERP, so the buyer's tax number and address have to exist THERE — not in TaxStar. Each ERP keeps them in a different field, and QuickBooks has none by default, so one has to be created. This is per customer, and it is a one-time job per customer. ERP prerequisites →
- 6Raise invoices as you always have. Nothing changes in your own process. Each invoice you raise is read out of the ERP on its own and checked against the UAE PINT-AE rules. Invoice rules →
- 7Fill in anything left to invoice level, then submit. An invoice needing a field you marked as provided at invoice level arrives in Staged Invoices and waits there. Supply the value, submit the invoice, and it rejoins the flow. Where the entity requires approval, it then waits for an Approver. Staged invoices and approval →
- 8It is sent to the Peppol network. Converted to the UAE XML format and filed. Sent is the milestone that counts for compliance; delivery to the buyer is tracked separately. Invoice status reference →
Steps 2 to 8 are the same wherever you are. Only step 1 differs between environments: in production the account and entity are created by your FTA onboarding, while on the development server you create both by hand to test with. The ERP connection, the mapping, staged invoices, approval and the journey to the network behave identically in both.
Where each ERP keeps the buyer's tax number
Every connected system stores it somewhere different, and the platform reads only the field that system publishes. The short version, with the full setup on the next page:
| System | Where the TRN lives |
|---|---|
| QuickBooks | A custom field on the customer holds the TRN — it does not exist until you create it. |
| Xero | Contact → Tax Number, plus a street address on the contact. |
| Zoho Books | Customer → Tax Registration Number, plus a billing address. |
| Odoo | Contact → Tax ID, plus street, city, state and country. |
| Wafeq | Contact → Tax Registration Number, plus address, city and country. |
| Naqood | Contact → Tax Number, plus a street address. |
None of these is a TaxStar field. They are fields in your own system, and filling them in correctly there is what makes an invoice fileable.
What the platform does not do for you
It does not invent a buyer's tax number. A missing TRN is a rejected invoice, not a guessed one, because the invoice would otherwise be filed against an unidentified party.
It does not renumber your invoices. The number you raised in the ERP is the number that is filed, so duplicates are your ledger's problem before they are ours.
It does not change your amounts. Totals, tax and currency are carried across as they are. Where the FTA needs the same figures in dirhams, the AED side is added alongside yours rather than replacing it.
What is in this section
Read it in order the first time; after that it is a reference.
| Set up your account | Where your account and entity come from: automatic in production, by hand on the dev server. |
| Users and roles | Admin, Editor and Approver, and how invitations work. |
| Connect your system | One connection per entity, and what changes once it is live. |
| ERP prerequisites | The per-customer setup inside each accounting system. |
| Tax Codes | Your own tax rates, mapped to UAE categories. |
| PINT Mapping | Which field in your data fills each field on the invoice. |
| Sending invoices | Staging, approval, and how far an invoice has got. |
| Receiving invoices | Supplier invoices arriving, and reconciliation. |
| Invoice rules | What every invoice must satisfy, every time. |
| When an invoice fails | The common rejections and where each is fixed. |
If you would rather push invoices yourself
The OAuth API is the other way in: your own system calls ours directly, with no ERP connection. It is documented in the two OAuth sections of this site, starting at the OAuth API introduction. The tax rules on this page apply there too — only the delivery method differs.