# Cash flow forecast from the pipeline: turning open deals into expected cash dates

https://salesbond.app/blog/cash-flow-forecast-crm-pipeline/
Published: 2026-10-20 · Updated: 2026-10-26

A cash flow forecast built from the CRM pipeline takes each open deal’s expected close date, adds the delay before the invoice goes out and the payment terms on top of that, and counts only the stages you trust, at a reduced weight. Without a payment-terms field on the deal, what you get is a bookings forecast with a new label, not cash.

A cash flow forecast as a whole is opening cash plus money coming in minus money going out, week by week or month by month. This article builds one row of it: receipts from deals that have not closed yet. The revenue side of it, what your CRM knows about next quarter and what it does not, is covered in [revenue forecasting for a sales manager](https://salesbond.app/blog/revenue-forecasting-sales-manager-crm/).

Most cash forecasting guides are written for the person who owns the spreadsheet. Ripple Treasury’s guide, for one, tells you to gather the data from your accounting software or bank accounts ( [Ripple Treasury: what is a cash flow forecast](https://treasury.ripple.com/posts/what-is-a-cash-flow-forecast-examples-template)). The pipeline isn’t on the list, though the least certain income next quarter is deals that haven’t closed, and those live only in the CRM. This piece is for the head of sales who gets asked for that row.

## What finance actually needs from a deal

The same Ripple guide makes the timing point plainly: most organizations use accrual accounting, which records income by invoice date rather than payment date, and a medium-term cash forecast has to account for that gap. A cash forecast puts money in the week it lands. Not when the deal is signed, and not even when it is invoiced.

So per open deal, finance needs a date the cash arrives and an amount they can believe. The CRM has neither. It has a value, an expected close date and a stage: inputs to the cash date, not the cash date.

Four things turn one into the other: the sign date, the payment terms, what triggers the invoice, and whether part of the money comes up front. The rep decides three of those, usually in the last week before signature. Finance can’t see them unless the deal record holds them.

One thing to settle before going further. Bookings (the value of contracts signed) are not billings and not revenue, and we covered the difference in [bookings vs billings vs revenue](https://salesbond.app/blog/bookings-vs-billings-vs-revenue-pipedrive/), so here we take it as read. The CRM holds bookings. Cash is what we are trying to derive from them.

## Close date is not cash date

Take a made-up deal: 24,000, expected to sign on 16 November, net 30, invoice at project kickoff, which on this team happens about two weeks after signature. In the CRM forecast it sits in November. In the bank it is 24,000 around 30 December: signature, plus two weeks to the invoice, plus thirty days to pay. One deal, six weeks of difference, and nobody did anything wrong.

The arithmetic is the whole method:

cash date = expected close date + invoice lag + payment terms

Payment terms are the part most teams know. The invoice lag, the days between signature and the invoice going out, is the part they skip, and it is often the bigger surprise. Ask finance what your contracts count the terms from. If the clock starts at the invoice, and the invoice waits for kickoff or first delivery, every day of that wait is added to the cash date. On a services team the kickoff lag can be longer than the terms. Measure it once from the last ten or twenty invoiced deals and keep the median as the the team’s default; you don’t need a number per deal.

Deposits move money the other way. With a 50% deposit on signature, the same 24,000 deal shows two cash events: 12,000 in mid-November and 12,000 at the end of December.

And terms are a promise, not behaviour. If finance tracks how late customers actually pay, add their number on top; if not, say so in the assumptions. How agreed terms feed finance’s collection metric is covered in [days sales outstanding and the payment-terms deal field](https://salesbond.app/blog/days-sales-outstanding-payment-terms-deal-field-hubspot/).

![Timeline of one deal: close date, invoice after a lag, due after payment terms, then cash, with a smaller deposit bar at day 0](https://salesbond.app/wp-content/uploads/2026/10/cash-flow-forecast-crm-pipeline-2.png)

## Four fields on the deal: sign date, terms, invoice trigger, deposit

Which fields, exactly? We would put four on the deal record and make three of them dropdowns, because free text gives you “net 30”, “Net30”, “30 days” and “standard”, and a forecast built on that is a forecast of spelling.

1. **Expected sign date.** This is the close date field your CRM already has. The change is the definition: the date the buyer signs, not the date the rep would like them to. The [five fields a forecast template needs](https://salesbond.app/blog/sales-forecast-template-crm-fields/) start with this one, and the same rule applies.
2. **Payment terms.** Prepaid, net 15, net 30, net 60, and whatever else your contracts actually use. For a cash forecast we ask for it from the proposal stage, filled with the terms on the table. Our DSO piece makes the field required at Closed won, and both hold: DSO needs the signed terms, a forecast of open deals needs the proposed ones weeks earlier, and the rep corrects the value at Won. When procurement asks for net 60 on signing day, [price it rather than give it away](https://salesbond.app/blog/net-60-payment-terms-request-pipedrive/).
3. **Invoice trigger.** On signature, at kickoff, on delivery, monthly in arrears. Each value maps to a lag in days that finance agrees once (on signature is 0, kickoff is your measured median). We keep the trigger on the deal and the lag in the spreadsheet, so a new lag never means editing deals.
4. **Deposit share.** A number, as a percentage, default 0. Most deals will stay at 0, and that’s fine.

Four fields is two more than most teams will fill. If you only get two, take payment terms and deposit share. The invoice trigger can be a team rule (“we invoice at kickoff”) until someone sells a deal that breaks it and the sign date is the close date you already police.

## Which stages go in, and at what weight

Fewer than you put in the sales forecast. That is our position, and here is the reason.

In a bookings forecast, a deal at 10% is noise that averages out across the quarter. In a cash forecast, the same 24,000 deal at 10% puts 2,400 into a specific week, and that week then looks a little more funded than it is. Finance reads the week, not the quarter. A hire gets pencilled in. So we only include deals where the buyer has seen a price and has given a date: proposal stage and later, or Commit and Best case if you run forecast categories. Early-stage deals stay out of the cash view, even though they are in the pipeline forecast. Undercounting week 12 is a smaller problem than showing cash for a deal the buyer has not priced.

For the weight, use the number you already use for the weighted pipeline: stage probability, forecast category or the rep’s own figure, one number per deal from a known field (the choice is worked through in [how to build a weighted pipeline forecast](https://salesbond.app/blog/weighted-pipeline-forecast/)). Don’t invent a second set of percentages for cash. Two sets of weights means two meetings about why the numbers differ.

The weight multiplies the amount, never the date. A deal at 60% shows 60% of its value on its cash date. No customer pays 60%; the point is that across twenty deals the expected value is roughly right. With five deals and one of them half the quarter, it isn’t. In that case show the biggest one or two unweighted on there own line, so finance sees the lumpiness instead of a smoothed average that no week will ever match.

## A 13-week cash flow forecast from one CRM export

A 13-week cash flow forecast is a weekly cash forecast across one quarter. Ripple Treasury calls it “the most widely used standard in enterprise treasury management, providing a full quarterly view for each submission”, and files it under medium-term forecasts, the ones covering one to six months (same guide as above). Finance already thinks in that window, so your pipeline export should cover the same thirteen weeks.

Export open deals from proposal stage onward with these columns:

```
Deal, Owner, Amount, Expected sign date, Weight, Payment terms, Invoice trigger, Deposit %
```

Then make two rows per deal, because a deal can produce two cash events:

- deposit: date = expected sign date; amount = Amount × Deposit % × Weight
- balance: date = expected sign date + invoice lag + terms in days; amount = Amount × (1 − Deposit %) × Weight

Skip the deposit row when the deposit is 0. Then bucket each row into a week, with week 1 starting on the Monday of the week you build it. With the sign date in column D and the lag and terms as days in two helper columns, the balance date is `=D2+lag+terms`, and the week number is `=INT((date-start)/7)+1`, where start is that Monday.

Three invented deals, all names and figures illustrative. We built the view on Tuesday 20 October 2026, so week 1 starts on Monday 19 October; kickoff lag is 14 days.

Northwind renewal, 24,000 at 80%, expected to sign on 16 November, net 30, invoice at kickoff, 50% deposit. The deposit row lands on 16 November, week 5, at 9,600. The balance row lands on 30 December, week 11, at another 9,600.

Contoso onboarding, 9,500 at 60%, expected to sign on 25 November, net 15, invoiced on signature. One row: 10 December, week 8, 5,700.

Fabrikam pilot, 15,000 at 60%, expected to sign on 30 October, net 60, invoice at kickoff. One row: 12 January, week 13, 9,000.

The total, 33,900, matches the weighted bookings forecast for these deals to the unit. The timing doesn’t: the bookings view puts all of it in October and November, and the cash view puts the first money in week 5 and more than half of it in the last four weeks of the quarter. Then look at Fabrikam. It signs in week 2 and pays in week 13, because net 60 plus a kickoff invoice is more than ten weeks, and that’s the deal a rep would call “basically closed” in October.

Hand finance the weekly totals as one income row labelled “open pipeline, weighted”, separate from receivables (invoices already sent) and from won-but-not-invoiced deals, which are the next section. Write the assumptions (weights, lag, terms as agreed, no lateness adjustment) at the bottom of the sheet.

## The Monday check: won deals without a payment date

Deals fall into a gap between the two systems every month. A deal marked Won leaves the pipeline forecast the same day. It enters finance’s receivables only when an invoice exists. Between those two moments it is in neither forecast, and if the invoice trigger is kickoff, that gap can be weeks.

So one filter, run on Monday with the rest of the pipeline review: status Won, won in the last 90 days and payment terms empty or invoice trigger empty. For each deal on the list the rep either fills the two fields or tells finance the invoice can go out. Five minutes, most weeks zero rows. The weeks it isn’t zero are exactly the weeks the cash forecast would have been wrong.

A second filter for teams that take deposits: Won, deposit share above 0, deposit not received. The CRM can’t tell you whether the money arrived; the list of who to ask is still a sales list.

A disclosure, since this is now a weekly routine. We build SalesBond, a sales management layer on top of the CRM a team already uses; we started with Pipedrive. Its Sales Plan shows the target, the forecast for a chosen period and the gap between them, with the period, currency and assumptions stated explicitly. The cash forecast itself stays in finance’s spreadsheet, and we think that is where it belongs. If you want to see your pipeline against plan with the assumptions visible, [check your CRM with SalesBond](https://salesbond.app/).

What we would not do is wait for finance to ask. This week, add the payment terms and invoice trigger fields, run one export from proposal stage onward, and send finance the weekly row with its assumptions written underneath. Then put the Monday filter on next week’s pipeline review agenda.