The day it said Disimpan

The screen said Disimpan. It is Indonesian for saved. On the afternoon of 14 August, Coretax accepted a file generated by KAZENA Books for the first time. The signal that 2 months of work were over was a single word that we had not written any part of.

Here is what we were doing. KAZENA Books can produce withholding certificates. Beyond that point, though, a person was reading the numbers off our screen and typing them again into the government system: the counterparty number, the amount paid, the rate, the period covered. One certificate at a time, the same information entered twice. We wanted that to stop. The file format is published, so we only had to produce a file that matched it. We had something that looked like valid XML on day 3.

A file that looks valid does not get accepted. Between that first file and Disimpan, we were rejected 27 times. I will go through where it fell over, in order. Looking back, every one of them was ours.

The first was the number. The counterparty NPWP does not exist, it came back. Our test data used numbers with the right shape, the right length and the right separators. But the receiving side checks the number against a register, and a number that is not in the register does not pass, however well formed it is. That is correct behaviour. What it meant was that numbers we had invented ourselves would never get through this path, not once. We got no further until we tested with our own company number and with a number that V, an accountant in Jakarta, told us we could use for her office. She has tested KAZENA Books with her office's live data more than 20 times, and here again she was the one who worked out which numbers we were allowed to try. Every number in this post is an illustrative one.

Next was the digit count. NPWP is in the middle of moving to 16 digits, and we were still sending 15, with dots and a dash between the groups. We were writing the display format straight into the file. Strip the separators, send 16 digits. That took 2 days, because the formatting for the screen and the data for the wire came out of the same single function. Fixing one broke the look of the other.

The smaller failures, together. Three rejections on the period: we were putting the month of the payment date straight into the reporting period. Two on the amount: the rupiah has no decimals, and we were sending 1,500,000.00, because the type we use in the accounting code still had its default of 2 decimal places. The rate was wrong the same way, since we wrote 2% as 0.02. One on a symbol: a counterparty name containing an ampersand, which XML will not take as it stands. We had left the escaping out of the name field and nowhere else.

The one that took longest gave no reason at all. What came back was a single short line saying the document could not be processed. No line number, no field name. It took 4 days. It had nothing to do with the contents: it was the order of the elements. The specification fixes the sequence, and our file listed the fields alphabetically by name. To a person reading them, the two files say the same thing. To the system receiving them, they did not.

The order in which they passed is worth recording. BPA1 went through on 14 August, BPMP on the 17th, BPPU on the 20th. All three are built by the same code, and 6 days separate the first from the last, because each form differs a little in which fields are required and in what order they have to appear. I had assumed that once one passed, the rest would follow. That was my mistake.

We also had to correct what Disimpan means. When I asked E about it, he told me it is saved, not submitted and not accepted. He lives in a small town some way outside Jakarta and reviews the wording we show in the local language. I had been about to display Submission complete. What the government system is saying is that it has kept a draft. After that there is a submission step, and then a confirmation that it was accepted. Widen the meaning of one word in translation and the person using it closes the screen believing a process is finished when it is not.

Here is what we changed. Before sending, we check what we can check ourselves: that the number is 16 digits, that the amounts are whole, that the sequence matches the specification. And when something is rejected, we print the returned message exactly as it came, with our translation underneath it and a note of which form and which field. We stopped showing only our own paraphrase in a single line. Some words really do change meaning on the way through a translation.

What I learned about design is not subtle. The tests we write test our own understanding; they do not test the rules of the party receiving the file. Of the 27 rejections, our own tests could have caught 4 in advance. The other 23 we found by sending the file out and having it refused. Whether something built from a specification matches that specification is not settled until you hand it to whoever holds the specification.

I should say plainly that I am not a tax accountant. Forms and procedures change, and which form applies depends on the shape of the transaction. The numbers in this post are illustrative; only the dates and the counts are records of our own work. Please confirm anything about an actual filing with a professional.

One request. If a submission of yours is rejected with a message we cannot yet translate, send us the message as it came. The short line that came back helps us more than a long description of it. What 27 rejections taught us was how to read lines like that.