The rule we wrote in 2 places

INV-2026-0001. One set of books held 2 invoices carrying that number. Different customers, different amounts. One was issued on 2 July, the other on 4 August, and both were produced correctly by our own screens. Nobody mistyped anything. We were the ones who issued the same number twice.

V found it. She is an accountant here in Jakarta who has tested KAZENA Books with her firm's live data more than 20 times. On 20 August she went looking for an invoice she had issued the month before, searched by its number, and 2 came back. Which one are we talking about? The number no longer decides. An invoice number is the name you use later to point at 1 document. The moment a name is shared, it has stopped working as a name.

Some background. In KAZENA Books, each set of books defines how its invoice numbers are formed: a prefix, the year, and a 4 digit sequence. There is a second setting for when that sequence goes back to 1. Until June the only choice was every year. Enough people asked for a monthly reset that we added it in June.

The trouble is that 2 separate places were deciding things about the number. One decided how the number is assembled — how the prefix, the year and the sequence are joined. The other decided when the sequence returns to 1. In June I changed only the second one. The sequence now restarts every month, but the month itself never entered the number. July's first invoice and August's first invoice came out as the same string.

I had meant to change both. That is the honest version: I did not forget the other place, I believed I was finished once I had changed one. The rule looked like a single rule to me. In my head, what keeps a number from repeating was 1 idea. In the code it was 2, and the 2 sat far apart.

The tests were split the same way. The test for assembly checks that the prefix, the year and the sequence join correctly. The test for the reset checks that the sequence returns to 1 when the month changes. After the June change both were green. Each was correctly testing its own half. A rule cut in 2 cuts its tests in 2 as well, and from either side of the cut nothing looks wrong.

We counted. There are 612 active sets of books, and 31 of them had chosen the monthly reset we added in June. Between 1 July and 20 August, 58 invoices shared a number with another invoice in the same books, across 12 sets of books. I could say that is not many. Those 58 have already gone out to the people on the other side of the transaction.

There was a third place. E found that one. He lives in a small town some way outside Jakarta and always works right through the app on his own handset before we ship. When he pressed the button that duplicates an invoice, the new one came out numbered 1 above the original. That path had its own numbering code, a third way of counting, looking at neither the month nor the year. It produced 4 more collisions.

Here is what we changed. Numbers are now issued in 1 place. The screen that creates a single invoice, the batch that creates the recurring ones, and the duplicate button all call the same routine. The caller passes the set of books and nothing else; it cannot decide the shape, the reset, or the next figure. For books using the monthly reset, the month is now part of the number.

We also wrote the rule into the data itself: within 1 set of books, a number can be used only once. Everything above is about how the code is written; this line exists so that we do not have to rely on how the code is written. If someone writes a fourth path, the number will not save and the work stops there. Stopping is better than quietly issuing a second copy.

We have not renumbered the 58 invoices already issued. We decided some time ago that we do not rewrite figures in someone else's books on our own judgement. The 12 affected businesses were contacted individually and given the list of invoices that share a number. Whether to change a number is a question about documents already handed to a customer, so it is not ours to decide.

To be clear: I am not a tax accountant. What is required of an invoice number differs from country to country, and whether an already issued number may be changed depends on those rules and on the situation of the transaction. What is written here is the record of us fixing our own build. For anything you actually have to decide, please confirm it with a professional.

The moment you write a rule in 2 places, it is settled that one of them will go stale. The only open question is when. I used to think of myself as a careful person. What I learned here is not that I should be more careful, but that this was never a place carefulness should have been holding up. If you see the same thing in KAZENA carrying 2 numbers or 2 names, please tell us. From where we stand, both of them look right.