When your business runs through joint ventures and project finance, the usual startup-valuation shortcuts quietly break. Here is how to keep the numbers honest.
Most early-stage valuation advice assumes a simple shape: one company, one profit-and-loss statement, revenue that grows and costs that follow. Plenty of real businesses do not look like that. If you are building something capital-intensive (energy, synthetic fuels, hardware at scale, real assets, infrastructure climate-tech), your business is often a parent company that spins up a special-purpose vehicle (SPV) for each project, brings in partners and a bank per project, and earns its return through those vehicles rather than directly.
That structure is the right way to finance the business. It is also the fastest way to produce a valuation model that contradicts itself without anyone noticing. This guide walks through how to value a company built this way, what decision drives the whole model, and the specific modelling mistakes that wreck the number.
The short answer
Before you model anything, decide one thing: is each SPV part of your company, or a separate company you own a stake in? You have two clean options, and the entire valuation depends on picking one and committing to it.
- Consolidate the SPV. Treat the project as if it sits inside the company. All of its revenue, all of its costs, all of its capex, and all of its financing go into your model.
- Treat it as external. The SPV is a separate company you happen to own a share of. None of its internal numbers touch your model. Only the cash it distributes up to you appears: dividends, profit share, and the repayment of any loan you made to it.
Both can be correct. They are two ways of telling the same economic story, and done properly they land on a similar valuation. What breaks a model is mixing them: booking the project’s full revenue but only your share of its costs, or counting the distributions you receive while also loading the project’s capex onto your books.
This is the same fork that applies to any holding company with subsidiaries, where the question is whether to value the group as one consolidated company or as a portfolio of separate ones. The principle is old and well established: when a parent holds stakes in other entities, you value each holding on its own terms and avoid double-counting, because a parent and its projects usually have very different cost of capital, growth, and reinvestment profiles.
The decision in practice: is the SPV part of your company, or not?
Say a single project needs a €20M reactor. The startup does not fund that alone. The capex sits inside an SPV co-owned by the startup, one or two strategic partners, and often a bank in the consortium. The startup puts in a slice of the equity and, in return, collects a share of whatever the project eventually pays out.
So when you model the parent, what belongs on its books? The honest test for which route to take is the one you would use for any subsidiary. If the project shares your brand, your team, and your operations, and could not be cleanly sold off on its own, it behaves like part of the company, so consolidate it. If it is genuinely standalone, with its own balance sheet and its own investors, and you mainly care about the cash it returns to you, treat it as external. Pick the route that matches how the business actually works, then model it consistently all the way through.
Option 1: consolidate the SPV (and make the financing add up)
Once you decide to consolidate a project, you have to represent its financing inside a model built for a single company. This is where most consolidated models go wrong, because the capex is easy to remember and the financing that pays for it is easy to forget. Four mechanics matter.
Capex is annual, not cumulative. The capex line is what you spend on assets in that specific year, between 1 January and 31 December, not the running total. If you buy one reactor for €20M in 2030 and two more for €40M in 2031, the 2031 capex line is €40M, not €60M. The asset itself is not a cost. The depreciation that follows spreads that €20M over the asset’s life, say €1M a year over twenty years, and that is the part that hits your profit-and-loss.
Match every capex spike with its financing. This is the error that produces alarming negative cash flows: capex jumps by €40M but the financing lines move by only a fraction of that. Of course the cash flow goes negative, because the model is funding the gap out of thin air. Infrastructure is not financed that way. It is financed with project debt and partner equity. A clean DCF keeps operating flows and financing flows separate so each capex commitment is matched to the money that pays for it. Put the financing in and the cash flow behaves.
Debt goes in the debt line, as a balance, not a flow. Project finance, meaning the bank’s loan to the SPV, is debt. The debt line on the balance sheet is the amount outstanding at the end of each year. It rises when you draw a new loan for a new project and falls as you repay. Draw €19M, repay €2M a year, and the line reads €17M the following year, plus whatever you draw next. With several projects a year, you track the total outstanding across all the loans, so it is worth modelling that explicitly in your spreadsheet before you transcribe it.
Partner equity goes in future fundraising. This is the counter-intuitive one. When co-investors put equity into a project, it is not equity in your company. But if you have chosen to consolidate the whole project, the only consistent way to represent it is as an equity contribution in the future-fundraising line. You are modelling the project as if it sits inside the company, so its equity financing has to appear as equity financing. A €20M project financed half with debt and half with equity shows up as roughly €10M of project debt in the debt line and roughly €10M of partner equity in future fundraising. For a pure infrastructure project you may decide to model it as all debt, which is a legitimate simplification.
Put plainly: every euro of capex you consolidate needs a matching euro of financing, split between the debt line for project loans and future fundraising for partner equity. Get that mapping right and the model stops fighting you.
Option 2: treat the SPV as external (only the cash that reaches you)
The external route is simpler to model and harder to oversell. The SPV’s reactor, its project debt, its construction costs: none of it appears in your projections. You carry your equity stake as an investment, and once the project is running you book the cash it pays you, meaning your dividends, your profit share, and the repayment of any loan you made to the vehicle. That is the whole of it. In accounting terms this mirrors the equity method, where only your economic share of a separate entity flows through, not its gross revenue and costs.
The trade-off cuts both ways. Your top line is smaller, because you are not claiming revenue you only partly own. But your balance sheet is also not carrying tens of millions in project debt that is not really yours. For a parent raising on its own equity story, built on a technology, a pipeline of projects, and a development capability, this is often the cleaner story to tell, because it shows what the parent actually earns rather than the gross scale of the projects it assembles.
The rule that keeps both honest: never mix the two
If you book the project’s full revenue, carry its full costs, capex, and financing too. If you book only the distributions you receive, keep the project’s capex and debt off your books entirely. Taking the full revenue but only your share of the costs, or booking distributions while also loading in the capex, is the single most common way these models go wrong. It quietly inflates the valuation, and it is exactly the inconsistency a sharp investor will find first.
Watch the terminal year
In a discounted-cash-flow model, the last year of your projection does outsized work. It is the basis the model uses to extrapolate the company’s value into perpetuity. If your terminal year happens to land on a huge capex outflow, a year you are buying three reactors at once, the model projects that distortion forever and wrecks the valuation.
So make the final projection year representative of the steady state you expect afterwards, not an anomalous peak or trough. For a business with lumpy, project-driven capex this takes deliberate attention, because you do not want the perpetuity built off your single most cash-negative year. If your natural projection happens to end on a spike, extend it by a year or two until it settles, or normalise the final year to a run-rate you can defend.
Where investors actually push
Equidam blends qualitative and financial methods by design, and that blend holds for a capital-intensive business too. What changes is where the scrutiny lands. For a long-horizon project, the investment case rests on the projected economics of building and operating the assets, so the people writing the cheque reason mostly from the cash flows, and that is where your model has to be solid.
The practical implication: the hard questions in your raise will not be about your team score or market timing. They will be about technology risk, how much is de-risked versus still to be proven, and whether the demand and the project pipeline genuinely exist. The valuation follows the financials, the financials follow the assumptions, and the assumptions are what you defend in the room.
Expect one limitation rather than fighting it. If your projections run a decade or more, benchmark comparisons that work cleanly over three to five years run out of data past a point, because very few companies project that far. That is not a flaw in your model. It is the nature of a long-horizon infrastructure play, and most investors understand immediately why your charts look different from a software company’s.
Sanity check: model it both ways
If your tool supports scenarios, build both versions and compare them. One consolidates the whole project. The other carries only the distributions the SPV pays you. Done consistently, they should land on a similar valuation, because they describe the same economics from two angles.
If they diverge wildly, you have broken the rule somewhere: full project revenue without the matching costs and financing, or distributions booked while the project’s capex is still sitting in your model. Treat a large gap between the two as a bug to hunt down, not a result to choose between.
A note on industry-average defaults
Valuation tools, including ours, pre-fill many line items from industry averages: depreciation, receivables, inventory, working capital, tax. For a small, conventional startup those defaults are a reasonable starting point. For a capital-intensive project company they are often wrong, because the averages describe a different kind of business. Depreciation pulled from industry norms assumes an asset that does not exist until the first build years out. Receivables benchmarked to a typical cohort can be nothing like your payment terms. Tax is computed from profit, so it goes stale the moment you change a line above it.
The defaults are a scaffold, not an answer. If you have already built a detailed operating model in a spreadsheet, and an infrastructure founder always has, put your own numbers in, and re-trigger the calculated lines so depreciation, tax, and working capital reflect the new reality instead of the old default. Every line you override should trace back to an assumption you can defend, because an investor will ask.
Frequently asked questions
Should I consolidate my SPV or treat it as a separate entity for valuation?
Consolidate it if the project shares your brand, team, and operations and could not be sold off cleanly on its own. Treat it as external if it is genuinely standalone with its own balance sheet and investors, and you mainly care about the cash it returns to you. Either is defensible. The mistake is mixing the two within one model.
How do I avoid double-counting when my parent company owns subsidiaries?
Pick one treatment and apply it consistently. If you consolidate, include the subsidiary’s full revenue, costs, capex, and financing, and do not also add your dividend from it on top. If you treat it as external, include only the distributions it pays you, and keep its capex and debt off your books. The classic error is counting a project’s gross revenue while only partially counting its costs.
How do I model project debt in a startup valuation?
Project debt belongs in the debt line of the balance sheet as a balance, not a cash flow. It is the amount outstanding at year-end: it rises when you draw a new loan and falls as you repay. With multiple projects, track the total outstanding across all loans.
Where does partner equity into an SPV go in the model?
If you are consolidating the project, partner equity into the SPV goes in the future-fundraising line, because you are modelling the project as if it sits inside the company, so its equity financing has to appear as equity financing. If you are treating the SPV as external, partner equity does not appear at all, since you only book what the vehicle distributes to you.
Why does my valuation model show huge negative cash flows?
Usually because a capex spike is not matched by its financing. If capex jumps when you buy an asset but the debt and equity that pay for it are not in the model, the cash flow goes negative for a reason that is not real. Match every consolidated capex commitment to the financing behind it.
Can I use a DCF to value an infrastructure or project-finance startup?
Yes, and it usually carries most of the weight, because the case rests on the projected economics of building and operating the assets. The main cautions are keeping operating and financing flows consistent, matching capex to financing, and making sure the terminal year is representative rather than a one-off peak or trough.
Building something with this kind of structure and want to pressure-test your model before a raise? Walk through your numbers on Equidam. The methodology and every benchmark behind the figures are visible, so you can see where your assumptions diverge from the market and defend them when it counts.