Skip to content
Ashish Kumar AgnihotriOperating Partner

A multi-entity enterprise · Finance operations

Compressing the billing approval cycle from two months to fifteen days

A two-month approval cycle ties up cash, strains clients and hides errors in its own length. Compressing it to fifteen days — across 75 entities and more than 2,000 people — meant re-engineering the process, not just chasing approvals.

A billing approval cycle that runs to roughly two months is rarely slow because the work is hard. It is slow because of the structure around the work — serial approvals, unclear ownership, and rework triggered by errors that surface far downstream. This one spanned 75 entities and more than 2,000 employees, which gave the delay both scale and inertia.

My brief was to compress the cycle without weakening the controls it existed to provide. That distinction is the whole challenge. It is easy to make an approval process faster by removing the checks that protect it; the discipline is to remove only the steps that add delay without adding control, and keep every step that actually earns its place. A long cycle ties up cash, strains clients, and hides errors in its own length — the longer the cycle, the more places a mistake can sit unseen.

The cycle compressed from around two months to fifteen days across all 75 entities and more than 2,000 employees — a reduction of roughly three-quarters. Cash moved faster, client friction fell, and the process became transparent enough to keep improving. Here is how it was re-engineered rather than merely chased.

01The challenge

The billing approval cycle ran to roughly two months, spread across 75 entities and more than 2,000 employees. The length was not caused by the work itself but by the structure around it: serial approvals, unclear ownership, and rework triggered by errors that surfaced far downstream. Long cycles delay cash, frustrate clients, and make problems harder to trace — the longer the cycle, the more places a mistake can hide.

02The intervention

What I actually did.

  1. 01

    Mapped the end-to-end approval flow across all 75 entities, distinguishing the steps that added control from the steps that only added delay.

  2. 02

    Re-engineered the sequence — parallelising where serial approvals added no control, and fixing ownership so nothing waited in an unattended queue.

  3. 03

    Built validation into the early stages so errors were caught at source, removing the downstream rework that had been inflating the cycle.

  4. 04

    Standardised the process across entities and instrumented it, so cycle time became a visible, governed metric rather than an assumption.

03The outcome

The approval cycle compressed from around two months to fifteen days across all 75 entities and more than 2,000 employees — accelerating cash, reducing client friction, and making the process transparent enough to keep improving.

~75%

reduction in cycle time

75

entities standardised on one process

2,000+

employees within the redesigned flow

Client identity withheld under confidentiality. The figures are real and were measured at the time of the engagement.

In depth

The operating reasoning behind the result.

The length was the structure, not the work

The first thing to establish was that the two-month cycle was not caused by the billing work itself. The actual effort of preparing and approving a bill is small; the months came from the structure around it. Approvals ran in series when they did not need to. Ownership was unclear, so work waited in queues nobody was watching. And errors surfaced far downstream, triggering rework that sent items back through steps they had already passed. A long cycle is almost always a structural artefact of this kind rather than a sign of heavy work. Naming that correctly mattered, because it pointed the fix at the sequence and the ownership rather than at the people doing the billing.

Mapping the flow across 75 entities

I mapped the end-to-end approval flow across all 75 entities, and the purpose of the map was discrimination: separating the steps that added control from the steps that only added delay. Every approval in a long cycle feels necessary to someone, which is exactly why cycles never shorten on their own. The map made the distinction objective. It showed which sign-offs genuinely reduced risk and which were habit, duplication, or compensation for a problem better fixed elsewhere. Doing this across all 75 entities also exposed how much the same process varied between them — variation that was itself a source of delay and confusion. You cannot safely cut steps from a process you have not mapped; the map is what let the redesign remove delay without removing protection.

Re-engineering the sequence and fixing ownership

Two structural changes drove most of the compression. First, I parallelised the approvals that had been running in series purely out of habit — where a sign-off added no control that required it to wait for the one before, it could happen alongside rather than after. Serial sequence is one of the largest and most invisible sources of cycle time, because each step inherits the wait of every step before it. Second, I fixed ownership so nothing waited in an unattended queue. Much of a two-month cycle is not work and not even waiting for a decision; it is work sitting unowned, between people, while everyone assumes someone else has it. Clear ownership at every stage removed those dead intervals.

Catching errors at source

