Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
Liberia · West Africa
Almost every summary of this change reports five percentage points. That is the smallest thing about it. Today's Goods and Services Tax is single-stage with no right of deduction, so it sticks to every business it touches and compounds down the chain; the VAT that replaces it is deductible, so it sticks only to the final buyer. The headline rate goes up and the tax a business cannot recover goes down. Below: the same supply chain taxed both ways, and an honest account of which half of the change our system is ready for.
Five points up, ten points down
Three registered businesses in a line. Each adds 100 of value. Under the GST every sale is taxed and nobody may deduct what they paid, so the tax charged at each step is charged on the tax already in the price. Under the VAT each business hands over tax on its own value added and no more.
| Stage | Value added | Today · GST 13%, not deductible | From 1 January 2027 · VAT 18%, deductible | |||||
|---|---|---|---|---|---|---|---|---|
| Taxed on | Tax charged | Price out | Net | Tax charged | Deducted | Handed over | ||
| Importer | 100.00 | 100.00 | 13.00 | 113.00 | 100.00 | 18.00 | — | 18.00 |
| Wholesaler | 100.00 | 213.00 | 27.69 | 240.69 | 200.00 | 36.00 | 18.00 | 18.00 |
| Retailer | 100.00 | 340.69 | 44.29 | 384.98 | 300.00 | 54.00 | 36.00 | 18.00 |
| Value actually added | 300.00 | 300.00 | ||||||
| Total tax collected | 84.98 | 54.00 | ||||||
| Tax as a share of value added | 28.33% | 18.00% | ||||||
| What the last buyer pays | 384.98 | 354.00 | ||||||
A 13% tax took 28.33% of the value added. An 18% tax takes 18.00%. Nothing was avoided and nobody was cheated — the difference is entirely the 30.98 of tax-on-tax that the GST charges and the VAT does not.
An illustration of a mechanism, not Liberian price data: three registered businesses, 100 of value added at each, every supply standard-rated, no exemptions and no zero-rating anywhere in the chain. Real chains are longer, shorter and more mixed than this. The point is the shape, not the figures.
This is why the change is worth preparing for rather than absorbing. The business in the middle of that chain is currently carrying tax it can never reclaim, priced into its cost of goods and invisible in its accounts as tax. From January that same amount becomes a recoverable balance — but only if it is recorded as one, which means recording tax on the purchase side. Which brings us to what we do not do.
Our own limitation, stated
A tax change with a known future date is exactly the case for storing a rate against the date it starts. We have those columns. They have been in the per-organization tax rate table since February 2026, next to a region and a city column, and every one of them is dead weight — which we would rather write down here than let you discover in January.
What the record can hold
A rate can be given a start date.
A rate can be given an end date.
Two optional dates on the record that holds your organization's own tax rates. Everything a scheduled rate change needs — and nothing on either side of them that acts on it.
Nothing reads them
Both of the ways a rate gets resolved for a document pick the rate marked as the default and stop there. No date is consulted, and nothing runs on a schedule to bring a future rate into force.
A rate with a start date of 1 January 2027 will not start on 1 January 2027.
Provisioning never writes them
When your organization is first given a tax rate from the country reference, both columns are left null.
The default state of every rate we create is "no date", so there is nothing for a future fix to migrate from.
The API writes them, and it changes nothing
The tax settings API accepts both dates and stores them faithfully. Marking a rate as the default also demotes the previous one — immediately, without consulting either date.
Enter next year's rate and mark it default and it applies today. Leave it undefaulted and it never applies at all. There is no third outcome.
The rate you submit is discarded
Both the create and update paths overwrite whatever rate you send with the current value from the country reference for that country and tax type.
You could not pre-enter 18% today even if the dates worked, because the field is validated and then thrown away.
Put plainly: there is exactly one tax rate per organization per tax type, it is always the country reference's current value, and the two date columns beside it are decoration. For a market with no scheduled change that is an unremarkable simplification. For Liberia in August 2026 it is the specific thing you would want, five months before you need it, and we do not have it. Nor do we hold tax on the purchase side at all — there is no tax column on a purchase order anywhere in the schema, which is adequate for a GST you can never reclaim and inadequate for a VAT you can.
Both are commissionable and neither is a small change, so we are not going to imply a date. What we will do is state the position precisely enough that you can hold us to it: the dates are dead, the purchase side has no tax, and there is a test in the repository pinning both so that fixing them has to be deliberate. Ask the other vendors on your list what their system will do on the second of January. The useful question is not whether they support VAT — everyone will say yes — but whether an invoice raised on 31 December and credited on 5 January gets 13% or 18%.
What the cutover costs
Every one of these exists whichever system you use. They are here so that the questions you put to us — and to everyone else on your list — are the ones that will matter in February rather than the ones that demonstrate well in August.
Under a cascading GST the tax on your purchases is not tax in your accounts — it is part of what the goods cost. It does not appear on a tax line, it is not recoverable, and it is not visible as a number anyone could tell you. The first thing the VAT does is turn that invisible amount into a balance, and the second thing it does is ask you where the records are.
An order placed in December and delivered in January. An invoice raised at 13% and credited at 18%. A recurring schedule that runs straight through the change. None of these are unusual; all of them need the system to know which side of a date a document belongs on, and most systems know only what today's rate is.
The Liberian dollar and the US dollar both circulate, so a single business routinely holds costs in one and prices in the other. That is a reporting problem before it is a treasury problem: the question "what did this actually cost us" has two answers and a date.
A regime change is precisely when a business wants an adviser, and the bench that can walk a mid-sized Monrovia distributor through a VAT cutover is small and about to be very busy. Whatever your system does not do for you in January, somebody will be doing by hand at exactly the moment they are hardest to hire.
What we are actually for
Everything below is running today. Deductible input tax, scheduled rates and filing are not on this list, and the scope section immediately after it says so in more detail than a vendor normally would.
Every invoice line keeps the rate it was raised at as a stored figure rather than a lookup. A document raised in December 2026 will still read 13% in 2030, whatever the reference says by then. This is the half of a rate change we already get right, and it is the half that protects your history.
Freight, duty, port charges and handling attach to a consignment as their invoices arrive, with unit cost recalculating each time. While GST on inputs is part of cost rather than a receivable, this is where it actually lives — and it is the record you will be reconstructing from in January.
Raise and hold documents in more than one currency and report across them. In an economy where two currencies circulate side by side, the reporting question is the everyday one, and it is answered without a spreadsheet.
Order, receipt and invoice reconciled against each other, with variances surfaced rather than absorbed. The discipline that makes a purchase record trustworthy is the same discipline a deduction claim will need, whatever the tax rules turn out to require.
Every document carries its own dates and its own history, and corrections are recorded as corrections. Across a regime change, being able to show when something was raised — not when it was last edited — is most of what a reviewer will ask for.
Attribute cost and revenue to the branch, site or project that produced it. Independent of any tax question, and the thing most likely to be asked for first once the tax question is settled.
Scope, in three parts rather than two
Three columns, because "no" means two entirely different things and one list hides which is which. The middle column is work that has not been done and has a price. The right-hand column is work we would decline from a paying customer — and it is the one worth demanding from every other vendor you talk to, because a page without it has not told you where its edges are.
Running in the product today
Not built yet — and commissionable
What we would decline, and would rather say now
Two of those five are dated obsolescence rather than absence: purchase-side tax and scheduled rates are both things this product will need, and Liberia is simply the first market that makes the need legible. Both are commissionable now, on the same terms as everything else here — a written specification, a timeline and a price, before any money moves. The evidence that this is a real offer rather than a sales line is Kenya, where the eTIMS transmission and the maintained statutory payroll engine were both built exactly this way. We will not name a date on this page, and we will name one in a quote.
The five months are yours, not ours. If our answer on purchase-side tax is not good enough for your January, the right conclusion is a different system, and this page exists so you can reach it in August rather than in February.
How this starts
Take one month of purchase invoices and total the GST on them. Under today's rules that figure is part of your cost of goods and appears nowhere as tax. From January the same figure is a recoverable balance. It is usually the first number that makes the change concrete, and almost nobody has it to hand.
Not what the rate is — what the system does. Ask your current vendor, ask us, and ask anyone else on your list. The answers separate systems that store a rate on the document from systems that look one up, and the difference will be visible within a fortnight of the change.
In whatever you use today, find the field that holds tax on a purchase. If there is not one, you have found the same gap we have named on this page, and you now have a question to put to every vendor rather than a feature list to read.
Read before you shortlist
A cascading tax charges tax on tax. A credit-invoice tax does not. Liberia switches from one to the other on 1 January 2027, and the five percentage points are the least interesting part of it.
A field that saves without error is not evidence of a feature. We have two date columns on our own tax rate table that accept writes and change nothing, and the pattern is common enough to test any vendor with.
Ask every vendor where tax on a purchase is recorded, and what happens to a December invoice credited in January. We publish our own answers, and the first one is that the field does not exist.
Questions we are asked here
Not as it stands today, and the honest answer has two parts. What already works: the rate on each invoice line is stored on the line, so documents raised under GST keep 13% permanently and nothing rewrites your history when the rate changes. What does not: we hold no tax on the purchase side at all, and deductible input tax is the entire point of a VAT. Recording output tax at 18% is a configuration change; recording and claiming input tax is a data-model change, and we would be misleading you to describe the second as a setting. **On the roadmap and commissionable now** — a written specification, a timeline and a price, with Kenya's eTIMS transmission and payroll engine as the evidence that we build this way rather than talk about it. We will not name a date on a public page, because there is no published VAT invoice specification to build against yet.
No, and this is worth understanding precisely because the screen suggests otherwise. Your organization's rate can be given a start date and an end date, and both will be accepted and stored. Neither is ever read. Marking a future rate as your default applies it immediately, because the only thing the rate lookup asks is which rate is the default; leaving it undefaulted means it never activates. And the rate you submit is discarded and replaced with the current value from our country reference, so the figure would come back as 13% regardless. **A backlog item, not a boundary** — scheduled rates are commissionable and are named in the middle column above. In the meantime, the reliable answer is to change the rate on the day, which is one field.
For businesses in the middle of a supply chain, yes, and the table above shows why. A cascading tax is charged on a price that already contains tax, so a 13% rate collected three times over collects 28.33% of the value actually added. A VAT collects 18% once, because each business deducts what it was charged. The final buyer in that illustration pays 384.98 under the GST and 354.00 under the VAT. That is a model with stated assumptions rather than a forecast for your business, and your own chain will differ — but the direction is a property of the mechanism, not of the numbers we picked.
That is the right question and it is not ours to answer. Transitional relief for stock on hand at the cutover is a matter for the Authority's transitional rules and for your tax adviser, and a software vendor offering a view on it would be doing something we think is genuinely wrong. **A boundary rather than a backlog**, and the reason it protects you is straightforward: our incentive is to make our software look sufficient, which is exactly the wrong incentive to have when the answer determines a real liability. What we will do is record whatever treatment you are advised to take, and produce the stock and purchase history your adviser needs to work it out.
Not for the system. Documents can be raised and held in more than one currency and reported across them, which in an economy where both circulate is an everyday requirement rather than an export feature. What we will not do is advise you on which to price in, hold or bank in — that is a treasury and commercial decision with real consequences, and no software choice improves it. We hold that line everywhere for the same reason; the Malawi page explains it at length.
No, and we produce no return in any format the Authority accepts — that is true today under GST and it will be true in January under VAT until somebody builds it. **Two halves, and they have different answers.** The data half is a backlog item: producing a return from records the system already holds is buildable against a published specification, and none exists for the new regime yet. The filing half is a boundary: we do not correspond with the Authority on your behalf and we hold no practising credential, so an intermediary who does is not a gap in our product but a person you should have.
No. English is Liberia's official language and the language of business and administration, so the interface being English-only — a real constraint we raise on our Francophone and Arabic-market pages — is not a constraint here. We mention it only because we would rather answer the question than have you wonder whether we quietly avoided it.
Quite possibly you should not, and if a Monrovia implementer knows your industry and will answer the phone, that is worth more than anything on this page. We are further away, in a different time zone — though a workable one, unlike our Pacific pages — with no office and no local partner. What we offer instead is checkability. This page names two specific gaps in our own schema with the column names, states that the largest one is dated obsolescence rather than a missing feature, and there is a test in the repository pinning both so a fix has to be deliberate. Ask every other vendor on your list what their system does with tax on a purchase order. The ones who understand why you are asking are the ones worth talking to.
Total the GST on them. That figure is invisible in your accounts today and becomes a recoverable balance in January. Bring it and we will tell you honestly which part of the change we are ready for and which part we are not.