Bank reconciliation: what the unmatched items cost

Whether the matching can be automated, what the studio's own finance engagement touched, and what an unresolved item costs: a recovery window, an escheatment clock, and an audit finding, each sourced.

By the Foxnut team · Updated 14 August 2026

What this page records

Yes, in the narrow sense the question is usually asked. Matching a bank statement line to the transaction that caused it is not a live decision once the statement arrives in a structured electronic format and the company’s own books are coded consistently: a shipped feature in at least one major accounting system already imports a bank statement, runs it against a set of matching rules, and posts the standard case without a person touching it. What is left over after that mechanical pass, the unmatched residue, is a smaller and much more specific population than “bank reconciliation” as a phrase suggests, and what it costs turns out to be set by statute more than by workload. Before any of that, how this studio hands a reconciliation system to its owner is worth reading first, because a control nobody but its original builder can operate is not a control a business actually owns.

The two populations sit inside the same statement. One is timing: a check the payee has not yet deposited, a deposit the bank has not yet processed, a fee or a currency adjustment the bank posts before the company’s ledger catches up. Left alone, most of this clears itself within a cycle or two, and a rule-based matching engine closes the rest automatically once the pattern is known. The other population is not timing at all. It is an item that does not match because it was never authorised, or because it was altered after it was issued, and a reconciliation is one of the few points in a finance process where that second kind of item first becomes visible on paper, sitting in the same unmatched queue as an ordinary timing gap and looking, at a glance, exactly like one.

What an unmatched item is actually running against

Two separate clocks start the moment a statement makes a discrepancy visible, and neither is a business decision the company gets to make on its own timetable.

The first is a recovery clock. Under the Uniform Commercial Code, a bank customer has a duty to examine a statement with reasonable promptness and report an unauthorised signature or an alteration; a customer who does not discover and report it within one year of the statement being made available loses the right to assert that unauthorised signature or alteration against the bank at all. The exposure narrows further if the same wrongdoer strikes twice: once the first forged item has appeared on a statement, the reasonable period the customer has to catch a second item from the same source can run as short as thirty days before the bank’s own liability for it ends. Nothing about that clock cares whether the item sat unmatched because nobody looked or because the volume was too high to look properly. It runs from the date the statement was available, not from the date anyone opened it.

The second is an escheatment clock, and it runs the other direction: toward a state government rather than away from the bank. An outstanding item that is genuinely unclaimed, rather than fraudulent, is presumed abandoned once it ages past its state’s dormancy period; Delaware’s general catch-all is five years for property, including an uncashed business check, that is not given its own shorter or longer period elsewhere in the statute. Once that period passes, the item is no longer a bookkeeping question a company can quietly resolve; it becomes a reporting and payment obligation to the state, and a late report is priced by name: interest of 0.5% a month on the unpaid amount, capped at 50%; a separate late-report penalty of 5% a month, capped at the lesser of 50% of the amount or $5,000 per report; and, if any part of a shortfall traces to fraud, a further 75% on that portion.

Checks are the instrument most exposed to exactly the fraud half of this picture. In the most recent year measured, 76% of U.S. organisations surveyed reported attempted or actual payments fraud of some kind, and 58% named checks specifically as subject to it, the single most commonly named payment method in that survey. A reconciliation control is not incidental to that exposure; it is one of the places the exposure first shows up as a line that does not match.

What the decision turns on

Six structural dimensions decide whether a process is worth automating. Bank reconciliation reads unusually on most of them, because what is at stake in an unmatched item is rarely the item’s own size; it is which of two statutory clocks is already running against it.

