The Setting That Did Nothing
Somebody ticked "tax exempt" on a customer record and the customer kept being charged tax. No error, nothing on screen, no reason to doubt it. The test that separates a missing feature from a broken promise, and how to find the ones in your own system.
There is a checkbox on the customer record marked tax exempt. Somebody ticked it, for a customer who genuinely is. The page saved, the box stayed ticked, and every invoice raised for that customer from then on charged tax exactly as before.
Nothing went wrong in any way a person could see. No error appeared. The setting persisted, displayed correctly when the page was reopened, and did nothing whatsoever, because the value was written to the database and read by no part of the system.
This was ours. It was fixed on 5 August 2026, and the more useful thing than the fix is the test that was written alongside it, because that test applies to every system you will ever evaluate.
The test
It is one sentence: can a user set this and reasonably believe it does something?
If the answer is yes and it does nothing, that is a defect. Not a missing feature, not a gap on a roadmap — a defect, because the software made a representation to somebody who acted on it.
The distinction matters more than it sounds, because the two are usually treated identically and they are not remotely the same thing.
A gap
- The capability is absent and visibly absent.
- A user looking for it does not find it.
- They go and do it another way, knowingly.
- Costs them time and a workaround.
- Fixable whenever it becomes worth building.
A defect
- The capability appears present and is not.
- A user finds it, sets it, and stops thinking about it.
- They rely on it, unknowingly, possibly for years.
- Costs them whatever depended on the belief.
- Fixable only after somebody notices, which may be nobody.
A gap costs you a workaround. An inert setting costs you whatever you were relying on it for, and you find out from a customer or an auditor.
Why inert settings happen
Nobody builds one deliberately. They appear through a sequence that is entirely ordinary and happens in every codebase of any size.
-
The field is added first
A form field, a column, a place to put the value. This is the easy half and it is usually done in one piece of work.
-
The reading is a separate piece of work
Applying the value means touching whatever calculates the thing it affects — pricing, tax, permissions — which is a different area of the system and often a different person.
-
The second piece slips
Not abandoned; deprioritised. And the first half is already released, so the setting is now visible, saveable and inert.
-
Nothing ever complains
A value that is stored and not read produces no error anywhere. Tests of the form pass, because the form works. Tests of the calculation pass, because the calculation is correct for the inputs it actually receives.
-
A user finds it and believes it
Which is entirely reasonable. It is on the page, it saves, it displays. There is no signal available to them that anything is missing.
The fourth step is why these survive so long. Almost every category of defect announces itself somehow — an error, a wrong number, something that looks off. An inert setting produces correct behaviour according to a rule nobody knows is being applied.
The one we left, deliberately
On the same table as the exemption flag there is a per-customer rate override — a field for charging a specific customer a specific tax rate. It is stored and it is not applied.
It has not been wired, on purpose, and the reasoning is worth setting out because it looks inconsistent.
The exemption flag was a defect: somebody reported it, they were relying on it, and their customers were being charged tax they should not have been. Wiring it corrected a belief people already held. The rate override is a different thing — nobody asked for it, and switching it on would change what customers are charged in a second way that nobody has requested. Turning on an unrequested pricing behaviour because the field happens to exist is how you cause the next incident rather than close this one.
So it stays unwired, the customer pages say so on screen, and it is recorded as outstanding rather than quietly removed. Which is the other half of handling these honestly: an inert setting either gets wired, gets labelled, or gets deleted. What it must not do is stay silent.
Three acceptable endings for an inert setting
Wire it, so it does what it appears to do. Label it on screen, so a user knows before they rely on it. Or remove it, so nobody can set it at all. Every one of those is defensible. Leaving it in place, unlabelled and inert, is the only outcome that is not — and it is also the cheapest, which is why it is the common one.
Finding them in your own system
You cannot read the code, so you have to test behaviour. The good news is that inert settings are cheap to find if you look deliberately, and nobody ever looks deliberately.
An afternoon that is worth more than it sounds
- List every setting your business relies on for something that costs money — tax treatment, credit limits, discount rules, approval thresholds, notification recipients.
- For each, construct the transaction it should affect and check the output. Set the exemption, raise the invoice, look at the tax line.
- Test the negative too. Set a limit low enough that it must trigger, and confirm something actually stops.
- Check the settings that were configured during implementation and never revisited. Those are the highest-risk group, because the person who set them has usually left.
- Ask the vendor directly which settings are stored but not yet applied. It is a fair question and the answer tells you a great deal about the vendor.
- Repeat after any significant upgrade. A setting that worked can be orphaned by a change elsewhere, and nothing will report it.
The third item is the one people skip. Confirming that a control does not fire when it should not is easy and proves nothing; confirming that it does fire when it should is the entire test. A threshold that never triggers looks identical to a threshold set correctly and never breached.
What AWRA OpsHub does today
- Customer tax exemption is applied, wired on 5 August 2026 after being reported as stored and unread.
- The remaining one is labelled on screen. The per-customer rate override is stored and not applied, and the customer pages say so rather than leaving a user to find out.
- It is recorded as outstanding rather than quietly deleted, so it stays somebody's problem instead of disappearing.
What it does not do
- The per-customer rate override does nothing. It is stored and not applied, deliberately — wiring it would change what customers are charged in a way nobody requested.
- No systematic audit has been published. One class of inert setting was found because a user reported it. We have not swept the whole system and claimed it is clean, because we have not done that work and saying otherwise would be the same kind of representation this page is about.
- Two related cases are documented in their own posts rather than here: two asset movement actions that exist and are written by nothing, and a hand-typed reorder point that is overwritten nightly. Both are the same shape — something a user can set that does not persist or does not act.
Not ours, by choice
- We will not wire an unrequested behaviour because a field exists. Switching on a per-customer rate override to tidy up an inconsistency would change what real customers are charged, which is how the next incident gets created while closing this one.
- We will not quietly delete a setting somebody may have relied on. Removing it silently makes the record of what they believed disappear along with the field, and they still need to know their assumption was wrong.
A per-customer rate override is a real feature and a reasonable thing to want. It is scope rather than a ceiling — but it would be specified, priced and turned on deliberately, rather than enabled because the column is already there.
This is the test we hold ourselves to and it is the test worth holding us to. If you find something in this system you can set and that does nothing, that is a defect and we would like to be told, not a limitation to be worked around.
What to ask before you buy
Two questions, and the second one is more revealing than the first.
The first is direct: are there settings in your product that are stored but not yet applied? Every system of any size has some. A vendor who says none is either not looking or not answering.
The second is better: show me your tax exemption working, end to end, on a live record. Set it, raise a transaction, and let me see the tax line. Then do the same for your credit limit and your approval threshold.
Demonstrations almost never work this way. A demo shows you the settings screen and then, separately, a transaction that behaves correctly — and the connection between the two is implied by the sequence rather than shown. Asking for one continuous path from setting to consequence takes four minutes and tests something no feature list can tell you.
The tax mechanics themselves are in tax-inclusive pricing at the till, the credit control that does fire in credit limits, and the reorder-point version of the same shape in the till sells, the reorder point does not hear it.
Our take
Take the test with you: can a user set this and reasonably believe it does something? If yes and it does nothing, that is a defect rather than a gap, and it should be wired, labelled or removed — never left silent. Spend one afternoon constructing the transactions your money-relevant settings are supposed to affect and checking the output, including the negative case where a control has to actually stop something. And in any demo, ask to see one continuous path from setting a value to seeing its consequence, because that is the four minutes no feature list can substitute for.
See a setting working end to end
Set a customer as tax exempt, raise an invoice, and look at the tax line — one continuous path from the setting to the consequence, which is the only demonstration worth accepting.
Explore sales managementFrequently asked questions
What is an inert setting?
A value a user can set, that saves correctly and displays correctly, and that no part of the system reads. It produces no error and no visible symptom — the software simply behaves as though the setting were never made. Our own example was a tax exemption flag on the customer record: it was written by the form, shown on the page, and read by nothing, so a customer marked exempt kept being charged tax with nothing on screen to suggest anything was wrong.
Why is that a defect rather than a missing feature?
Because of what the user did next. A missing feature is visibly missing — somebody looks for it, does not find it, and does it another way knowingly. An inert setting is found, set, and then stopped being thought about, so the user relies on it, possibly for years, and the cost is whatever depended on that belief. The test we published alongside the fix is one sentence: can a user set this and reasonably believe it does something? If yes and it does nothing, it is a defect.
Are there any left in AWRA?
One that we know of and have labelled: a per-customer tax rate override, stored and not applied, with the customer pages saying so on screen and the item recorded as outstanding. It is deliberately unwired — switching it on would change what real customers are charged in a way nobody has asked for, which creates the next incident while closing this one. We have not swept the entire system and would not claim it is clean, because that claim would be the same kind of representation this page is about.
How do we find them in a system we already use?
Test behaviour, since you cannot read the code. List the settings your business relies on for something that costs money, then for each one construct the transaction it should affect and look at the output — set the exemption, raise the invoice, check the tax line. Crucially, test the positive case: set a limit low enough that it has to trigger and confirm something actually stops. A threshold that never fires looks exactly like a threshold that is set correctly and has never been breached.
What should a vendor do about one?
One of three things: wire it so it does what it appears to do, label it on screen so a user knows before relying on it, or remove it so nobody can set it. All three are defensible. The only outcome that is not defensible is leaving it in place, unlabelled and inert — which is also the cheapest, which is why it is the common one. Quietly deleting it is not much better, because the user who relied on it still needs to know their assumption was wrong.
What should we ask in a demo?
Ask to see one continuous path from setting a value to seeing its consequence — set the tax exemption, raise a transaction, look at the tax line, without cutting away in between. Demos almost never run this way: they show the settings screen, then separately show a transaction behaving correctly, and the connection is implied by the sequence rather than demonstrated. It takes four minutes and it tests something no feature list can tell you.
