Key-person risk in finance — when the only person who understood it resigns

These figures are modelled, not measured. They come from an internal planning model built on realistic Malaysian inputs for a business of this shape. No real customer is described here, no company is named, and nothing below is a quotation from anyone. Actual results depend on your entity structure, your transaction volume, how clean your data already is, and how much of the current process lives in one person's head. Treat this as a worked scenario for sizing an argument, not as evidence of what happened to somebody else.

There is a moment that every multi-entity finance function eventually has, and almost nobody plans for it.

The financial controller hands in their notice.

Not a junior. The one who built the intercompany mapping in a spreadsheet nobody else opens. The one who knows that entity three's management fee is charged quarterly but accrued monthly, and why. The one who can look at a trial balance and tell you within ten seconds which of the five companies has a problem. They have three months of notice, a successor who does not exist yet, and a filing system that makes sense only to them.

Everyone in the room knows what has just happened. Very few people say it out loud, because saying it out loud means admitting the group has been running an unmanaged risk for years.

This is a modelled scenario built around exactly that trigger — and around a conclusion that the arithmetic does not support on its own. That part is at the end, and it is the part worth reading.

The shape of the modelled group: five entities, 900 invoices, a 14-day close

The model assumes a group with five special-purpose entities under one management team. Each entity has its own books, its own bank accounts, its own supplier relationships, and its own set of costs that are genuinely its own. They also charge each other — shared services, management fees, cost allocations, staff time recharged between companies.

The operational inputs the model runs on:

• 900 supplier invoices a month across the five entities, with a meaningful proportion needing to be split or allocated between them.
• Intercompany charges raised in both directions, which have to agree to the cent on both sides or the consolidation will not balance.
• A 14-day month-end close, meaning management sees last month's numbers roughly halfway through the current one.
• 195 hours a month of invoice handling — receiving, coding, chasing approvals, entering, filing.
• 120 hours a month of reconciliation and intercompany work — the part that is genuinely difficult, and the part exactly one person could do unsupervised.

Fourteen days is not unusual for a group of this shape. It is also, quietly, a strategic problem: by the time anyone can see whether an entity is drifting, they are two-thirds of the way through the next month and the drift has already happened again.

But the 14 days is not the interesting number. The interesting number is one. One person who could close it.

Why the resignation is the strongest buying trigger, and why nobody sells to it

Software gets sold on efficiency. Save hours, cut costs, do more with less. That is the pitch in almost every deck, and it is why so many finance systems get evaluated in a spreadsheet, scored on a savings line, and quietly shelved.

Meanwhile, the thing that actually forces a decision is rarely efficiency at all. It is the discovery that a process has no redundancy. The controller resigns, or goes on extended leave, or is off sick for three weeks during a year-end, and the group finds out that a critical function was never a process — it was a person.

That discovery does three things at once. It creates urgency, because there is a leaving date on a calendar. It creates budget, because a salary has just come free. And it collapses the usual objection, because "we already have a way of doing this" has just stopped being true.

Almost nobody builds an argument around it. Partly because it feels tactless to point at a resignation, partly because it is harder to quantify than hours saved. But it is the honest reason a group of this size finally moves, and pretending otherwise leads to buying the wrong thing — a system chosen for cost savings when what was needed was continuity. The general version of this problem is the same one in keeping your business running when you are away, scaled up to a group structure and a departure that is permanent.

What the modelled deployment puts in place across the five entities

The model assumes roughly 200 hours of internal time over three months — the group's own people, in workshops, in data cleanup, in testing, in the awkward parallel-run period where the old way and the new way both exist. That number matters more than most buyers expect. It is not the vendor's time; it is finance and operations people not doing their day jobs, at precisely the moment the group is short a controller.

Five things go in:

An accounts payable workflow spanning all five entities. One intake, one coding standard, one approval structure, five sets of books. The invoice arrives once and lands in the right entity with the right allocation, rather than being sorted by whoever opens the envelope. The mechanics of this are covered in AI in accounts payable.