Bank reconciliation: process profile
Dimension	What it reads on bank reconciliation	Source
Exception variance	Defined by timing and by intent, not by size. Most of a first-pass mismatch is timing: an outstanding check, a deposit in transit, a bank fee or a currency adjustment posted before the company's own books catch up. A materially different population sits inside the same unmatched pile: an item that does not match because it was never authorised. Checks are the payment method most commonly named as subject to fraud, cited by 58% of U.S. organisations surveyed, against 76% reporting attempted or actual payments fraud of any kind that year - and a reconciliation is one of the first places that second population becomes visible on paper.	AFP, 2026 Payments Fraud and Control Survey Report
Volume	Not the transaction count. At least one shipped matching engine organises its own automation setup around the number of distinct bank accounts and the statement format each one delivers, not the volume of any single account's traffic: setup is per account, per format, per matching-rule set. What grows the manual population is the number of accounts and unstructured statement feeds a company carries, not the size of the business measured any other way. No verified public figure ties a specific line count or dollar volume to when this pays back, so none is quoted here.	Microsoft, Dynamics 365 Finance, 'Advanced bank reconciliation overview'
Cost of an error	Priced by a clock, not by a percentage. A bank customer who does not examine a statement and report an unauthorised signature or alteration within one year of the statement being made available loses the right to assert it against the bank at all; if the same wrongdoer strikes again after the first forged item has appeared on a statement, the window can run as short as thirty days. The cost of a missed unmatched item is not a fee. It is the value of the item itself, shifted permanently from the bank to the company that did not look in time.	UCC 4-406(c), (d)(2), (f)
Reversibility	High while the two clocks above are still running, and forced once they close. Before the Uniform Commercial Code's reporting windows lapse, an unauthorised or altered item can still be disputed back to the bank; before a genuinely unclaimed item reaches its state's dormancy period, five years under Delaware's general rule, it can still be reissued, voided or paid out. After either deadline the outcome is no longer a choice, and a late escheatment report is itself priced: 0.5% monthly interest capped at 50%, a 5%-a-month late-report penalty capped at the lesser of 50% or $5,000, and 75% more on any part attributable to fraud.	Delaware Code Title 12 §1133(17); §1183
Regulatory exposure	Named directly, at the level of the control rather than a single transaction. Auditing guidance does not treat a missed bank reconciliation as an ordinary line error; the PCAOB's own worked example of a material weakness that has to be tested for remediation is, by name, a company's failure to perform bank reconciliations across its subsidiaries. Separately, an unmatched item that turns out to be genuinely unclaimed becomes a state reporting obligation in its own right, with its own filing deadline and its own named penalties for missing it.	PCAOB AS 6115.39; Delaware Code Title 12 §1183
Vendor market maturity	Settled on the input side, open on the judgment side. At least one major ERP's bank reconciliation module ships support for three standard electronic statement formats, a configurable set of matching rules keyed to transaction codes, and a dedicated view in its own worksheet for lines that do not match, as documented, shipped functionality rather than a custom build. That maturity covers getting a statement in and clearing the standard case automatically. The documentation has nothing to say about which unmatched line deserves a person's judgment, because that call was never a configuration question.	Microsoft, Dynamics 365 Finance, 'Advanced bank reconciliation overview'

The regulatory-exposure and reversibility rows carry the argument together. One says the control itself, not just a transaction inside it, is what gets named if it is not run. The other says an unmatched item is only ever a choice for a limited window, after which its outcome is fixed by statute rather than by anyone’s judgment. Between them they describe a process where the risk is not in the software failing to find a match; it is in nobody being told, in time, that it did not.

Bank reconciliation: the studio’s position

Two claims on this page need to be read with more care than the rest of it. Both trace to one source only, the founder’s own account of the studio’s engagement history: an operating record, not a cited market statistic.

Named directly

The studio has built accounting and finance automation for a client, and the engagement's own account of what it touched names bank reconciliation directly, alongside daily reconciliation and invoice reconciliation

Method The founder's observed pattern across the systems the studio has built and handed over; stated as operating experience, not a cited market statisticSample Client systems the studio has built and handed overPeriod As of August 2026Source Foxnut Studios engagement records (not externally retrievable)

Not in isolation

The founder's stated view, given as the studio's position rather than a finding: that finance automation is very hard to build one process at a time, because it touches all the different parameters and subsystems that make up a company's finance function

What the studio's engagement records support, and what they do not
Number	What it measures	Period	Source
Named directly	The studio has built accounting and finance automation for a client, and the engagement's own account of what it touched names bank reconciliation directly, alongside daily reconciliation and invoice reconciliation	As of August 2026	Foxnut Studios engagement records (not externally retrievable)
Not in isolation	The founder's stated view, given as the studio's position rather than a finding: that finance automation is very hard to build one process at a time, because it touches all the different parameters and subsystems that make up a company's finance function	As of August 2026	Foxnut Studios engagement records (not externally retrievable)

The “Named directly” record states which processes the engagement reached, nothing more - not how it went, how well it worked, or what it cost. The “Not in isolation” record is a view, not a finding: a position taken from that same operating record. Everything else - exception counts, build time, cost, who ran it, which client - stays unstated, because the founder did not supply it and this page does not infer it.

What this comparison usually gets wrong

The first error is treating “can it be automated” as one question with one answer. The mechanical match, a structured statement against a coded ledger, is close to a solved question wherever both sides of it already exist electronically; the residual population, the items that do not match on the first pass, is a different question with a narrower answer, and it is the one the two statutory clocks above are actually about.

The second error is reading an unmatched item as a bookkeeping nuisance rather than as something with a running deadline attached. Neither the recovery window on an unauthorised item nor the dormancy period on a genuinely unclaimed one waits for a slow month or a short-staffed close. A line that sits unmatched because nobody had time to look at it is in exactly the same legal position as one that sits unmatched on purpose.

The third error is buying or building a matching engine before confirming the bank delivers a structured statement at all. Every documented automation pattern in this space assumes the input already exists in one of a handful of standard electronic formats; a business still working from a PDF or a paper statement has a data-readiness problem to solve first, not a software problem.

