Your accountants didn't get slower. Your upstream processes got less designed.
Every close-acceleration project is a negotiation between the calendar and eleven upstream teams who weren't consulted. The tracker says Day 5. The GL is still open on Day 7. Someone is on WhatsApp at 9pm asking about a missing accrual.
The pressure lands on the close team. The problem lives elsewhere.
The effort trap: why working harder doesn't move the date
Controllers who treat close acceleration as a people problem are solving the wrong equation.
When a Day-5 close slips to Day 7, the standard response is tighter deadlines, escalation calls, and longer hours. Those measures may recover one cycle. They do not hold. By the third month, the timetable has slipped again — and the team is more fatigued.
The underlying variable hasn't changed: close speed is a function of when upstream inputs arrive, not how fast the close team processes them. Accruals posted late, AP approvals held in a queue, intercompany reconciliations released two days past their window — these are design failures in upstream processes. The cost shows up in audit risk, delayed reporting, and senior time consumed re-litigating the same escalations each cycle.
The upstream-dependency map: the artefact controllers are missing
A financial close is not a single process. It is a deadline imposed on fifteen processes that were built independently.
Most controllers can name their close checklist. Few have mapped which items are blocked by which upstream owners, what the typical delay looks like, and what the design fix is. That map is what makes acceleration possible.
| Upstream Process | Typical Owner | Typical Delay | Design Fix |
|---|---|---|---|
| AP invoice approval | Procurement / Business Units | 2-3 days past cut-off | Defined approval SLA; automated escalation at T+1 |
| Accruals submission | Cost-centre managers | 1-2 days late; incomplete data | Templated accrual form; pre-populated with actuals from prior month |
| Intercompany reconciliation | Regional finance teams | Mismatched entries held open | Standardised intercompany coding; bilateral sign-off deadline |
| Fixed-asset additions | Capex owners / Finance ops | Additions posted mid-cycle | Capex approval gate tied to system posting, not manual upload |
| Payroll journal | HR / Payroll ops | Late sign-off on variable pay | SLA between payroll and GL with named owner |
| Provisions and reserves | Business heads | Delayed due to unclear ownership | Named provision owner per GL account; documented review cadence |
This table is the starting point. Not because it is comprehensive, but because it forces the question: who owns each delay, and is it a process or a timing problem?
What the story looks like on Day 6
Consider a financial-services firm running a Day-5 close target. Day 6 arrives. The GL is 80% complete. Treasury operations has not submitted its accruals. Email. No response. Follow-up. Then a WhatsApp message to a senior manager who was not part of the original process design.
The accrual arrives at 4pm, incomplete. Two line items are missing the cost-centre code. The accountant corrects it manually. The entry posts at 6pm. The close finalises at 8pm — Day 6, not Day 5.
Nothing here is an effort failure. The accruals template had no mandatory fields. The submission deadline was informal. No SLA existed between treasury operations and the close team. The WhatsApp escalation worked this time. Next month, it may not.
Applying E-S-S-A-M: Simplify before you automate
The instinct to automate the close is understandable — and premature.
ESSAM's process-engineering framework — Eliminate, Simplify and Standardise, Automate, Migrate — is sequenced deliberately. Automate is the fourth action, not the first. Automating an undesigned process embeds its failure modes at machine speed.
On approval chains feeding the close, the Simplify step alone recovers significant time. Cut the approval steps that add latency without adding control. An accruals form routing through four reviewers — where two are rubber-stamping — is a designed delay. Removing two hops shortens the cycle by the sum of their queue times.
Standardise means every upstream team uses the same submission template, the same deadline, the same escalation path. Not because standardisation is tidy, but because variability in inputs produces variability in close timing.
Once done, selective automation — automated reminders, escalation triggers, system-to-system journal posting — holds the improvement without embedding new failure points.
Close as a recurring design checkpoint, not an annual project
Financial close improvement is not a one-time initiative — it is a recurring design discipline.
ESSAM's 7-step AI Lean Cycle — Baseline, Map, Analyse waste, Optimise, Document, Deploy, Improve — is built to repeat. For a close team, each cycle is a checkpoint: which upstream dependencies caused delays this month, what changed in the design, and what holds for next.
The Baseline step captures the current close timetable and its upstream inputs — conversationally, in a single session, without notation software or workshop prep. The output is a live process model with named owners, SLAs, and a before/after audit view showing where time was lost and where it was recovered.
That audit view changes the upstream conversation. Not an assertion — "you were late." A data point — "the AP approval SLA was breached on Day 2, and the downstream impact was Day-6 close instead of Day-5."
"Close speed is an upstream design property, not an accountant effort property. Once you map the dependencies and assign SLAs to each, the timetable becomes a design output — something you can engineer, not just hope for." — Abdulla Al-Awadi, ESSAM's founder and former Chief Strategy Officer at a Kuwait bank
By analogy: a Kuwait bank procurement engagement reduced cycle time from 139 days to 57 days at the same headcount. The gain came almost entirely from the Eliminate and Simplify steps, before any automation. The close is a different process. The principle holds.
The only metric that matters: when does the GL close?
Effort metrics are noise. The signal is the close date.
Track two numbers per cycle: target close day and actual close day. For every day of variance, document which upstream dependency caused it. Within three cycles, the map writes itself. Within six, the fixes are visible.
Finance process standardisation is not a culture-change programme. It is a process-engineering task with owners, SLAs, and a before/after audit view — run in repeating cycles, not annual reviews.
The month-end timetable slips because upstream processes were never designed to meet it. That is fixable. It does not require harder work. It requires a map.
Book a demo on your process. Your actual workflow. No hypothetical use case required.
Related reading: What is an AI Process Engineer? · How to Calculate Business Process Cost · ESSAM Features