One line said: anywhere but Japan, return 0

On 2 September, looking at a monthly summary in a test account, I noticed the input-tax line had read 0 for 3 months running. There are months where 0 is correct; if none of the purchases carry tax, it is 0. But that account held 41 purchases with a faktur pajak behind them, and the tax on them came to about Rp 3,180,000. The summary was not adding up wrongly. Not 1 of the entries underneath it carried any tax at all.

It was the path. Entries typed in by hand had the tax separated out correctly. Only entries read from a photograph and then saved were folding the whole tax-inclusive amount into the expense. Inside the same month, in the same account, entries that carried tax and entries that did not sat side by side with nothing to tell them apart. Both kinds match the total printed on the paper.

Here is the cause. Where the reading is turned into a journal entry there is a function that separates out the tax. It was written for Japan: from the tax category and the rate it produced the input consumption tax. When we added Indonesia and the Philippines, I put 1 line at the top of that function. If the country is not Japan, return 0. At that point the photograph path only handled Japanese receipts. It was a line I wrote meaning to come back to it.

I added that line on 18 June. We opened the reading up to Indonesian books in July. So it stood for 2 and a half months. I found it while building the summary screen, by accident. The confirmation screen after a reading had no tax field on it at all. There was no 0 sitting there; there was no field. A value that is not shown cannot be checked by eye.

Here is what it costs. A business registered as a PKP in Indonesia pays the PPN on its sales less the PPN on its purchases. If the purchase side is not in the books, it is not subtracted, and the amount payable is settled without it. Nothing stops. No warning appears. The figures stay tidy all the way to the end, and only the total comes out larger than it should be.

What was affected was a test account and our own books. No customer account is filing with it yet. That is the only reason I can write this as a near miss. We were lucky; nothing we had built caught it. Had I found it a month later, this note would have opened with an apology.

This is the part I actually wanted to fix. We had never decided what to do when we find a mistake that touches money. Until then it was: fix it, put it in the next release, write 1 line in the change list. The same procedure as correcting the wording on a screen. Because findings that move money sat on the same shelf as everything else, how seriously one was handled depended on whoever found it.

Here is what we settled on. First, count which entries were affected and over what period, and write them into a list. Do it before fixing anything, because once it is fixed the affected entries can no longer be told apart. Then tell the people using that account ourselves. Not this is fixed, but entries of this kind in this period carry no tax, and here is why. For a finding with a money impact, what moved and by how much matters more than whether it is fixed.

Whether to rewrite past entries ourselves was the hardest call. Recompute them and the figures become correct. But software silently moving figures in books that have been closed is its own kind of accident. What we settled on is a list the person works through and chooses from. There is an operation that fixes them in bulk, but before you press it, it shows how many entries and how much money will move. Anything moved can be put back.

We changed the build as well. The per-country branch came out of the function. How tax is separated is written in a per-country table: Japan, Indonesia, the Philippines. When a country that is not in the table arrives, it does not return 0 — it stops there and raises an error. 0 wears the face of an answer. Not returning values that pretend to be answers was the most important part of this fix.

We added a test. The same receipt is saved 2 ways, once read from a photograph and once typed in by hand, and the entries that come out have to agree. Our tests until then only checked whether each path was correct on its own. For a feature with 2 entrances, each path being correct on its own and the 2 producing the same answer are different things.

The afternoon I found it, the squall came. I ended up waiting about 30 minutes under a shopfront awning, counting affected entries over a kopi susu gula aren. Jakarta's afternoon rain stops your plans and hands you the time instead. 41 is the number I came out of those 30 minutes with.

I should say this plainly. I am not a tax accountant. The conditions under which input tax may be credited, and the evidence required for it, are decided on the system's side and keep changing. What is written here is the record of a defect in our own software, which was not recording the tax at all. Please confirm any actual filing decision with a professional.

One request to close with. If you find an entry in your KAZENA books with no input tax on it, please tell me, whether or not it has since been fixed. We will count it again on our side. A mistake that touches money looks, from the user's side, exactly like a correct figure for as long as we say nothing. To be told about what cannot be seen, we should have been the ones to write down where to look.