James Carl Sitsit

OCR confidence is a routing rule, not a probability

Cashi uses a weighted completeness score and required-field checks to send uncertain receipts to review. It does not pretend to predict accuracy.

By James Carl Sitsit · From the Cashi case study

Cashi calls it a confidence score, but the number is not a prediction of how likely a receipt is to be correct. It is a routing rule.

That distinction matters because I have not benchmarked the app against a large receipt set. I have tested it with real receipts on my own phone, but calling the score a calibrated probability would be made up.

What the score measures

The parser adds weight for each field that comes back clean. The amount, the transaction type, and the date count for the most, and smaller weights go to the reference number and the other party. A score below a fixed threshold flags the receipt for manual review, and a harder rule sends any receipt missing an amount, type, or date to review whatever its score.

In practice the required-field rule does the routing. With the current weights, a receipt that has all three required fields always clears the threshold, so the threshold is a backstop that does not fire on its own. The score is kept on each saved transaction, which is what a future calibration would start from. The gate, not the number, decides whether a person has to look before the transaction is saved.

Why I still call it confidence

The name is useful in the product flow because a low value means the app is not willing to act alone. Internally, though, I think of it as completeness with weights. No model learned those weights, and I did not derive any of them from measured error rates.

That honesty keeps the feature in its lane. The parser tries to extract the right values. The gate checks whether enough required information survived extraction. A human handles the cases where it did not.

I like this more than a parser that always returns an answer. A reconciliation tool can survive asking for help. It cannot survive quietly writing a number it had no basis to trust.

What is still unproven

The current weights and threshold are design choices, not validation results. I have real-device use and passing tests, but no large OCR accuracy benchmark. I would need labeled receipts and measured false accepts before claiming the score is calibrated.

For now, the narrower claim is enough: Cashi has an explicit point where automation stops. Low or incomplete results go to review, and only confirmed transactions are written.


This is from Cashi, a Flutter app that reconciles a GCash outlet's cash and e-float on-device. The case study covers the full build.