AWRA OpsHub Search

Trinidad and Tobago · Caribbean

If you export, your VAT return is not a bill. It is a claim — and it is built from the half of the ledger we do not keep.

Trinidad and Tobago charges VAT at 12.5% and collects returns every two months. But zero-rating here is wide — basic foods, crude oil, natural gas, exports — so a great many registered businesses charge little or no tax on what they sell while paying it on almost everything they buy. For those businesses the return is a refund claim, the balance is a receivable, and the whole exercise rests on input tax: what you paid, to whom, on which invoice, in which period. We hold no tax on the purchase side at all. This page is about what that means before you buy anything from us.

The rate
12.5%, administered by the Board of Inland Revenue, with returns every two months — six a year, due the last day of the month after the period ends.
The subject
Zero rating here is broad. If you export, your return is a claim rather than a payment, and the number it turns on is what you were charged rather than what you charged.
What we get right
The sales side. Rates are stored per line, so zero-rated and standard-rated supplies sit in one ledger without a second set of books.
The limit
We hold no tax on a purchase — not a rate, not an amount, nowhere in the schema. For a business in a standing credit position that is the number the whole return is built from. Named below with the three tables that do hold one.

One rate, two directions

Two businesses, one rate, opposite returns

The same 12.5%, the same bi-monthly cycle, and two entirely different relationships with the Board of Inland Revenue. Which one you are is decided by what you sell, and it changes what your accounting system is actually for.

Filing period Every two months — six returns a year, due the last day of the month following the period end.

A standard-rated domestic trader

SellsCharges 12.5% on sales
BuysPays 12.5% on purchases
ReturnOwes the difference

Output tax. The system needs to get what you charged right, and it does.

An exporter or zero-rated supplier

SellsCharges 0% on sales
BuysPays 12.5% on purchases
ReturnReclaims the whole of it

Input tax. The system needs to get what you were charged right, and we do not record it.

A business in the second column is in a standing credit position: it is financing its own input tax from the moment it pays a supplier until the moment its claim is settled. That is a structural feature of being zero-rated in a country with a broad zero-rating list, not a criticism of anybody, and it is the reason the evidence behind a claim is worth more here than the convenience of producing it.

Which column you are in is not always stable. A domestic trader that wins an export contract moves between them, and can be in both at once — which is precisely the case where a system that records only one side of the tax becomes hardest to work with.

Our own schema, counted

Nowhere to record tax on a purchase, anywhere

We looked for this rather than remembering it, because the claim is checkable and worth being exact about. Across the whole product, a tax rate is held in three kinds of document — and all three of them are sales.

Customer invoices

A tax rate on every line

Sales

Quotations

Tax held on the document

Sales

Point-of-sale receipts

Tax on every retail line

Sales

Purchase orders hold no tax at all. Not a rate, not an amount, not a flag — the tax you were charged by a supplier has nowhere to go in this system.

What that means for a claim

  • The input tax on a period cannot be totalled from the system, because it was never recorded as tax. It is inside the cost of what you bought.
  • A claim has to be assembled from supplier invoices outside the system, which is exactly the reconstruction work an accounting system is bought to avoid.
  • Landed cost — where import duty, freight and tax on a consignment do get recorded — deliberately folds them all into unit cost, which is right for costing and wrong for reclaiming.
  • Nothing in the product will ever tell you your credit position, because the figure it would be computed from does not exist.

This is the gap, and it is not a small one here

On our Liberia page the same absence is described as adequate, and today it genuinely is — Liberia levies a tax you cannot reclaim, so tax on a purchase really is part of what the purchase cost, and that is where we put it. In Trinidad and Tobago that reasoning does not hold and has not for years. If you are in a standing credit position, input tax is not a cost, it is a receivable, and we are asking you to keep the record of your largest current asset somewhere other than in our system. We would rather write that down than let it emerge in your second filing period.

The same column fixes both markets, which is why it is one piece of work on the roadmap rather than two. It is commissionable on the usual terms — a written specification, a timeline and a price agreed first. What we will not do is imply that landed cost is a substitute, because it is designed to do the opposite of what a claim needs: it puts tax into the cost of goods, and a claim needs it kept out.

What this costs, six times a year

Four problems that belong to whoever assembles the claim

None of these are exotic and none of them are anybody's fault. They are the ordinary consequences of a system that records what you charged carefully and what you were charged not at all.

A receivable that lives in a spreadsheet

For a business in a standing credit position the VAT claim is often one of the larger current assets on the balance sheet, and in most systems it is assembled by hand from supplier invoices at the end of every second month. The number is real, material and outside the accounting system.