I built validation into the early stages so errors were caught at source, which removed the downstream rework that had been inflating the cycle. Rework is one of the most expensive forms of delay because it does not just add a step — it sends an item backward through steps it has already cleared, multiplying the cost of a single error. When a mistake surfaces only at the end of a two-month cycle, correcting it can mean restarting much of the journey. Validating early meant errors were caught when they were cheap to fix and before they had travelled, so far fewer items looped back. This is also why a shorter cycle is a more accurate one: there are fewer places downstream for an error to hide and compound.

Standardising and instrumenting to hold the gain

A gain that is not measured regresses. I standardised the process across all 75 entities and instrumented it, so cycle time became a visible, governed metric rather than an assumption. Standardisation mattered at this scale because 75 entities running 75 variants of an approval process is itself a source of delay and an obstacle to improvement — you cannot manage what is defined differently everywhere. Making cycle time a measured, visible number gave the organisation something to govern: drift back toward the old length would now show up early as a movement in the metric, rather than being discovered when the cycle had quietly crept back to months. Measurement is what turned a one-time compression into a process that could keep improving.

The transferable principle

The principle applies to any approval or fulfilment cycle that has grown long over time. The length is almost never the work; it is serial sequence, unowned queues, and downstream rework from errors caught too late. The fix is not to chase approvals harder but to re-engineer the structure: map the flow to separate control from delay, parallelise what does not need to be serial, fix ownership so nothing waits unattended, validate early so errors are caught at source, and then standardise and measure so the gain holds. The same discipline compresses any cycle where cash and client experience are trapped inside a process that was never actually designed.

Questions

Common questions.

The work followed the structure of the problem rather than a fixed clock. It began with mapping the flow across all 75 entities to separate control from delay, then re-engineering the sequence and ownership, then building in early validation, and finally standardising and instrumenting the process so the gain would hold. The mapping and redesign are where the compression is created; the standardisation and measurement are what make it durable across that many entities. A transformation of this breadth lands in stages, with the structural changes producing the visible drop in cycle time and the governance layer ensuring it does not creep back.

By cycle time — the elapsed time from the start of the approval process to its completion — measured before and after the redesign across all 75 entities. It fell from roughly two months to fifteen days, a reduction of about three-quarters. The figure is end-to-end elapsed time rather than hands-on work, which is the point: the delay lived in the structure between the steps, not in the steps themselves. Instrumenting cycle time as an ongoing, governed metric is also what allowed the result to be proven and sustained rather than asserted, because regression would show up as a measurable movement.

No, and protecting the controls was the central constraint. It is easy to make an approval cycle faster by deleting the checks that protect it; the discipline is to remove only the steps that add delay without adding control. The mapping stage existed precisely to tell those apart — which sign-offs genuinely reduced risk and which were habit, duplication, or compensation for a problem better fixed upstream. Parallelising independent approvals and removing unowned waiting time shortens the cycle without touching the controls that matter. In fact, catching errors at source strengthened control, because mistakes were caught earlier and more reliably than before.

A two-month cycle ties up cash, because billing that has not cleared approval has not converted to collectible revenue. It strains clients, who experience the delay directly. And it hides errors in its own length: the longer the cycle, the more places a mistake can sit unseen before it surfaces, and the more expensive it is to correct once it does, because it has travelled further through the process. Compressing the cycle attacks all three at once — it accelerates cash, reduces the friction clients feel, and makes the process accurate enough that errors are caught early rather than discovered late.

Yes, if you have an approval or fulfilment cycle that has grown long over time — billing, procurement, onboarding, claims, any multi-step process gated by sign-offs. The causes are remarkably consistent: approvals running in series that need not, work waiting in queues nobody owns, and rework from errors caught too late. The remedy is the same regardless of sector: map the flow to separate control from delay, parallelise what can run alongside, fix ownership at every stage, validate early, and standardise and measure to hold the gain. The 75-entity scale here makes the point vivid, but the structural problem is one of the most common in operations.

By standardising the process across all 75 entities and making cycle time a visible, governed metric. Standardisation removed the variation that lets a process quietly drift, since 75 different versions of an approval flow are impossible to hold to one standard. Instrumentation gave the organisation an early-warning signal: any slip back toward the old length now appears as a measurable movement in cycle time rather than being noticed only once the cycle has crept back to months. Because the compression came from structural change — parallel approvals, clear ownership, early validation — rather than from extra effort, holding the gain did not depend on people sustaining heroics.

Next case

4×

Quadrupling newsroom throughput to 400 stories a day

There is a number like this in your operation.

A diagnostic is the fastest way to find it and put a figure on what fixing it is worth.

Book a consultation