VAT policy is client-specific: how firms keep treatment consistent
VAT treatment is rarely just about what is on the invoice. More often, it is about who the invoice is for.
The same-looking invoice can lead to different treatment depending on the client’s VAT position. A business that can reclaim input VAT is not the same as one that cannot. Partially exempt businesses have their own nuance. Reverse charge gets missed. Blocked VAT exists on the invoice but still becomes a cost.
Once a firm scales beyond a handful of clients, the real question is not whether people understand VAT. It is where that client-specific logic lives so it gets applied consistently.
What usually happens in practice
A lot of the nuance ends up living in memory, checklists, client notes, reviewer habit, and ERP conventions. None of those are wrong. They are just fragile when work moves between people or when the same edge case shows up months later under pressure.
That is why VAT issues often feel repetitive rather than difficult. The logic is known, but it is not always carried forward cleanly.
Blocked VAT is a good example
Sometimes VAT is clearly charged on the invoice, but the client cannot reclaim it because of the kind of activity they do. In Xero there is not always a perfectly neat way to represent that without using a convention. So firms create one. A label that looks right to the reviewer, but is configured in a way that fits the reporting and posting constraints of the software.
That is not bad practice. It is accounting meeting software constraints. The important thing is that the underlying logic stays correct and the convention is applied consistently.
What consistency actually requires
The client’s VAT policy needs to become part of the operating context, not something rediscovered every time. Once that policy is built up and carried forward, the edge cases stop depending on memory and start becoming repeatable.
That means keeping the source of truth clean, recognising when VAT was charged, recognising whether it is reclaimable for that business, and then exporting the draft into the ERP in a way that matches the firm’s own conventions.
The aim is not to force a new workflow
The last thing firms need is a system that tells them their current conventions are wrong. The better approach is to understand the accounting logic first, then fit the output to the way the firm already reviews and reports.
That is how you get consistency without adding friction.