One chart, three readers

The invoice is for a generator. It is going to a provincial clinic, it was paid for out of money the health ministry was appropriated this year, and it will still be running in eight years. Somebody sitting at a screen has to turn all of that into a string of numbers, and the string has to satisfy three people who have never met each other.

The budget office reads the string as control. Was this authorised, is there room left in the vote (budget), could it have been stopped before the money left. The accountant reads the same string as IPSAS. Is this an asset or an expense, when is it recognised, and what does it look like on the statement of financial position in year six. The statistician reads it as GFS. Which economic category is this, so that what this country spends on health can sit in a table beside what every other country spends on health.

Three readers. One string. They are never in the room at the same time, and the person at the screen has about four seconds to decide.

That is the chart of accounts problem, and almost nobody describes it that way. It gets described as a technical exercise, a coding structure, something the system people will sort out during configuration. It is not. It is the moment where three different claims on the same transaction either get reconciled by design, or get handed to a clerk to arbitrate one invoice at a time, forever.

Start with the good news, because it is most of the story. Most of the time these three are not fighting. They are asking different questions, and different questions can live in different segments. The budget wants to know whose money and under what authority. The accounts want to know what kind of thing this is and when it counts. The statistics want to know what the economy did. Those are three questions, and a chart with three segments answers all three without anybody choosing a winner. The apparent conflicts mostly dissolve the moment you notice the readers are not even asking about the same thing.

The trouble starts when one segment is asked to answer two questions.

Take the word capital. To the budget office, capital is a side of the budget: the development vote, the projects, the money that was appropriated separately and gets reported separately. To the accountant, capital is a recognition test: does this thing meet the definition of an asset, does it have a useful life beyond the period, is it above the threshold. To the statistician, capital is acquisition of nonfinancial assets, an economic category with its own boundaries. Those three definitions overlap enough that people assume they are the same word. They are not, and a chart that uses one code to mean all three has quietly promised something it cannot deliver.

Regular readers will recognise the shape of this, because it is last week’s truck wearing different clothes. The standard says capitalise it. The financial instructions say anything bought from the recurrent budget is expenditure of the vote. Last week I argued that when those two genuinely collide, the law wins, and you disclose the departure. That is the right answer at the moment of the transaction. But it is a rescue, not a design. The chart of accounts is where you decide whether that rescue has to happen at all, or whether the same generator can be recurrent to the budget office, an asset to the accountant, and an acquisition of nonfinancial assets to the statistician, all at once, without anyone lying to anyone.

It can. That is the whole point. Those three statements are not contradictory. They are three true descriptions of one generator, and they only become a contradiction if the chart forces them through a single field.

So the design rule underneath all of this is unglamorous: one segment, one question, and the question has to be answerable by the person entering the transaction at the moment they enter it.

That second half is where charts go to die. Every segment is a question a clerk answers at every transaction, forever, and the cost of a segment is not what it costs to add. It is what it costs to answer a million times. A director asks in a workshop to see spending by region, a segment gets added, and now a clerk with a national maintenance contract on their desk has to pick a region. There is no right answer. So they pick the first one on the list, and they pick it every time, and eighteen months later the region report is worse than no report at all, because it looks like data and it is a habit.

The test for a segment is not whether somebody wants the report. Somebody always wants the report. The test is whether the answer is knowable, at the moment of entry, by the person doing the entering. If it is not, you are not collecting information. You are collecting the path of least resistance.

Then, eventually, the chart gets replaced, and you build a crosswalk from the old one to the new one. This is the reckoning, and it is worth saying plainly what it feels like, because it is the most instructive thing in the whole business.

A crosswalk is honest work. It is also a list of every question the old chart was never asked. You find them one balance at a time. A code that meant two different things depending on which office posted to it. A fund that was really a department. A line that carried both the asset and the expense because nobody had ever needed to tell them apart, and the day they needed to, the history could not be recovered. None of that was visible while the chart was in use. Everything reconciled. The reports ran. It surfaced only when a balance had to map to somewhere else and refused.

Mapping is not the failure. Mapping is where the failure finally becomes legible.

So, the working order.

First, name the readers before you name the segments. Write down who reads this chart and what each of them needs to be able to ask of it. If you cannot name three, you are designing for one and you will meet the other two later, in a crosswalk.

Second, one question per segment. If a segment is answering the budget office and the statistician at once, it is going to lie to one of them, and you will not find out which until the year it matters.

Third, apply the entry test to every segment you are about to approve. Knowable, at entry, by the person entering. If not, cut it, and get the report another way or not at all.

Fourth, write down what each code means, in a sentence, in a place people will find. Most of what a crosswalk uncovers is not bad structure. It is good structure that nobody documented, applied by people who each made a reasonable guess.

None of this is exotic. It is not a system question and it is certainly not a configuration question, though it will arrive dressed as one, usually about three weeks before go-live, when it is far too late to be having it. It is an accounting question about who has to be able to read the answer.

A chart of accounts is not a coding structure. It is a promise to three readers that the same transaction can be true in three ways at once. Make the promise on purpose, or the clerk will make it for you, four seconds at a time.