What arrived was not a bug report but a redesign of the payslip
September 24, 2026 · Taro — Founder, KAZENA
On the morning of 12 September, what arrived from E was not a bug report. It was a single drawing of how he wanted the payslip rebuilt: lines drawn by hand, showing which figure goes where and which row should be set larger. He has been with us since the early days of the company and has sent plenty of reports about our screens. But a report and a design are 2 different things.
Here is what our payslip looked like at the time. One table, 23 rows. Base pay, then several allowances, then the tax line, then the social insurance lines, and the net amount at the very bottom. The order was exactly the order in which we calculate. I suppose we thought that if we laid it out top to bottom in the order of the arithmetic, the person reading it would read it in that order too. At any rate I cannot remember ever asking anyone why it was in that order.
E's drawing split those 23 rows into 3 blocks. At the top, one figure only: the amount that reaches the person, set in larger type with nothing else around it. The second block is the pay the figure was built from. The third is what was taken out of it. In the margin he had written the reason, briefly: because the first thing anyone looks at is one number.
He had also written out how the person receiving it actually reads it. Most read it standing up, in a few seconds. They look first for the amount landing in their account, and check whether it is the same as last month. Only if it differs do they start reading the breakdown. Many photograph it to keep. The top half of his drawing was cleared for those few seconds.
We had been building the payslip as a document for the company side, a sheet for whoever handles the books to check that the amounts add up. That is why it followed the arithmetic. In reality the person who reads this sheet most often is the one being paid. We had the wrong reader in mind, and were tidying the order of the rows on top of that mistake.
He had something to say about the deductions as well. The tax line and the social insurance lines were scattered in among the allowances. On top of that, the part deducted from the person and the part the company pays separately sat in the same column, looking identical. For an item like BPJS, where there is both an employer share and an employee share, that is where misreadings come from.
And one had already happened: someone looking at a payslip from our test run asked whether that amount was being taken out of their pay too. It was not. It is paid by the company, separately. Nothing in the arithmetic was wrong. What was wrong was the placement that was supposed to say what the figure is. A number being correct and a number being understood correctly are 2 different things.
Here is the shape we shipped on 19 September. Three blocks; the A4 table is gone, and it now fits on 1 sheet of A5. The employer-paid share has been moved out of the third block to a place of its own, with 1 line saying that it is not deducted from what you are paid. The number of rows has not gone down. What went down is the number of rows you have to read in the first few seconds.
One disclaimer. I am not a tax accountant. What we changed here is only how things are shown; we did not touch the calculation of tax or of social insurance contributions. Which items belong on a payslip, and how each amount is treated, is set by the rules of the country you are in, so confirm that with a professional.
We fixed something in our own process too. The report form we had provided contained a single field: describe the problem. Tell us what is broken. There was nowhere to put a proposal, nowhere to write how you would like something built. In the end E did not use the form at all; he sent a drawing. Which means our form was shaped so that it could not receive his most valuable work. There is a field for proposals now.
A little about E. He is an Indonesian colleague who has been with us since the early days of the company, and he is not in Jakarta; he is in a town some way from here. He sees the payslips that are actually handed out there. What I see is the government's specifications and our own screens. We are building the same product, but the real thing in front of us is not the same.
A request and a design cost the person bringing them very different amounts. Asking for a fix only needs the trouble written down. Someone who brings a design has thought it through first, and has accepted in advance that it may be turned down. So what we owe in return is a quick answer, and a reason on the days we do not take it. This time we took it. We built it as drawn, and sent him what we had changed.
Tell us what you think
How the KAZENA apps feel to use, what we should fix, features you wish existed — if you run a small or medium business or work freelance in Indonesia or the Philippines, your voice is exactly what we want to hear. Messages in Bahasa Indonesia or English are answered by teammates who know your market from the inside. KAZENA Books is already set to launch in the Philippines and Indonesia — and if your company would like to bring it to other countries as a partner, or is interested in acquiring the system, we would love to hear from you too. We also take on new system development. We are a small team, so we cannot always start right away — but what we build carries made-in-Japan quality and stays close to how business really works here, one project at a time.
Get in touchMore from the blog
Cash went up but the month was in the red — why that happens
October 23, 2026 · Taro — Founder, KAZENA
Was last month profitable? Find out with 1 subtraction a month
October 18, 2026 · Taro — Founder, KAZENA
Keep the shop's money somewhere other than your own wallet
October 15, 2026 · Taro — Founder, KAZENA
