A Federal Rate Is Not a National Rate
Our country tax table holds Canada at the federal rate, which is correct. It then writes that rate into an organization's own settings and never revisits the question — so a business in a harmonised province is configured at the federal figure and nothing says otherwise.
There is a row in our country tax configuration that reads: Canada, Goods and Services Tax, 5%. Every part of it is correct. Five per cent is the federal rate, GST is its name, and Canada is where it applies. And for most Canadian organizations using our product it is the wrong default, because in most of Canada a sale does not carry the federal rate on its own. This is a post about how a correct reference value becomes an incorrect setting, and what to go and check if you are the organization in question.
Correct about the country, wrong about the sale
Canada has three arrangements. In Alberta and the territories, a sale carries the federal tax alone. In Ontario and the Atlantic provinces, the federal and provincial components are merged into one harmonised tax at a higher rate. In British Columbia, Saskatchewan, Manitoba and Quebec, the federal tax applies and a separate provincial tax sits alongside it.
So there is no rate that is right for Canada. There is a rate that is right for one province and the territories, a different rate for several others, and a pair of rates for the rest. We are naming the structures and not the numbers on purpose — the arrangements are stable and the percentages have moved, one of them as recently as 2025.
Which means the row cannot be corrected
The instinct on reading "5% is wrong for most Canadian sales" is to type a better number in. There is not one. A harmonised rate would be wrong in Alberta; a federal-plus-provincial figure would be wrong nearly everywhere and meaningless as a single value. Any edit moves the error to a different set of organizations. The row is not wrong — the shape of the table is, and that is a different repair.
The four steps from a correct row to a wrong setting
This is the part worth reading closely, and not because it is unusual. It is an extremely ordinary pattern and it is in a lot of software.
-
An organization turns its consumption tax on
A perfectly normal thing to do on the day you start issuing documents. Nobody is doing anything wrong at any point in this sequence.
-
The resolver asks the table for the country's rate
One country, one row, one number. It cannot ask "which province" because the province is not part of the key, and it cannot ask "which class of supply" for the same reason.
-
The rate is written as that organization's default
This is the step that matters. It is not held as a reference or a suggestion — it is stored in the organization's own settings, as its own default rate, where it is indistinguishable from a value somebody chose deliberately.
-
The provisioning routine returns early, and does so forever
Once a default row exists, it stops looking. There is no refresh, no re-check, and no event that revisits the question. Correcting the reference table afterwards changes nothing for that organization.
A lookup that answers a question each time can be corrected. A lookup that answers it once and stores the answer has already made a decision on somebody's behalf, and correcting the source does not undo it.
Why nobody notices
Three reasons, and they compound. The first is that the figure is plausible: 5% on a Canadian invoice is not an obviously broken number, it is a real Canadian tax rate, and it looks exactly like a considered choice. The second is that everything downstream is internally consistent — the tax, the subtotal and the total all agree, because they were computed from the same rate, so no reconciliation catches it.
The third is the awkward one. The people best placed to notice are the organization's own finance team, and they will assume the software was configured correctly at setup, because that is a reasonable assumption about software. The value was provisioned rather than chosen, and there is nothing on the screen that distinguishes those two things.
What to check, if you run our product in Canada
Five minutes, and worth doing before you trust a total
- Open your tax settings and read the default rate that is actually stored — not what it should be, what the field contains.
- Compare it to what your province's structure requires: federal only, harmonised, or federal plus a separate provincial tax.
- If it reads as the bare federal rate and you are not in Alberta or a territory, it was almost certainly provisioned rather than chosen.
- Check a document from your first month of using the system. If the rate on it matches the provisioned default, the exposure has a start date.
- If you are in a two-tax province, also read our post on the split — the total being right does not mean the record can produce either return.
The transferable version, for anyone building this
Reference data that provisions is a different category of thing from reference data that informs, and the two are worth separating explicitly in a codebase. An informing lookup can be wrong today and right tomorrow with no migration. A provisioning lookup writes into a place you do not own — a customer's configuration — and every future correction becomes a data question about who already has the old value.
- If a lookup provisions, the written value should record that it was provisioned, and from which version of the source. Ours does not, which is why the check above has to be done by eye.
- A provisioning path should have a revisit condition — even a crude one, such as re-checking when the source changes — rather than only "write if empty".
- Where a country has no single correct value, the table should be able to say so rather than holding a plausible one. Our United States row is labelled as an average, which is the least bad version of this, and it is still a number that a resolver will happily return.
What AWRA OpsHub does today
- A country tax profile with the instrument named rather than assumed — the Canada row says GST, at the federal rate, with a comment recording that provincial taxes are separate.
- Alias-tolerant country lookup, added after a name-keyed match silently provisioned four countries at nought per cent.
- Per-levy arithmetic against each levy's own base, so a two-tax stack produces a correct total.
- Comments on every row that cannot be right in this shape, naming which part of the one-rate assumption fails.
What it does not do
- A province in the key. There is a jurisdiction column on our rate table and nothing selects a rate by it.
- Any re-provisioning. Once an organization has a default rate, no correction to the reference table reaches it.
- A record of whether a stored rate was chosen or provisioned. They are indistinguishable on screen, which is why this post ends with a manual check.
- Any CRA or provincial return output.
Not ours, by choice
- We will not type a plausible number into the Canada row. It would make the table look complete and make the error harder to find, and it would be wrong for a different set of organizations rather than for none.
- We will not tell you which province a supply belongs to, or which rate your sales should carry. Those are your adviser's determinations.
A province in the key and on the record, rate selection by jurisdiction rather than by organization, and a provisioning path with a revisit condition. It is a schema change and we would quote it as one. The precedent that market-specific tax work gets finished here is Kenya — a live tax-authority integration and a maintained statutory payroll engine, both built to specification and both still ours to run. A written specification, a timeline and a price agreed before anything starts.
We would rather publish this than fix the row quietly and let the organizations already carrying the provisioned value discover it themselves. The check in the middle of this post is the mitigation until the shape is repaired.
What is not built for Canada today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Canada. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If storing the split, not just the total, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
The cheapest first build in this corpus, and then three larger ones
Persist the per-levy breakdown onto the document at the moment of saving. The figures are already computed — our engine works out each levy against its own base and returns them — and today they are discarded, leaving a blended rate and one tax type on the record. In a province levying two taxes that means the total is right and the split, which is the only thing either return needs, has to be re-derived from settings that may since have moved. Storing what is already in hand would make every such invoice decomposable for the rest of its life, and it is a fraction of the size of the capability it unlocks. After that: a tax type on the line, a province on the customer and the sale, and a return assembled from the three.
Banks and payments
EFT files and bank statement feeds wired into the Payments Register, so money in and out reconciles against the documents rather than being typed twice.
Certifications and inspections, which is where a Canadian commission usually starts
A trade ticket, a medical or an equipment examination with a date that has to be watched, and a consequence when it passes: an asset that cannot be issued, a crew member who cannot be assigned, a list somebody actually receives. Custom field sets and expiry reporting exist today; making an expiry refuse rather than notify is the small build, and it is the same shape of work as the certificate stop we would do in Guyana. Seasonal resupply planning per location — lead times driven by a window rather than a reorder point — is the other one we would expect to be asked for here.
Payroll and statutory returns
A Canadian payroll engine with CPP and EI contributions, T4 and record-of-employment production and provincial levies computed on live employee records. None of it exists today; labour cost attribution to projects and cost centres does.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedThe one-line version
A federal rate is not a national rate, and a table with one row per country cannot tell the difference. If you are Canadian and running our product, the number in your settings field is the thing to look at — it was probably provisioned, and it looks identical to a choice.
Check the field, not the documentation
If your default rate reads as the bare federal figure and you are not in Alberta or a territory, that is worth a conversation before it is worth a quarter of invoices.
Read the Canada page