One Field Wired and One Deliberately Not
A customer record can carry a tax profile: registration, a number, an exemption, and a rate override. Ticking the exemption genuinely exempts them. Typing the rate override does nothing, on purpose, and the page says so. The rule that separates the two is the most useful thing on this page.
Every product has fields that do less than they appear to. What is unusual is a product that has decided, in writing, which ones are allowed to.
The test
It is recorded in our own source, and it is the reason this page exists: can a user set this and reasonably believe it does something?
If yes, and it does nothing, that is a defect. Not a gap, not a roadmap item — a defect, to be fixed. If the answer is no, because the page says plainly that it is not applied, then it is an unbuilt feature and can wait.
That distinction is worth more than any single field, because it is a rule you can apply to any software you are evaluating, including ours.
A tick box that lies is a defect. A tick box that says it is not connected yet is a decision. The difference is whether the user was told.
The field that was a defect
A customer's tax profile has an exemption flag. For a period, it was written by the customer form, displayed on the customer page, and read by nothing.
So anybody who marked a customer exempt got a customer who was still charged tax. No error, nothing on screen to suggest the setting was inert, and an invoice that looked entirely normal.
That was fixed. Tax resolution now checks the customer's exemption and, where it is set, returns a disabled tax context at a zero rate. It is cached per request, because a screen pricing many lines for one customer would otherwise ask the same question repeatedly.
It is worth noticing what the fix was not. Nobody added a warning that the setting was inert, or a note in documentation. The field was made to do what a reasonable person would assume it did.
The field that is not a defect
On the same record, in the same form, there is a rate override. It is validated between zero and a hundred. It is stored. It is not applied to anything.
And that is deliberate, on two grounds worth understanding.
The first is that the customer pages say so. A user setting it is not misled, which is exactly the condition the test turns on.
The second is more interesting: applying it would change what customers are charged, in a second way, that nobody asked for. A per-customer rate override is a feature — one with real consequences for tax correctness — and shipping it as a side effect of fixing an unrelated defect would have been the wrong way to introduce it.
| Field on the customer tax profile | Stored | Applied |
|---|---|---|
| Tax registration status and number | Yes | Recorded on the customer; appears where the customer appears |
| Registration date | Yes | Recorded |
| Exemption | Yes | Yes — tax resolution returns a zero rate for that customer |
| Default tax type | Yes | Used as the customer's stated default |
| Rate override | Yes | No — deliberately, and the page says so |
| International trade allowance | Yes | Recorded |
The third decision in the same file
Worth including because it is the same instinct applied in the opposite direction.
The tax resolution used to accept an item and a category as parameters, and read neither. They were removed rather than newly honoured, on the stated ground that a rate does not vary by item or by category anywhere in this product — and that a function signature accepting an argument it discards is a promise to every caller that it matters.
Deleting a promise nobody could keep is the same act as wiring one somebody was relying on. Both are about the gap between what something looks like it does and what it does.
Why a customer-level exemption is worth checking in a small, open economy
Because in an economy where a large share of trade crosses a border, exemption is not an exotic case. A meaningful proportion of a Lesotho seller's customers may be treated differently from the domestic default, and that treatment is a property of the customer rather than of the item.
Which makes a per-customer exemption flag exactly the right shape for the problem — and made the period during which it did nothing exactly the wrong kind of quiet failure. An invoice charged tax when it should not have been is not a rounding error to the customer receiving it.
What AWRA OpsHub does today
- A tax profile per customer holding registration status, a registration number and date, an exemption, a default tax type and an international-trade allowance.
- The exemption honoured in tax resolution, returning a disabled context at a zero rate, cached per request.
- Tax applied per line on invoices, with the document-level tax context frozen in a snapshot at the time of raising.
- A published test governing whether an unwired field is a defect or a gap, and the reasoning recorded in the source rather than in a ticket nobody can read.
What it does not do
- The per-customer rate override. It is stored, validated and not applied, deliberately, and the customer pages say so.
- Any rate variation by item or by category. Those parameters were removed rather than honoured, because no such behaviour exists.
- Automated filing or transmission of anything outside Kenya.
- Any validation of a customer's tax registration number against an authority.
Not ours, by choice
- The exemption is a switch, not a regime. It turns tax off for that customer; it does not model a reduced rate, a zero-rating with recovery, or a reverse charge.
- The rate override remaining unwired is a decision we would defend: shipping it silently would change what customers are charged without anybody asking for it.
- Nothing here is specific to Lesotho. It is what a per-customer tax profile is worth; a small open economy is where a large share of your customers are non-standard.
What is not built for Southern Africa 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 Southern Africa. 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 revenue authority pipeline, 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.
Tax pipelines and return output
Return output in the shape your revenue authority expects and electronic invoicing against any prescribed interface, with retries, a failure queue and a reconciliation report.
Banks, EFT and card acquirers
Bank statement feeds, EFT and debit-order files and card acquirer settlements pulled into the Payments Register so receipts match invoices without re-keying.
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
Payroll tax and social security schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt each month.
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 integratedThree questions to ask of any settings screen, anywhere
Which fields on this screen change behaviour, and which are recorded only?
A good answer sounds like
Two lists, without hesitation.
What it actually means
Every product has both. A vendor who cannot separate them has not audited their own settings, which is how a field that lies survives.
Set the exemption and show me an invoice for that customer.
A good answer sounds like
No tax on it.
What it actually means
Watch the document, not the setting. This is a thirty-second test and it is the only one that proves the wire exists.
Is there a field here that is stored and not applied?
A good answer sounds like
Yes, and it is labelled as such.
What it actually means
The honest answer is almost always yes. What matters is whether the user is told on the page rather than in a release note.
Our position
The exemption works and you can rely on it — test it once on a real invoice anyway, because that is a good habit with any tax setting in any product. The rate override does not work, on purpose, and the page tells you so. If you need per-customer rates rather than per-customer exemption, treat that as a requirement to raise rather than a box to tick.
Test your tax settings against a real document
One exempt customer, one invoice, one look at the tax line. It takes a minute and it is worth doing after every configuration change, in any system.
Review the tax setupFrequently asked questions
Does the exemption apply at the till as well as on invoices?
Tax resolution is shared, so a customer identified at the point of sale resolves the same context as one on an invoice. The practical caution is that a counter sale often has no customer attached at all, in which case there is no exemption to find — which is a process question rather than a software one.
What would the rate override do if it were wired?
It would replace the resolved rate for that customer with the stored figure. It is unwired because turning it on changes what customers are charged in a second way that nobody has asked for, and because a per-customer rate is a feature with tax consequences rather than a convenience.
How do I know which other settings are inert?
Ask, and test the ones that matter against a real document. We publish the ones we find — a bin capacity that enforces nothing, a count-plan frequency that schedules nothing, a pick sequence that sorts nothing — and the honest position is that publishing them is the only reliable way anybody finds out.
