The Column That Nothing Reads
A column that exists, accepts writes, and is read by nothing is worse than a missing column — because the missing one is visibly missing, and this one looks like a feature.
Your organization's tax rate can be given a start date and an end date. It has been able to since February 2026. Both are accepted and stored faithfully. Nothing anywhere in the product ever reads either one. We found this while writing a page about a country whose tax regime changes on 1 January 2027 — which is to say, while looking for exactly the feature those two dates appear to be.
This post is about that class of defect, because it is common, it is nearly invisible, and it is the one kind of gap that a feature list will actively mislead you about. A missing capability announces itself: the screen has no field, the API rejects the parameter, the answer is no. A dormant capability does none of that. It has a field, it accepts your input, it saves without error, and it does nothing.
The three states a field can be in
| State | What you see | What happens | How you find out |
|---|---|---|---|
| Absent | No field. The API rejects it. | Nothing, and you knew that. | Immediately, during evaluation. |
| Live | A field. It saves. | Something reads it and acts. | It works. |
| Dormant | A field. It saves. No error, ever. | Nothing at all. | When the thing you were relying on does not happen — typically on the date you were relying on it. |
How ours got that way, which is the ordinary way
Nobody was careless. A tax rate table was designed properly, with the columns a tax rate table ought to have — a jurisdiction, a rate, a validity window. Then the code that resolves a rate for a document was written to answer the question actually being asked at the time, which was "what is this organization's default rate", and the natural way to answer that is to select the row marked as the default. The date columns were not ignored on purpose. They were simply never part of the question.
That is how most dormant columns happen: a schema designed for a general case, and a query written for a specific one. The schema is aspirational, the query is real, and nothing in between fails.
The schema was designed for the problem. The query was written for the ticket. Nothing failed in between, which is exactly why nobody noticed.
Why "just add a date filter" is not the fix
It is tempting to think this is a one-line change. It is not, and understanding why is useful when a vendor tells you it is.
Adding a date predicate to the rate lookup immediately raises the question: which date? Today's date is right for some callers and wrong for others. A document being raised now should use the rate in force now. A credit note against a two-year-old invoice should not. A provisioning routine that gives a new organization its defaults has no document date at all, because there is no document — the organization is registering today, and today is the correct answer for it. So the date has to be threaded through every caller, each caller has to decide what date it means, and one of them legitimately has no answer.
There is a second problem, and in our case it is the one that would bite first. Marking a rate as the default demotes the previous default immediately. So a user who dutifully enters next year's rate and marks it as the one to use has just changed today's rate. A user who does not mark it has entered a row that will never activate. The two available behaviours are "too early" and "never", and there is no third.
The full state of ours, measured
Four things, all measured rather than remembered. One: neither date is ever read — both of the ways a rate gets resolved pick whichever rate is marked as the default and stop there, with no date consulted and nothing running on a schedule. Two: provisioning never sets them, so every rate we create starts with both dates empty. Three: they can be entered and stored, and it changes nothing, except that marking a rate as the default applies it at once. Four: both creating and updating a rate discard the figure you submit and substitute the current value from our country reference, so a future rate could not be pre-entered even if the dates worked. Published on our Liberia page and pinned by a test, so that fixing it has to be deliberate.
Finding dormant fields in something you are buying
Three questions that separate live fields from decorative ones
What reads this field?
What you will hear
A named process, report or job — or a pause.
How to read it
The pause is the answer. A live field always has somebody who can name its consumer, because somebody wrote the consumer.
What happens on the date I put in this box?
What you will hear
Ideally a description of a scheduled process and when it runs.
How to read it
"It becomes effective" is a restatement of the label, not a description of a mechanism. Ask what runs.
Can you show me it working with a date in the past?
What you will hear
A demonstration, or a reason why not.
How to read it
Backdating is the cheapest possible test of a date field, because the effect should already have happened. If it cannot be demonstrated, it is not implemented.
None of those questions require technical knowledge and all three are hard to answer evasively. They are also, notably, questions you can ask about our product — and the answers are on our Liberia page in more detail than we would like.
The short version
A field that saves without error is not evidence of a feature. Somewhere between a schema that anticipated a requirement and a query written for a narrower one, capabilities go dormant, and nothing in normal testing catches it because nothing fails. Ask what reads the field. If the vendor cannot name the consumer in one sentence, assume there is not one — and if the vendor volunteers the dead ones without being asked, that is worth more than the feature would have been.
