CHEQUE PROCESSING
Every cheque read, verified and locked before it moves on.
Reading, matching and a verdict you can open.
WHAT ARRIVES
Built for the cheques you actually receive.
Handwritten, photographed, faxed, and stapled into a stack.
Every cheque read, matched, verified and locked.
PROOF
The system counts its own corrections.
Every correction a person makes is written to the audit trail with the field, the old value and the new one. The accuracy figure is not a claim we make. It is what that trail adds up to.
Read how it is measured →
FAQ
The questions we actually get asked.
Including the ones where the answer is no.
What can we upload?
PDFs, photographs, scans and Word files, which are converted for you. A multi page document is split and each page is read on its own, and pages with no cheque on them are skipped rather than queued for a person to dismiss.
What happens when a reading is uncertain?
It stops instead of guessing, and it says why. A due date that reads as being in the past is never filled in for you. A due date that falls before the cheque was printed is rejected outright. When the figures and the written amount disagree, or when two independent readings disagree and neither can be trusted, the field is left empty and the reason is written beside it.
Can a locked record be changed?
No, and that is the point of locking it. A correction afterwards goes through a revision request with a category and a written reason, which an administrator approves or rejects with a note of their own. The original value, the proposed value and the decision all stay on the record.
Does it notice the same cheque twice?
No. We would rather tell you that than imply otherwise. A duplicate is caught by the person reviewing the batch, and there is a delete reason for exactly this case, so a removed duplicate still leaves an explanation behind.
What if the reading service is unavailable halfway through a batch?
The batch waits instead of failing, and carries on from where it stopped once the service is back. If a field had to be read by the standby route, the reviewer is told so on the field itself and asked to check it. If an upload is retried after a dropped connection, it continues the original attempt rather than starting a second one, and a retry carrying different files is refused rather than quietly accepted.
What can our own systems pull, and when?
Only transactions that are locked. That is checked on every single read, not once when access is granted, so a record that is reopened stops being readable immediately, its images included.
Who can see which batches?
A branch sees its own work and nothing else. Operators upload and match but cannot lock. Reviewers verify, save and raise revisions. Administrators see every branch and decide revisions. Signing in takes a password and a one time code, and a session that goes quiet closes itself.
Can we remove a person’s details later without losing our totals?
Yes. Staff attribution can be stripped from historical records after an approved cut off date while the processed counts stay intact, so an erasure request does not put a hole in the accounting.
Start with one concrete workflow.
A document flow, a conversation line, an approval process. Live in weeks.