We wrote “estimated” on every field

Typing 1 receipt in by hand took 40 seconds. Having the same receipt read from a photograph, checking what came out and then saving it took 1 minute 20. That is what I got at the end of August, timing 20 receipts at my own desk. The feature we had built to make entry easier was, at that point, taking exactly twice as long.

The cause was not the accuracy of the reading. It was the wording on the screen. When the reading finishes, a band of 1 line appears above the fields: this content was estimated by AI, please check it before saving. We thought we were being honest.

Of the fields lined up under that band, the total, the date, the currency and the shop's name are copies of characters visible in the photograph. Either it read them or it did not; there is no state in between. When it read them, the figure sitting there is the figure written on the paper.

Meanwhile, the same screen also held values written nowhere in the photograph. The account. The match to a registered counterparty that fills the counterparty field. The treatment of input VAT. Every one of them was chosen on our side. And those fields carried no mark at all. There was 1 band at the top of the screen and nothing written at the values themselves.

So the word estimate sat on the parts that were certain, and nothing sat on the parts we were actually guessing at. Hang 1 word over everything and it says nothing about where the danger is. V's report took this shape: if all of it is an estimate, I have to check all of it. She is an accountant in Jakarta who tests KAZENA Books with the live data of her own practice.

Here is what actually happened. When a handwritten receipt was read, the shop's name was matched to whichever registered counterparty was closest in spelling. The characters had been read correctly. Only the matching was wrong. That counterparty's name sat in the screen, with nothing to say where the name had come from. It was noticed 3 weeks later, because that counterparty's monthly total looked larger than it should have. The mistake was in 1 place, the amount was small, and nothing had been filed yet. We corrected it, but we were not the ones who noticed.

Here is why it happened. The band was a sentence written once, when the screen was built. The values are made somewhere else. The part that assembles the reading and the part that fills in the missing fields were written separately, and neither had a mouth with which to tell the screen what it had done. Certainty that does not travel together with the value never arrives where the value is.

Here is the fix. Every field now carries 1 of 3 states. The first is a value read from the paper. Press it and the matching place in the photograph is framed for you. The second is a value we supplied; underneath the field, in short words, is what we supplied it on the basis of. The third is a field that could not be read.

The third took the longest to settle. Before, we put a plausible value into fields we could not read, because coming back with a blank makes a feature look weak. Now we come back with the blank and write what could not be read: the date could not be read. After the change, the share of fields returned blank rose from 2% to 9%. The higher figure is the correct one. Part of the old 2% was values we had made.

We fixed the supplied values too. A counterparty match now says, with the name spelled out, that we matched this to the registered counterparty Toko A. We considered showing a score for how certain the match was, and dropped it. Being shown 0.82 does not change what the person does next. With the name shown, anyone who knows it is wrong knows on the spot. Undoing it takes 1 action beside the field.

We swapped out the wording as well. We took the term AI out of every field label. What matters to the person using it is not which part of our software the value came from, but whether it came from their own paper or was decided by us. The word estimate stayed only on the fields we decided.

We measured again. Per receipt, from reading to saving, 35 seconds. It came out shorter than typing by hand because there are fewer fields left to check, not because the reading itself got better; we did not touch that. Before anything ships, E photographs receipts on his own device and tries it. He is in a small town some way outside Jakarta, and in pictures taken at dusk in a dim shopfront, far more fields come back unread. A screen that honestly says it could not read is worth more in a place like that.

I should say this plainly. I am not a tax accountant. How an account is chosen, how input VAT is treated, what is accepted as supporting evidence — all of it is decided on the system's side and keeps changing. What is written here is a record of how we fixed the wording on our own screen. Please confirm any actual judgment with a professional.

One request to close with. If you have ever looked at a KAZENA screen and could not tell whether a value came from your own document or was put there by us, please tell me. A misreading will happen sooner or later. What is worse than that is having to review everything because you do not know where to look. That is our failure to write it down.