Our year-to-date began where our records did

There is a field on the withholding screen in KAZENA Books labelled year-to-date. The figure in it was calculated correctly. What the screen never said was what the figure had been calculated from: only the payments recorded in our own ledger. For anyone who started using us partway through the year, that year-to-date did not start at the year.

V told us. She is an accountant in Jakarta and has tested KAZENA Books with the real data of her own practice more than 20 times. What arrived on 19 August was an image with her spreadsheet and our screen side by side. For the same payment to the same recipient, the amount withheld differed by 6,000,000 rupiah. Which one is right, she asked. Hers was.

Here are the numbers. That recipient had been paid 90,000,000 rupiah in March and 120,000,000 rupiah in August. The March payment was made before this ledger moved to KAZENA, so it is not in our data. The cumulative for the year is 210,000,000 rupiah, which under the progressive rates comes to 25,500,000 rupiah for the year. By March, 7,500,000 rupiah had already been withheld, so the August withholding should have been 18,000,000 rupiah. Our screen said 12,000,000 rupiah, because it treated the August payment as the first one of the year.

The software did not miscalculate. Across the data it held, the arithmetic was right. What was wrong was the name we put on the figure. The moment you write year-to-date, you are talking about the calendar, and the calendar belongs to the world, not to our database. We counted what was in our hands and gave it a name that belonged to the world.

We counted. Of the ledgers in trial use, 61 use the withholding feature. Of those, 23 started partway through the year — their first recorded payment falls after 1 January. Within those 23 there are 9 where at least one recipient was paid both before and after the switch. That affects 34 certificates, and the shortfall in withholding comes to 41,200,000 rupiah in total.

Migration is not the only road out of our data. A branch pays in cash and the paper reaches the books later. A company keeps separate ledgers per line of business and the same recipient appears in both. A stretch of time where the bookkeeping has not caught up. Our software sees what has been recorded. A payment that was never recorded does not fail to exist; it fails to be visible.

The design fault is easy to state. Every figure we compute has a boundary. The software knew where its boundary was, and did not say. Our test data had the same shape: every ledger we built for verification begins in January. We had never once built a ledger that starts partway through the year.

It is worth writing down why nobody reported it. This figure does not wear a wrong face. The digits, the formatting, the total row are all in order, and it does not contradict last month's figure. A number that is consistent on the inside cannot be caught unless you check it against the outside. V could catch it because she keeps her own spreadsheet. Looking only at the software, I doubt anyone would have.

Here is the fix. Under the cumulative field there is now one line saying what the figure is made of: that it counts only the payments recorded in this ledger, and the date of the earliest of them. If that earliest payment falls after 1 January, the line changes colour and asks for anything paid before it — 2 fields per recipient, the cumulative before the switch and the tax already withheld. You can go on without filling them in, but the fact that you did not now stays on the screen.

E rewrote my first draft of that line. He lives in a small town some way outside Jakarta, and he reads wording like this back to me in the local language. My version said this total is based on KAZENA's data. That reads as a claim that the basis is solid, he said, and the point is the opposite. It now says payments not recorded in this ledger are not included. The two sentences say much the same thing, and what a reader does afterwards is not the same.

For those 34 certificates we sent the list and the working behind the correct amounts. Anything already submitted to Coretax needs a correction filed. Filing it, paying the shortfall, and carrying whatever a late payment costs all fall on the business, not on us. One line we left unsaid leaves our side and turns into somebody else's paperwork and somebody else's money. That felt like the part to write down honestly.

I should say this plainly. I am not a tax accountant. Withholding depends on the recipient's status and the shape of the contract, and corrections have a procedure of their own. The numbers here are illustrative, to explain the mechanism. If any of it sounds familiar, check the payments made before the switch in any ledger you started partway through the year, and please confirm the final judgement with a professional.

While we were at it we went through every total we display. Inside KAZENA Books, 7 figures were claiming a period wider than the data behind them. All 7 now say what they leave out. Before a number is right or wrong, it should state how far it looked. If a total anywhere in KAZENA comes out smaller than you expected, tell us. What is missing is probably not your record.