Example
Work / Finance
A month that closes itself.
A reconciliation flow rebuilt as one audited pipeline, so the monthly close stopped depending on a single person's spreadsheet.
An illustrative example, written to show how we present a case study. No client is named and no result is claimed as a figure.
Case facts
The project at a glance
- Client
- Accounting group
- Sector
- Finance and accounting services
- Team shape
- Two engineers and a designer, plus their finance lead
- Duration
- Four months, from first workshop to handover
The story
How the close was rebuilt
The same account we would give a colleague: what was wrong, what we changed, and what the team can do now that it could not before.
The challenge
Every month the same few days disappeared. Balances arrived from four places — a bank export, two ledgers and a spreadsheet that had grown its own macros — and one person matched them by hand. Nobody else could run the process end to end, and when a figure was questioned, tracing it meant reopening the files it came from rather than reading a record. The team knew the risk. What they did not have was a way out that let them keep closing while it was built.
The approach
We began by writing down the rules that lived in one person's head, one at a time, and turning each into a rule the system could apply and explain. Imports became typed adapters with their own tests, so a change to a bank's file format fails loudly instead of quietly. Matching became a review queue an accountant works through rather than a black box that either agrees or does not. Every adjustment records who made it, when, and against which source. The screens came out of the design system we built alongside the pipeline, so the shapes matched the tools the team already used.
The outcome
The close is now a process the team runs, not a person. Exceptions surface as they appear instead of gathering until month end, and a question from an auditor is answered by opening the record rather than reconstructing it. Because the rules sit in one place with tests around them, a change at the bank is made once and reviewed like any other change. We have not put a number on any of this, and neither has the team — the difference they describe is that the month no longer has three days nobody wants.
Inside the product
One screen the whole close runs through.
The reconciliation queue, mid-close.
The problem
Days that belonged to one person.
The close worked, which is exactly why it had survived. It ran on a spreadsheet nobody else fully understood, held together by conventions that were never written down, and it produced correct numbers as long as the person who built it was in the room.
When we sat with the team through a close, the pattern was plain: the hard part was not the arithmetic. It was knowing which of four sources to trust when they disagreed, and being able to say afterwards why that choice was made.
- One person could run the close, and only that person.
- Corrections lived in cell comments, not in a record.
- Mismatches surfaced at the end, when there was least time.
How we built it
Rules written down, then written in code.
We refused to start with screens. The first month was spent turning tacit rules into explicit ones — a matching rule, a tolerance, a reason a transaction may be split — each written in plain language, agreed with the accountant who applied it, and only then implemented.
The pipeline runs in their cloud, in their repository, with tests that read like the rules they came from. When a rule needs to change, the person who owns it can read the test and see what changing it will do.
- Typed import adapters, each with its own tests.
- Matching as a review queue, not a black box.
- Every adjustment recorded with its source and its author.
In their words
The close used to be three tense days. Now it is a process anyone on the team can follow, and we can show an auditor where every number came from.
An example testimonial, shown to demonstrate the layout. Real client words will replace it once we have consent to publish them.
Details
Three parts of the same system.
Rule editor, with the plain-language version beside it. Exception review, one accountant's day. Audit trail for a single adjusted entry.
This case study is an illustrative example. The client, the quote and every image on this page are placeholders standing in for work we cannot yet publish — no client is named and no result is stated as a figure.
Next step
Does the close rest on one person?
Describe how the month currently ends at your company and we will tell you plainly what we would look at first, and whether the work is worth doing at all.