A field you can type in is a permission

Please remove the PPN field from the invoice screen. That request reached us on 11 August. One short line, no reason given. To give away the ending: we did not remove the field. We made it impossible to type into. The PPN field has indeed disappeared from that person's screen, but the place we changed is not the place we were pointed at.

Some background. In Indonesia, only a business registered as a PKP may add PPN — value-added tax — to an invoice. Registration becomes compulsory once annual turnover passes 4.8 billion rupiah, and is optional below that. If a business that is not registered writes PPN on an invoice and collects it, that is not money it is entitled to hold. So for many of our users this was not a field they simply did not need. It was a field they were not allowed to use.

Our screen did not say that. The invoice entry screen always showed a PPN field below the amount, and anyone could type a number into it. That is what comes of moving the look of a paper invoice straight onto a screen. On paper, a field you do not need is a field you leave blank. Paper does not distinguish between a field you may leave blank and a field you must not fill in. Neither did our screen.

I counted. There are 612 active sets of books. Of those, 449 are set to not registered as a PKP. Among those 449, there are 37 that have issued at least 1 invoice with a number in the PPN field. Counted as invoices, that is 214 of them.

What was inside them was not what I had expected. In 9 of those 37, the number in the field was not PPN at all but withholding tax: the 2% of PPh 23. A tax that is deducted had been written into the box for a tax that is added. The invoice total comes out 2% higher than it should be. And the withholding that ought to have been recorded is recorded nowhere. Two mistakes at once, on 1 invoice.

I thought about why the 2 get mixed up. Both are tax, and both are numbers that sit near the bottom of an invoice. The only difference is direction. PPN is added to what the customer pays. Withholding is subtracted from what you receive. I described this to V, an accountant here in Jakarta who has tested KAZENA Books with her firm's live data more than 20 times. She said the 2 run in opposite directions and yet stand there on the screen wearing the same face. She also said that people who are used to this do not tell them apart by looking at the screen; they tell them apart from what they already know. We had not built a screen that could be relied on for it.

There were 2 reasons we did not simply delete the field. The first is that the buying side needs it. A business that is not registered still receives invoices from suppliers with PPN on them. It cannot claim that tax back, but the amount paid still has to be recorded. The second is that PKP status changes. Once turnover passes the threshold a business registers, so there are businesses that were not registered last year and are this year. What we needed to write down was not remove or show, but what decides it.

Here is what we changed. Company settings now carry 1 item: whether the business is registered as a PKP. If it is not, the PPN line does not appear at all on a sales invoice. Not greyed out — absent. A field you can see but cannot fill leaves the person using it to guess why. If the business is registered, the PPN amount is calculated from the lines and the rate and shown. It cannot be typed over. The number is now decided in 1 place.

We gave withholding tax a place of its own on the same screen. There is now a withholding line below the invoice, marked so that it reads as a number being taken away. The order of the totals is fixed: subtotal, PPN, withholding, amount to be received. We wanted the order itself to say which numbers are added and which are subtracted. We fixed the label as well. It used to read simply tax amount. A field that does not say which tax leaves every reader picturing a different one.

We have not rewritten the 214 invoices. We decided some time ago that we do not correct numbers in someone else's books on our own judgement. Instead, the 37 affected accounts were shown a one-time notice listing the invoices concerned, asking that the contents be checked with their own professional. For the 9 where withholding had been mixed in, we wrote individually. Whether a correction is required is not ours to decide.

The design lesson is not subtle. A field you can type into is a signal that the number is yours to decide. We had treated whether to show a field as a question about appearance, and treated whether the contents were right as the business of whoever was typing. In fact, the moment we show a field, we are saying: you may write here. And what decides whether they may was sitting in the settings, on our side, the whole time.

To be clear: I am not a tax accountant. Rates change, thresholds change, and whether PKP registration is required depends on the business and on who it trades with. What is written here is the record of us fixing our own screen. For anything you actually have to decide, please confirm it with a professional.

One request. If you find a place in KAZENA where the name of a field and the number you actually put into it are not the same thing, tell us. A field you can go on using by renaming it in your head looks, from our side, like a field that works. What started this was 1 line with no reason attached. Even if the reason is not clear to you, send it first — the counting is our job.