Takeover review and invoice exception queue — Ledger Solutions

Built by Noorflows (noorflows.com) for Ledger Solutions, a practice that keeps the books for other companies. Working system, running on demo data. Every client, supplier, purchase order and invoice is invented.

The takeover review — what a practice is taking on

A new client hands over books somebody else kept. Before the practice can quote for cleaning them up, it has to know what is in there. The review reads the file and sorts what it finds into two halves.

What was read: 144 transactions across 18 months, for a client called Harborview Interiors.
Findings raised: 8.
Findings the records can settle: 4, covering 6 records. Reconciliations, supplier merges, tidying — work the practice can schedule and price by the hour.
Findings only the client can answer: 4, covering 13 transactions. Nothing in the file settles these. Each is a question to a person who may take a week to reply.

The second number is the point. Every tool in this category publishes what it found. The count that actually decides how long a cleanup takes, and therefore what it should cost, is how much of it cannot be settled without asking somebody — and that is the number nobody publishes. A quote built on findings alone is a quote for work, with the waiting left out.

How the review was measured

The demo file was built with 8 defects planted deliberately and 5 further things built to look wrong and be right — a supplier that shares a first word with another, a company alongside its subsidiary, an empty holding account, an account reconciled last month, and a large payment that does have its bill attached. The review found 8 of 8 planted defects and flagged 0 of the 5 traps.

Each trap is proven clean by name, not by counting. An earlier version compared how many findings a check raised against how many defects were planted for it and called the surplus a false flag. That is blind to the case that matters: flag a trap and miss a real defect in the same check and the count does not move, so the review reports itself perfect. A test now reproduces exactly that scenario.

Stopping contact, without saying why

A practice that keeps other people's books can be under an obligation not to disclose that it has reported something. The review's output on one side is a list of questions to put to a client, with reminders behind them, and an automatic nudge is exactly the thing that has to stop.

So there is a switch. While it is on, nothing goes out: no question, no reminder, no message. The findings stay exactly as they were and the practice's own work carries on underneath.

It gates the outbound path, not the display: Client-facing questions are produced by one function that takes the hold as an argument. Filtering at the point of display would leave the list reachable by an export or a reminder job added later, and that later path is always the one that matters.
It has nowhere to record why: There is no reason field. A reason field would be filled in with the exact sentence that must not travel, and it would then sit in the store, ride along in every export, and one day be read by somebody who did not know what they were looking at. The reason belongs in the firm's own records.
It records that a hold was placed, and by whom: Written to a trail with no delete and no edit. Who and when, never why.
It does not look for money laundering and cannot tell you whether anything is suspicious: It has no view on that at all. It is a switch that stops us contacting somebody, and a person in the practice decides when to use it.
It does not tell anyone whether to report anything, or to whom, or by when: That decision belongs to whoever the firm has made responsible for it. It is not for us to advise on, and software offering a view would be wrong at the moment it mattered.
It cannot stop a person picking up the phone: It stops the system — the part that would otherwise send something at three in the morning without being asked.

What the review cannot do

It cannot tell whether a payment was for the business: Nothing in a ledger records intent. Where a payment goes to a merchant that could be either, the review says it cannot be settled and stops. It never states that an expense is personal.
It cannot produce a document that is not there: Where the handover records no receipt, the review reports that the handover does not say. It does not treat an unknown as documented.
It cannot say anything about what happened before the handover: Opening balances arrive already wrong or already right, and the file does not show which.
It reads only what it was given: "Nothing was found" and "nothing was searched" are different sentences, and the review is written not to say the first when it means the second.

What the monthly system does

A supplier invoice arrives. If it agrees with what was ordered and with what actually turned up, there is nothing for a bookkeeper to decide, and it posts itself. If it does not agree, it goes into a queue with the reason and the evidence attached, and a person decides.

Nothing is ever paid or blocked automatically. The system's job is to take the invoices that do agree off a person's desk, and to make the ones that do not agree quick to deal with.

The measured number

Posted without a person: 74 of 100 — 74%
Stopped for someone to look at: 26 of 100
Built to be stopped, and stopped: 26 of 26
Built to look wrong and be right, and correctly left alone: 8 of 8

This is the straight-through rate: how many invoices needed no human decision of any kind. Accepting a suggested account code counts as a decision, because it is one — counting those as automatic would have produced a much better figure and a dishonest one.

Where the count stops

It covers one stretch of the job: an invoice arrives, it is checked, it is posted to the ledger. Paying it is not included, because no money leaves on this system's say-so. The rate the industry quotes covers a longer run, through to payment being released, so the two are not the same measurement sharing a name. Ardent Partners, benchmarking 212 accounts-payable teams in 2025, put the best-in-class touchless rate at 49.2% counted that longer way. Read against that figure, 74% is not a better result. It is a shorter race, run on a hundred invoices we built ourselves and publish in full below.

