Turning a Sales Pipeline Into a Revenue Budget You Can Defend

A sales forecast and a revenue budget are two different documents with two different purposes, and the mistake that ruins a budget is treating the second as a tidied-up copy of the first.

A sales forecast is a management instrument for the sales function. It answers what the team should be working on and whether the current quarter is going to land, and it is supposed to be ambitious, because a forecast that nobody has to stretch for is not doing its job.

A revenue budget is the number the rest of the company is committed against. Hiring is scheduled from it. Capacity is bought against it. Debt service is planned around it. It is the denominator of every cost decision made in the following twelve months.

The finance job in between the two is not to argue about optimism. It is to document the translation, so that when the year comes in under plan, and it will in some month, you can say which of four things went wrong: the recurring base shrank, the new business did not close, it closed later than assumed, or it closed smaller than assumed. Those four have completely different responses. A budget built by accepting the sales number wholesale, or by quietly cutting it, cannot distinguish between them, and by the second quarter the conversation degenerates into whether the plan was realistic, which is a conversation that has never once produced a decision.

Both failures are common and the quiet cut is the worse one. A revenue budget that simply equals the sales forecast has had no finance work done on it. A revenue budget where finance has applied an unstated haircut is worse, because the adjustment is invisible, it cannot be scored at the end of the year, and the sales lead correctly concludes that giving finance a real pipeline is punished. Do that twice and you no longer receive a real pipeline, which removes the input the whole exercise runs on.

Build four components, and never net them

The revenue budget is four separate builds that are added together at the end and reported separately all year.

Component	Where it comes from	Who owns the assumption
Recurring and contracted base	The contract register, contract by contract, with end dates and renewal terms	Finance builds it, the owner agrees the renewal assumptions on the largest contracts individually
Known losses and non-renewals	What you already know: notice given, a contract not being renewed, a customer winding down	The person who holds the relationship, in writing, by name
New business	The pipeline, staged and lagged as below	Sales owns the pipeline, the owner owns the weighting, finance owns the arithmetic
Price and volume changes on the base	Announced or planned price changes, contracted escalators, known volume changes on existing customers	Owner, and it is a decision rather than a forecast

Keep them separate in the model and separate in the monthly reporting, because that separation is what turns a miss into a diagnosis. A company that reports one revenue line against one budget line learns in month five that revenue is behind. A company that reports four learns that the base held, prices went in as planned, and new business closed sixty days later than assumed, which is a completely different meeting.

The base is built from contracts, not from last year’s revenue

Start with the contract register rather than the general ledger. Last year’s revenue is what happened; the register is what is still in force.

Every contract with a value, a start date, an end date, a renewal mechanism and a notice period. For the largest ones, individually, name the renewal assumption and who agreed it. For the tail, group them and state the group assumption in one line, along with what it is based on.

The thing to be careful about here is the blanket renewal percentage applied across everything because it is easier. It might even be roughly right in aggregate, and it hides the two or three contracts whose loss would actually change the year. Those are the ones the owner needs to be asked about by name, and being asked about them by name in the budget build is how a renewal conversation happens in time to matter.

Where revenue is recognised over time rather than on billing, the base is built on the recognition profile from your revenue recognition policy, not on the billing schedule. A contract billed annually in advance and recognised monthly contributes to the budget differently from the way it contributes to cash, and mixing the two produces a plan whose revenue line and cash line are both defensible and do not agree with each other. Keep the billing dates on the same contract register, because they are what the cash forecast runs on.

Staging rules: define the stage by evidence, not by confidence

Every pipeline has stages, and in most companies they are defined by how the rep feels about the deal. That is not a criticism of sales, it is what a stage is for internally. It is unusable as a budget input, because the definition moves with the person.

Redefine each stage by an observable event. Not “highly likely”, but a thing that has either happened or has not:

• The customer has confirmed a budget exists for it.
• A written proposal has been issued with pricing in it.
• The customer has named a decision date and a decision maker.
• Terms have been agreed and it is with their legal or procurement.
• It is signed.

Those are illustrative rather than prescriptive; the right list is the one that matches how your customers actually buy. The requirement is that each stage is a fact someone can check, so that two people looking at the same deal put it in the same stage.

Then the weighting, and this is where every article on the subject wants to hand you a percentage. There is no honest number to give you. Conversion varies with the industry, the deal size, the sales motion, the person and the year, and any figure quoted at you without your own history behind it was made up somewhere upstream and repeated.

So, in order of preference:

