An eleven-day close, traced to four.
One engagement, traced from problem to outcome. Nine named problems. Five pieces of software, built in order. Four descriptions of how the close should run, in the team's own words. Four outcomes the client commits to, and the plan we both sign to measure them. One thread runs highlighted through every exhibit: the close, from eleven days to four.
The finance function runs on spreadsheets. The close takes eleven days.
The finance team knows the month-end close takes eleven business days because someone counted the calendar for the last two quarters; no system tracks it. The forecast has been ±35% off actuals for four quarters, not because the team forecasts badly, but because its inputs are assembled by hand from three disconnected sources every month.
This is not a technology problem. The business has the data, and the data has no path to the decision. The close is eleven days because nobody has ever owned the problem with enough specificity to redesign it.
This is what a Problem Register names. Nine problems in the language the business already uses, plus one raised and refused. Each is traced to the capability that would retire it. A capability is something the business can now do, and the software that does it. Nine problems don't become nine tools. They converge into five capabilities, and those into four committed outcomes.
That thread is highlighted in blue in every exhibit below.
| ID | Owner | Felt cost | Current workaround | Named outcome |
|---|---|---|---|---|
| P-01 | FP&A lead | Forecast variance averages ±35% over four quarters. The forecast meeting is the argument. | Rebuilt by hand each month from CRM exports, controller estimates, and last quarter's actuals. | Forecast variance under ±10%, rolling six months. |
| P-02 | Controller | CRM and accounting hold different customer numbers. Neither is fully trusted. | Cross-checked from memory; reconciled by hand whenever they diverge. | One trusted set of customer numbers across systems. |
| P-03 | Controller | Month-end close runs eleven business days. Past the 10th. Decisions in weeks 1–2 rest on stale data. | Manual sign-offs chased across the team each period. | Month-end close in four business days. |
| P-04 | Controller | Five subledgers reconciled by hand every close. | Spreadsheet reconciliations on the controller's laptop. | Reconciliations off the critical path; close holds at four days. |
| P-05 | Controller | The close calendar has no owner's view. Status is a guess until someone asks. | Calendar kept as a Google Doc, chased over email. | Close calendar owned; signed pack ready day five. |
| P-06 | Treasurer | Cash position takes two business days to verify. Short-term borrowing stays conservative. | Daily manual export from three banks into a spreadsheet. | Cash position verified within the hour. |
| P-07 | Treasurer | AR aging reconciled by hand. Collections work largely blind. | Manual aging reconciliation against AR/AP each week. | AR aging current; collections work from live data. |
| P-08 | CFO | Board pack assembled from three disconnected sources every month. | Hand-built deck, numbers re-keyed from each system. | Board pack from one source, not three. |
| P-09 | COO | Operational metrics lag a week behind the business they describe. | Weekly manual report pulled from each function. | Operational metrics current — same-day. |
Five capabilities, in the order they have to be built.
The dependency runs one direction: the spine first, then what reads from it. So the architect sets the order with the client in Scoping, the two 90-minute conversations that open every engagement. The close (C2) is the spine.
Set the spine
Master data and the month-end close — the foundations everything else reads from.
Build on the spine
Forecasting and cash visibility — workflows the Phase 1 spine makes possible.
Close the loop
Board and operational reporting, current across the new system.
The close, in the controller's team's words.
A scenario is a problem turned around: how the work should run once the capability is in place. The controller's team wrote these four in Scoping, with the architect drafting where theirs were thin. They're the client's. The architect turned them into the spec, and the Capability Engine, our AI software factory, built the close pipeline from it.
| ID | Scenario | From problem | Accepted |
|---|---|---|---|
| S1 | When a subledger posts, its reconciliation runs that night, and only the exceptions reach the controller. | P-04 | Friday 2026-04-10 |
| S2 | When a bank line doesn't match the GL, it's flagged the same day, not found on day nine. | P-04 | Friday 2026-04-10 |
| S3 | When a close task runs late, its owner and the controller see it that morning, without anyone asking. | P-05 | Friday 2026-04-17 |
| S4 | When the last reconciliation clears, the close pack assembles and goes to the CFO for sign-off. | P-03 | Friday 2026-04-17 |
Each one was accepted at a Friday demo, and the Engine has tested every build against it since.
A Benefit Realization Plan, signed before the first sprint.
A sprint is one senior architect's week. Each outcome gets a lagging metric: the number that shows the result once it's in. It also gets a baseline, a date it's measured, an owner on each side and a review trigger. The trigger is the gate: cross it, and the engagement stops to be re-examined.
| Outcome | Lagging metric | Baseline | Measured | Review trigger | Owner |
|---|---|---|---|---|---|
| Tighten forecast accuracy | Absolute variance between published monthly forecast and GL actuals, rolling six-month window. | ±35% variance across the prior four quarters; rebuilt by hand monthly. | Phase 2 + 6 months | Variance exceeds ±15% for two consecutive months, or publication lag exceeds two business days post-close. | Client FP&A lead + CF architect |
| Compress month-end close | Business days from period end to signed close pack, from the close calendar and approval workflow. | Eleven business days, averaged across the prior two quarters. | Phase 1 + 90 days | Close duration exceeds six business days for any single period in the first two quarters post-go-live. | Client controller + CF architect |
| Move cash position to real-time | Elapsed time from latest cash transaction to verified position, sampled across treasury inquiries. | Two business days to verify; AR aging reconciled by hand. | Phase 2 + 30 days | Verification exceeds four hours for two consecutive days, or AR auto-reconciliation drops below 90%. | Client treasurer + CF architect |
| Bring operational reporting current | Lag between period activity and the operational report that reflects it, sampled weekly. | One week behind; metrics hand-pulled from each function. | Phase 3 + 60 days | Reporting lag exceeds two business days for two consecutive weeks. | Client COO + CF architect |
The plan is the commitment, not the pitch. Every metric is sourced from a system, and every trigger is a real stop. The trigger isn't the target: the forecast aims for ±10%, and ±15% is the line that pauses the engagement.
Working product every Friday. Six weeks of the demo log.
A Friday demo is the unit of the engagement. The log is the durable record: date, what was shown, who saw it. Demos aren't status reports — they're the moment the work either earns the next sprint or doesn't.