A Tax That Has Not Started Yet

There is a tax on our own market pages that nobody in the country is charging. The Marshall Islands passed a Consumption Tax Act in 2025 and it sets the rate at 12%. The Act commenced in October 2025. It applies to supplies and imports made on or after 1 October 2026. Both of those sentences are true at once, and the gap between them is where a whole category of quiet finance-system failure lives.

It is worth sitting with how ordinary this is. A rate is not a property of a country. It is a property of a country and a date, and almost every system that stores one stores only the first half — one row per country, one percentage, no date attached. That model is correct almost all of the time, which is exactly what makes it dangerous: it is not wrong until the day it is, and nothing announces the change.

Two dates, and they are not the same date

The Marshall Islands case is unusually clean because the statute separates the two explicitly. One section commences the Act — that happened in October 2025, and from that moment the law exists, the administration exists, the definitions bind. A later section says the chapter applies to supplies and imports made on or after 1 October 2026. So for roughly a year there has been a consumption tax in force and no consumption tax on any invoice.

And it is not one tax arriving alone. An excise act and a tax administration act were enacted in the same year, which means the whole apparatus — how you register, how you file, what the penalties are — is new at the same time. Anything written about Marshall Islands business tax before 2025 describes a system being replaced rather than one being amended.

This is not a Pacific peculiarity, it is just unusually visible here — as is the neighbouring question of whether a consumption tax exists at all, which three markets in the same region answer three different ways. Palau replaced its entire business tax system on a single day in January 2023 — a 10% goods and services tax and a new business profits tax arriving together, with the old gross revenue tax gone. Fiji moved VAT from 9% to 15% on 1 August 2024. Vanuatu went from 12.5% to 15% in 2018. Every one of those dates is a seam, and every seam has documents lying across it.

What actually sits in the gap

It is tempting to treat a start date as a switch: charge nothing before, charge 12% after. The difficulty is that a business does not produce documents at a single instant. It produces them in a sequence that outlives the date.

• A quotation issued in August for work delivered in November. The price was quoted under one regime and the supply happens under another. Whether the quote should have carried the tax is a question about your terms, not about your software — but your software decides what the document said, and that decision is being made now.
• A contract priced for a year. If the price was agreed as a single figure with no tax breakdown, the arrival of a consumption tax is a margin event rather than a pass-through, and which of the two it is depends on wording nobody reads until it matters.
• A recurring invoice. The schedule was set up once. It will keep producing documents on the far side of the date, at whatever rate it was configured with, until somebody notices.
• A credit note against a pre-change invoice. This one is the sharpest, because the answer is unambiguous and most systems still get it wrong: a credit reversing a supply taxed at one rate must carry that rate, not today's.
• Stock bought before and sold after. Where the tax is creditable the transition rules matter; where it is not, the cost of what is on the shelf changes character on a date.

Not one of those is answered by knowing that the rate is 12%. All of them are answered by knowing which rate applied on a particular day — and that is a different question, which most systems cannot be asked.

Ask a finance system what the rate is and it answers instantly. Ask what the rate was, and most of them answer the first question again without telling you.

What our system does, precisely

Half of this is better than we expected when we went to look, and half is a gap we would rather name than let a reader discover.

The good half: documents remember. A quotation stores the tax type, the rate, the tax amount and the totals as they were when it was raised. An invoice stores a rate on every line. A point-of-sale line does the same. So a document produced before a change is a permanent record of what was charged, and it stays right forever — which is exactly what you want, and it is why our rate-correction migrations deliberately do not touch documents that have already been issued. Correcting a stale default is a fix; rewriting an issued invoice is falsifying a record.

The gap: the default has no date. Every new document asks the organisation for its current rate, and that lookup finds the one rate row marked as the default for that tax type. That row carries a date the rate starts and a date it ends. Both can be set through the settings screen and through the API, both are stored — and nothing anywhere reads either of them. A rate you dated to start in October is charged today.

That is a specific and slightly embarrassing kind of gap, and it is the kind worth publishing: a field a user can fill in and reasonably believe does something. By our own test that makes it a defect rather than a missing feature. We wrote it up in full in the column that nothing reads — including why "just add a date filter" is not the fix — and pinned it with a test so that repairing it has to be a deliberate act rather than a side effect.

A second thing to know about the default: it is written once. When an organisation first enables a tax type, we create its rate row from the country preset. If a row already exists we leave it alone — forever. So updating our shipped figure for a country does not reach organisations that already have one. What reaches them today is a hand-written migration that updates only the rows still holding the old value, written when we find a rate that has moved. That works, it is careful, and it is a person noticing rather than a system knowing.

One more, because it is the sort of detail that decides an integration: our invoice endpoint accepts and validates a tax rate per line and then does not use it. The line rate is resolved from the organisation default and the item's own tax treatment. If you post a rate expecting it to be honoured, nothing rejects you and nothing warns you.

Why our published figure for the Marshall Islands is 12% and not zero

This is a decision rather than an oversight, and the reasoning generalises.

A country preset is written into an organisation's settings once, at the moment it enables the tax, and never re-read. That single property decides the whole question. Ship zero, and any organisation that sets up before October gets a permanent zero that nothing will correct, silently under-charging from the day the tax starts — and an under-charge produces no complaint from anybody, because the buyer is happy and the seller's invoices look right. The shortfall is owed by the seller and discovered late. Ship 12%, and an organisation setting up today over-charges visibly, on the first invoice, and someone says so within a week.

One of those errors announces itself and one does not. Where a system's defaults are sticky, choose the one that gets caught. The market page carries the date at the top of its caveat rather than buried in it, so the figure is never read without the date attached.

What to do when a rate has a date on it

1. Find out whether your system stores a rate history at all

   Ask it directly: what was the rate on a date six months ago? If the answer comes back as today's rate with no acknowledgement that a date was asked about, you have one rate per country and a change is a manual event. That is workable. It is only dangerous when you think otherwise.

2. Check the date fields are real before you rely on them

   Ours are not, and we are unlikely to be the only ones. A settings screen with a "valid from" box is not evidence that anything resolves by it — the field is the easy half. The test is a document raised on a date, not a form that saves without complaining.

3. Inventory the documents that will cross the date

   Open quotations, recurring invoice schedules, annual contracts, unbilled work. This is a list-making exercise that takes an afternoon and it is the whole of the risk. The ones that hurt are the recurring schedules, because they keep producing correct-looking documents at the old rate with nobody in the loop.

4. Decide the credit note rule in writing

   A credit against a pre-change invoice carries the pre-change rate. That is not a preference, and it is the rule your system is least likely to enforce for you — ours cannot, because our credit note is a single amount with no tax on it at all. Write it down and put it where the person raising credits will see it.

5. Set a reminder for the source, not for the date

   The useful diary entry is not "tax starts today". It is "re-read the authority's page" a few weeks before, because the thing most likely to have changed is the date itself. We put the Marshall Islands row on a sixty-day review cycle for exactly this reason.

The Marshall Islands is a small market with a very clear statute, which is what makes it a good place to see this. The pattern is not small at all. Every jurisdiction that has ever changed a consumption tax rate has produced the same seam, and the systems that ran across it mostly did not notice, because nothing about charging last year's rate looks like an error on the day you do it.

What we would say plainly: if a date is coming in a market you operate in, the work is not configuring the new rate. That part takes a minute. The work is the list of documents already in flight, and the only good time to make it is before.

Frequently asked questions