Inside a CPA firm's exception-based close: what AI reconciliation changed, and what it did not

Start with the problem. Why was the monthly close the right place to apply AI?

The close is where a firm like ours spends a disproportionate share of junior labor on work that carries no professional judgment. For a typical small-business client, someone was pulling bank and card feeds, matching them against the general ledger line by line, chasing the handful of transactions that did not tie, and only then producing statements. That cycle ran days behind the month it described. Commercially, two things bothered me. First, clients were paying senior rates, indirectly, for keystroke-level work. Second, our best people were leaving that work rather than doing it, because early-career accountants do not stay at a firm to reconcile ledgers. The close was the right target precisely because it is high-volume, rules-based, and repetitive, which is the profile of work machines handle well, and because compressing it frees the exact hours we most wanted to redeploy. We were not chasing novelty. We were removing the least valuable hours from every engagement.

Reconciliation software is not new. Why is this viable now and not five years ago?

Two capabilities matured at the same time. The first is connectivity. Bank and card feeds now arrive through stable interfaces, so the data comes in structured rather than being keyed from PDFs or paper statements. The second, and the one that matters more, is that models can now read messy, inconsistent transaction descriptions and reason about them. Older rules engines matched on exact strings and amounts, so a vendor that appeared three different ways on three statements broke the match and landed in a manual queue. Current systems handle one-to-many and many-to-many matching, tolerate the variation in how the same payee is written, and can still explain why they proposed a given match. That explainability is what changed the economics for a firm our size. Five years ago the exceptions were so numerous that the software saved little. Now the match rate on clean books is high enough, often around ninety percent in our experience, that reviewing the remainder is genuinely faster than doing the whole reconciliation by hand.

Walk me through how the workflow actually runs, step by step.

It runs as a pipeline with a human at the end, not in the middle of every line. Transactions flow in from the client's bank and card feeds and from their bookkeeping system. The engine normalizes that data, then proposes matches between the feed and the ledger, including grouped matches where one deposit covers several invoices. Anything it can match with confidence above our threshold posts to a proposed close; anything below it, or anything that looks unusual against the account's own history, is routed to an exceptions queue with the supporting context attached. A staff accountant works that queue, not the whole population. They confirm or correct the proposed treatment, code the genuine exceptions, and put questions to the client where a transaction is ambiguous. Every action, the machine's proposal and the person's decision, is written to an audit trail with the reviewer's name and a timestamp. Once the exceptions clear, a senior reviews the completed close and the statements go out. The shift is from doing the reconciliation to reviewing one.

This is client financial data. How do you handle confidentiality and security?

We treated that as the gating question before anything went live, because our obligations here are not optional. Under the AICPA's confidential client information rule, we cannot disclose client data without consent, and putting that data into a third-party tool is a form of disclosure we have to control. So we did a few concrete things. We use systems with read-only access to client financial records, so the software can see the ledger but cannot write to it. We confirmed in the vendor's contract terms that client data is not used to train public models, and we keep it inside the engagement rather than any shared pool. Access is scoped by client, so a staff member sees only the books they are assigned. We told clients, in plain language, which tools touch their data and why, and we secured their agreement. The audit trail helps here too: because every data access and every decision is logged, we can show exactly what was submitted, when, and who reviewed the result. Confidentiality is a controls problem, and we engineered the controls first.

Where does accountability sit? If the system proposes a match, who is responsible for it being right?

The firm is, without qualification. The software does not sign anything and it is not a party to the engagement. Accountability sits with the accountant who reviews the close and the partner who releases the statements, exactly as it did before. What changed is where their attention goes. Rather than verifying thousands of routine matches, they concentrate on the exceptions, the unusual accruals, and the items that require a materiality judgment the machine is not entitled to make. We keep the human in the loop by design, not as a courtesy: a proposed match is a draft until a person accepts it. We also run our own quality-assurance sampling across the auto-matched population, so we are not taking the high match rate on faith. When we find the model is weak on a particular client's patterns, we tighten the threshold for that client so more items route to review. The principle we hold to is that professional skepticism cannot be delegated to a tool, and our workflow is built so it never has to be.

