I Screened 11 Developers for a UAE E-Invoicing Rollout: the 7 Steps That Left 2 Standing

The requisition I was handed said senior integration developer, five years, XML, ERP experience, UAE market knowledge preferred. Eleven candidates cleared that bar on paper. Two of them could look at a credit note that referenced an earlier invoice and tell me, without hedging, which fields had to carry the reference and what the receiving side would do if they did not. The gap between those two numbers is what this piece is about, and the reason for it is that the advert described a technology stack when the job is really about a prescribed data model and a pipeline that is not allowed to fail quietly.

One framing note before the steps. Guidance published by tax advisers describes the UAE model as a Peppol-based five-corner architecture: the supplier and the buyer each connect through a service provider accredited by the Ministry of Finance, and the invoice travels between those providers as structured XML conforming to the PINT AE schema. The Federal Tax Authority issued technical guidance on 23 February 2026 that, as KPMG summarised, sets 51 mandatory fields for electronic tax invoices along with the semantic model, code lists and XML structure. This article is a hiring method, not tax advice: confirm your own obligations and the current phase dates with the Ministry of Finance or your adviser.

Step 1: Write Down Four Numbers Before the Advert

Monthly invoice volume. The number of systems in your business that issue an invoice. The exact ERP version, including the hosting model. The share of your transactions that fall in scope. That is the whole scoping exercise, and it takes an afternoon with your finance lead.

It matters because those four numbers decide whether this is one hire or three. Two thousand invoices a month from a single reasonably current ERP needs one competent integration engineer for a quarter. Invoices issued from an ERP, a billing platform, a property management system and a spreadsheet that somebody in operations maintains needs an engineer plus a data owner plus a decision about retiring the spreadsheet, and pretending otherwise is how a three-month project becomes a nine-month one.

Step 2: Decide Which of Three Jobs You Are Buying

Nearly every requisition I see for this work describes three different people. An integration engineer builds and operates the connection: payload construction, provider interface, retries, monitoring. An ERP functional consultant knows where the master data lives in your specific system and what a configuration change breaks three modules away. A data engineer fixes the counterparty records, the tax identifiers and the product codes that will not validate.

Candidates are usually strong at one and conversant in a second. Advertise for all three and you get applicants who claim all three, which is the least useful possible signal. Decide which one you cannot borrow: if you already run SAP or Dynamics 365 with an internal functional team, hire the integration engineer. If your ERP is supported by a vendor on a retainer and nobody internal can change it, the functional gap is the one that will stall you, and no amount of integration talent closes it.

Step 3: Screen the Semantic Model, Not the XML

XML is not the hard part and it has not been the hard part since about 2012. The hard part is deciding which of your fields answers each of the fields the schema demands, and the only way to test that is with your own data.

Send three cases ahead of the call, redacted, taken from real documents. A credit note that refers to an earlier invoice. An invoice to a counterparty whose registration details you hold inconsistently across two systems. A line item with a discount applied at document level rather than line level. Ask the candidate to walk through how each one becomes a compliant payload and, more importantly, what they would ask your finance team before deciding.

Strong candidates ask questions. They want to know whether the discount is commercially a price adjustment or a rebate, because that changes which field carries it, and they want to know which system holds the authoritative counterparty identifier. Weak candidates start describing schema syntax. Notice also who mentions the identifier scheme and the distinction between a tax registration number and the tax identification number derived from it; the detail is published, and knowing it is a reasonable proxy for having read the guidance rather than a vendor brochure.

Step 4: Ask the Rejection Question

This is the single most useful question I have found for this role. It is twenty words long.

The provider returns a validation failure at 23:50 on the last day of the month. What happens next?

Listen for five things, in roughly this order of importance. Does the send retry, and is it idempotent, so a retry cannot produce a duplicate document on the counterparty side. Where does a permanently failing document go, and does a human find out the same night rather than at the next close. Is there a daily reconciliation between documents issued in your ledger and documents accepted by the provider, because without it a gap is invisible until somebody chases a payment. What is the manual fallback, and who is allowed to use it. And is there an audit trail that survives the fix.

Candidates who have operated a filing-critical pipeline answer this in paragraphs, usually with an anecdote. Candidates who have built one and handed it over answer the first two points and stop. Candidates who have done neither talk about error logging. All three can be the right hire for different jobs, but only the first one should own your pipeline after the integrator leaves.

Step 5: Test the ERP Reality, Not the ERP Experience

Three questions, answered by you rather than the candidate, and answered honestly before anyone starts. Who in your organisation is allowed to change the ERP, and how long does an approval take. Does a tested connector exist for your exact version, or is middleware required. Is there a sandbox with realistic data, and if not, who creates one.

I have watched a capable engineer lose six weeks waiting for a sandbox nobody had been asked to provide, and the post-mortem blamed the hire. It was a scoping failure, and a predictable one: the interview covers the candidate’s ERP experience and never covers your ERP’s change process, which is the actual constraint. If your ERP is frozen pending a vendor upgrade, the role changes shape, because you now need somebody comfortable building alongside the system rather than inside it. Our note on building a CRM system in the UAE covers the same trap on the master-data side.

Step 6: Run a Paid Payload Review, Not a Coding Test

A take-home coding exercise tests the thing this job is not about. Replace it with a paid review of three to four hours: hand over a real sample payload, a short extract of the schema requirements you are working to, and one deliberately broken field, and ask for written findings.

Pay for it, at a sensible rate, and say so in the invitation. You get three signals a conversation will not give you. Whether they find the deliberate break, and what else they find that you did not plant. How they write for a mixed audience, because a finance director will read their escalations for the next year. And whether their findings are ranked by impact or listed in the order they were discovered, which tells you what their first week of triage will look like.

Two of my eleven candidates produced a one-page document that led with the broken field, flagged two genuine ambiguities in my own sample, and asked four questions I should have anticipated. That output is worth more than any number of interview loops, and it cost less than a day of agency fees.

Step 7: Write Post Go-Live Ownership Into the Offer

Two sentences in the offer letter, and they are the two that get left out. The first names a dated deliverable tied to your phase: a validated end-to-end send from each issuing system by a specific date, with testing against real documents rather than samples. The second names who owns validation failures ninety days after go-live.

That second sentence is where these projects quietly fail. The integration partner’s statement of work ends at go-live. Finance cannot debug a payload. The engineer who built it has usually been reassigned to the next thing, because the pipeline is working and attention follows breakage. So the first serious rejection after the project closes arrives with no owner, and it arrives during a close, and somebody pastes an XML error into a group chat at ten at night. Naming the owner in writing costs nothing at offer stage and is close to unnegotiable afterwards.

What the Method Costs and What It Saves

Running all seven steps takes about three weeks from advert to offer, plus the paid reviews. Against a conventional loop you add the scoping afternoon, the three data cases and the paid review, and you remove a take-home coding exercise and an interview round that was mostly repetition. The two failure modes it is aimed at are a strong generalist who cannot operate a filing-critical pipeline, and a specialist who arrives into a scoping vacuum and spends six weeks discovering that nobody decided which system owns a counterparty record. The second is the more common and the more expensive, because it burns a good hire and then gets written up as a performance problem. If you are weighing a contract engagement instead, our SAP hiring sequence for Dubai covers the same decision for a neighbouring role.

FAQ: Hiring for a UAE E-Invoicing Rollout