The same account, under 2 names

When we saved a journal entry, we wrote the name of the account into it as text. Not only the number, but the name that happened to be on the screen at that moment, kept exactly as it was. I will come to why we did that. The result, to put it first, is that one single account came out as 2 separate rows on a profit-and-loss statement.

V found it. She is the accountant in Jakarta who tests KAZENA Books with her own real data, and she has sent back what she runs into in actual practice more than 20 times now. What arrived was a short question and a cropped image of a table: the same number, 6220, on 2 consecutive rows under 2 different names. The upper row read 4,120,000 rupiah, the lower one 1,860,000 rupiah. All she wanted to know was which of the two was the real travel expense.

The correct answer is 1 row, 5,980,000 rupiah. Our statement grouped by name, because a name is what a person reads. With 2 names there are 2 groups. The number was identical on both rows; only the totalling had split.

Where did the second name come from. In March she had renamed that account to match the wording her office uses. In the chart of accounts, the name became 1 name. But the entries posted before that still carried the old name burned into them as text, and the statement was reading the text on the entries, so both names survived, one on each side of the rename.

There is a second route to the same fault: language. KAZENA Books runs in 6 languages. She posts entries in Indonesian and does her month-end review on the English screen. If the name is burned in, the English screen shows her the Indonesian names from the moment of posting. This is not a gap in our translations. We had stored the output of a translation as though it were the thing being translated.

I counted. Her books hold 1,240 entries across 8 months, and 214 of them carried a name that no longer exists in the current chart of accounts. 6 accounts were involved. Only 2 of them split into double rows on the statement; the other 4 happened to have entries on only one side of the rename, so they stayed on 1 row. Staying on 1 row was not the safer outcome. Those rows simply wore an old name with a perfectly correct face.

Let me give the original reasoning rather than an excuse. I believed a ledger ought to be a record of how things stood at the time — that if renaming an account today also changed the appearance of last year's books, that would be a dishonest sort of record. And if I am honest, I also wanted to avoid looking up the chart of accounts every time we drew a row. If the text is already in the entry, you can simply print it.

What I had wrong was which part is the fact. The thing that cannot move about that entry is the number 6220. The name is only a tag people have hung on that number; tags get swapped, and they change with the language of whoever is reading. What I had been storing was not a fact but how one screen looked on one day. Once you store an appearance, you can no longer change the appearance later.

Other symptoms surfaced as soon as I started fixing it. Filtering entries by account name missed 20 entries that carried the old name. From the user's side, those 20 entries do not exist. The CSV export carried both names as well, so anyone who totalled it in a spreadsheet took the split figures home with them.

The fix itself was simple. An entry now holds only the number, and the name is looked up at the moment of display, from the chart of accounts in force, in the language of the person reading. The migration stripped the old text from 214 entries. Before stripping it, we compared the burned-in name against the name resolved from the number for all 1,240 entries. In 6 cases the name and the number disagreed. That was not a display problem: those 6 entries had been posted to the wrong account in the first place. She is working through the list now.

Not everything should be resolved fresh, though. The name of the party you traded with, or the tax rate applied at the time, has to remain as it was even after the world changes around it. The line runs between a fact and a presentation. The counterparty's name is a fact attached to that transaction. The account's name is a tag attached to today's chart of accounts. We had been keeping both in the same drawer.

I should say plainly that I am not a tax accountant. What split here was the grouping on a financial statement, and that statement feeds a filing. An account split across 2 rows does not change the total for the year, but it does change the figure for each category. Please have a professional confirm anything final.

These days, every time I am about to store a string, I ask myself once: is this a fact, or is it how the screen looks right now. If you have ever seen the same account sitting under 2 names in the software you use, I would like to hear about it. That statement is probably grouping by name.