What the number deliberately is not

It is not extraction accuracy — how well a machine reads fields off a page. That is a solved problem with public benchmarks and published results in the mid-to-high nineties. Any figure we produced would sit below them and prove nothing about us. What is not solved, and what a bookkeeper is actually buying, is what happens to the invoices that do not simply agree.

What the hundred contained

The mix is ours. We chose how many go wrong and in what way, which makes the rate a property of this test set and not a measurement of anyone's real postbag.

Billed above the agreed price — 4: All stopped.
Billed for more than arrived — 3: All stopped.
A service with no order to match against — 3: All stopped, and routed for approval rather than matching.
Documents that could not be read — 3: All stopped, each with the reason named.
Billed before anything was booked in — 2: All stopped.
An extra line nobody ordered — 2: All stopped.
A printed total that does not match the lines — 2: All stopped.
A supplier with no history to code from — 2: All stopped.
A supplier with too little history to be sure — 2: All stopped.
The same charge re-issued with a new date — 1: Stopped.
The same reference re-typed off a statement — 1: Stopped.
Correct in every way except the account number — 1: Stopped.
A monthly charge repeating last month's amount — 2: Correctly left alone.
The first sighting of an invoice a later one copies — 2: Correctly left alone.
Over the order, but not by enough to be worth a person — 2: Correctly left alone at the client's own setting. Tighten the price tolerance and these are the first to move.
Well over on percent, and worth pennies — 2: Correctly left alone. Only the cash floor saves these; remove it and they stop.

Those last four sit deliberately near a threshold. Without them the tolerances were never exercised at all — every other invoice in the set is either priced exactly on the order or far over it, so moving the settings changed nothing and the rule the whole design turns on went untested.

Those last two rows are the ones worth reading twice. A check that stops them is worse than one that never ran, because a queue full of correct invoices is a queue nobody reads.

The two controls this category expects

Duplicate invoices.: A duplicate is not a duplicate file. Nobody sends the identical document twice — the supplier re-issues it with a new date, or someone keys it again off a statement with a slash and a leading zero added. Both are found. The invoice number has to agree first, once punctuation and leading zeros are set aside; everything else is corroboration. Allowing even one character of slack is wrong here, because invoice numbers are sequential and consecutive invoices from one supplier are one character apart by construction.
Bank details that have changed.: Invoice redirection works by sending a real-looking invoice from a real supplier with one field altered. Every other check passes and the money goes to someone else. This compares the account printed on the document against the one on file, shows both, and asks for confirmation by telephone on a number the firm already had — not one printed on the invoice. It never calls it fraud: suppliers do change banks, and the alert fires the same either way.

What it will not do

It finds no duplicate re-issued under a completely new number.: From the two documents alone that is indistinguishable from two genuine deliveries billed correctly. Telling them apart means checking what actually arrived, which is a person's job.
It checks nothing that was never recorded.: Work nobody raised an order for, or a delivery nobody booked in, cannot be matched — only approved by whoever asked for it.
It guesses at nothing it could not read.: A blurred photograph, a missing second page, handwritten amounts — each is named and the file goes to a person as it arrived. No amount is inferred, because a wrong figure that looks right is posted without anyone looking twice.
It codes nothing on a hunch.: An account code is filled in automatically only where this supplier's own history has settled it three times over with nothing disagreeing. Anything weaker is a suggestion and waits.
It pays and blocks nothing.: Every invoice that stops goes to a person with the reason and the evidence attached.

Where the tolerances sit

A price is questioned only when it is over the order by more than 2% AND by more than $5.00 — both, not either. A percentage on its own waves through hundreds of dollars on a large line; a cash floor on its own turns every small line into an exception. Being billed below the agreed price is never an exception. A part delivery is normal and is not one either; being billed for more than arrived always is, at any size.

Tax is held on the invoice line, not on the header total. One invoice carrying two rates is ordinary, and a system that stores a single tax figure against the total cannot represent it or code it to the right accounts. Money is held as whole minor units throughout, because a floating-point total drifts by a penny and that penny is reported as the supplier's error rather than ours.

Data

The public demo and any live system are separate stores that never touch. No real accounting record is ever copied into the demo, for any reason, including testing. One set of credentials per build; no key that can read across two of them; no personal data in shared logging.

Every rule described on this page — each tolerance, each control, each published figure — is covered by an automated test, and the numbers above are checked against the system's own measurement rather than typed in. Model versions last checked 2026-08-08. Page written 2026-08-08.

The working demo · Noorflows

How this handles your data — where it lives, what we keep, and the independent security reviews we have not had.