Financial Modeling for Startups: An Introduction

That said, I think most founders should not be forecasting salary expenses on a per-position basis, even if they're under 100 employees. In my experience, you definitely won't know which positions you'll be hiring for further out than 1 year. If you're trying to impress investors it might work, but it will have limited utility for you personally.

Instead, you should group salaries by function (e.g. sales, engineering) and then make explicit your assumptions about labour efficiency. In the model described in the article, these assumptions are also there, but spread out over 40 rows in a table - not good! Assumptions in models should always be explicit.

For example, you could say that, in order to maintain your projected growth, you need to spend 10% of your revenue on sales staff. Or if you're aiming to be funded, you might instead work out how much labour it might take to make one sale, and then extrapolate based on how many sales you intend to make in the year.

You could look at engineering and decide you need 1 person in your engineering team (disregarding job title) per 100 clients. Then extrapolate, once again, based on number of projected clients. Obviously, software is meant to be scalable, so this all depends on how much up-front development you intend to do and at what pace you intend to add new features, so you might want to factor your growth targets in too.

Now, organisations normally bring in layers of management as teams grow. Do you need to account for this? Probably not. Remember, we're focusing on labour efficiency. These managers might increase your costs, but the idea is that they also help your teams function in a scalable way. And if you have good managers, the average tenure at your company should increase, leading to higher productivity.

The benefit of the above approach is that, now that all your assumptions have been made explicit, you can easily tweak them to see how they impact your model, rather than having to dig through many rows of data.

Lastly, and this is nit-picking, but ignoring income tax means this model should only be used to forecast up to periods where the company is not profitable. As soon as there's profit it will be completely wrong. Although it's a nice simplifying assumption if all you're trying to model is your road to break-even.

On top of the model every business needs an operational cash flow forecast going out say 3 months at least. For every day you enter the brought forward balance from yesterday. Then you add and subtract all of the line items of cash inflow and outflow for the day to forecast a closing can balance. It is more than possible for your financing model to show profitability and yet to be insolvent, because you are paying money out before it comes in. Like maybe a big customer pays on the 28th but payroll goes on the 25th...

Cash is king as they say, and a daily cash-flow forecast is the main tool that a financial controller would use to maximise it.

From what I was told, this mostly affects supply-chain heavy companies; software companies are mostly spared this kind of consideration.

What are some of the red flags that founders should be aware of when reading their own cashflow statements?

Think of it like this: if you are providing a service, but are not getting paid for this in advance, you are essentially giving the customer a short term loan. You cannot infinitely provide those short term loans considering that you have bills/salaries to pay. It might still be money that belongs to you, but if you do not have it in your bank account when your bills are due, you are insolvent.

Things to be very wary of when looking on your balance is having very low ratio of liquid cash in respect to your debtors post (e.g. unpaid outgoing invoices). This means that if your debtors are going to pay later than expected, you have very little runway to cover that. Now, what risk this poses to your company depends a lot on how many customers you have, whether they pay their invoice automatically, and what their history of late payments is. Furthermore, the same applies for you on the purchasing side: if the majority of your costs are on the purchasing side and you can afford to pay those bills later without getting your servers shut down, then being illiquid is less of a risk. If the majority of your costs is in employees, then you are in trouble: not paying employees is a big no-no, so that increases risks and allows for less wiggle room.