The first trap was the template we handed out

I handed that template out myself. When someone moves to KAZENA Books, we give them a spreadsheet template so they can bring across the records they have been keeping in Excel: date, description, account, amount, tax category. I wrote it in a single day in the spring, and if I am honest, I was rather pleased with it. This month I learned that the template was the first trap anyone touching our product steps into.

Someone in the Philippines who uses KAZENA Books wrote with something odd: after the import, May's expenses had suddenly grown. All they had done was paste a year of records — 284 rows — into our template and press the import button. The screen had told them the import was complete. Not one error had been reported.

She let me look at the real file, and I counted. Of those 284 rows, 187 were nowhere in the books. Only 97 had arrived. Of those, 93 were sitting in the wrong month. Exactly 4 rows landed on the right date, and only because the number of the day and the number of the month happened to be the same. In practice, nothing had imported correctly.

The cause was inside the file. Our template was an .xlsx, and the date column carried Excel's date formatting. Excel writes dates back in the regional format of whatever machine opened the file. On hers, 13 August 2026 had become `08/13/26`. Our instructions said to write dates as yyyy-mm-dd. They did say that. But she had not typed those dates into the column — she pasted them. What we received was what Excel had rewritten.

Then our own side. Our importer read yyyy-mm-dd first and fell back to dd/mm/yyyy. `08/13/26` was read as day 08, month 13; there is no thirteenth month, so the row was dropped. Meanwhile `08/05/26`, written to mean 5 August, passed cleanly as 8 May. One file, 2 different ways of breaking, and which one a row got was decided by nothing more than the day of the month it fell on.

The dropped rows were the merciful ones. At least nothing is there. The frightening ones are the rows that went through. May swells, August shrinks, and the annual total is unchanged, so nobody looking at the year notices. They noticed because they happened to remember what May should have been. If they hadn't, those figures would have flowed straight into a quarterly filing.

I asked for the same template to be opened and saved on 3 machines. On the machine of V, the accountant in Jakarta who tests with her own real data, it came back as `13/08/2026` — and because 13 can only be read as a day, her rows would have imported correctly. Pure luck. On a second machine, `08/13/26`. On the machine of E, our colleague in a small town some way outside Jakarta, it came back in yet another shape. Same file, same column, same actions, a different result on each machine.

That is where it became clear. The default we ship is stronger than the instruction we write. People do not read the manual and comply; they use the thing they were handed, in the shape they were handed it. The moment we shipped an .xlsx whose date column carried Excel's formatting, we had said: the shape of a date is whatever your machine decides. Our instructions were only contradicting that afterwards, in a smaller voice.

So, first, we stopped guessing. `03/04/26` might be 4 March and it might be 3 April. A file with that shape mixed into it is no longer imported at all: we stop, and we name the column and the number of the first row where we found it. Only when the day is above 12, and the reading is therefore fixed at 1 possibility, do we carry on — and then we say which reading we used. We are reading this column as 13 August 2026; switch it if that is wrong.

Second, we stopped losing rows in silence. Before anything is written, we show the number of rows in the file, the number we can import, and the number we cannot read. The unreadable ones are listed by row number, with the text that was actually in them. Not how many are bad — which ones are bad. Nothing is written until someone has seen that screen.

Third, we fixed the template itself. It is a CSV now, and the date column is text. The first row holds 1 filled-in example that reads `2026-08-13`. Opened in Excel, a column with no date formatting on it does not get rewritten. But our order was wrong: before handing a template out, we should have built the thing that notices when a template comes back deformed. Whatever you hand out comes back changed.

What I regret most is what happened next: they went through their own records by hand. Opening a year of books, hunting for the rows that had moved months, putting them back, checking the totals again. They were only trying the product out of goodwill; nobody pays them for it. An evening of their life went to cleaning up after our bug. That is how the cost of a bug gets paid — by somebody.

To be clear, I am not a tax accountant. Imported figures flow straight on into filings, so expenses sitting in the wrong month change the tax. Please confirm anything final with a professional. What we can do is keep the origin of each number visible, so that the confirmation is short.

If a piece of software tells you an import is complete, it is worth checking once whether that screen says how many rows went in. If it doesn't, it may be dropping them quietly. And if our template did this to you as well, please tell me. I read every message myself.