Intercompany approvals with both sides recorded. A recharge between entities is raised, approved by both, and posted symmetrically. This is the single largest source of consolidation pain in a group of this shape, and it is almost always the thing living in a spreadsheet with one owner.

An audit evidence app. Every approval, every allocation, every intercompany entry stores its supporting document and its approval trail at the moment it happens, indexed and searchable. Not assembled in a panic in March.

A month-end closing tracker. The close becomes a visible list of tasks with owners, dependencies and statuses, instead of a sequence of steps that existed only as one person's working memory. Anyone can see what is done, what is blocked, and who has it.

A named contact on the vendor side. For a group replacing its only expert, having a specific person to call is not a nicety. It is part of the continuity being bought.

Notice what all five have in common. None of them is primarily about speed. They are all about making a process legible to someone who did not design it.

The modelled outcome: 14 days to 6, and 194 hours a month returned

On these inputs, the model produces:

• Close: 14 days down to 6. Management sees the month in the first week of the next one. That is the difference between a report and a decision.
• Invoice handling: 195 hours a month down to 73. The reduction comes from intake, coding and chasing, not from the judgement.
• Reconciliation and intercompany: 120 hours a month down to 48. Intercompany largely stops being reconciliation work at all, because both sides are recorded at the point the charge is raised rather than matched afterwards.
• Audit query time and fee reduction: around RM20,000, modelled on evidence being retrievable rather than reconstructed.
• Leakage stopped: around RM40,000, modelled from duplicate payments, missed recoveries and charges allocated to the wrong entity — the errors that a five-entity structure generates naturally and a single reviewer cannot reliably catch across 900 invoices a month.
• The departing controller replaced with an assistant manager rather than a like-for-like hire, modelled at around RM72,000 a year.

That last line is the one that carries the strategic weight, and it is worth being precise about what it means. The model does not assume the controller role disappears. It assumes the role can be filled by someone more junior because the hardest part of the job no longer requires the person to have designed it. The intercompany logic is in the workflow. The close sequence is in the tracker. The evidence is in the app. What is left needs competence and review, not institutional memory.

If that assumption is wrong for your group, the largest single line in the model disappears. Which brings us to the honest part.

Why the cash lines alone make this scenario negative

Here is the caveat, stated plainly, because a scenario that only reports upside is marketing rather than analysis.

On the cash lines alone, this modelled scenario is negative. The savings above — the hiring differential, the audit reduction, the leakage — do not, at this level of deployment scope, add up to the cost of getting there. Anyone building the business case should expect the savings arithmetic to come out short, and should not be surprised or feel misled when it does.

The reason is structural and specific to this market. The labour being displaced is not expensive enough in Malaysia to justify a deployment of this size on cost grounds. A finance clerk's fully loaded cost here is a fraction of the equivalent in Singapore, Australia or the UK, so 194 hours a month of released capacity converts into a much smaller ringgit figure than the same hours would elsewhere. Vendors who import a Western ROI model into Malaysia and present the resulting savings figure are, at best, not checking their inputs.

So if the finance director asks "does this pay for itself in labour savings", the honest answer for a scenario of this shape is: probably not, and certainly not quickly. Whether it pays back at all depends entirely on scope, on how many entities and processes are actually in play, and on current pricing — see /price for how that is structured. Do not let anyone tell you the hours alone carry it.

What carries it is a different question, asked in a different way.

What the group is actually buying: the next resignation

The question is not what this costs. The question is what it costs the next time the person who knows how it works walks out.

That cost is not theoretical, and it is not small. In the modelled group, the three months of notice are spent on handover instead of work. The successor takes six months to reach the previous standard, and during that period the close slips, errors get through, and management makes decisions on numbers that arrived late. The audit is harder because the person who could explain the odd entries has gone. If the departure is sudden rather than resigned, remove the three months of handover entirely and the picture gets considerably worse.

