Sales Tax Is Not a VAT, and the Difference Is Structural
They are both a percentage added at the till, which is where the resemblance ends. One is collected in stages and reclaimed; the other is collected once and avoided with a document. Software built for the first models the second incorrectly rather than incompletely.
If your software was built for value-added tax and you are asked to support US sales tax, the temptation is to treat it as the same problem with different rates. It is not, and the difference is not a matter of degree. A VAT is collected in stages and reclaimed by registered businesses along the way; a US sales tax is collected once, from the final buyer, and is not reclaimable by anyone. Every structural consequence follows from that one distinction, and there are more of them than people expect.
This matters commercially as well as technically. A vendor who has confused the two will demo something that looks right and will have built a model that cannot produce a correct return. The purpose of this post is to give you the four questions that tell the difference.
Four differences, and each one breaks a different part of a schema
Value-added tax
- Charged at every stage of the chain, and reclaimed by each registered business in it.
- A registered buyer's real cost is the net figure. The tax washes through them.
- A return nets output tax against input tax, so both sides have to be recorded.
- Exemption is mostly about what was sold — the class of supply.
- The rate follows the seller, so a country-keyed rate is a workable simplification.
US sales tax
- Charged once, at the last stage, to a buyer who cannot reclaim it.
- The tax is a real cost to whoever pays it, unless they are buying for resale.
- A return reports tax collected, by jurisdiction. There is no input side to net.
- Exemption is mostly about who bought it, and is evidenced by a certificate.
- The rate follows the buyer, so a company-level setting is not the right shape of thing.
What each difference does to the data model
No input side means the hard problem moves
In a VAT market, the difficult half of a return is input tax: what you paid, at what rate, on what, and whether it is recoverable. We have written about that at length in a UK context, because that is where our own schema is weakest. None of it transfers here. A US return does not ask what you paid; it asks what you collected. So a system that is bad at purchase-side tax is not thereby bad at sales tax — the weakness is somewhere else entirely, which is the mistake this post exists to prevent.
Where a US return is demanding instead is granularity. Tax collected has to be reported by jurisdiction, which means every sale needs to carry the jurisdiction it was taxed in, not merely the amount of tax. A single tax total for a period is useless. That is a different schema requirement from a VAT return's, and it is one a country-keyed rate model cannot meet at all.
Exemption is a document with a life of its own
This is the difference most often modelled as a boolean, and a boolean is the wrong type. A resale or exemption certificate is issued under a particular state's rules, is held on file by the seller, applies to a particular kind of purchase, and can expire. It is evidence you produce under audit. What that needs in a schema is a record: an issuing jurisdiction, an identifier, a date, an expiry, a link to the customer, and a link to the sales it was relied on for.
A checkbox on a customer that says "exempt" cannot carry any of that. It cannot tell you which state's exemption, cannot expire, and cannot be produced as evidence — and if the audit covers three years, the question is not whether the box is ticked now but whether it was valid then. We are not offering a view on when a certificate applies; that is your adviser's. The modelling point stands independently: exemption is a document, and documents have dates.
Our own version of this, said plainly
Our customer record has an exemption flag — a boolean, no issuing state, no expiry. Until 5 August 2026 no tax calculation read it either, so a customer marked exempt was charged anyway; that half was a defect and it is fixed. What remains is the modelling point this section is about, and it is not fixed by reading the flag: a boolean cannot tell you which state's exemption, cannot expire, and cannot be produced as evidence for a period. We mention it because a post about how other people model exemption badly would be worth nothing without it.
The rate follows the buyer, so the rate is not a setting
A VAT rate is a property of the supply, and a supply's seller is in one country, so a country-keyed rate is a workable simplification. A US sales tax rate is a property of the destination, so it changes per customer, and per delivery address for the same customer. There is no value you can put in a company-level settings field that is right more than accidentally. This is not "the default needs overriding often" — it is that a default is not the right shape of thing.
There is no national rate, and averages are worse than blanks
Reference tables want a number per country. For the United States there is not one, and our own table holds a figure explicitly labelled as an average — an average of rates that never apply together, which is a number with no referent. We have deliberately left it labelled rather than corrected, because there is nothing to correct it to. An average in that field is more dangerous than an empty one, for the same reason a populated tax column with no rate beside it is more dangerous than an empty column: it looks like an answer, so nobody asks the question.
Four questions that separate the two models
Ask a vendor selling you US tax capability
Which field on the sale carries the taxing jurisdiction?
What a good answer sounds like
A named field on a named record, stored per sale.
What a bad answer is telling you
If tax is stored as an amount and a rate with no jurisdiction, no return can be produced from it, however accurate the totals are.
How do you store an exemption certificate — not the file, the record?
What a good answer sounds like
An issuing state, an identifier, an expiry and a link to the sales it covered.
What a bad answer is telling you
A boolean means exemption cannot be evidenced for a period, only asserted for today.
Where does the rate come from, and who maintains it?
What a good answer sounds like
A specialist service, named, with an integration. Or an honest "you configure it".
What a bad answer is telling you
A vendor maintaining thousands of jurisdictions as a side line is describing a liability they have not priced.
Do you net input tax against output tax anywhere in your US reporting?
What a good answer sounds like
No, because there is no input side to net.
What a bad answer is telling you
If the answer is yes, the model is a VAT wearing a sales tax label, and the returns it produces will be wrong in a way that balances.
The uncomfortable conclusion for a VAT-shaped product
Ours is VAT-shaped, and being honest about what that means is more useful than a roadmap. The tax model assumes a rate per organization, a single tax type per document, and a return that nets two sides. A US-capable model needs a jurisdiction per sale, a certificate record per customer with dates on it, and a return that aggregates one side by jurisdiction. Those are not settings. Reshaping is real work, and the honest version of it involves an integration with a service that does nothing but rates, rather than us claiming to keep a rate table current.
What AWRA OpsHub does today
- A VAT-shaped tax model that works correctly in VAT markets: a rate per line, item treatment, per-levy arithmetic against each levy's own base.
- A document vault with scheduled retention, where a certificate can be stored as a file against a customer.
- Machine-readable exports in CSV, XLSX and JSON for handoff to whatever produces your returns.
- Procurement, inventory, projects and governance, none of which depends on which tax regime you are in.
What it does not do
- A jurisdiction on the sale, which is the field a US return is aggregated by.
- An exemption certificate record with an issuing state, an identifier and an expiry.
- An exemption that is more than a boolean. The flag is read now, which fixes what a customer is charged and not what you can prove. There is still no issuing state, no expiry and no link to the sales it covered.
- Any US sales tax calculation, return or filing.
Not ours, by choice
- We will not tell you whether a certificate applies to a purchase, or when one is valid. That is your adviser's determination and software with a view on it invites reliance it cannot carry.
- We will not maintain US rates ourselves. The responsible version of this capability is an integration, and we would say so in the specification rather than after it.
- We will not report a US position by netting two sides. There is only one side, and a model that nets is wrong in a way that balances.
A jurisdiction per sale, a certificate record with dates, per-customer settings that are read, and an interface to a specialist rate service. Four pieces, priced as four. 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.
What is not built for the United States 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 the United States. 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 a jurisdiction on the record, and settings that are actually read, 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.
Three builds, and we would decline the fourth
A jurisdiction field on the customer and on the sale — a real field, not a state parsed out of a free-text address line, which is the cheap version and produces confidently wrong returns. Then per-customer tax settings that are read rather than only stored: the exemption flag, the registration number and the override rate all exist on the customer record today and no tax calculation looks at any of them, which is a defect fix rather than a feature. Then the interface a specialist tax service plugs into, so the rate comes from something that does nothing but rates. What we would decline is the fourth build — a US rate table we maintain ourselves. Thousands of jurisdictions with rules that move is not a thing to own as a side line, and we would rather say so in a specification than discover it in year two.
Banks and payments
ACH origination and bank statement feeds wired into the Payments Register, so money in and out reconciles against the documents that authorised it rather than against a spreadsheet.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
A US payroll engine with federal and state withholding, FICA, quarterly and annual returns, state unemployment insurance and multi-state allocation for employees who cross state lines. None of it exists today.
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 VAT has a recovery problem and a sales tax has an evidence problem. If a vendor answers your sales tax questions with input-tax capabilities, they have solved the wrong half — and the returns their model produces will reconcile perfectly and still be wrong.
Four questions, one conversation
Ask them of us. We have answered them above and the answers are checkable against our schema, which is the only kind of answer worth having.
Read the United States page