By KYN AI Advisory Team — AI implementation specialists, Singapore
We match bank lines to invoices by scoring candidate matches and showing the reason for each score. The system never posts a match to the ledger by itself. A named person confirms, edits or rejects every suggestion. This costs a few seconds per line and removes the one failure that hurts: a wrong match posted silently into the books. For related background, see how to automate bank reconciliation in Singapore.
Why not post matches automatically?
Auto-posting looks like the whole point of automation. It is not. The point is to remove the search, not the decision.
A bank line has a date, an amount and a free-text description. An invoice has a number, a customer, a total and a due date. The link between them is an inference. Customers pay two invoices in one transfer. They pay in part. They deduct a bank fee. They type the wrong reference. A rule that is right 97 times in 100 is wrong on three lines, and in accounting a wrong line is not a rounding error. It moves money between customers, misstates receivables and sends a chase email to someone who paid.
Posting is also hard to reverse. A wrong match feeds the aged receivables report, the GST return and the month-end pack before anyone looks. Undoing it means finding it first.
So the design splits the work in two:
- The system does the search, the scoring and the explanation.
- A person does the confirmation.
That split holds the speed gain (the search is the slow part) and keeps accountability with a named human.
How does the matching work?
We treat each unmatched bank line as a query and each open invoice as a candidate. Then we score.
- Amount. An exact match to the invoice balance scores high. A match to the sum of two or more open invoices for one customer scores high too, and is flagged as a combined payment. A match within a known fee tolerance scores medium, with the difference shown.
- Reference. An invoice number found in the description scores high. A partial number or a customer name scores lower.
- Counterparty. The payer name on the line is compared with the customer on the invoice and with names that customer has paid from before.
- Date. The payment lands after the invoice date and near the due date. A payment before the invoice exists is a red flag.
- History. If this customer's earlier lines were confirmed against certain invoices, that pattern adds weight.
Each suggestion carries its parts. A reviewer sees: "Amount equals INV-1042 balance. Payer name matches customer. Reference not found." That is the reason, in plain words. Without it, a score is a number nobody can check.
The output is a ranked list per line, not a single answer. The top suggestion is pre-selected. The reviewer confirms with one action or picks another candidate.
What does the reviewer see and do?
The screen is built around one decision per line. It is a table, not a wizard.
| Column | Content | |---|---| | Bank line | Date, amount, description | | Suggested match | Invoice number, customer, balance | | Reason | The scored parts in one line | | Confidence | High, medium or low, from the score band | | Action | Confirm, change, split, reject |
Three rules shape the workflow:
- High-confidence lines are grouped. A reviewer can confirm a batch of exact amount-plus-reference matches in one pass, after scanning the reasons.
- Low-confidence lines are never pre-selected. The reviewer chooses, and the system records that choice.
- Splits and partials are explicit. One line can be allocated across invoices, with the residual shown and unallocated until the person assigns it.
Nothing posts until the person acts. Each confirmation writes the match to the ledger with the actor, the time and the reason that was shown. The audit trail answers "who matched this, and why did the system suggest it" months later.
How do suggestions improve over time?
Every confirmation and every correction is a labelled example. We use them in two ways, and neither one lets the system act alone.
- Counterparty memory. If "ABC TRADING PL" has paid Customer X four times, that alias is stored against Customer X after a person confirms it. The fifth line scores higher.
- Rule review. If reviewers keep changing one kind of suggestion, such as matches that ignore a fee, the pattern shows in the correction log. A person then decides whether to change the scoring.
We do not let the model rewrite its own scoring weights unseen. A change to how suggestions are scored is a change to controls, so it is reviewed like any other.
What did this look like on a real ledger?
On one manufacturer's system, we reconciled a ledger of 3,309 rows with zero duplicates. Zero duplicates is a property we test for, not a hope: a bank line can be matched once, an invoice balance cannot go below zero, and a line cannot be re-imported under a different row. The database refuses these states, so a reviewer cannot create them by mistake.
The same discipline applies to imports. Each statement row is stored with a hash of its date, amount, description and running balance. Re-uploading the same statement changes nothing.
What are the trade-offs?
- Speed. Suggestions are slower than full auto-posting. A reviewer still touches each line or each batch.
- Reviewer load. If the volume is very high and the data is clean, batch confirmation is the right setting. If it is low and messy, line-by-line review is.
- Cold start. The first month has little counterparty memory. Expect more medium and low bands until aliases build up.
The alternative is a hard rule set that posts exact matches only and leaves everything else. That is a valid choice for a business whose customers always pay one invoice with the right reference. Most SMEs in our work do not have that pattern. Foreign-currency receipts add another layer; see how to record foreign currency expenses in Singapore.
Where KYN fits
KYN builds reconciliation as part of a finance system that runs in a cloud account in your name. Matches are suggestions. Money, filings and deletions wait for a named person, and every action is logged with the actor. Agents have their own restricted accounts, and the database uses row-level security. See security for the access model.
The first 14 days are a review of your current stack and interviews with your team. A full build ships in under 90 days. Rights in the custom code and configuration pass to you on full payment, and you can revoke KYN's role while everything keeps running.
Frequently asked questions
Can bank reconciliation be fully automated?
The search and scoring can be. The decision to post a match should not be for most SMEs. A wrong match changes receivables, GST and what you chase, so a named person confirms.
What happens when one payment covers several invoices?
The system tests sums of open invoices for the same customer and flags a combined payment when one matches. The reviewer confirms the split. Any residual stays unallocated and visible until a person assigns it.
How do you prevent duplicate bank lines?
Each imported row is stored with a hash of its date, amount, description and balance, and the database rejects a second copy. Re-uploading a statement therefore adds nothing.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