Now price that, and price it as a recurring event — because it is one. Controllers move every few years. That is normal, and no retention policy makes it not happen.

The deployment above does not make the group faster, fundamentally. It makes the group's knowledge transferable. The intercompany logic stops being something a person knows and becomes something a system enforces. The close stops being a sequence in someone's head and becomes a list anyone can pick up. The evidence stops being a folder structure only one person can navigate and becomes a searchable record.

That is a risk-and-continuity argument, not a cost argument, and it should be presented as one. If a board evaluates it on the savings line it will look like a poor deal, because on the savings line it is. If a board evaluates it on "what happens when the next controller resigns", it looks entirely different. Both readings use the same numbers. The difference is which question is being answered — a distinction explored more generally in the cost of doing nothing.

Getting intercompany out of one person's head first

If a group of this shape wants to start somewhere narrow, the model suggests intercompany rather than accounts payable — even though AP is the bigger hours line.

Intercompany is where the key-person concentration is most acute. It is the piece with the least documentation, the most judgement, and the highest consequence when it goes wrong, because a mismatch does not just cost time, it stops the consolidation. AP is high volume but broadly understood; three people in the department could describe how it works. Intercompany is usually understood by one.

Getting both sides of every recharge raised, approved and posted through a defined workflow does not save the most hours. It removes the most risk, and it can be done while the person who understands it is still employed — which is the only window in which it is easy. Waiting until the handover period means documenting a process under time pressure, with someone whose attention has already moved on. The general principle is the same one behind approval workflows people actually follow: a rule that lives in a system survives the person who wrote it.

The same test applies to the numbers themselves, not only the processes: explaining your numbers to someone who was not there looks at what a successor, an accountant or a bank actually needs in order to verify a figure without your commentary attached to it.

The cost of this kind of gap is not limited to a single resignation — it compounds every time it happens, which is the actual argument for building the habit rather than absorbing the loss once: what a resignation actually costs beyond the notice period.

Common questions

Are these real customer results?

No. Every figure here is modelled, produced by an internal planning model using realistic Malaysian inputs for a group of this shape. No real customer is described, no company is named, and there are no quotations from any individual. The operational figures — 900 invoices a month, a 14-day close, 195 and 120 hours — are illustrative inputs and outputs of that model. Your own numbers will differ depending on entity count, volume, data quality and how concentrated your process knowledge currently is.

What is key-person risk in a finance function?

It is the exposure created when a critical process exists as one person's knowledge rather than as a documented, enforced system. In a multi-entity group it usually concentrates in intercompany reconciliation and the close sequence, because those need judgement and rarely get written down. The test is simple: if that person gave notice tomorrow, could someone else close the books next month without them? If the answer is no, that is the risk.

Does a deployment like this pay for itself?

On the labour savings alone, in a scenario of this shape, the honest answer is no — the arithmetic comes out negative, because the work being automated is not expensive enough in Malaysia to cover a deployment of this scope. Whether it pays back overall depends on scope, entity count, how many processes are in play, and current pricing, which is set out at /price. The argument that carries it is continuity and risk, not cost savings.

How much internal time does a multi-entity rollout take?

The model assumes around 200 hours of the group's own time over roughly three months — workshops, data cleanup, testing, and a parallel-run period where both the old and new processes exist. That is finance and operations people away from their day jobs, which is a real cost and is often understated in vendor estimates. Plan for it explicitly, and be aware that it lands hardest when the group is already short-staffed.

Most finance systems get bought to save money and end up justified on something else entirely. This one is honest about it from the start: on the cash lines, a scenario like this does not clear the bar, and no amount of rearranging the hours will make it. What clears the bar is the difference between a group whose close depends on a named individual and a group whose close depends on a process. Whether that difference is worth paying for is a judgement about risk, and it is the board's judgement to make — but it should at least be the question being asked.

Related: month-end without the scramble and AI in accounts payable. </content> </invoke>