Buying Operations Software in the US: A Straight Guide
We do not do US sales tax at all, and that is the first thing on the page rather than the last. Here is what to ask everyone else, what to ignore, and the five things that should take us off your list.
We do not calculate US sales tax. Not partially, not with a workaround, not with a rate table you maintain — there are no state rates, no local rates, no jurisdiction resolution, no destination-based calculation, no returns and no filing. If your operations system needs to do that, stop reading, and you have saved yourself a demo and three follow-up calls.
The rest of this is written on the assumption that you are still here, which means your tax is handled by an accounting system or a specialist service and what you need from an operations system is procurement, inventory, project cost, approvals and governance. Those are genuinely built. This guide is about how to evaluate them, and about the questions we would ask if we were the ones buying.
The five exclusions, in full
| What is missing | What that means in practice |
|---|---|
| No sales tax capability | No rates at any level, no jurisdiction resolution, no returns, no filing. Tax on a sales document comes from one rate configured on your organization, which is not how US sales tax works. |
| No jurisdiction on the customer | There is no state, province or postal-code field. The rate could not be keyed to a destination even if the calculation existed. |
| The per-customer override rate does not apply | The exemption flag on the customer record is read — that was a defect and it was fixed on 5 August 2026. The override rate beside it is still stored and not applied, because it is a feature rather than a correction. |
| No US payroll engine | No federal or state withholding, no FICA, no quarterly or annual returns, no state unemployment insurance, no multi-state allocation. Labour cost is attributed to projects and cost centres, which is useful and is not payroll. |
| No US reference customer | Nothing here is a case study. This product was built in Nairobi and its live tax-authority integration is Kenyan. |
Where we are a straightforward fit
Not a feature list — a shape of business.
- Your tax is somebody else's job, whether that is an accounting package, a specialist service or an outside firm, and you want clean exports rather than a second tax engine.
- Your real problem is procurement discipline — requests, approvals, purchase orders, receiving and matching, with the approval attached to the order rather than sitting in an inbox.
- You hold inventory across more than one location and need transfers, counts, adjustments and per-item movement history rather than a current-quantity number.
- You run projects or jobs with cost attribution, and you want budget checks at the point of commitment rather than a report afterwards.
- You need a governance trail on decisions: who approved what, at which threshold, and what changed since.
Where you should rule us out
| If this is true of you | Why we are the wrong choice |
|---|---|
| You sell into more than one state and need tax calculated | There is no jurisdiction on the customer and no rate resolution. This is not a configuration gap. |
| You have exempt or resale customers to manage | The flag works — an exempt customer is not charged — but there is no certificate record with an issuing state, an identifier or an expiry. You can stop charging a customer; you cannot evidence why, for a period, under audit. |
| You want payroll in the same system | There is no US payroll of any kind. Our one statutory payroll engine is Kenyan. |
| A US reference customer is a requirement | We do not have one, and describing similar work elsewhere is not the same thing. |
| You need a specific compliance attestation to buy | We publish a compliance matrix rather than attestations, and two of its thirteen rows carry a code-verification date while eleven explicitly do not. If procurement needs a certificate, that is a straight no. |
Why the tax gap is at the top rather than in a footnote
We could have opened with procurement, which we do well, and mentioned tax somewhere near the bottom. A US reader needs the tax answer in the first thirty seconds because it decides whether the rest is worth reading at all. Burying it would win more demos and waste more of your time, and the trade is not close.
Six questions to ask every vendor, including us
None of these can be answered from a brochure
Which field on the customer carries the taxing jurisdiction, and which field on the sale?
What a good answer sounds like
Two named fields.
What a bad answer is telling you
If the answer is the address line, ask what happens to addresses that do not parse — and ask to see it fail.
Who maintains the rates, and what happens the week a jurisdiction changes one?
What a good answer sounds like
A named specialist service with an integration, or an honest "you do".
What a bad answer is telling you
A vendor maintaining thousands of jurisdictions as a side line has not priced the liability.
Show me an exemption certificate on a customer record. Not the file — the record.
What a good answer sounds like
An issuing state, an identifier, an expiry, and the sales it was relied on for.
What a bad answer is telling you
A checkbox cannot be evidence for a period, only an assertion about today. Ours is a checkbox: it correctly stops the tax, and it proves nothing.
Can you produce tax collected by jurisdiction for a period, from stored data?
What a good answer sounds like
A report, run live.
What a bad answer is telling you
A single tax total for a period cannot become a return, no matter how correct it is.
What exports exist, and in what formats?
What a good answer sounds like
CSV, XLSX and JSON, with a schema you can inspect.
What a bad answer is telling you
PDF-only reporting means every downstream handoff is re-typing, which is the thing you are buying software to stop.
Name a US customer at my scale I can speak to.
What a good answer sounds like
A name, or a straight no.
What a bad answer is telling you
A hedge is a no that has not been said out loud. Ours is a no.
Three things worth ignoring
First, "supports US sales tax" as a line item. It is true of a system with one configurable rate and it is true of a system with a live jurisdiction service, and those are not the same product. The question is which record the rate is keyed to, and it takes one sentence to answer.
Second, compliance badges without a scope. A claim on a features page is not a statement about anything checkable. The useful version names the capability and its limits — which obligations the software can evidence and which it cannot. Ours are set out row by row, and the rows that have not been verified in code say so.
Third, any promise about where your data lives that sounds like a switch. Hosting region is a property of a deployment. A US-region deployment is a real thing to buy and price; a per-organization region toggle does not exist here, and we published otherwise until we checked and corrected it. If a vendor offers you the toggle, ask which column it is stored in.
What AWRA OpsHub does today
- Procurement end to end — requests, approvals, purchase orders, receipts, three-way matching, supplier records and prequalification.
- Inventory across warehouses and locations, with transfers, approvals, counts, adjustments and item-level movement history.
- Projects, time and budget control, including checks at the point of commitment.
- Governance — roles, permissions, approval thresholds and an audit trail of who changed what.
- A document vault with a scheduled retention and purge job, plus machine-readable exports in CSV, XLSX and JSON.
What it does not do
- Any US sales tax capability — no rates, no jurisdiction resolution, no returns, no filing.
- A jurisdiction field on the customer, which everything else waits on.
- The per-customer override rate. The exemption flag beside it is read; this one is not.
- An exemption certificate record with an issuing state, an identifier and an expiry.
- A US payroll engine, in any part.
Not ours, by choice
- We will not tell you where you have nexus. It is a legal determination about your own activity.
- We will not read a state out of an address string to make a demo work.
- We will not maintain a US rate table. The responsible version of this capability is an integration with a service that does nothing else.
- We would decline a US sales tax build as a first engagement. It is our largest gap and the worst possible introduction to working together.
- We have no US reference customer, which given the length of the middle column is the sentence to weigh most heavily.
Narrower than "US sales tax", and we would rather be specific than impressive: a jurisdiction on the customer and the sale; the override rate on that customer record, which is the last piece of it still inert; and the interface a specialist rate service plugs into. The exemption flag used to head this list and does not any more — it was a defect rather than a feature, so it was fixed rather than quoted for. Three pieces, priced as three. The precedent that market-specific 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.
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
If your tax is handled elsewhere and your problem is operations, there is a real and short conversation here. If you need your operations system to determine and file destination-based tax, we are the wrong choice today — and you now know that from the first paragraph rather than from month three.
Tell us who 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 piece of scoping rather than a rate table anybody has to maintain.
Read the United States page