Use your own history if you have it. Two or three years of pipeline data with stage transitions is enough to derive a rate that means something for your business. Most companies at this size do not have it, because the pipeline has been rebuilt in a new system twice.

Where you do not have it, the weighting is a decision, not an estimate. The owner sets it, it goes in the assumption register with their name and the date, and it is explicitly labelled as an assumption without historical support. That label matters, because it makes the number falsifiable. At the first reforecast you score it against what actually converted, and by the second year you have your own history and the assumption becomes an observation.

Start capturing the data this year regardless. Snapshot the pipeline by stage on the same day every month and keep the snapshots. It costs nothing and in eighteen months it is the most valuable planning input the company has.

The two lags, which are the biggest single overstatement

This is the part that gets left out, and it is usually worth more than the weighting argument everybody spends their time on.

Lag one: close to start. A deal that closes in a given month does not start that month. There is signature, then onboarding, then a start date the customer chose. Measure your own typical gap, or agree one with the delivery lead, and apply it. It is rarely nil and it is often longer than sales assumes, because the part after signature belongs to somebody else’s calendar.

Lag two: start to recognised revenue. Once it starts, the revenue arrives according to your recognition policy, not all at once. A contract recognised over its term contributes a fraction of its value to the year it starts in.

Put the two together and the arithmetic is unforgiving. A deal that closes in the fourth month, starts in the sixth, and is recognised evenly over a twelve month term contributes just over half its annual value to the budget year, and a deal that closes in the tenth month contributes very little to this year no matter how large it is. That is not pessimism, it is the calendar.

The practical consequence, and it is the sentence worth taking out of this piece: the size of next year’s revenue budget is decided mostly by what closes in the first half of the year. Deals in the second half are next year’s revenue with this year’s celebration attached. A budget build that treats a fourth-quarter close as equivalent to a first-quarter one has overstated the year, and the overstatement will not surface until the hiring committed against it has already happened.

The capacity check, before the number is agreed

A revenue budget the delivery side has never seen is a plan to sell work the company may not be able to do.

Take the phased revenue, convert it into whatever unit your delivery is constrained by, and give it to the person who runs delivery. Ask one question: with the hiring plan as it currently stands, can this be delivered in these months? The answer changes the plan more often than anyone expects, and it changes it in the budget build, where it is cheap, rather than in the second quarter, where it arrives disguised as a delivery failure.

Where the answer is no, there are three responses and the owner picks: move the revenue later, move the hiring earlier, or reduce the plan. What is not a response is agreeing the revenue and hoping.

The assumption register

Every adjustment between the sales forecast and the revenue budget is a row here. If an adjustment is not on this register, it does not go into the budget.

Column	What it holds
Assumption	Stated in one sentence, as a rule rather than as an amount
Applies to	Which component, which contracts, which pipeline stage
Basis	Own history, an agreed decision with no history, or a contractual term
Owner	The person who agreed it, by name
How it will be scored	The specific thing that will be measured at the reforecast to say whether it held

The last column is the one that turns the register from documentation into an instrument. An assumption you cannot describe a test for is not an assumption, it is a preference. And a register scored at each reforecast is how the second year’s budget gets better, which is the only mechanism there is: not a better method, the same method with a year of scored assumptions behind it.

What the output looks like

One page. Revenue by month, split into the four components, with a total. Behind it, the contract register, the staged pipeline, the lag assumptions and the register above.

The monthly variance report then has four lines rather than one, and each line has an owner. Base variance goes to whoever holds the relationships. New business variance goes to sales, split between what did not close and what closed late, because those are different problems. Price variance goes to the owner, because it was a decision.

That split is the whole return on the exercise. Anyone can produce a revenue budget. What makes it defensible is that when it is missed, and it will be missed in some month, the document tells you which assumption broke instead of starting an argument about whether the number was ever realistic.

What we do not do

We do not publish a conversion rate, a close rate or a benchmark, here or in a client’s model, because no such figure exists that is true for a particular company and using someone else’s is how a plan acquires a number nobody can defend.

We do not apply a weighting the sales lead has not seen and agreed. A haircut applied quietly is worse than no haircut, because it cannot be scored and it teaches the sales function to stop giving finance real data.

We do not build a revenue budget as last year plus a percentage. That is the number a company arrives at when nobody wants to have the conversation, and it carries no information about what has to happen for it to be true.

And we do not treat a signed deal as revenue in the month it was signed. It starts when it starts and it is recognised when it is recognised, and the gap between those three dates is where most first budgets lose their year.