The fourth error is sizing the decision by transaction count. What actually grows the manual population is the number of distinct accounts, currencies and statement formats a close has to absorb, not the raw volume flowing through any one of them, which is why a large business with one clean account can be a smaller automation decision than a small business with several messy ones.

What this page cannot show you

The founder’s answer says which processes the engagement touched and states a general view about why finance automation resists being built one process at a time. It does not say how many exceptions that reconciliation caught, how long the system took to build, what it cost, who ran it day to day, or which client it was built for. None of that was given, and this page does not guess at it.

No verified public figure connects a specific transaction volume or account count to the point at which bank reconciliation automation pays for itself, which is why the profile table’s volume row states a condition rather than a number. The payments-fraud figures cited above measure fraud across payment types and organisations broadly; they are not a bank-reconciliation-specific detection rate, and this page does not present them as one. And the two records under the studio’s own position are not checked against any public benchmark, because none exists at the scale the claim is made about; each says so rather than dressing itself up as measured data.

The verdict

Automate the structured match wherever the bank already delivers one of the standard statement formats and the company’s own coding holds steady month to month, and keep a named person on everything that does not clear on the first pass.

The case for the first half rests on the volume and vendor-maturity rows: at least one major system already ships this as configured, documented functionality, and the automation decision is really about account and format coverage, not about writing something new. The case for the second half rests on the two rows that carry the real risk. The reversibility row says an unmatched item is only reversible for a limited window, not indefinitely, and the regulatory-exposure row says the control itself gets named, by an auditing standard’s own worked example, when it is not run consistently. A system that surfaces every unmatched line to a person, promptly, is doing the one thing that keeps both clocks from running out unnoticed. A system that quietly clears them is not.

For a team weighing this, the cheap check is a date, not a demonstration. Pull the oldest line still sitting unmatched on any account and ask how long it has been there against the two windows above: a year for an unreported unauthorised item, five years before a genuinely unclaimed one has to be escheated. An account whose oldest unmatched line is older than either window has already been running the exposure this page describes, whether or not anyone has been asked to look at it.

Get the next one of these before your auditor asks about it: subscribe to the digest and it covers this territory as it publishes.

How these records were compiled

Six sources ground the profile table and the body of this page: an auditing standard’s own worked example, two sections of the Delaware Code, the Uniform Commercial Code’s official text, one ERP vendor’s product documentation, and one industry survey’s press release, all fetched and read on 12 August 2026 and dated in sources[] with their retrieval date. Every figure quoted, the interest and penalty percentages, the one-year and thirty-day windows, the five-year dormancy catch-all, the fraud-exposure shares, is read from the cited page itself, not from a secondary summary of it. The two records under “Bank reconciliation: the studio’s position” trace to one source only: the founder’s own account of the studio’s engagement history, summarised and edited for publication without adding a number anywhere in it. They are not checked against a public benchmark, because none exists at the scale the claim is made about, and this page says so rather than dressing assertion up as data.

The part most pages leave out

When not to choose Foxnut Studios

Situations where another option is the better call, and where we say so in the first conversation rather than the fourth.

The accounting or ERP system the business already runs ships a bank-statement-matching feature of its own, complete with configurable matching rules, transaction codes, and a dedicated queue for whatever does not match, and nobody has switched it on. That feature, configured rather than replaced. At least one major ERP's documentation lists automatic statement import, rule-based matching and a dedicated unmatched-transactions view as shipped, standard functionality; the honest recommendation is to turn on what is already licensed before commissioning a new system to do the same job.
The design lets a rule or a model clear a discrepancy or write it off without a named person looking at that specific line, on the reasoning that the amount is small or the pattern looks routine. A human control point placed before the line clears, not after. An unauthorised or altered item written off unread is not a mistake a later pass can quietly fix; recovering its value from the bank runs against a reporting deadline that starts the moment the statement showing it was made available, and once that deadline passes the loss belongs to the company, permanently.
The company's bank does not deliver a structured electronic statement, or the internal ledger's account coding changes from month to month, so there is no consistent electronic record on either side of the match for a rule or a model to compare. The organisation itself, first arranging a structured statement feed from its bank and settling a stable chart-of-account coding, both of which a matching engine assumes already exist before it can run at all.
The business banks with one account, the monthly line count is small, and the same person who reconciles it also reviews the trial balance before the books close. The person already doing it, unchanged. What turns this into a real automation decision is not a fixed transaction count; it is the number of accounts, currencies and statement formats a close has to absorb, which this business does not yet have.

Sources

Foxnut Studios works on briefs like this one from Bengaluru and Paris. If you want the shape of that before you talk to anyone, here is what an AI engagement covers and what you keep.