Reconciliation Variance: The Bug That Became an Industry

Reconciliation software is a multi-billion-dollar market. Close management tools. Flux analysis platforms. Variance tracking dashboards. This entire category exists because the financial systems underneath produce discrepancies that need to be managed. We’ve built an industry to clean up after a bug that we’ve decided to live with.

Consider what reconciliation actually is, stated plainly: it’s the process of verifying that two records of the same thing agree. You have accounts receivable recorded in a subledger. You have accounts receivable recorded in the general ledger. At the end of the month, you check whether they’re equal. If they’re not, you find the difference and resolve it. Then you do the same thing next month.

The question that rarely gets asked is: why do those two records disagree in the first place?

The accepted abnormality

The reconciliation process is so embedded in accounting practice that it’s treated as fundamental — a necessary discipline, like balancing a checkbook. But it isn’t fundamental. It’s a workaround for an architectural choice. The reason the subledger and the GL can disagree is that they’re maintained separately, synchronized through posting processes that can fail, run incomplete, or run incorrectly. If they were the same data, viewed through different filters, they could not disagree. There would be nothing to reconcile.

The accounting profession has adapted to this limitation so thoroughly that the reconciliation process is now a control in its own right — performing reconciliations is considered evidence of a strong control environment. And it is: if your systems produce discrepancies, performing reconciliations diligently is genuinely better than not. But we’ve reached the point of treating the treatment as the cure. The reconciliation is managing a symptom of the underlying disease.

The ecosystem that grew around it

BlackLine, the publicly traded software company focused on financial close automation, had revenue of over $500 million in fiscal year 2023.¹ FloQast, TriNet, Trintech, and a dozen similar companies have built significant businesses in the same space. These products are good. They genuinely make the reconciliation process faster, more consistent, and better documented. They’re legitimate solutions to real operational problems.

They’re also an industrial-scale response to a design flaw. The financial close automation industry exists because: (1) ERP systems produce data in disconnected subsystems, (2) those subsystems disagree periodically, (3) resolving disagreements is labor-intensive and error-prone, and (4) there’s a market for tools that manage that labor. If ERP systems didn’t produce disagreements between subledgers and the GL, step (2) wouldn’t exist, and neither would the market for steps (3) and (4).

The cost distribution

The costs of reconciliation are distributed across multiple budgets in ways that make the total hard to see. There’s the software cost: the BlackLine license or the FloQast subscription. There’s the labor cost: the finance team members whose primary responsibility is performing reconciliations and resolving variances. There’s the time cost: the weeks that month-end close extends because reconciliation has to complete before the books can lock. There’s the risk cost: the probability that a reconciliation misses a discrepancy that turns into an audit finding.

Ventana Research estimates that companies with revenue over $100M spend an average of six business days on month-end close.² A significant portion of that time is reconciliation. For a finance team of ten people spending a week per month on close, that’s roughly 10% of the team’s annual capacity allocated to a process that exists because the architecture doesn’t prevent discrepancies.

The alternative measurement

The measurement that matters is not “how efficiently can we reconcile?” but “how much reconciliation work does the system generate?” A system that generates less reconciliation work is a better financial system — not because it skips a control, but because the control is built into the architecture rather than added on top.

When journal entries are the atomic unit of every financial transaction, and every application module reads from those entries rather than maintaining its own balance, the question “does the subledger agree with the GL?” doesn’t have an answer other than “they’re the same data.” The reconciliation isn’t faster. It’s gone.

Sources