Evidence, six times a year

A claim is only as good as the invoices behind it. Every two months somebody gathers them, checks the supplier is registered, checks the period, and rebuilds a total that the system could have carried all along.

Moving between the two columns

A domestic trader that wins an export contract is suddenly partly zero-rated, apportioning input tax between the two. That is the point where a manual method stops scaling and where errors become expensive rather than annoying.

Cost that hides the tax inside it

Landed cost is the right way to value goods and the wrong way to hold a claim, because it folds duty, freight and tax into one unit cost on purpose. Every system that does costing well makes reclaiming harder unless it keeps the tax separate — and most do not.

What we are actually for

The discipline underneath a claim, even where the total is not ours

Everything below is running today. Input tax, credit position and filing are not on this list, and the scope section immediately after it is specific about that.

Purchase orders, receipts and three-way matching

Order, receipt and supplier invoice reconciled against one another with variances surfaced rather than absorbed. This is the record a claim is eventually built from, and getting it disciplined is worth doing whether or not the tax field ever arrives.

Landed cost, open after receipt

Freight, duty, port charges and handling attach to a consignment as their invoices arrive and unit cost recalculates each time. Named here with the caveat above: it is costing, deliberately, and not a tax record.

Supplier records with documents attached

Every supplier carries its own record, contacts and attached documents, so the invoice behind a line is retrievable from the transaction rather than from a filing cabinet.

A rate stored on every sales line

Output tax is recorded per line as a stored figure, so zero-rated and standard-rated sales sit side by side in one ledger and a document raised today keeps its rate permanently.

Multi-currency documents and reporting

Raise and hold documents in more than one currency and report across them, which for an exporter is the ordinary case rather than the exception.

Reporting by period, project and cost centre

Cut activity by whatever period you actually work to, including one that is not a calendar month, and attribute it to the site, project or department that produced it.

Scope, in three parts rather than two

What runs today, what we would build, and where we stop on purpose

Three columns, because "no" means two entirely different things and one list hides which is which. The middle column has a price. The right-hand column is work we would decline from a paying customer, and it is the one to demand from every other vendor on your list.

Scope in Trinidad and Tobago, including the side of the ledger we miss

Running in the product today

  • Purchase orders, receipts and three-way matching, with variances surfaced rather than quietly absorbed.
  • Landed cost open after receipt, so late duty and freight invoices still reach the goods — costing, not a tax record.
  • Supplier records with documents attached, so the invoice behind a transaction is retrievable from the transaction.
  • Output tax stored per sales line, so zero-rated and standard-rated supplies coexist without a second set of books.
  • Multi-currency documents and reporting, and reporting periods that need not be calendar months.

Not built yet — and commissionable

  • No tax on the purchase side. There is no tax column on a purchase order in our schema — not a rate, not an amount. For a business in a standing credit position that is the number the whole return is built from, so this is the largest gap on this page by a distance, and it is a data-model change rather than a screen. The same missing column is what our Liberia page is about, which is why it is one piece of work rather than two.
  • No input tax total, and therefore no credit position. It follows from the above rather than being a separate gap, but it is worth naming separately because it is the thing you would actually want on a dashboard, and no amount of reporting can derive it from data that was never captured.
  • No VAT return output for the Board of Inland Revenue, bi-monthly or otherwise. We have no concept of a filing period at all — this is a boundary as much as a backlog, and the next column says why.
  • No apportionment between zero-rated and standard-rated activity. A business that is partly both has to work out the split outside the system. Genuinely commissionable, and honestly the second thing we would build here rather than the first.
  • No Trinidadian payroll engine. No income tax tables, no NIS calculation, no filing. Labour cost is attributed to projects and cost centres, which is the reporting half rather than the calculation half. Kenya remains the only market where we maintain a statutory engine.

What we would decline, and would rather say now

  • We will not advise on refund timing or how to plan around it. That a business in a credit position is financing its own input tax is a structural fact we will state. How long a claim takes to settle, and what to do about it, is a treasury question and a political one, and a software vendor with an opinion on it is a software vendor selling something.
  • We will not present landed cost as an input tax record. It folds tax into unit cost by design. Using it as evidence for a claim would be using a tool for the opposite of its purpose, and we would rather lose the argument than help set that up.
  • We will not file, correspond with, or represent you to the Board of Inland Revenue. No practising credential, no agency. Producing the data your adviser files from is the part we would do.
  • We will not tell you whether a supply is zero-rated. The list is broad, it moves, and the consequences of getting it wrong land on you rather than on us.