How did the staff respond, and what went wrong first?

The early skepticism was reasonable and I did not fight it. Experienced staff had watched tools overpromise before, and their first assumption was that a high match rate hid errors they would be blamed for. What went wrong first was that we trusted the thresholds too much on messy books. On clients with disorganized ledgers, the system matched confidently on things that were wrong, and a reviewer nearly let a few through because the queue looked short. That taught us to calibrate per client rather than firm-wide, and to keep the quality-assurance sample even on the auto-matched items. The workflow redesign was harder than the software. Reconciliation had been a solo task; it became a review discipline, which needs different habits and a different rhythm to the month. We retrained people to read an exceptions queue critically instead of grinding through a full ledger, and we were explicit that the time saved was meant to move to advisory work, not to more files. Once staff saw the reallocation was real, the resistance faded quickly.

What are the measurable outcomes, and how should a reader weigh them?

On clean, well-run client books, reconciliations that used to take the better part of a few days now take minutes of machine processing plus a focused review of the exceptions. That is the headline number, and I would caveat it heavily: it applies to clients with organized records and stable transaction patterns, and it describes elapsed processing time, not a claim that judgment itself got faster. Across the practice, we have reallocated roughly eight and a half percent of staff time from compliance data-handling to advisory and quality assurance. That figure is modest by design, because we moved deliberately and did not cut review. Clients receive their monthly statements faster, which for them is the outcome that matters most, since financials that arrive closer to the period they cover are more useful for decisions. I am wary of the larger numbers that circulate in vendor material. The gains are real, but they concentrate on the routine end of the work, and a firm that expects the same lift on complex or disorganized engagements will be disappointed.

What would you say to a skeptical peer, or to a client who is nervous about this?

To a peer, I would say the risk is not that the tool is dramatic and wrong. It is that it is quietly plausible. A confident, incorrect match is more dangerous than an obvious failure, because it invites a reviewer to relax. That is why the discipline matters more than the software: calibrated thresholds, quality-assurance sampling, and a documented trail are what make it defensible. Anyone adopting this without those controls is taking on real exposure. To a nervous client, I am direct about the division of labor. The AI does the matching and the clerical assembly. A licensed professional reviews the exceptions, signs off on the statements, and remains fully accountable for them. Their confidential information is handled under controls we can describe and log, and nothing is fed into a public model. I also tell them what it does not do: it does not interpret their numbers, it does not give advice, and it does not replace the conversation about what the results mean. That conversation is the part they are actually paying us for.

Is there a specific moment where the approach proved itself?

One that stays with me involved a client whose bookkeeper had left mid-year. Their books were behind and inconsistent, and a manual catch-up would have taken a junior most of a week, at a cost the client could not really absorb. We ran the backlog through the reconciliation engine, which matched the clean majority quickly and, more usefully, isolated a cluster of exceptions it could not resolve. That cluster turned out to be a set of duplicated vendor payments the previous bookkeeper had not caught. A person scanning line by line, under time pressure, might well have matched past them, because each looked ordinary on its own. Surfacing them as a group, against the account's normal pattern, is what made the duplication visible. We flagged it, the client recovered the money, and the conversation shifted from cleanup to how to prevent it recurring. That is the version of this technology I find persuasive. It did the volume work and it made a real problem easier for a professional to see, rather than pretending to solve it on its own.

What does this mean for the profession and for the client relationship over the next few years?

I think it resets what a client pays an accountant for. For decades a meaningful share of small-firm revenue came from the mechanical production of compliant financials. That work is being compressed toward the cost of the software, and firms that define themselves by it will feel margin pressure. The opportunity is that the same shift frees capacity for advisory work, which clients value more and which is harder to commoditize. For us the goal is not to close the books faster as an end in itself. It is to use the recovered hours to sit with a business owner and talk about pricing, cash flow, and where the numbers say the business is heading. There is also a talent dimension. The people entering this profession do not want to spend their twenties reconciling ledgers, and a firm that offers judgment-heavy work earlier will recruit and keep better. I am cautious about the pace, because trust is the asset and it is slow to rebuild once lost. But the direction is settled: the routine work automates, and the relationship becomes the product.