Getting Cheque Data Into Clearing, Not Beside It

It is entirely possible to deploy an accurate extractor and remove no work at all. The cheques get read, structured data appears, and a clerk reads that data off one screen and types it into another — because the core banking platform, the clearing interface and the ERP were never connected to it. That is extraction beside the process rather than in it, and it is the most common way these projects disappoint while technically succeeding.

Four destinations, four different contracts

"Integrate with our systems" is four projects. Each has its own format, its own timing and its own consequence when it is wrong, and scoping them as one is where timelines go.

The second row is the one with a deadline attached. Clearing runs to a cut-off, and a batch rejected on a format error at the wrong hour is not a technical incident that can be fixed tomorrow — it is a day's settlement delayed. Anything integrating with a clearing window needs validation before submission rather than error handling after it, which is the same discipline that a rejected payroll file demands for exactly the same reason.

The reference that ties it together

One design decision does more for a cheque deployment than any accuracy improvement: every item gets a single identifier, assigned at capture, that travels to all four destinations and back.

Without it, tracing one cheque means matching on amount and date across three systems, which works until two customers pay the same round figure on the same day. With it, "show me this cheque" is a lookup: the image, the extracted fields, the posting, the clearing reference and the outcome, all reachable from one value. Every investigation, every customer query and every reconciliation break resolves through that identifier, and its absence is felt every day without ever appearing as a defect.

Exceptions are the integration, not an afterthought

Most integration effort gets spent on the path where everything works, which is the path that needs the least design. The exception paths are where a deployment is actually judged, and there are four that recur.

Low confidence. An item the extractor is unsure about must stop before it posts, not after. That means the confidence threshold sits upstream of the integration, and the review queue is part of the flow rather than a report.

Amount disagreement. A CAR/LAR mismatch is a policy decision, not a posting — it should never reach a downstream system unresolved, and it needs its own handling.

Not yet presentable. A post-dated item must be held in a state the integration understands, or it will be posted the day it is captured, months early.

Returned after posting. A cheque that clears and then comes back has to reverse cleanly in every system it touched, tied to the same reference. This is the path most often left for later, and it is the one where a missing design shows up as a manual journal entry every week.

Measure typing, not accuracy

Field-level accuracy tells you how well the model reads. It says nothing about whether work was removed. The number that answers the actual question is the share of cheques that reach their final destination without a human keystroke — and it is the one to agree before deployment, because it is the only figure that can fall while accuracy holds.

A useful companion metric is keystrokes per exception. A review queue where each item takes four seconds and one where each takes four minutes have the same exception rate and completely different staffing consequences. That difference is almost entirely interface design: whether the reviewer sees the relevant crop of the image beside the field in question, or has to go and find it.