As you’ve probably noticed by now, we have been building PSA.I, an AI tool for the data side of the PAYE Settlement Agreement process, for a while. Over roughly the same period I completed two Imperial College Business School programmes, the Emerging CTO Programme and Agentic AI in business, and used employment tax as the worked example throughout both, which the other participants bore with good grace (and I gracefully bored them!).

Between the two there has been a fair amount of trial and error, and this article sets out what we have learned so far: where AI is already useful in tax work, where it is not yet ready, and what we would say to anyone thinking of building or buying something similar.

Where AI is already useful

Preparing a PSA is, for the most part, a classification exercise across thousands of rows of expense and benefit data. The category the claimant chose at the point of claim is the field that looks like the answer, and anyone who has reviewed a PSA knows not to rely on it. Expenses are a chore, and I’m just as guilty as anyone of choosing a ‘close enough’ category from the drop-down with little regard for the tax implications of my choice.

AI reads the narrative, the supplier, the amount and the category together and applies the same reasoning to the last row as it did to the first. It never gets distracted, never misses a line, and never makes assumptions across a chunk of similar-looking data. The speed is the obvious benefit. The more valuable one, in our experience, is consistency, since the same facts receiving the same treatment across the whole population is what a defensible position looks like when HMRC asks, and HMRC does ask.

The second thing it does well is explain itself. Each row comes back with a treatment, a category and a short rationale that names the rule or exemption relied upon. In most PSA working papers we have seen, the reasoning behind a decision existed only in the head of whoever made it, who has frequently since left. Having it written down makes review a good deal quicker. It is far easier for a reviewer to disagree with a sentence than with an empty cell.

It should also be noted that AI is reasonably good at knowing when it is unsure, which is more than can be said for some of the expense claims. Each classification carries a confidence score and, when we have compared those scores with what reviewers subsequently changed, the changes sit mostly in the lower bands. In practice that score has become the way the review queue is built, with the threshold set by the firm according to how much review effort it is prepared to spend against the residual risk it is willing to accept.

Finally, there is drafting. On the Imperial AI programme I put the same brief, a travel and expenses policy review for a mid-sized employer, through three general-purpose AI assistants. All three produced a first draft I could have worked from. I would not say drafting is solved. More that the time is now spent checking rather than writing, and the checking still matters.

Where it is not yet ready

The biggest limitation is not the AI but the data. The £150 annual function exemption depends on the cost per head, VAT and ancillary costs included, and on whether the event was open to all employees at a location. Long service awards depend on years of service. The line between staff entertaining and client entertaining depends on who was in the room. Expense data rarely records that information perfectly. What it records is “Dinner x 6”, a supplier and an amount, and the AI, like the reviewer before it, is left to infer who the six were. A model that guesses confidently in those circumstances is worse than one that stops.

Arithmetic is a related point. Per-head tests, gross-up and the allocation of items across tax bands are deterministic, and best kept in code rather than left to the model, on the basis that a calculator has never once been creative with a sum. The same applies to anything “agentic”, where the model loops, retries and corrects itself. That adds cost and variability to an output that ends up in front of HMRC, and we see no case for it in the classification itself. The model reasons about each row once and the calculation is conventional software. Agents have their place in the process, data mapping for example, but classification doesn’t benefit from a moving picture.

Measuring how accurate the AI is turns out to be a tax exercise in its own right. To score a classifier you need an answer key, and in employment tax the answer key is open to argument. When we test against adviser-labelled data, a proportion of the disagreements are the key’s rather than the engine’s. An accuracy figure in this area is sometimes as much a statement about the labels as about the model.

What building PSA.I has taught us

Three things stand out.

The first is that the input has to be normalised before anything can be reasoned about. Every client’s expense types conflict with every other client’s. “Travel – Other” means a taxi at one employer, a hotel at the second and, at the third, whatever the claimant could not find a better category for, which in one case was a golf day. Translating the source labels into a common vocabulary, and keeping that translation visible, is what allows a decision to be traced from the source row through to the HMRC category.

The second is that the rules are easy to state and hard to apply. Everyone in employment tax knows the £150 rule. It is also misapplied all the time, because it is per head rather than per event, inclusive of VAT, lost in full rather than in part when exceeded, and subject to an eligibility condition that is checked less often than it should be. A Christmas party at £155 a head does not exempt £150 and put £5 on the PSA. The whole £155 is taxable, and the hotel rooms the finance director booked for the overnight guests are part of the £155. Poor data makes that worse, but there are ’tells’: dates, narratives and vendors all help to build a picture of the spend.

The third is that the reviewer’s decisions are the most valuable thing in the process. A call on a borderline row, captured, kept with that client and applied again next year, turns a one-off review into a standing policy, rather than an argument that is re-run each July by whoever is left. We keep those decisions separate for each client. Whether they could ever be pooled is a confidentiality question before it is a modelling one, and we have not taken that step.

What the Imperial programmes added

Three ideas from the programmes have held up in practice. The first is augmentation rather than substitution. The tool reinforces the specialist’s judgement and expands their capacity, it does not replace them. Great news for us humans! It also happens to be true, which helps.

The second is that ethics scales with autonomy. The lighter the human check, the heavier the controls upstream need to be, so safeguards are designed into the first supervised phase rather than added once automation has expanded.

The third came from the Watson for Oncology case study, which is that agreement with the expert is a weak measure of value. What matters is the time taken to reach a defensible decision and what the review catches. Agreeing with the expert is, after all, something the expert can already do.

Where this leaves the work

AI has moved the PSA from classifying rows to adjudicating exceptions and setting policy. The reviewer still owns the position and HMRC still writes to the employer, not the model. What has changed is that the reasoning is written down, the judgement is remembered, and the next cycle starts from the last one rather than from a blank spreadsheet and a vague sense of dread.

If you are weighing up AI for PSA work, whether building, buying or simply testing, we would be happy to compare notes.