On this page
A startup financial model review should take less time than rebuilding the spreadsheet and produce more than a list of formula errors. A useful mentor review tells a founder which assumptions are unsupported, which cash risks could stop execution, and which questions an investor will ask first. For Indian founders preparing for angels, grants, or an institutional round, the model must connect operating reality to the amount of capital being raised.
A startup financial model review starts with decisions
Mentors often begin by checking whether formulas add up. That matters, but it is not the first job. A startup financial model review should begin with the decision the model is meant to support: whether to raise now, how much to raise, which customer segment to pursue, when to hire, or whether the current pricing can sustain the business.
Ask the founder to explain the model without opening the spreadsheet. They should be able to state their revenue engine, major cost drivers, expected cash runway, and the milestones the proposed capital will fund. If they need to scroll through tabs to answer basic questions, the model is too complicated or the founder has not made the assumptions their own.
Review the model in the context of the company’s stage. A pre-revenue founder needs a testable customer and pricing plan, not a five-year forecast with false precision. A company with paying customers needs to show what drives repeat usage, sales conversion, collections, and contribution margin. The model should match the evidence available today.
Mentor test: At the end of the review, the founder should know what they will do differently next week. If the only output is “clean up the sheet,” the review did not reach the operating decisions.
At Nebula, we treat financial planning as part of the work across validation, product, fundraising, and go-to-market. The model has to explain the path from current proof to the next fundable milestone, rather than decorate a pitch deck.
Test assumptions before testing formulas
Every output in a model comes from an assumption. Mentors should spend most of their time on those inputs: price, customer acquisition rate, conversion rate, sales cycle, churn, hiring date, salary, payment terms, and gross margin. A formula can be technically correct and still produce a bad forecast because one input has no basis in evidence.
Ask each assumption a simple question: “What happened in the real world that makes you believe this?” The answer may come from customer interviews, a pilot, invoices, website data, vendor quotations, or a documented hiring plan. “A competitor charges this” and “the market is large” are context, not proof that the startup can achieve the same result.
For an India-focused company, mentors should also check local operating details. Does the model account for GST where relevant? Are customer collections based on actual payment behaviour? Does the sales plan distinguish between a founder-led sale and a repeatable sales process? Are service delivery costs included when the business sells through cities or regions with different fulfilment conditions?
- Mark each assumption: actual, tested, estimated, or aspirational.
- Ask for the source: a customer record, contract, quotation, experiment, or internal calculation.
- Set an owner: someone must update the assumption when new evidence arrives.
- Set a review date: assumptions expire when customer behaviour or costs change.
This classification gives founders a cleaner view of uncertainty. It also prevents a mentor from debating a decimal point when the underlying input is still a guess.
Review revenue as an operating system
Revenue forecasts are where many early-stage models lose credibility. Founders often start with a market-size figure, apply a small percentage, and call the result a plan. Mentors need to reverse the calculation. Start with the number of sales conversations, demos, trials, channel partners, orders, or active users required to produce the forecast.
For each revenue line, trace the sequence from acquisition to cash. A SaaS business may need leads, qualified calls, pilots, conversions, paid accounts, monthly retention, and collections. A consumer or commerce business may need traffic, conversion, average order value, repeat purchase, cancellations, and fulfilment capacity. A services business may need project pipeline, team capacity, billing milestones, and payment collection dates.
| Review question | What the founder should show | Warning sign |
|---|---|---|
| How does demand enter the model? | A visible pipeline or user-acquisition driver | Revenue grows without any sales activity or channel cost |
| How is price set? | Current price, tested price, or a stated pricing experiment | Price rises without a product or customer reason |
| When does revenue become cash? | Payment terms and collection timing | Invoice value is treated as cash received |
| What keeps customers? | Retention, repeat purchase, or renewal logic | Every customer stays forever by default |
Do not demand certainty from a young company. Demand traceability. If the founder cannot connect a revenue month to a sales action, product event, or customer behaviour, the number belongs in a scenario, not the base case.
Find the cash risk, not only the profit and loss
A model can show accounting profit and still leave the company unable to pay people or suppliers. This is why mentors must review cash timing separately from revenue and expenses. The cash balance is often the number that determines whether the team gets another chance to learn.
Check when customers pay, when vendors must be paid, and whether taxes, deposits, refunds, inventory purchases, or platform payouts create gaps. In India, founders can face long collection cycles from business customers while paying employees and operating costs monthly. A model that ignores timing can make a capital requirement appear smaller than it is.
Review the burn calculation line by line. Separate fixed commitments from spending the founder can pause. Then ask what cost is required to hit the next milestone and what cost merely makes the plan look bigger. Early teams frequently add future hires too early, include broad marketing spend without a channel thesis, or postpone expenses that are necessary for delivery.
Cash warning: Never accept a single “burn” number without seeing its components. A founder should be able to explain what changes if revenue arrives late, a key hire starts earlier, or collections slip by one cycle.
This is also the right point to check funding use. Capital should be linked to a defined period of work and measurable outcomes: customer validation, product release, repeatable acquisition, or revenue proof. If the raise amount comes first and the plan is fitted around it, reverse the process.
Need a tighter raise plan before investor conversations? Apply for Nebula 1.0, our current 2-week fundraising sprint.
Force base, downside, and upside cases
A single forecast implies that execution will follow one clean path. Startups do not operate that way. Mentors should require a base case, a downside case, and an upside case built from a small number of changed assumptions. This makes uncertainty visible without turning the model into a maze of tabs.
The base case should reflect what the founder can defend using current evidence. The downside case should model the events most likely to hurt cash: a slower sales cycle, lower conversion, delayed collections, weaker repeat purchase, or higher delivery costs. The upside case should show what changes if a specific learning or distribution bet works.
- Choose three drivers: use the inputs that most affect cash and milestone timing.
- Change them deliberately: avoid changing every number at once.
- Measure the result: compare cash balance, runway, hiring timing, and next-round readiness.
- Define the response: state what the team will cut, delay, or double down on in each case.
The mentor’s job is not to force pessimism. It is to make the founder ready for variance. Investors will test whether the team understands what happens when sales take longer or costs rise. A founder who has already worked through those cases can discuss risk with control rather than defensiveness.
Scenarios also improve internal discipline. When actual performance differs from the model, the team can identify the driver that moved instead of declaring that the entire plan failed. That turns the spreadsheet into a weekly management tool.
Audit structure and investor readiness
Once the business logic holds, review the spreadsheet structure. A mentor should be able to move from assumptions to operating drivers, revenue, costs, cash flow, and funding requirement without hunting through unrelated tabs. Clear structure helps investors inspect the work and helps founders update it after the meeting.
Keep inputs separate from calculations. Use clear labels for months, currency, units, and assumptions. Avoid hard-coded numbers inside formulas unless there is a clear reason. Check for broken links, circular references, double-counted costs, inconsistent dates, and totals that do not tie across statements. These are basic checks, but errors here can make an otherwise credible founder appear careless.
Ask for a short model summary page. It should show current position, core assumptions, monthly cash movement, key milestones, and the capital requirement. An investor does not need to inspect every line in the first meeting. They do need to see that the founder knows the drivers and can provide detail when asked.
Practical rule: Build the investor view from the operating model. Do not create a separate spreadsheet for fundraising numbers. When two versions disagree, confidence drops quickly.
For founders preparing a raise, the model must agree with the deck. Customer count, pricing, revenue timing, hiring plan, and use of funds should tell the same story in both places. Review these documents side by side before sending either one.
Run review meetings that change behaviour
Good mentors do not take over the model. They create a review rhythm that teaches the founder to manage it. Use a focused meeting format: founder walkthrough, assumption challenge, cash-risk review, scenario discussion, and a written list of changes. Keep the meeting anchored to decisions, not spreadsheet aesthetics.
Ask founders to send the model before the meeting with a note on what changed since the prior version. Then begin by reviewing actuals against the prior forecast. Where did reality differ? Was the assumption wrong, was execution weak, or did an external condition change? This comparison builds the habit investors want to see: learning from evidence and updating plans without hiding misses.
End every review with a small set of actions. One item may be to validate willingness to pay. Another may be to separate sales pipeline from cash collections. A third may be to delay a hire until a revenue trigger is reached. The founder should know the owner, deadline, and expected effect of each action.
We co-build with founders across validation, product, fundraising, and go-to-market rather than operating as an advisory layer. Our three-phase process moves from venture validation through product development to go-to-market and scale, while our engagement models fit different stages of company building.
A financial model earns trust when it records what you know, exposes what you do not know, and gives the team a plan for learning faster. If you need to turn that plan into a fundable raise, Apply for Nebula 1.0.
Enjoyed this? Get the next one in your inbox.
Fundraising guides and validation frameworks, every two weeks. No spam.
Frequently asked questions
What should mentors review first in a startup financial model?
Start with the decision the model supports and the assumptions driving the forecast. Formula checks come after the operating logic is clear.
How many scenarios should a startup financial model include?
Use a base, downside, and upside case. Change only the few assumptions that most affect cash, milestones, and hiring timing.
Ready to build your startup?
We work with a small number of founders each year — mentorship, fundraising support, and a co-founder network included.
Start a conversation
Talk to the founder directly. We reply within two working days.
Applying to Nebula 1.0? Apply here →