Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
For Fiji
A rate is not a fact about a country, it is a fact about a country on a date — and almost every finance system, including ours, stores it as though the first were true. Raise a credit note today against an invoice from July 2024 and the right answer is 9%. Ask our own country profile what Fiji's rate was that month and it will tell you 15%, because it holds one rate and no date. Half of our answer here is already safe and half is not; the page below says which is which, with the column names.
One change, five documents
Every row below is the same event — the rate moving from 9% to 15% on 1 August 2024 — seen from a different document. Read the last column as a verdict on us rather than on Fiji.
The change — before
9% to 31 July 2024
The change — after
15% from 1 August 2024
An invoice raised 15 July 2024
9% — the rate in force when it was raised
The rate is stored on the invoice line as a decimal, not looked up. Reopen it, reprint it or report on it in three years and it still says 9.
A recurring invoice generated on 5 August 2024
15% — the rate in force at supply
Each generated document resolves the rate when it is created and then stores it. A schedule crossing the change produces documents at the right rate on both sides of it.
A credit note raised today against that July invoice
9% — a credit follows the supply it reverses
Our credit note is a single amount with no lines and no tax columns at all. It cannot carry 9%, and it cannot carry 15% either. The split lives in whatever your accountant journals.
A quotation issued 20 July, accepted 5 August
A question with a real answer, and the answer depends on the terms and the time of supply
The quotation carries the rate it was issued at and converts carrying that rate. Nothing prompts anybody that the rate moved between issue and acceptance, so the check happens only if a person remembers to make it.
Asking the country profile what Fiji's rate was in July 2024
9%
It answers 15. The profile holds one rate per country with no effective date anywhere in the file or the resolver, so there is no date to ask it about.
The two rows that pass are the reason to believe the three that do not. Documents already raised are safe — the rate is on the line, it was never a lookup, and no rate change reaches backwards into your history. What is not safe is every NEW document that is about an OLD period, and the reason is the same in all three cases: the system knows what rate it used, and does not know what rate applied.
The first is `credit_notes.amount`. Our credit note is one figure with a customer, a reason and an optional link to the invoice it relates to — no lines, no tax rate, no tax columns. For most of what a credit note is used for that is adequate. Against a rate change it is not, because there is no place in the record to say that this credit reverses a supply taxed at a different rate than today's. The second is the absence rather than a column: `config/tax_rates.php` holds one rate per country and there is no effective date anywhere in the file, on any row, or in the resolver that reads it. For provisioning a new organization that is correct, because they are registering today. For any question of the form "what was the rate on this date", it is not answerable at all.
We are not going to fix either quietly and then describe it as a feature. Effective-dating a rate is not a column on a config row — it needs a rate HISTORY per country, and every consumer in the codebase resolves a country to exactly one profile today. That is a data-model change with an owner and a migration behind it, and until somebody has done it properly this page will keep saying so. What we are claiming is narrower: your history is safe, we know precisely which three cases are not, and we have written the column names down. A vendor who has never had to answer this question has not had a customer live through a rate change.
The operational half
A national stock figure is an average of places that cannot substitute for each other. The distances are short and the schedules are not, which makes availability a calendar question rather than a quantity question.
The main warehouse
Where the number in most systems comes from, and where the goods usually are not when they are needed.
Stock on hand, committed against open orders, and what is already allocated to a transfer that has not left.
A second island branch
Days away by sea, not hours by road. A stockout here is not solved from the main warehouse this week.
Its own on-hand position and its own counts, with transfers confirmed on receipt rather than on despatch.
Goods on the water
Owned, paid for, insured, and in neither location's figure. The single most common place for stock to be invisible.
An in-transit position between two of your own locations, with a despatch date and a confirmation that has not happened yet.
A resort, site or consignment location
Your goods, somebody else's premises, and usually somebody else's counting.
A location you do not own, counted against, with the same transfer discipline as any other.
None of this makes a boat come sooner and we are not going to suggest it does. What it changes is narrower and worth paying for: the difference between "we have forty" and "we have forty, of which eleven are on this island, nine are on the water since Tuesday and twenty are at a resort". The first sentence is a number. The second is a decision.
What this costs today
None of these produce an error. Each is a document that is internally consistent and describes the wrong thing, which is the hardest class of mistake to find because nothing about it looks unusual.
A return against an old supply is credited at the rate that supply carried. Where the record holds one gross figure and no tax split, the correct treatment exists only in the head of whoever posted it — and it is found, if ever, by an accountant reconstructing a year from invoice copies.
Issued at one rate, accepted after a change, converted without anybody re-checking. The document is internally consistent and the total is wrong, which is the hardest kind of error to catch because nothing about it looks unusual.
A national figure that is the sum of positions which cannot substitute for one another. It is not wrong, it is unusable — and the reorder decision made from it is made blind to the only fact that mattered, which is where the goods are.
Freight, inter-island shipping, handling and clearance invoiced separately and weeks apart. If the receipt closes when the goods arrive, none of it reaches the unit cost, and the margin on a line is calculated from a price that was never the cost.
What we are actually for
Everything below is running today. Fiscalisation, filing and payroll are not on this list, and the scope section says so in more detail than a vendor normally would.
Each branch, island and consignment location holds its own position, transfers are confirmed on receipt rather than on despatch, and goods in transit are a state rather than a gap. In a market where the next resupply is a schedule rather than a drive, in-transit visibility is the feature.
Freight, duty, VAT at import, port charges, inter-island shipping and handling attach to the consignment as their invoices arrive, with the unit cost recalculating each time. Which is the only way a cost that arrives three weeks after the goods ends up in the price of them.
Every invoice line keeps the tax rate it was raised at as a stored figure. This is the half of the rate-change problem we already get right, and it is worth naming as a capability rather than as an accident: your history does not move when a rate does.
Import paperwork against the consignment, the supplier invoice against the receipt, the credit against the sale — previewable in place and retrievable by the transaction rather than by whoever filed them. Where a tax question is answered by reconstruction, this is what shortens it.
Branch, site, cost centre and customer captured at entry rather than reconstructed at reporting time, so per-island and per-branch profitability is a filter instead of an excavation.
Goods bought in Australian, New Zealand or US dollars and sold in Fijian dollars keep both amounts and the genuine rate on the transaction, so a margin can be explained months later rather than recalculated from a rate nobody wrote down.
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 to demand from every other vendor on your list, because a page without it has not told you where its edges are.
Running in the product today
On the roadmap — and commissionable now
Not ours, by choice — and this column is the reason to believe the other two
Nothing in the middle column is a permanent limit, and the first two are things we want fixed for every customer rather than for one. Kenya's eTIMS transmission and its maintained statutory payroll engine exist because Kenyan clients needed them and commissioned them; neither arrived by itself. The credit note tax split is a small, well-defined build. Effective-dated rates are a genuine data-model change and we would rather quote it honestly than describe it as a configuration option. If any of these is what stands between you and a decision, say which and we will scope it as a build: written specification, timeline and price, before you commit to anything. What we will not do is print a date on this page that nobody has paid for.
Read the three columns rather than counting them. The middle one is work, and work has a specification, a timeline and a price. The right-hand one is where we stop on purpose, and it is the column worth demanding from every other vendor on your list — a page without one has not told you where its edges are. One thing deliberately absent from all three: language. English is an official language here and the language of business, so unlike our Francophone and Gulf pages there is nothing to disclose, and we are not going to pad the list to look thorough.
How this starts
A credit raised after 1 August 2024 against a supply invoiced before it. Ask what rate it was treated at and where in the system that is recorded. If the answer is a person rather than a field, you have found the subject of this page in your own data.
Not what an old invoice says — what the system believes the rate was on that date. Most will answer with today's rate and no warning that they were asked a question they cannot answer. Ours does exactly that, which is why it is on this page rather than in a footnote.
Fiscalisation, filing and payroll are local purchases and we have said so above with the column names to back it. What is left is cost, stock across places, evidence and control — a smaller conversation than most vendors will let you have, and the one we can stand behind.
Read before you shortlist
Almost every finance system stores one tax rate per country and no date. That is correct until the first credit note against a pre-change invoice, and then it is confidently wrong with nothing to warn you.
Twenty-six pay days do not fit into twelve months, and the two left over arrive on a six-monthly rhythm rather than by accident. Most finance systems store a payroll period as a calendar month and never mention it.
Ask every vendor what their system does with a credit note raised today against an invoice from July 2024. We publish what ours does, which is not enough, which is what makes the question fair.
Questions we are asked here
No — that is the system working correctly, and it is the half of this problem we already get right. The tax rate is stored on each invoice line as a figure at the moment the document is raised, not looked up when the document is viewed. So a July 2024 invoice shows 9% today, will show 9% in five years, and would show 9% even if the rate moved three more times. A system that re-resolved the rate on display would rewrite your history every time a budget passed. If you are checking whether your own system does this, raise nothing and change nothing — just open a document from before the change and see whether the rate on it is the rate it was raised at.
Honestly: less than it should. Our credit note is a single amount with a customer, a reason and an optional link to the invoice it relates to. There are no lines and no tax columns, so there is nowhere in the record to say that this credit reverses a supply taxed at 9% rather than at today's 15%. The correct treatment is not in doubt — a credit follows the supply it reverses — but the system does not hold it, which means it lives in the journal your accountant posts and in their memory of why. **This is on the roadmap rather than a boundary and it is commissionable now.** It is the smallest of the three gaps on this page: lines and a rate on the credit note, defaulting from the invoice being credited. If it is what stands between you and a decision, say so and we will come back with a written specification, a timeline and a price. Kenya's eTIMS transmission exists because a client commissioned it, which is the only reason we make that offer with a straight face.
No, and it will answer confidently anyway, which is worse than refusing. Our country profile holds one rate per country and there is no effective date anywhere in the reference file or in the resolver that reads it — so asked about July 2024 it returns 15, because 15 is the only number it has. We have recorded that in the reference file itself, published it here, and pinned it with a test. **It is on the roadmap rather than a boundary, and it is the larger of the two builds on this page**: effective-dating a rate needs a rate history per country rather than a date on a row, and every consumer in the codebase currently resolves a country to exactly one profile. We would scope it, price it and do it properly rather than bolt a date onto a config file and call it solved. And there is a matching limit in the right-hand column of the scope section that is not a build at all: we will provide the field, and what goes in it for a country we do not file in stays yours and your accountant's to confirm.
No, and this one is a boundary rather than a backlog. The Revenue and Customs Service operates a VAT Monitoring System requiring approved point-of-sale equipment for businesses in scope, that approval attaches to certified equipment rather than to a web application, and it is the Service's to grant rather than ours to claim. We would sit alongside what you already have rather than in front of it. **You should want that answer**, because the alternative is a vendor who blurs "we can produce the data" into "we are approved" — and you discover which they meant during an audit. The data half is different and is genuinely buildable: producing sales data in a published format, against equipment you already own, is a specification-and-price conversation like any other.
As separate places rather than as one number, which sounds obvious and is the thing most systems get wrong by default. Each branch and island holds its own position, transfers between them are confirmed by the receiving location rather than by the sender, and goods on the water are an in-transit state instead of a gap in both figures. What that gives you is the difference between "we have forty" and "we have forty, of which eleven are here, nine have been on the water since Tuesday and twenty are at a resort". What it does not give you is any influence over when the next boat sails — we make the schedule visible and costed and we are not going to imply anything more than that.
We are in Nairobi at UTC+3 and you are at UTC+12. There is effectively no shared working day: your morning is our night, and your afternoon is our very early morning. This is the largest time gap of any market we have written a page for and we are putting it in the FAQ rather than in a footnote because it is the kind of thing that is fine in the demo and corrosive in month two. In practice support is asynchronous — you write, we answer within our day, you read it the next morning — which works well for configuration questions and badly for anything urgent. **Extending cover is a staffing decision rather than an engineering one and it is quotable like anything else**, but as things stand today it is a real cost of buying from us and you should price it in rather than discover it. If same-day response inside your working hours is a requirement rather than a preference, a regional vendor is the rational choice and we would rather say so.
No. No income tax tables, no provident fund calculation, no filing, no statutory forms. What we do is attribute labour cost to branches, sites, cost centres and jobs, which is the reporting half of payroll rather than the calculation half — useful alongside a local payroll, useless as a replacement for one. **It is on the roadmap rather than a boundary and it is commissionable now**, on the same basis as everything else here: our maintained statutory payroll engine covers Kenya only, and it exists because a Kenyan client needed it and paid for it to be built and kept current. That is the precedent and also the warning — a payroll engine is not a one-off build, it is a maintenance commitment, and we would quote it as one rather than as a project with an end date.
Possibly you would not, and the page is written so you can decide that quickly rather than in month three. What we can offer instead of proximity is checkability: this page names two things in our own schema that are inadequate for a Fijian rate change, gives the column names, and there is a test in the repository pinning both so that a fix has to be deliberate. That is a kind of evidence a reference story is not. The rest is ordinary and unflattering — no office, no implementation partner, no shared working day, remote support in English. Ask us what happens when the person who implemented your system leaves. Then ask every other vendor on your list what their system does with a credit note against a pre-August-2024 invoice, and see which of them has thought about it.
Find a credit raised after 1 August 2024 against a supply invoiced before it, and ask your system which rate it was treated at. Bring the answer and we will tell you honestly which half of your problem we are for.