Cash Flow Forecasting for Brands: Payment Schedules Instead of Gut Feeling

Your bank balance tells you how yesterday went. It tells you nothing about whether you can pay the goods invoice in six weeks.

That gap caught us out twice, even though there was enough money both times. It just was not there at the right moment. Since then we have built a running balance: a curve that shows, for the coming weeks, how much money is expected to sit in the account on any given day. Here is the setup, step by step.

Why bank balance and profit both mislead you

There are two numbers founders look at, and both answer the wrong question.

Your bank balance is a snapshot. It does not know that the Meta invoice goes out tomorrow and a Shopify payout arrives the day after. It is reassuring right up until it is not.

Profit from your books is a period calculation. It assigns income and expense to the month they belong to, not the day money moves. You can be profitable and still unable to pay, and in e-commerce that happens constantly. You pay for goods up front, you receive revenue afterwards, and weeks sit in between.

A cash flow forecast answers a third question: how much money is in the account on which day? This is about timing rather than size.

The core idea: everything is a payment schedule

The trick that keeps our setup simple is a single idea. Every payment you expect or owe becomes an entry with three fields:

• Amount. Positive for inflow, negative for outflow.
• Expected date. The day the money moves, not the invoice date.
• Certainty. Fixed, likely or estimated.

That is all it takes. A customer invoice with 30-day terms is a payment schedule with one entry. A purchase order with 30 percent down and 70 percent on delivery is a payment schedule with two entries. Rent is a payment schedule with twelve entries a year.

The running balance is then just a sum. You take today's bank balance and add up the entries day by day. The result is a curve with a lowest point, and that lowest point is the actual information.

Which inputs you need

Five blocks, no more. The first three are mandatory, the last two are what make the forecast usable.

1. Your current bank balance, automatically. Ours comes in through the Qonto API, because our accounting system is connected there anyway. A manually typed starting value is the fastest way to let a forecast quietly go stale. How our connection is built is described in Automating bookkeeping with AI.

2. Open outgoing invoices. Money somebody owes you. For agencies and B2B this is the biggest block, for pure D2C brands it is rather small. What matters is the expected payment date, not the payment terms. If a customer is always two weeks late, you enter it two weeks late.

3. Committed spend. Purchase orders with deposits and final payments, freelancers, customs and freight, tax prepayments. This is exactly where it helps if your purchasing is already structured. Every approved purchase order automatically creates its payment dates with us, because it hangs off the same inventory logic as our multichannel inventory management.

4. Fixed costs as recurring entries. Rent, salaries, software subscriptions, servers, insurance. You enter these once, with a rhythm and a day of the month. It is the dullest block and the one almost everybody underestimates. On our first pass we had 34 line items, four of which we had forgotten.

5. Expected revenue. The only block that is genuinely an estimate. We work with the daily revenue of the last 30 days and subtract the return rate. The decisive part is the delay: Shopify does not pay out on the day of sale, neither does PayPal, and marketplaces least of all. Enter revenue with the real payout delay, otherwise your curve looks too good too early.

Reading the curve: three numbers count

A forecast you only look at is decoration. We watch exactly three values.

The low point. How low does the curve go over the next eight weeks, and on which day. That is the number that decides whether an order goes out this week or next.

The distance to the floor. We defined a fixed lower limit: the balance must never fall below two months of fixed costs. If the forecast drops under it, that is a task rather than a thought.

The direction across the weeks. Is the low point rising week to week or falling? A low point that slides 3,000 euros deeper every week is a problem, even if it still looks comfortable today.

Out of that we built a simple traffic light that lands in Slack every morning next to the revenue report. Green means the low point is above the limit. Yellow means it gets close to it within the next 30 days. Red means it goes under. We look for five seconds and we know. Same principle as everything else in our setup: a machine calculates, a human decides, see 3 brands with 2 people.

How often to update

This is where most people go wrong in one of two directions. Either they build a model once and never look at it again, or they tinker with it every day.

Our rhythm:

• Daily, automatic. Bank balance, new transactions and the revenue average get pulled again. Without us doing anything.
• Weekly, 15 minutes. We walk through planned spend. New purchase order entered? Payment date moved? Customer paid, or not?
• Monthly, 30 minutes. We compare the forecast from four weeks ago with what actually happened. Where were we off, and why.

The monthly review is the part everybody skips, and it is the most valuable. It uncovered two systematic errors for us: we had set the return rate too low, and we had entered one payment provider's payout delay four days too short. Together those two made the running balance look several thousand euros too optimistic every week.

What this actually gave us

The benefit shows up in decisions that used to come from the gut.

We pushed a purchase order in the mid five figures back by ten days, because the running balance hit its low point in exactly that week. Ten days later the curve sat much higher and the order was uncritical. Without a forecast we would have either ordered blind or waited entirely out of caution and received goods too late.

Second case: we wanted to raise the ad budget for a month. The running balance showed that this collided with an upcoming tax prepayment. We moved the increase back by three weeks instead of scrapping it.

And a side effect I had not expected: discussions in the team got shorter. A gut feeling is hard to discuss, a curve is easy.

The limits

A cash flow forecast is a tool, not a crystal ball. These limits apply to us too:

• The revenue block is guesswork. Everything else is known, revenue is not. If your sales swing hard, your forecast swings with them. So we also run a pessimistic variant with 30 percent less revenue. If that still sits above the lower limit, we sleep fine.
• Seasonality breaks every model. An average of the last 30 days forecasts a November in November and a January in January. For Q4 we use last year's figures instead of the running average.
• The further out, the more worthless. Four to eight weeks are usable for us, three months are a tendency, twelve months are a story. We deliberately display only eight weeks so that nobody takes the long curve seriously.
• It does not replace bookkeeping. A forecast is not a profit calculation and certainly not tax planning. VAT, depreciation and the annual accounts stay with the tax advisor.
• Garbage in, garbage out. If payment dates are not maintained, the curve is worse than no forecast, because it fakes certainty. Those 15 minutes a week are not optional.
• Too small does not pay off. With five fixed-cost items, no meaningful purchasing and no payment terms, a spreadsheet will do. Where automation generally does not carry its weight is covered in What automation really costs.

How to start this week

You do not need a system for this. You need two hours and a spreadsheet:

1. Enter your fixed costs. All of them. Go through three months of bank statements for this, not your memory.

2. Enter the next eight weeks of planned spend. Purchase orders, taxes, freelancers, anything over 500 euros.

3. Estimate revenue conservatively and enter it with the real payout delay.

4. Sum day by day starting from today's bank balance and mark the low point.

5. Set a lower limit before you see the result. Otherwise you will fit the limit to the result.

Once you have done that by hand for three weeks, you know exactly which parts are worth automating. And you know which data you are missing. Our receipts moved into a system in exactly that order: understand manually first, then build.

Conclusion

A cash flow forecast in e-commerce stays well clear of financial mathematics. It is a list of payments with dates, summed up from today's bank balance.

The three blocks that make the difference are complete fixed costs, realistic payout delays and planned purchase orders. The rest is upkeep, 15 minutes a week.

And the most important part is the lower limit you set in advance, rather than the curve. Without it you look at a nice graph and keep deciding from the gut.

If you would rather not build this yourself: financial and bookkeeping systems like this are exactly what we build at Flowhouse, including for ourselves. Get in touch, we are happy to show you our running balance in detail.