An Input Tax Amount With No Rate Cannot Answer the Question

Here is a question that sounds trivial and is not: when your system records a purchase with tax on it, what exactly does it remember?

Almost every system remembers the amount. Rather fewer remember the rate that produced the amount. Fewer still remember which kind of tax it was, or whether the figure recorded was inclusive or exclusive of it. Each of those omissions looks harmless at the point of entry, because the amount is the thing that has to reconcile to the supplier's invoice and it does. The cost arrives later, in a different room, when somebody has to decide what is recoverable.

We are going to be specific about our own product in this post, including where it comes out badly, because a general essay about data modelling would be the cowardly version of the same argument. Nothing here is tax advice, and what is recoverable in your business is a determination for your accountant.

What a recovery decision actually requires

To decide whether tax on a purchase can be reclaimed, and to defend that decision later, you need to know several things about it. An amount is one of them and it is the least discriminating one.

An amount with no rate beside it is worse than no amount at all, because an empty field prompts a question and a populated one does not.

That last line is the whole argument and it is counter-intuitive, so it is worth slowing down on. If a system holds nothing about purchase tax, everybody knows the return has to be built elsewhere. Nobody is misled. If a system holds an amount, the field is populated, the report has a column, the column has a total, and the total looks like an answer. It is the appearance of completeness that does the damage.

Where we are, stated plainly

Our sales side is genuinely good at this. Every invoice line, every point-of-sale line and every quotation carries its own tax rate, which is why the output figures on a return are questions our records can answer directly and without anybody transcribing anything.

Our purchase side is not. A purchase order carries no tax at all — no rate, no amount, no flag. An expense carries an amount and nothing beside it to say what rate produced it or what kind of tax it was. So the honest summary of our position is that we can tell you exactly how much tax you were charged on expenses and we cannot tell you whether you can reclaim it.

Three markets, three different dates on which this bites

This is not a UK problem that happens to appear elsewhere. It is one gap whose consequence changes completely depending on how a country's tax works, which is why it took several markets to see it properly.

1. In the United Kingdom it bites now, because the return is a form with a box for it

   Input tax reclaimed is one of nine boxes, the return is filed from software, and the chain from record to figure is required to be digital. A box our records cannot produce is a box somebody types — which is precisely the step the rule was written to remove. The gap is not merely inconvenient there; it is the wrong shape for the regime.

2. In Trinidad and Tobago it has been biting for years, because the return is a claim

   Broad zero-rating puts a large share of registered businesses in a standing credit position, where the return is not a payment computed from sales but a claim computed from purchases. When input tax is the whole return, a system that holds no input tax holds no return.

3. In Liberia it is correct today and becomes wrong on a known date

   A single-stage tax with no right of deduction really is part of what goods cost, so recording it inside the cost is the right answer rather than a gap. That stops being true when the mechanism changes to a credit-invoice tax, at which point the same absence becomes a defect. The unusual thing about this market is that we can see the day our answer expires.

Read together, those three say something that neither says alone: whether purchase-side tax is a gap or a correct simplification depends entirely on whether the tax has a right of deduction. That is not a feature question. It is a question about the mechanism, and it is why we now describe a tax by its mechanism rather than by its local name.

What the fix is, and the order it has to happen in

Three pieces, and the sequence is not negotiable, because each one is theatre without the one before it.

1. Hold the rate and the kind of tax at the moment the purchase is recorded

   Not derived later from a total, not looked up from the supplier, not inferred from the category. Recorded, on the purchase, at entry, alongside whether the value captured was inclusive or exclusive. This is the piece without which nothing else means anything.

2. Assemble the return from those records rather than from a summary

   Once the facts are on the transactions, a return is a query. Before that, a return is an opinion, and opinions do not survive being asked where they came from.

3. Only then transmit it

   Transmission is the easiest of the three and the one vendors build first, because it is the one that demos. A filing button over figures nobody can trace is the worst of the available outcomes: it industrialises the transcription instead of removing it.

What to ask, whoever you are buying from