Purchase-side tax is the piece of work behind three of the five items above, and it is the same piece of work the Liberia page describes from the other direction. Commissionable now on the usual terms: a written specification, a timeline and a price agreed before anything begins. The reason to treat that as a real offer is Kenya, where eTIMS transmission and a maintained statutory payroll engine were both built to specification for a single market and are now part of the product. No dates on a public page.

If you are standard-rated and domestic, almost none of this affects you and the page has overstated your problem. If you export, it is the first thing to ask us — and every other vendor — about.

How this starts

Three moves, and the first is your last return

01

Work out which column you are in

Take your last return. If the bottom line was a claim rather than a payment, input tax is the number your system most needs to hold, and you should be testing every vendor on it rather than on invoicing.

02

Ask where tax on a purchase is stored

Ask to be shown the field, on the screen, on a purchase order. Not a report — the field. We have told you above that ours does not exist. It is a fair and revealing question to put to anyone else on your list, and the hesitation is usually more informative than the answer.

03

Time how long your last claim took to assemble

Not to be paid — to be assembled. If gathering the evidence for one bi-monthly claim takes a person more than a day, that is the recurring cost any system should be measured against, six times a year.

Questions we are asked here

Straight answers, starting with the side we do not hold

Can your system produce our bi-monthly VAT return?

No, and there are two separate reasons rather than one. **Two halves, and they have different answers.** The first is a backlog item: we hold no tax on the purchase side, so the input figure the return needs was never captured and no report can recover it — that is the missing column described above and it is commissionable, on a written specification with a timeline and a price. The second is a boundary: we produce no filing output for any authority in this market and do not represent you to the Board. Even with the column built, the return is something your adviser prepares from our data rather than something we submit.

We export almost everything. Is this system wrong for us?

For the part of your business that matters most, it is incomplete, and you should weigh that seriously. Your sales side is well served — zero-rated and standard-rated lines coexist, rates are stored per line, multi-currency is ordinary. Your purchase side is where your money is, and we hold no tax there. What we would genuinely be good for is the discipline underneath a claim: matched orders, receipts and supplier invoices with the documents attached, which is the evidence a claim rests on even when the total has to be assembled elsewhere. Whether that is enough is your call, and we would rather you made it now.

Does landed cost not already capture the VAT we paid on imports?

It captures the money and puts it in the wrong place for this purpose. Landed cost exists to fold freight, duty and tax into the unit cost of goods so your margins are honest, and it does that well. A reclaim needs the opposite: the tax held out of cost, identified as tax, attributable to a period and a supplier. Using landed cost as a claim record would understate your margins and produce a total nobody could defend. **A boundary rather than a backlog** — we will not repurpose it, because the two jobs genuinely conflict.

How long do VAT refunds take here?

Not our question to answer, and we would be suspicious of a software vendor who offered a figure. What we will state is the structural part, because it affects what your system needs to do: a business in a standing credit position is financing its own input tax from the moment it pays a supplier until the claim settles, whenever that is. That makes the speed and quality of your evidence worth real money, which is an argument about record-keeping rather than about anybody's administration.

Our filing period is two months. Does that break anything?

No, and it is worth being precise about why, because we have written elsewhere about a period that does break things. Reporting in this system can be cut to whatever dates you like, including a two-month window, so there is nothing to work around. We have no concept of a statutory filing period because we do not file — that is a boundary rather than a limitation. Our Papua New Guinea page describes a genuinely different case, where a fortnightly pay cycle is refused by a unique key in the database; this is not that, and we would rather not borrow the drama.

Is foreign exchange going to be a problem for us?

It is a real feature of operating here and it is not a software problem, so we will keep this to one line: we will report accurately in whatever currencies you transact in, and we will not advise you on sourcing, timing or holding foreign currency. Our Malawi page sets out at length why we hold that line rather than making a feature of it.

Is English-language software a limitation here?

No. English is the official language of Trinidad and Tobago, so the English-only interface — a real constraint on our Francophone and Arabic-market pages — is not one here.

Why would we buy from Nairobi?

Possibly you would not, and the honest case against us is on this page rather than hidden from it. There is no local office, no implementation partner, and the largest gap we have named is directly relevant to exporters, who are much of the market. The time zone works — a Port of Spain morning reaches a Nairobi evening, so there is a daily window, unlike our Pacific pages. What we offer past that is checkability: we have said which three tables hold a tax rate and confirmed all three are sales, rather than describing our procurement module and hoping you do not ask. Put the same question to every vendor on your list and see who can answer it precisely.

Bring your last return

If the bottom line was a claim, we will show you exactly which parts of assembling it our system would carry and which parts it would not. That is a more useful twenty minutes than a demonstration of invoicing.