Revolutionizing Cheque Processing with Powerful AI

Why manual cheque entry is still a bottleneck

A clerk keying a cheque reads five things: the account details, the amount in figures, the amount in words, the payee and the date. Four of the five are handwritten, in whatever hand the drawer happened to have. Throughput is capped by how fast a person can read handwriting, and it does not improve with volume — a clearing day twice the size takes twice the people.

The errors are the expensive part. A transposed amount is not caught by the person who made it, and by the time reconciliation surfaces it the funds have usually moved. That is why cheque processing tends to be double-keyed: not because one clerk is unreliable, but because the only cheap way to catch a keying error has historically been to have somebody key it twice.

What an AI cheque extractor actually reads

A cheque is not a free-form document. It is a fixed set of fields in roughly predictable positions, which is what makes it tractable.

The MICR line

The band of characters along the bottom edge carries the bank, branch, account and cheque number in a font designed to be machine read. It is the most reliable thing on the document and the natural anchor for everything else: if the MICR line parses, the extractor knows which bank's layout it is looking at and where the remaining fields should be.

CAR and LAR, and why both

The amount appears twice — once in figures in the box (courtesy amount, CAR) and once written out in words (legal amount, LAR). Reading both and requiring them to match is the single most valuable check in cheque automation, because the two fields are written independently by the same hand. A model that misreads a digit will rarely misread the corresponding word in the same way, so a CAR/LAR disagreement is a reliable signal that the cheque needs a human. Where they agree, the confidence is far higher than either field could justify alone.

This is also why the legal amount matters legally as well as technically: where the two disagree, banking practice in most jurisdictions treats the written words as authoritative.

Payee, date and signature

The payee name is the hardest field, because it is unconstrained text and often a company name that no dictionary contains. Dates matter disproportionately in the Gulf because of how routinely post-dated cheques are used — an extractor that reads the date correctly but does not flag that it is three months in the future has not finished the job. Signature verification is a separate problem from extraction, and worth treating as one: comparing a signature against a mandate is a matching task, not a reading task.

Why Arabic cheques are harder than English ones

Most published accuracy figures for cheque OCR are measured on Latin-script, Western-numeral documents. A cheque drawn in Oman frequently is neither, and the gap between those two situations is where most GCC deployments run into trouble.

Three things change. Numerals may be Eastern Arabic (٠١٢٣٤٥٦٧٨٩) rather than Western, and the two sets appear on the same document often enough that a system has to handle both without being told which to expect. The legal amount is written in Arabic, which is cursive by default — letters join, and the segmentation problem that makes handwriting recognition hard in any script is harder when there is no reliable gap between characters. And the layout is right-to-left, so field positions derived from an English-language template simply do not transfer.

None of this is insurmountable, but it is not free either. It is the difference between a system trained on the documents a Gulf bank actually receives and one adapted to them afterwards.

How to judge an accuracy claim

Vendor accuracy numbers are close to meaningless without knowing what was measured. Character-level accuracy of 99% sounds strong and is nearly useless: a fifteen-character field with 99% per-character accuracy is wrong about fourteen percent of the time. Field-level accuracy is the honest measure, and it should be quoted per field, because payee recognition and MICR recognition are not remotely the same difficulty.

The number that actually predicts value is the straight-through rate: the share of cheques processed end to end with no human intervention at an agreed error tolerance. A system that clears 70% automatically and routes a well-chosen 30% for review will usually beat one claiming higher raw accuracy but offering no confidence score to triage on. Ask what happens to the cheques the model is unsure about — a good answer describes a review queue, not a silent guess.

Gains in production come from removing the double-keying step and shrinking the exception queue, and they vary widely with cheque quality, script mix and how much validation already exists. Any figure worth relying on is one measured on your own documents during a pilot, not one carried over from another bank's.