Two Taxes, Two Governments, One Column
Our tax engine computes each levy against its own base and hands back the breakdown. The document then stores a single blended rate and throws the breakdown away — so the total is right and the split, which is the only thing either return needs, is gone.
A Canadian sale can carry two consumption taxes at the same time. Federal GST is 5% everywhere; on top of it, some provinces levy their own sales tax separately, some merge theirs with the federal one into a single harmonised tax, and one province and the territories levy nothing of their own. Where the two are separate they are owed to two different governments, filed on two different returns, and only one of them is generally recoverable by a registered buyer. That last clause is the reason this is a data-modelling problem and not an arithmetic one.
We are naming structures rather than rates throughout. The arrangements are stable; the percentages have moved, including a provincial reduction in 2025, and a vendor page that prints the table is telling you when it was last edited rather than what the law says. Nothing here is tax advice, and which province a supply belongs to is your adviser's determination rather than a lookup on an address.
Three structures, and only one of them is simple
| Structure | Where | What a return needs |
|---|---|---|
| Federal only | Alberta and the three territories | One figure, one government, one return. |
| Harmonised | Ontario and the Atlantic provinces | One figure, administered federally, one return. The components exist in the rate and not in your filing obligation. |
| Federal plus a separate provincial tax | British Columbia, Saskatchewan, Manitoba, Quebec | Two figures, separately, for two authorities — and the buyer's recoverability differs between them. |
The first two are well served by almost any system, because a line needs one number. The third is where software either holds the shape of the obligation or quietly does not, and the failure is invisible on the invoice because the total is correct.
The arithmetic is fine. That is what makes this interesting
It would be a duller post if our tax engine simply added the rates up. It does not. It computes each levy against its own base and returns a per-levy breakdown alongside a single blended effective rate — work that was done for Tunisia, where two levies compound and a naive sum is measurably short. So on a two-tax Canadian invoice the total that reaches the customer can be exactly right.
Then the document gets saved. And what is stored is the blended rate and one tax type. The line has a single tax rate column with no tax type beside it; the document's financial snapshot holds a singular tax type and a singular rate. The breakdown existed for the duration of the calculation and is not written anywhere.
The numbers a federal return and a provincial return each need were both computed, correctly, and then discarded within the same request.
Why that matters more later than it does today
For as long as your settings have not changed, the split is recoverable: take today's configured levies, apply them to the stored net, and you have the two figures. That works, and it is why this defect can live in a product for years without anyone noticing.
It stops working at exactly the moment you need it most. A return covers a past period. Rates move, registrations start and stop, a business changes province. Reconstructing a past split from present settings is a different operation from reading it off the record, and the difference only shows up when something has changed — which is to say, when the reconstruction is wrong and nothing indicates it.
The test to run on your own system this afternoon
Take a two-tax invoice from last year. Without referring to your current tax settings, recover the federal figure alone from what is stored on that document. If you cannot, your returns are being reconstructed rather than reported. That is a different risk from the one most people audit for, and it does not show up in any reconciliation, because reconciliations check totals.
The general principle, which is not about Canada
A document should store what it meant, not only what it totalled. This comes up constantly once you look for it: a discount stored as a final price rather than a percentage and a reason; a currency conversion stored as a converted amount with no rate; a tax stored as an amount with no rate beside it, which is a failure we have written about in a UK context. In every case the total is right and the derivation is gone, and in every case the loss is invisible until somebody has to explain the figure rather than agree with it.
The design rule that falls out of it: if a stored figure was computed from components, and any downstream obligation needs a component, store the components. Not as an audit log — as fields on the record, because an audit log tells you what happened and a field tells you what is true.
Which makes this the cheapest fix on any of our market pages
And that is worth saying plainly, because it is unusual. Most of the gaps this corpus documents are schema changes with real weight behind them — a purchase-side tax model, a per-line rate selector, a jurisdiction field. This one is: persist a breakdown you already have, at the moment you already save. The figures are in hand. Nothing needs to be computed that is not computed today.
A tax type on the line comes next, so two lines could carry two named taxes. Then a province on the customer and the sale, which is the larger piece. Then a return assembled from all three. But the first step is small, and a small step that makes every two-tax invoice decomposable for the rest of its life is a better thing to quote than a tax module.
Four questions worth asking any vendor
Ask these of anyone selling into a two-tax province
On a two-tax invoice, which fields on the document hold each tax separately?
What a good answer sounds like
Two named fields, or a related table with one row per tax.
What a bad answer is telling you
One tax field and one rate field means the split is not stored, whatever the totals look like.
Does the line carry a tax type, or only a rate?
What a good answer sounds like
A type as well as a rate.
What a bad answer is telling you
A rate alone cannot tell a federal figure from a provincial one, so no return can be aggregated from it.
If I change my tax settings today, what happens to last year's reporting?
What a good answer sounds like
Nothing — historical documents report from what they stored.
What a bad answer is telling you
If the answer involves recalculating, the reports are derived from current settings and will drift as those settings change.
Where is the province of supply stored — on the customer, or on the sale?
What a good answer sounds like
On the sale, ideally, because the same customer can take delivery in different provinces.
What a bad answer is telling you
If neither, the province is being inferred, and inference cannot be evidenced.
What AWRA OpsHub does today
- Per-levy arithmetic against each levy's own base, so a stack produces a correct total rather than a naive sum. This is the foundation and it genuinely works.
- A per-levy breakdown returned by the tax engine, with each levy's code, rate, base and share of the total.
- A tax rate on every sales line — invoices, quotations and point-of-sale lines — so a harmonised or federal-only province is expressed correctly.
- Machine-readable exports in CSV, XLSX and JSON, which is the practical handoff to whatever produces your returns.
What it does not do
- Persistence of the breakdown. It is computed and discarded; the document keeps a blended rate and one tax type. This is the smallest item and the one we would do first.
- A tax type on the invoice line. A line carries a rate and no indication of which tax produced it.
- A province on the customer or the sale. A jurisdiction column exists on our rate table and no query selects by it.
- Any CRA or provincial integration, and no return output of any kind.
Not ours, by choice
- We will not tell you which province a supply belongs to. Place-of-supply rules turn on delivery, the customer and the kind of supply, and applying them is your adviser's judgement.
- We will not publish a per-province rate table. The rates move, a stale table on a vendor page is worse than none, and the structures are the durable part.
- We will not be your filing agent for federal or provincial returns, even once an integration exists.
Persist the per-levy breakdown onto the document at the moment of saving. The figures are already computed and this is a fraction of the size of the capability it unlocks. Then a tax type on the line, then a province on the customer and the sale, then a return assembled from the three. The precedent that market-specific tax work gets finished here is Kenya — a live tax-authority integration and a maintained statutory payroll engine, both ours. A written specification, a timeline and a price agreed before anything starts.
One thing we are not doing: changing the Canada row in our country tax profile. It holds the federal rate, which is correct and is not what most Canadian sales carry — and there is no single number that would be right, so editing it would move the error rather than remove it. That has its own post.
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 correct total is not a correct record. If two authorities each need one component of a figure, the components belong on the document — and the test of whether they are there is whether you can recover last year's split without opening today's settings.
Bring a two-tax invoice
We will show you exactly which fields our schema would store and which ones it would drop, which is a more useful ten minutes than a demo.
Read the Canada page