The Month Your Input Tax Stops Being Simple
You win the export contract on a Tuesday. From that Tuesday your input tax has two characters, and your system probably records only one of them.
A business that sells entirely into one market has a simple tax character. Everything it buys relates to everything it sells, in the same way, and no interesting questions arise about which purchase supported which sale.
Then it wins an export contract. That is good news and it changes the shape of the accounting on the day it starts — because now some of what you sell is treated one way, some another, and the inputs behind them have to be capable of being told apart.
Nothing about the win is a problem. The problem is that the record was never designed to make the distinction, so the distinction ends up being made later, from totals, by somebody working backwards.
The distinction is a property of the lines
This is the whole technical point and it is easy to state. A document has one date, one customer and one reference. It does not have one character, once your business has two. A single invoice can carry lines that belong on different sides of the distinction, and a single purchase can support both.
A system that records tax treatment per document therefore loses the information at the moment of capture. Everything after that is reconstruction — and reconstruction from a total is not recovery, it is estimation dressed as arithmetic.
| Where it is recorded | What you can answer later |
|---|---|
| On the line, at capture | What the mix actually was, per period, per customer, per product |
| On the document | What the mix was for documents that happened to be uniform |
| On the customer | Nothing, once a customer buys both kinds |
| Nowhere — derived at period end | Whatever the person deriving it assumed, which is not a record |
Every method of splitting something requires knowing what you are splitting. The failure here is almost never the method — it is that the inputs to the method were never captured.
There is no apportionment method in this post, on purpose
There are several, they are not equivalent, the choice depends on your circumstances, and it belongs to your adviser. A software page working through one as an example would be giving tax advice with a number attached, and somebody would rely on it. What software can honestly claim is upstream of the method: whatever basis you and your adviser choose, it needs facts, and the facts have to have been recorded when they were true.
Four things that break in the first quarter
-
The price list
Built for one kind of sale. The first export quotation gets priced from a cost base that assumed the old character, and nobody notices because the margin still looks familiar.
-
Stock that supports both
The same item now goes to both kinds of customer. Its cost was calculated under one set of assumptions and it is being sold under two.
-
The periodic exercise
Somebody has to split things. They do it from summaries, because the detail does not carry the distinction, and next period they do it slightly differently because nothing recorded how they did it last time.
-
The evidence request
A question arrives about one contract, in one period. Answering it means proving which purchases sat behind which sales — the exact fact nobody recorded.
What a system can actually do
Narrow, and worth being precise about since the interesting part is the boundary.
A rate held on every sales line, at capture
Per line rather than per document, so a mixed invoice is recorded as mixed rather than resolved into whichever character dominated it.
Cost coded to project, customer and cost centre as it is entered
Which is what makes "which inputs supported which work" a filter rather than an argument. Coded at entry, not allocated at period end.
Documents held against the transaction
So a question about one contract in one period is answered by retrieval. An evidence request is the moment this either works or does not.
Reporting by period, project and cost centre
The same records queried whichever way the question arrives, rather than a pack built for one shape of question.
Any apportionment calculation
Not built and not planned as a tax calculation. We can hold the coding a basis is computed from; the basis, the method and the responsibility are your adviser's. This is a boundary rather than a backlog and it protects you: an apportionment your software chose is one nobody reviewed.
The thing to do in the first week, not the first quarter
Before the second export invoice goes out, settle one question with whoever keys transactions: is the distinction being recorded at the line, or is it going to be worked out later?
- Can a single invoice carry lines of both characters in your system today?
- When a purchase supports both kinds of sale, is that recorded anywhere at the time?
- If somebody asked which inputs sat behind one contract, what would you open?
- Who decided the basis being used now, and is that decision written down anywhere?
- Has anybody told your adviser the mix changed, or will they find out at the next filing?
The last one is not a software question and it is usually the answer. A mixed position is a conversation with an adviser that is much cheaper before a period closes than after — and the software's only job is to make sure that when the conversation happens, it is about facts rather than about what somebody remembers.
What is built here, what is not, and what we would decline is on the Trinidad and Tobago market page. The standing version of this position, and the discipline a large recoverable balance deserves, is a current asset nobody reconciles.
