Most automation articles stop at slogans. This one walks the actual floor of one report. We are going to take a single recurring regulated report, a month-end reconciliation, from raw inputs to a signed output, and show you where the real work hides, where it breaks, and what actually changes once it runs as code.
One note up front, because honesty is the point of the piece. The company below is illustrative, and the round numbers (a three-day close becoming a same-day one) are presented as a target, not a measured customer result. The benchmarks and failure cases are real and sourced. The goal is to show you the anatomy clearly enough that you can map it onto your own process.
Why this is worth doing at all
The pain is well documented. APQC's benchmarking of the monthly close puts the median cycle time at about 6.4 calendar days from trial balance to finished statements, with the bottom quartile taking ten days or more and the top quartile under five (APQC via CFO.com). A 2024 BlackLine survey found that nearly 40% of CFOs do not completely trust the accuracy of their own organization's financial data (BlackLine, 2024). And the tool doing most of this work is still the spreadsheet, which is where a lot of the trouble starts.
Where spreadsheets quietly fail
Spreadsheets feel safe because they are familiar. The audit record says otherwise. Reviewing thirteen field studies of real operational spreadsheets, researcher Raymond Panko found that 94% contained at least one error (Panko, University of Hawaii). These are not edge cases:
- JPMorgan, 2012. A value-at-risk model spread across spreadsheets with manual copy-paste between them divided by a sum where it should have divided by an average, understating risk and contributing to a loss of roughly $6 billion (US Senate report).
- Reinhart and Rogoff, 2013. An Excel average formula that failed to include five rows changed a widely cited economics result, flipping average growth in the high-debt group from negative to positive (PERI, UMass Amherst).
- TransAlta, 2003. A cut-and-paste error that misaligned rows of bids cost the company about $24 million. The CEO called it, literally, a cut-and-paste error in a spreadsheet they did not detect (The Globe and Mail).
The common thread is not stupidity. It is that a spreadsheet has no memory of who changed what, runs differently depending on who opens it, and gives no signal when a formula silently stops covering the rows it should.
The anatomy of the report
Take a mid-market insurer closing its books each month. Strip away the labels and almost every regulated report has the same six stages.
| Stage | What happens | Where it breaks manually |
|---|---|---|
| 1. Ingest | Pull balances from the general ledger, sub-ledgers, bank feeds, and custodians. | Inconsistent formats, a feed that arrives late, a column that shifted. |
| 2. Map | Normalize accounts to one chart, classify, convert currency. | A new account nobody mapped; an FX rate keyed by hand. |
| 3. Reconcile | Match transactions within set tolerances across sources. | Thresholds applied unevenly run to run. |
| 4. Handle exceptions | Investigate the breaks that did not match, post adjustments. | The genuinely hard, judgment-heavy part, buried under manual matching. |
| 5. Generate | Produce the statement or regulatory return. | Last-minute copy-paste into the filing template. |
| 6. Sign off | Review, approve, and retain the audit trail. | Evidence scattered across emails and file versions. |
Look at where the human effort concentrates. Stages one through three and five are mechanical, the same every month, and exactly the work that should never have depended on a person carefully not making a mistake. Stage four, the exceptions, is where judgment actually belongs. Good automation does not try to replace stage four. It clears away the mechanical stages so your people have time for it.
What "good" looks like to an auditor
Automating this is not just about speed. The output has to survive a review. Auditors and regulators keep asking for the same things: that a result can be reproduced for a given period, that you can trace a number back to its source, that duties are separated, and that there is a complete record of what ran and who approved it. In banking, BCBS 239 makes accuracy, completeness, and traceability of risk data explicit principles (Basel Committee). Under Sarbanes-Oxley, the CEO and CFO personally certify the numbers, which means everyone below them needs evidence the controls actually held.
There is a specific point here that matters more than it first appears. Audit standards treat fully automated controls differently from human ones. The PCAOB's guidance on benchmarking notes that automated application controls are "generally not subject to breakdowns due to human failure," so once tested they can be relied on in later periods without repeating every test, provided the program and its controls have not changed. The same guidance says this approach is especially effective for purchased software when the possibility of program changes is remote, "for example, when the vendor does not allow access or modification to the source code" (PCAOB, AS 5 Appendix B). That is worth sitting with: the audit framework actively rewards code that cannot quietly change between runs.
The same report, built on frozen code
Here is how the six stages look when the workflow is built in Dittah rather than maintained by hand. You describe each stage in plain English, AI generates Python you can read, and you test it against last month's real data until the output matches what your team produced by hand. Then you publish, which freezes that logic into a versioned, immutable artifact. From that moment the build phase is over.
Every month-end after that, production runs the frozen code. The same inputs produce the same outputs, every time, because there is no model in the loop making fresh choices and no spreadsheet that behaves differently depending on who opened it. Each run writes a complete execution log: what data came in, what the code did, what came out, tied to a specific version of the logic. When an auditor asks you to reproduce the March close, you re-run March's inputs through the exact version that produced it and get the exact same numbers. That is the reproducibility the standards are reaching for, and it is a property of the architecture rather than a promise.
The exceptions in stage four still go to a person, with a reviewer sign-off recorded against them, which keeps the separation of duties auditors look for. The difference is that your team now spends the close on the dozen items that need judgment instead of the ten thousand that did not.
The illustrative before and after
For the insurer in this example, the honest framing is a target, not a guarantee. The published benchmark range is the credible anchor: a laggard close of ten or more days moving toward the best-in-class five (APQC), and Ventana Research found that 72% of organizations automating most of their reconciliations finish the close within six business days, against 25% of those automating little or none (Ventana via ISG). The aspirational endpoint, a continuous or same-day close, is where this architecture points, and you should treat that last step as a goal you test rather than a number anyone can promise you in advance.
Bottom line
A regulated report is six predictable stages wrapped around one stage that needs human judgment. Manual processes and spreadsheets get the mechanical stages wrong in quiet, expensive ways and bury the judgment work in the noise. Automating with frozen, versioned code fixes both problems at once: the mechanical work becomes repeatable and auditable, and your people get their attention back for the exceptions. The fastest way to see whether your own close fits this shape is to build one stage of it. Follow the demo and rebuild your trickiest reconciliation against last month's real numbers, then check the output against what your team produced by hand.
Benchmarks and incident cases are linked inline and reflect material available as of April 2026. The example company, the three-day to same-day framing, and any payback figures are illustrative, not a documented customer outcome.
