A zero is not a number

I flew into Jakarta on 30 July. It is a working-visa renewal, so I will be in this city until 26 September. Morning traffic, the afternoon downpour, the smell of satay drifting in from nowhere in particular around dusk. If you come from Japan, this city will wear you out once in the first three days. And then, somewhere around day four, it starts to be fun. That is how it went this time too.

Most of my time here goes to one thing: sitting with a local accountant while she tests KAZENA Books on her real data. I will call her V (at her own wish, only the initial). More than 20 times now, she has taken our output to the actual Coretax portal, tried to file it, and sent back the exact place it failed. Roughly half of what this product has become, it owes to her.

The report that arrived last week read like this: I exported the XML for BP21 — the withholding certificate for payments to non-employees — and the counterparty tax number comes out as 0.

I looked at the real data and went cold. She had typed 0 into the field for a person who has no NPWP. That is not her mistake. In Indonesian practice a great many forms dislike an empty box, and putting a 0 there is a widespread habit. The problem was on our side: our code took that 0 at face value and treated it as a number.

Here is what that does. The annual BPA1 form groups recipients by tax number. So two different people, both carrying a 0 for NPWP, get added together as one person. When I reproduced it with her data, two people's salaries folded neatly into a single certificate, showing 3 times the real annual income. And not one warning appeared. A bug that stops with an error is far less frightening than a bug that walks out the front door wearing a correct face.

Digging further, I found a second one. When a NIK — the national ID number — came in with 15 digits, we were padding a zero onto the front to make 16. Whoever wrote that surely meant it kindly. But padding a digit onto an ID means manufacturing a number that may well belong to a real stranger. A number with a digit missing cannot be repaired. So we stopped repairing it. We stop, and we name the row.

The fix itself is, honestly, unglamorous. We stopped writing the rules — a zero is not an ID, a NIK is 16 digits and nothing else — form by form, and put them in one place. BP21, BPMP, the annual BPA1, the buyer field on an invoice: they all ask the same function now. The root cause was never a missing clever check. It was that the same rule lived in several places. Write the same thing twice and one of the two will be forgotten.

We also moved where we stop people. We used to say this row cannot be filed only at export time. The week before, V had everything entered correctly except one single field, watched the button refuse her, and asked me: is this an error? The instructions did say to fill that field. But saying it at the entrance and stopping her at the exit — that was our failure, not hers. Now the payroll form speaks while she is still editing the row: you can save this and post it to the books; it just needs this one more thing before it can appear on the certificate.

She asked one more thing: can I see the names of the people who cannot be filed? Entirely fair. The blocking screen now lists those rows by name. Not n rows failed — who failed. Answer in people's names.

One thing I have to write down honestly: this change takes something away. Rows that used to export — a 15-digit NIK, an NPWP with the wrong number of digits — will now be stopped. Some people are worse off than before. We still think it is far better than filing a government document that carries a stranger's number.

This one incident settled something for me. The job of accounting software is not to get every box filled. It is to not lie. A blank can stay blank. Tidying an unknown into a plausible shape is by far the greater sin.

I am writing this at night over a plate of nasi goreng near where I am staying, with a glass of sweet tea full of ice. At the next table a family is having an ordinary dinner. V works here in the city. E — the comrade who has been beside me since the beginning — lives in a small town well outside it. Both of them hold ordinary jobs in this country. If I had stayed in Japan looking only at a screen, I do not think I would ever have learned what that 0 actually means to the people typing it. That, probably, is the reason to be here.

For the record, I am not a tax accountant. Please confirm any final tax position with a professional. What we can do is have the numbers arranged so that confirming takes minutes, and show you plainly where something is unknown. If you ever meet a screen in your accounting software that will not let a blank stay blank, that is the product's problem, not yours. Tell us. I read the messages myself.