Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
There is no national sales tax rate in the United States, and that is not a detail — it is the whole shape of the problem. The rate is set by the state, and usually by a county or city underneath it, and which one applies depends on where the customer takes delivery. So the tax on a sale is a property of the destination, and the destination is a property of the customer record. Ours does not have one. customers holds a country, one address line, and a latitude and longitude to seven decimal places — enough to identify a building — and no state, no province, no region and no postal code. This page is about what we found when we went looking for where that question gets asked, because the answer turned out to be more interesting than "not supported": the question is asked in four places in our own code and discarded in all four.
Measured, and every row is checkable
Every row is a fact about this codebase rather than a characterisation of it, and each one names the decision it got wrong. Two of the four were fixed on 5 August 2026, the day this audit was written, and they are marked as such rather than quietly deleted: a page that lists only what is still broken hides the more useful information, which is what an audit like this actually costs to act on. The two that remain are the two that need a schema change rather than a wiring change.
The function that resolves the tax context for a sale
fixedTook a customer, an item and a product category
FIXED. It reads the customer now. The other two parameters are gone rather than newly honoured — there is no behaviour behind them, and a signature that accepts an argument it discards is a promise to every caller that it matters.
The function that provisions an organization's VAT context
fixedTook a customer and handed back an exemption flag for it
FIXED by removal. The flag was a literal false, with a comment calling it a placeholder, and had no callers anywhere. The parameter and the flag are gone; the method keeps its real job, which is provisioning an organization's rate from its country.
The region field on our tax rate table
columnA place to record a sub-national tax jurisdiction, beside the country
STILL OPEN. Written by the settings screens and never used to select a rate — rate lookup goes on organization, tax type and which rate is marked the default. Wiring it would not help on its own, because there is no jurisdiction on the customer to match it against.
The per-customer tax settings record
tableA whole record: registration status, number, date, an exemption flag, an override rate, an international-trade flag
HALF FIXED. The exemption flag is read now — a customer marked exempt is no longer charged, which was a defect rather than a gap. The override rate is still stored and not applied, deliberately: it is a per-customer rate override, which is a feature rather than a correction, and turning it on would change what customers are charged in a second way.
The record underneath all four
The tax-relevant half of the customers table. The point is the shape rather than any one row: we hold geography precise enough to find a loading dock and hold nothing that names a taxing authority.
A coordinate can be resolved to a jurisdiction, with a boundary dataset and the discipline to maintain it — which is a real product and not one we have built or would pretend to. What we will not do is read a state out of a free-text address line with a regular expression and charge tax on the result.
Why this is structural rather than partial
There is no national rate to configure
Every system that models tax as one number per country models the United States as a fiction. The number in our own config is labelled as an average, and an average of rates that never apply together is not a rate.
Sales tax is not a VAT, so the usual argument does not transfer
There is no input credit. A business does not reclaim the tax it paid on purchases; it either pays it as a cost or buys exempt with a certificate. Systems built around a VAT model get this structurally wrong rather than incompletely right.
Exemption is a document, not a checkbox
A resale or exemption certificate is issued by a state, held on file, and expires. It is evidence you have to produce under audit, and a boolean on a customer record is not that evidence.
The obligation exists before the software does
Whether you must collect in a state is a legal question about your activity there. No operations system answers it, and any that offers to is selling you a determination it cannot stand behind.
Scope, in three parts rather than two
Three columns, because "no" means two entirely different things and one list hides which is which. On this page the right-hand column is the one to read first: it contains the shortcut we will not take and the engagement we would turn down.
Real today, and none of it is a tax claim
Not built yet — and commissionable
What we would decline, and would rather say now
What is genuinely commissionable here is narrower than "US sales tax" and we would rather be specific. First, a jurisdiction on the customer and on the sale — a real field, not a parse of an address. Second, the per-customer override rate, which is the last piece of that customer record still stored and not applied. Third, the interface a specialist tax service plugs into, so the rate comes from something that does nothing but rates. The precedent for the shape of this work is Kenya, where we built and maintain a live tax-authority integration and a statutory payroll engine — real evidence that a market-specific build is something we finish. Usual terms: a written specification, a timeline and a price agreed before anything starts, and no dates on a public page.
One update first, because the page has already changed once. When it was published it said that per-customer tax settings were stored and read by nothing, so a customer marked exempt was charged anyway. That was true, it was a defect rather than a missing feature, and it was fixed the same day; the audit table above records it as fixed rather than deleting the row, because what an audit costs to act on is more useful than a list of what is still wrong. Now a word on why this page is mostly about what is missing. We could have written six paragraphs about procurement and inventory, which we do well, and mentioned sales tax once near the bottom. A US reader evaluating an operations system needs to know about the tax gap in the first thirty seconds, because it decides whether the rest is worth reading. If procurement, inventory, projects and governance are your problem and your tax is handled elsewhere, there is a real conversation here. If you need destination-based tax from your operations system, there is not, and you should know that before a demo rather than after one.
Operations in the United States
Sales tax is the part of the United States we are honest about not solving, and the sections above explain why in detail. It is worth being equally specific about the other direction, because a reader who stops there would conclude we do nothing here. Lot traceability, equipment custody, hours on a record, supplier documents with expiry dates and an approval trail that survives an audit are all shipped, and all of them are what the fifty regimes actually ask for.
Traceability
Lot and expiry that survive a recall conversation
Lot, batch and expiry held at item level with movement history, so "where did this lot go" is a query rather than a week of reconstructing delivery notes. Quality holds can block affected stock from sale while the question is open.
Assets
Inspection and service intervals on vehicles and plant
A register with a named custodian, a location, a movement history and a service record per asset. The interval comes from your regulator and the evidence lives on the asset rather than in a folder on somebody's desk — which is the form an inspector asks for it in.
Attendance
Hours are the evidence in a wage dispute
Clock records, shifts and leave held against the employee record and exportable. Overtime and break rules differ by state and we do not adjudicate them — we hold the hours, which is the part that is contested and the part that has to exist first.
Documents
Certificates that expire, attached to who they belong to
Exemption certificates, supplier insurance, tax forms and licences stored against the customer or supplier with retention that runs. Read the caveat honestly: a stored exemption certificate is a record here, not a rate decision — the schema section above is why.
Helpdesk
Requests with an SLA clock that will not stay quiet
Intake portals, queues, routing, escalation and SLA timers for internal IT or customer support, across sites in different time zones. Escalation is the feature that matters when the person who should have answered is four hours behind you.
Procurement
An approval trail that holds up when someone asks later
Requisition, threshold approval, RFQ, quotation comparison, purchase order, receipt and three-way match, with the quotes and the decision attached to the order rather than sitting in an inbox that has since been deleted.
The honest summary of this page in one line: the operational record is ours and the tax determination is not. There is also no US payroll engine — no federal or state withholding, no FICA, no quarterly returns — so labour cost attribution to jobs and cost centres is what exists on that side, and it is not payroll.
Before you buy anything
Ask where the rate comes from, not whether tax is supported
Every vendor supports tax. The question is which record the rate is a property of — the organization, the customer, or the address the goods went to. The third is the only one that matches how US sales tax works, and it is the rarest answer.
Ask what happens to a customer marked exempt
Then test it on a real document rather than taking the answer. Storing a flag and applying a flag are different pieces of work, and in our own product they came apart — which is why we now recommend the test to everybody, including on us.
Separate the tax decision from the operations decision
Most organizations that get this right run a specialist tax service alongside an operations system and connect them. That is cheaper and more accurate than one system claiming both, and it changes what you should be shortlisting for.
Questions we are asked here
Does AWRA calculate US sales tax?
No, and not partially. There are no state or local rates, no jurisdiction resolution, no destination-based calculation and no returns. On the roadmap, and commissionable now, in a narrower form than the question implies: a jurisdiction field on the customer and the sale, per-customer settings that are actually read, and an interface to a specialist tax service that does nothing but rates. We would not build and maintain a US rate table ourselves, and we would tell you why in the specification rather than after. The precedent that this kind of market-specific work gets finished is Kenya: a live tax-authority integration and a statutory payroll engine, both ours, both maintained. Specification, timeline and price agreed first, and no dates on a public page.
Our customer is tax-exempt. Can we mark them exempt?
Yes, and it works — which it did not when this page was first written, so the history is worth a sentence. The customer record has always carried a VAT-exempt flag. It was stored, it was displayed on the customer page, and no tax calculation read it, so a customer marked exempt was charged in full. We found that writing this page. Because it was a defect rather than a missing feature we fixed it rather than quoting for it: an exempt customer is now untaxed on invoices, quotations and point-of-sale sales alike, and a regression test fails if that is ever unwired. Still not applied, and we would rather say so than let you assume otherwise: the override rate on the same record. That one is a feature rather than a correction, and we will not switch it on and change what your customers are charged without being asked to.
Why not just work out the state from the customer's address?
A boundary rather than a backlog. Because it would be a regular expression over a free-text field, deciding real tax on real money, and failing silently on every address that does not fit the pattern. The right version is a jurisdiction field on the record with a maintained boundary dataset behind it — which is a real piece of engineering and a reasonable thing to commission. The wrong version is cheap, demonstrable, and produces confidently incorrect returns. We would rather have this paragraph on a public page than that feature in the product.
Can you tell us which states we need to register in?
A boundary rather than a backlog. No, and a commissioned build would not change it. Nexus turns on facts about your own activity — where you have people, property, inventory and how much you sell into a state — and it is a legal determination your tax adviser makes. Software that offered an answer would be inviting reliance it cannot carry, and the protection for you is that we hold the operational evidence your adviser needs rather than reaching a conclusion nobody would sign.
You handle VAT in other markets. Is US sales tax not the same work?
No, and assuming it is, is the commonest way vendors get this wrong. A VAT is charged at each stage and reclaimed by registered buyers, so the model needs input tax and a return that nets the two. Sales tax is charged once, at the end, and is not reclaimable — instead it is not charged at all when the buyer produces a certificate. So the pieces are different: no input credit, no netting, and an evidence-and-exemption problem where a VAT has a recovery problem. Our schema is VAT-shaped, and reshaping it is real work rather than a configuration exercise. On the roadmap, and commissionable now, in the narrow form set out above: a jurisdiction field, per-customer settings that are read, and an interface to a service that does nothing but rates. The reason we can price that instead of guessing at it is Kenya — a live tax-authority integration and a statutory payroll engine, both built to specification and both maintained. Written specification, timeline and price agreed before anything starts.
Do you handle US payroll?
No. On the roadmap, and commissionable now. No federal or state withholding, no FICA, no W-2 or 941 filing, no state unemployment insurance and no multi-state allocation for employees who cross state lines. What exists is labour cost attributed to projects and cost centres, which is genuinely useful for job margins and is not payroll. We maintain one statutory payroll engine, for Kenya, and that is what lets us price this kind of work instead of guessing at it.
Set the tax question aside. What is the product you would actually sell us?
An operations layer, and the list is specific. Multi-location inventory with lot, batch and expiry traceability and movement history per unit. Procurement from requisition through threshold approval, RFQ and quotation comparison to receipt and three-way match, with the quotes attached to the order. An asset register with named custodians, locations, movement and service history. Clock, shift and leave records against the employee record. A document vault with retention that runs, holding the supplier insurance certificates and customer exemption certificates that everyone stores in shared drives. Helpdesk queues with routing, escalation and SLA clocks. All of that is shipped, none of it is state-specific, and none of it depends on the determination we decline to make. The honest division of labour in the United States is that your tax engine decides the rate and we hold the operational record it is charged against.
Where does that leave us if we are a US business?
With a real answer either way, which is the point of the page. If your problem is procurement, inventory across locations, project cost, approvals and governance — and your tax is handled by an accounting system or a specialist service — then this is a straightforward conversation and those things are genuinely built. If you need your operations system to determine and file destination-based tax, we are the wrong choice today and you should not spend a month discovering it. We have no US reference customer, our live tax-authority integration is Kenyan, and we would rather write that sentence than have you find out in an implementation.
Further reading
US sales tax follows the customer. Our customer record holds a latitude to seven decimal places and no state field — and the question turns out to be asked in four places in our own code and answered from the organization every time.
Both are 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.
We do not do US sales tax at all, and that is the first line rather than a footnote. Then what to ask everyone else, what to ignore, and the five things that should take us off your list.
Next step
Tell us which system owns your sales tax. If the answer is an accounting package or a specialist service, the question becomes which exports and which interface — and that is a short, cheap piece of scoping rather than a rate table we would have to maintain.