Every close I have watched go from ten days to three has gone the same way. Nothing about the last three days changed. What changed is what was already true on the day the month ended.
That is the uncomfortable part of a fast close: almost none of the work happens during it. By the time anyone is reconciling, the outcome has already been decided by choices made four weeks earlier — how a card was issued, whether an invoice carried a purchase order, which entity a payment belonged to.
The four conditions
Ask a controller what a three-day close needs and you will get a list of tools. Ask what went wrong in the last one and you will get a list of four things — the same four things, in a different order.
- Every transaction arrives already carrying its account, its cost centre and its evidence.
- Every approval that could block a payment has finished before the period does.
- Every exception has a name and an owner before anyone starts reconciling.
A close is not a sprint at the end of the month. It is the last four hours of a process that started on the first.
— Iris Bakker, Head of Accounting, Finly
Everything is coded when it lands
Coding after the fact is the largest single cost in a slow close, and it is the most avoidable. A card that knows its cost centre at the moment it is issued produces a transaction that still knows it at settlement. The rule travels with the card, not with the receipt.
Approvals finish before the month does
An approval chain that is still open at cut-off is not a control, it is a queue. The fix is rarely fewer approvers — it is knowing, on the fifteenth, which chains will not have finished by the thirty-first, and clearing those instead of all of them.
| Condition | Where it breaks | Day cost |
|---|---|---|
| Coding | Coded after settlement | 1.5 days |
| Approvals | Chains still open at cut-off | 2 days |
| Evidence | Receipts chased by email | 1 day |
| Entities | Consolidated in a spreadsheet | 1.5 days |
| Exceptions | Found, not expected | 1 day |
| Recovered | 7 days |
Ten days minus seven is three. Median across forty teams that made the move — your own four will come in a different order, and the last one is always the most expensive.
One ledger, not four exports
The last condition is the one that sounds like plumbing and is really about trust. If the ledger is assembled from four exports, then four people have to agree the export was right before anyone can agree the number is. A settled transaction should arrive already carrying everything the ledger needs.
{
"event": "transaction.settled",
"amount": { "value": 4820, "currency": "EUR" },
"card": { "holder": "P. Raghavan", "policy": "eng-saas" },
"coding": {
"account": "6120 · Software",
"cost_centre": "ENG",
"entity": "NL-01",
"evidence": "receipt_9f31.pdf"
},
"posted_at": "2026-07-01T09:14:22Z"
}The exceptions are named in advance
No month is clean. The difference between a three-day close and a ten-day one is not the number of exceptions — it is whether they were expected. A team that knows on the twentieth that two suppliers always invoice late has two exceptions. A team that finds out on the second has an investigation.
Fig. 1 — Ten teams mapped their close on a board before changing any of it. Four of the seven days were sitting in two columns.
What day three actually looks like
Quiet. The reconciliation is a review rather than a reconstruction, because the coding, the approvals and the evidence all arrived with the transactions. What is left is judgement: accruals, the two suppliers who always invoice late, and the question of whether the number is right.
If you are starting from ten days
Pick one condition and fix it for one month. Coding is usually the cheapest and always the largest — it is a policy decision, not a migration. Then measure again before you touch the second one, because the four are not independent and the order you fix them in changes what the next one costs.
