Lesson 6 — Inbound bills, and who holds the keys
The mandate makes you a recipient as well as an issuer, which is where the last two operational decisions in this module live: what the system does with a supplier's document, and who is allowed to hold the credentials it travels under. Both are answered the same way, and it is the answer from Lesson 1.
When the inbound scheduled action (or the optional webhook) receives a document, the module creates a draft vendor bill from the XML. It is never auto-posted. You review it and post it as usual, exactly as you would a bill that arrived by email.
That restraint is not timidity, and it is worth being able to defend it in a meeting where someone proposes to "save time by auto-posting". A supplier's e-invoice is their assertion, not your agreement. Posting is the agreement — that the goods arrived, the quantities match your receipt, the price matches what was agreed, the tax treatment is right, and the coding is the coding you want in your accounts. Posting also creates a payable and moves input VAT into a return. A cron cannot check any of that. And the asymmetry from Lesson 1 applies again exactly: a draft bill nobody reviewed costs you a few minutes tomorrow, while a posted bill nobody reviewed costs you a reversal, an audit trail explaining it, and possibly a payment. There is also the duplicate case, which is common and mundane: a supplier resends a document, a person recognises it as one they have seen, a scheduled action does not.
The click path. A manager enables UAE E-Invoice: Fetch inbound documents under Settings → Technical → Scheduled Actions. The bills then appear as drafts under Accounting → Vendors → Bills, and the document they came from is in E-Invoice Documents with the Inbound filter, where View XML gives you the original the supplier actually sent.
A worked review. An inbound bill arrives from a supplier: net AED 12,000, VAT at 5% of AED 600, total AED 12,600. Check three things and you have done the job: the supplier's TRN against your contact record, the totals against your purchase order and goods receipt, and the tax treatment against what the supply actually was. Suppose the receipt supports only AED 11,000 net — one line was delivered short — so the bill you would accept is AED 11,550 including AED 550 of VAT. You do not edit the supplier's document to make it agree. Their XML is immutable on their side exactly as yours is on yours; you query the difference of AED 1,000 with them and let them issue a credit note, which arrives as its own inbound document. Symmetry is the point: what you cannot do to your own transmitted documents, you cannot do to theirs.
Now permissions, which are the other half of operating this safely. The module defines a UAE E-Invoicing privilege with two groups.
| Group | What it can do |
|---|---|
| User | Create, generate, validate, send and retry e-invoice documents, and read ASP accounts |
| Manager | Everything above, plus manage ASP accounts, view and edit the secret credentials, delete documents, and Reset to Draft |
The ASP secret fields are visible to managers only — API key, secret, client id and webhook secret. The reasoning is the same one that runs through this course. Those credentials are the identity your business transmits under, and anything transmitted under them produces documents that are immutable and reported to the FTA as yours. Meanwhile nobody needs to see the secret to do the daily work: the User group can generate, validate, send and retry, and read the ASP account, which is everything the person running the morning check actually touches. Documents and ASP accounts are additionally scoped per company by record rules, so a shared database does not become a shared outbox.
The failure modes are recognisable on sight. The ASP Accounts or E-Invoice Documents menus are missing, or the credential fields are hidden — the user is not in the right group; an administrator grants UAE E-Invoicing → User, or Manager where the credentials and account management are genuinely needed. Nothing inbound ever arrives — the fetch action is still off, and only a manager can enable it. Decide now which named people hold Manager, put them in the runbook next to the scheduled actions they own, and keep the list short. The guide does not describe a credential-rotation procedure, so agree that with your provider and diarise it yourself.
The idea to carry forward: the module automates what is recoverable and refuses what is not. It will queue, retry, poll and fetch on your behalf; it will not post a supplier's bill, and it will not show a secret to someone who only needs to press Send.