The Definitive Guide toAI Data Centers
Ask the GuideAboutAccount

Calculators

Open models for the numbers that decide an AI build — one project, worked end to end: size the cluster, price the build, cost the runtime, then see if the finance closes. Defaults trace to the numbers register (current as of 2026-08); change them to your case, then save, share a permalink, or export to CSV.

Shared starting assumptions
Connected fields: Cluster sizing — model → MW (19/19) · Build cost — $/MW capex (4/5) · Training run — cost & time (12/12) · Project finance — CFADS, DSCR & IRR (20/20) · GPU TCO & $/GPU-hour (13/13) · Inference $/M tokens (4/4) · Facility energy & water (5/5) · Rack cooling feasibility (3/21) · Reliability requirements (2/2). Independent: Site-scoring playbook (0/6; local judgment inputs).
Workload
Commercial boundary: the billable factor drives rental revenue (a take-or-pay reservation bills every reserved hour of every installed GPU in the rack, because the contract rents the whole rack; a merchant fleet bills only the active GPUs' hours it sells; stranded GPUs stay a cost in the unit-cost view); productive utilization drives owned/rented unit-cost comparisons. They are parallel analytical cases, not additive hour buckets or a hybrid allocation.
Hardware generation
1400 W · 288 GB HBM · 72/rack · 135 kW/rack · 2.5 PFLOPS dense · 72-GPU indivisible SKU minimum · on-demand list ~$18/GPU-hr (context only; revenue and comparators use the underwriting rate)
Performance profile: llama-3.3-70b · fp8 · 32,000 context · 64 batch/concurrency · guide assumption (11,200 tok/s); substitute a measured value from this exact profile
Facility & location
Financing & schedule
NVIDIA GB300 NVL7256 active / 72 installed GPUs · 16 stranded · 1 racks135 kW/rack · qualify cooling paths0.14 MW IT / 0.16 MW facility$9M program$6.11/active GPU-hr · $1.21/M tok owned at 70% productive utilization522 t CO₂/yr-13.6% equity IRR · fails stated covenant
All assumptions are the guide defaults (as of 2026-09). Everything runs in your browser — the share link carries the scenario in the URL fragment (never sent to a server); only an explicit Save stores it to your account, versioned (v5).

Size it

Cluster sizing — model to megawatts

56 active / 72 installed GPUs · 0.16 MW at nominal TDP × PUE
VRAM per replica (weights 70 + KV 676 GB, +15% overhead)858 GB
Qualified GPUs per replica → replicas for demand (VRAM floor 3)8 × 7
Installed GPUs / stranded slots72 / 16
Installed racks (72/rack)1
Facility draw on installed units at nominal rack TDP × PUE (not the OEM facility-design provision or transient peak)0.16 MW
Rental cost on active GPUs at the underwriting rate$204,400/mo

The MW figure is an energy/TCO basis at nominal TDP. Electrical design uses the named rack's facility-design provision and transient peak (GB300 NVL72: 135 kW nominal, up to 142 kW facility basis, 155 kW peak) — three different numbers, never interchangeable → Ch 7.2. VRAM establishes only a memory floor. Enter a replica degree qualified for the named model, runtime, hardware, context and batch profile; supported degrees need not be powers of two. Purchase quantum is a separate SKU or contract input and is not inferred from rack density. Facility design power follows installed units, while rental cost follows the active fractional fleet. At long context the KV cache can dominate VRAM → Ch 9.7.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Model size70 B params
Bytes / param1 bytes
KV cache / token330 KB
Context length32000 tok
Concurrent requests / replica64 requests
Activation + framework overhead15 %
HBM per GPU288 GB
Peak demand50000 tok/s
Throughput / replica11200 tok/s
Serving capacity70 %
Qualified GPUs / replica8 GPUs
GPUs / rack72 GPUs
Purchase quantum72 GPUs
GPU TDP1400 W
Host overhead1.3393 × GPU TDP
PUE1.15 ratio
Underwriting rental rate18 $/GPU-hr

Illustrative purchase decision: assume a 70-billion-parameter model at one byte per parameter, 330 KB of KV cache per token, 32,000-token context, 64 concurrent requests and 15% framework overhead. Memory is (70 + 330 × 32,000 × 64 / 1,000,000) × 1.15 = about 858 GB per replica. Assume 288 GB per GPU and a separately qualified eight-GPU replica: the three-GPU memory floor does not replace that qualification.

Assume 50,000 output tokens/s peak demand, 11,200 tokens/s per qualified replica and 70% serving capacity. Round 50,000 / (11,200 × 0.70) up to seven replicas: 56 active GPUs. A stated 72-GPU purchase unit gives 72 installed GPUs, 16 stranded slots and one 72-GPU rack. At an assumed 135 kW nominal rack input and PUE 1.15, the nominal facility screen is about 155 kW. Fractional rental at an assumed $18/GPU-hour costs $1,008/hour for the active fleet.

Assume a $1,100/hour active-fleet rental allowance. The seven-replica case fits. Above 7 × 11,200 × 0.70 = 54,880 output tokens/s, demand needs an eighth replica: at 60,000 tokens/s, 64 active GPUs cost $1,152/hour and exceed the allowance, while the same 72-GPU purchase unit still fits. Acquire the exact serving qualification before committing the purchase.

Guide derivation. Method and handoff: Chapter 1.7 — The Requirements-and-Consequences Matrix.

Rack cooling feasibility

not established: direct liquid and residual-air paths must close at both duties; verify liquid capacity, both terminal approaches, supported fluid/flow/pressure, rack water and the air delivery/inlet envelope in the declared redundancy state
Current liquid / residual-air split121.5 / 13.5 kW
Future liquid / residual-air split205.2 / 22.8 kW
Future residual-air load22.8 kW vs 20 kW limit
Current cold / hot terminal approach5 / 5 K
Future cold / hot terminal approach5 / 5 K

At each operating point: liquid duty = rack heat × capture fraction; the air path removes the remainder. CDU cold-end approach = TCS supply to rack − FWS supply to CDU; hot-end approach = TCS return from rack − FWS return from CDU. Both must meet the selected 5 K requirement. Qualification includes the actual fluid, flows, pressure, component envelope and surviving plant capacity; positive residual air also requires proven delivery, inlet temperatures and containment. The current and future profiles are independent screening cases. No annual PUE follows from these temperatures or rack kW → Ch 5.1, Ch 5.2.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Current rack power (screening input)100 kW/rack
Upper roadmap rack heat load (screening input)150 kW/rack
Heat captured to liquid80 % of rack heat
Future heat captured to liquid80 % of rack heat
Liquid path qualified at both operating points?yes
Qualified liquid-path capacity120 kW/rack
Air delivery/inlet envelope proven at both duties?yes
Rack water connection available?yes
Rear-door system qualified?no
Qualified door heat-capture duty0 kW/rack
Room residual-air capacity30 kW/rack
Required terminal approach5 K
Current TCS supply to rack35 °C
Current TCS return from rack45 °C
Current FWS supply to CDU30 °C
Current FWS return from CDU40 °C
Future TCS supply to rack35 °C
Future TCS return from rack45 °C
Future FWS supply to CDU30 °C
Future FWS return from CDU40 °C

Choose whether to release a 100 kW current / 150 kW future rack design. Assume 80% liquid capture in each profile: current liquid/air duties are 80/20 kW and future duties 120/30 kW. The 120 kW liquid capacity and 30 kW room capacity are assumed surviving-path ratings at the entered conditions. The Yes controls assume qualified liquid equipment, rack water and proven air delivery/inlet conditions at both duties; they are not test records. Rear-door assistance is absent.

Use the Chapter 5.1 teaching operating point at both duties: TCS 35 °C supply / 45 °C return; FWS 30 °C supply / 40 °C return. Cold-end approach = 35 − 30 = 5 K; hot-end approach = 45 − 40 = 5 K. Each meets the assumed 5 K requirement. Both heat paths pass this stated screen, with zero spare future liquid or room duty. Release equipment only after the suppliers and inlet map substantiate these assumptions.

Raise only future FWS supply to 31 °C: the cold-end approach becomes 4 K and fails; the crossover is 30 °C. Changing airflow qualification to No also leaves the design unestablished. A 200 kW future rack would require 160 kW liquid and 40 kW air, exceeding both ratings. Change the exchanger or the operating point and requalify before freezing density; no PUE is inferred.

Primary method: ASHRAE Handbook (2023), Applications ch. 20 — thermal paths and CDUs. Method and handoff: Chapter 5.1 — Thermal Fundamentals & the Density Wall.

Build it

Build cost — capex per megawatt

$2.25M excl. servers
Facility (shell, electrical, cooling, land)$1.59M
Network & cluster infrastructure$0.66M
Intensity, servers excluded$16.7/W

Benchmarks: JLL global-average shell/core ≈ $11.3M/MW (50 MW single-tenant, air-cooled; liquid +10%); Epoch's 1 GW model runs facility+land+utility ~$11.8M/MW and network ~$4.9M/MW, with servers ~$21.2M/MW on top → ~$38B/GW up-front. Electrical dominates the facility split → Ch 2.5, Ch 1.8.

Scope & how the benchmarks reconcile

This models construction-period capex excluding the server fleet. The benchmarks, reconciled on Epoch AI's May-2026 1 GW model: $11.3M/MW is JLL's global-average shell-and-core (air-cooled, 50 MW single-tenant; liquid cooling adds ~10%); Epoch's facility + land + utility works line is ~$11.8M/MW and its network and cluster infrastructure ~$4.9M/MW; servers — GPUs included — add ~$21.2M/MW, which is how a 1 GW campus reaches ~$38B up-front. Electrical systems are 45–70% of construction cost (as of 2026 → register). The server fleet is deliberately outside this calculator — the TCO model owns it, and adding it here would double-count.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
IT capacity10 MW
Facility, land & utility works10 $M/MW
Network & cluster infra (excl. servers)4 $M/MW
Project-priced facility premium20 %
Regional multiplier1.1 ×

Illustrative capital scope: assume 10 MW of usable IT capacity, facility/land/utility works at $10 million per MW, network infrastructure at $4 million per MW, a quoted 20% facility premium and a 1.10 regional factor. Facility cost is 10 × 10 × 1.20 × 1.10 = $132 million. Network cost is 10 × 4 × 1.10 = $44 million. The total is $176 million, or $17.60 per IT watt, excluding servers.

An illustrative $180 million allowance for those same two scopes passes with $4 million remaining. Raising only the facility premium to 25% raises the total to $181.5 million and fails. The topology drawing and supplier scope establish the premium; the reliability requirement buttons do not price it. Add the server purchase once in the shared program capital model.

The facility-premium crossover is 23.6%: (180 − 44) / (10 × 10 × 1.10) − 1. Above it, reduce scope or raise the same-scope capital allowance.

Guide derivation. Method and handoff: Chapter 2.5 — Project Finance & Capital Formation (Mechanics).

Site-scoring playbook

64 / 100 · Workable with mitigation

Kill gates come first: power or interconnect at ≤2, or water or land/zoning at ≤1, disqualifies a site no matter how the weighted score averages out. This is an illustrative weighting template: power availability carries the most weight, and the 0–10 scores are your judgment calls, so record the evidence behind each one. Adjust the weights and add a latency gate for inference workloads before ranking real candidates → Ch 3.13.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Power availability / speed-to-MW7 /10
Interconnect & permitting6 /10
Power price / PPA6 /10
Land & expandability7 /10
Water & climate6 /10
Incentives / tax5 /10

Decide whether candidate A merits the next diligence spend. Assume judgment scores of 7, 6, 6, 7, 6 and 5 for power, interconnect, price, land, water and incentives. The displayed rubric weights those axes 30%, 20%, 15%, 15%, 10% and 10%. These are an illustrative investment preference, not executed agreements or measurements. The weighted trace is (7×30 + 6×20 + 6×15 + 7×15 + 6×10 + 5×10) / 10 = 63.5/100: “Workable with mitigation.”

Advance A to evidence collection under this rubric; hold a site commitment until the service date, land rights, thermal/water design and workload latency are established under Chapter 3.13. Change the power score to 2: the score becomes 48.5 and the power kill gate disqualifies A. The crossover is power ≤2, regardless of incentives. Reallocate diligence to a candidate with a viable power path.

Guide derivation. Method and handoff: Chapter 3.13 — Market Clusters & the Site-Scoring Playbook.

Reliability topology requirements

Topology not determined
Concurrent maintenanceRequired
Single-component fault ride-throughNot required by this screening input

Project topology requires named maintenance and fault states, the exact affected path, transfer interruption, post-event loading, path and control independence, common-mode dependencies, a recovery SLO, and workload and contract consequences. These two choices are useful requirements, but they cannot select N, N+1, distributed-redundant, 2N, a Tier, or a capex premium. Compare and price candidate designs only after that project evidence closes → Ch 12.1.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Concurrent maintainability required?yes
Ride through one component failure?yes

Decide which reliability requirements to carry into the design brief. Assume the owner requires both concurrent maintenance and ride-through of one component failure. The test is Boolean: Yes / Yes yields Required / Required. The topology result remains “Not determined from these two requirements.” Hold topology selection and pricing until named isolation/fault states identify the exact paths, surviving capacity, interruption, independent controls and workload recovery consequence.

Change the fault requirement to No while keeping maintenance at Yes. The fault requirement becomes “Not required by this screening input”; the crossover is the owner's acceptance of workload interruption on an unplanned component fault. That relaxes the design brief and accepts that service consequence. It does not select an N+1 or 2N topology or certify a Tier. Chapter 12.5 owns the state-by-state acceptance method.

Guide derivation. Method and handoff: Chapter 12.5 — Quantitative Reliability & Availability Modeling (RBD / FTA / Monte-Carlo).

Run it

Training run — time, cost, energy & CO₂

8.1 days · $9.7M rental
Compute (6·P·T)6.3×10²⁴ FLOPs
GPU-hours1.94M
Facility energy (incl. host + PUE)4,193 MWh (~$0.34M)
Emissions at 384 gCO₂/kWh1,610 t CO₂

MFU and goodput compound: a 40% MFU × 90% goodput scenario yields 36% of peak theoretical FLOPs as committed training work under the declared definitions. Treat 90% versus 96% only as an illustrative sensitivity; measure the named fleet, job, window, and event accounting, then attribute badput before assigning any gap to checkpointing or cordon policy → Ch 12.2.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Model size70 B params
Training tokens15 T tokens
Peak per GPU2.5 PFLOPS
Cluster size10000 GPUs
MFU40 %
Goodput90 %
Rental rate18 $/GPU-hr
GPU TDP1200 W
Host overhead1.5 × GPU TDP
PUE1.2 ratio
Power price0.08 $/kWh
Grid carbon400 gCO₂/kWh

Illustrative dense-model run: assume 70 billion parameters, 15 trillion training tokens, 10,000 GPUs at 2.5 dense PFLOPS each, 40% MFU and 90% goodput. Define MFU on productive compute time so goodput does not deduct the same lost time twice. Training work is 6 × 70 billion × 15 trillion = 6.3 × 10²⁴ FLOPs. Effective rate is 10,000 × 2.5 × 10¹⁵ × 0.40 × 0.90 = 9 × 10¹⁸ FLOP/s. The run takes 700,000 seconds, or 8.10 days and about 1.94 million GPU-hours.

At an assumed $18/GPU-hour, rental is $35 million. With assumed 1.2 kW GPU power, a 1.50 total-IT multiplier and PUE 1.20, constant-power energy is 4,200 MWh: $336,000 at $0.08/kWh and 1,680 tonnes at 400 gCO₂/kWh. Do not add electricity to rental when the rental already includes it.

The run passes an illustrative nine-day deadline. At 80% goodput it takes 9.11 days and fails. Change the training-work model for sparse or non-dense workloads; the screening formula does not qualify model placement or convergence.

The nine-day deadline requires at least 81.0% goodput: 6.3 × 10²⁴ / (10,000 × 2.5 × 10¹⁵ × 0.40 × 9 × 86,400). Below that, reserve more capacity or move the deadline.

Primary method: Kaplan et al. (2020), §2.1 — 6N training FLOPs per token. Method and handoff: Chapter 12.2 — The AI-Cluster Reliability Rethink: Goodput vs Facility Availability.

GPU TCO & cost-per-GPU-hour

$6.11 / active GPU-hr · server ownership, energy and facility charge
Annual cost / active GPU$37,450
· Depreciation$22,320
· Energy$1,943
· Opex$8,928
· Facility charge$4,259
· Installed-to-active allocation1.286× across all four cost lines
Breakeven utilization vs contract rental86%

The facility charge puts space and power delivery into the owned cost, so it compares like-for-like with a rental rate that already includes them; energy is billed separately at PUE. Compare against the contract rate you would actually sign, not an on-demand list price. Ownership beats that rate only above the breakeven utilization computed from your own inputs — below it a debt-financed cluster bleeds cash → Ch 1.8.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Server cost240000 $
GPUs / server8 GPUs
Depreciation life3 yr
GPU TDP1000 W
Server power multiplier1 × GPU TDP
PUE1 ratio
Annual-average IT load100 % of nominal
Power price0.1142 $/kWh
Owned-use utilization50 %
Installed / active allocation1.25 ×
Opex5 %/yr
Facility / colocation charge0 $/kW-month IT
Contract rental comparator4 $/GPU-hr

Illustrative server-ownership decision: assume $30,000 per installed GPU, three-year straight-line cost allocation, $1,000 annual energy, annual opex equal to 5% of purchase cost, and 1.25 installed GPUs per active GPU. Annual cost per active GPU is (30,000 / 3 + 1,000 + 1,500) × 1.25 = $15,625. At 50% productive use, divide by 4,380 hours: $3.57 per productive GPU-hour.

An assumed like-for-like $4/hour rental crosses that cost at 15,625 / (8,760 × 4) = 44.6% utilization. Above that point ownership wins this stated numerator; below it rental wins. With all other inputs fixed, five- and seven-year ownership lives reduce the result to $2.43 and $1.94/hour. These are life sensitivities, not evidence that the fleet earns for those periods. The facility charge is set to zero here to isolate the server; a rental rate includes powered, cooled space, so enter the facility's capital recovery per kW-month and reconcile services outside either quote before making a full-service purchase decision.

At 40% productive use, ownership costs $4.46 per productive GPU-hour and the assumed $4 rental wins. Change productive use, not the independent electrical-load assumption.

Guide derivation. Method and handoff: Chapter 1.8 — Business Models, Economics & ROI.

Inference cost per million tokens

$1.21 / M tokens owned · $1.42 rented
Owned capacity at 70% productive utilization$1.21/M tokens
Rented capacity at the same 70% productive utilization$1.42/M tokens

Compare ownership and rental on the same throughput and productive-use denominator. Owned node cost is the calendar-hour allocation of capex, energy, and opex; rented node cost is the capacity held for that hour. Prices enterprises paid for tokens fell ~$10 → ~$2.50/M in a year (Ramp spend data, Mar 2025), so underwrite inference revenue with a price-decline curve → Ch 1.8.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Rented node cost20 $/hr
Owned node calendar cost10 $/hr
Throughput1000 tok/s
Owned-use utilization50 %

Illustrative serving case: assume one qualified node produces 1,000 useful output tokens/s within the declared latency target and runs productively 50% of each paid hour. Useful output is 1,000 × 3,600 × 0.50 = 1.8 million tokens/hour. Assumed rental of $20/hour costs $11.1 per million output tokens; an assumed owned calendar cost of $10/hour costs $5.56 per million.

Against an illustrative $6 per million output-token cost allowance, ownership passes and rented capacity fails. At 40% productive use the owned cost rises to $6.94 and also fails. Keep the model, precision, prompt/output mix, batching, latency target and cost boundary identical; prompt tokens and cached tokens do not silently enter this output denominator.

The owned case crosses the $6 allowance at 46.3% productive utilization: 10 / (1,000 × 3,600 × 6 / 1,000,000).

Guide derivation. Method and handoff: Chapter 1.8 — Business Models, Economics & ROI.

Facility energy & water

Average facility power0.16 MW
Annual energy1,360 MWh
Annual energy cost$108,799
Annual water0.5 M L

Annual energy uses nominal IT power × the stated average load × energy-weighted PUE × 8,760. Site water uses IT energy × WUE. Cooling technology does not determine PUE; use plant curves and weather/load bins → Ch 15.1.

Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Nominal installed IT power10 MW
Annual-average IT load60 % of nominal
PUE1.2 ratio
Power price0.08 $/kWh
WUE0.4 L/kWh IT

Illustrative annual operating case: assume 10 MW nominal installed IT power, 60% annual-average load, energy-weighted PUE 1.20, electricity at $0.08/kWh and site-water WUE 0.40 L/kWh of IT energy. Average IT power is 6 MW; annual IT energy is 6 × 8,760 = 52,560 MWh. Facility energy is 63,072 MWh, costing $5,045,760. Site water is 52,560 × 1,000 × 0.40 = 21,024,000 litres.

Against an illustrative $5.2 million annual electricity allowance, this case passes with $154,240 remaining. The allowance crosses at 61.8% average load. Holding all other assumptions constant at 100% nominal operation raises electricity cost to $8,409,600 and fails that allowance. Productive utilization alone does not change either energy case; change the average-load assumption when the load study changes.

Guide derivation. Method and handoff: Chapter 15.1 — Efficiency Metrics: PUE, WUE, ERF, REF & the Post-PUE Metric Stack.

Fund it

Project finance — CFADS, DSCR, IRR

-13.6% equity IRR

fails stated covenant. The stated retained fleet earns for 5 years against a 5-year operating hold.

Project (unlevered) IRR-1.2%
Minimum DSCR during ownership0.87×
Average DSCR during ownership1.32×
Debt at COD (incl. $0.18M IDC)$5.28M
Equity funded (incl. $0.64M reserve)$4.05M
Project / equity NPV @ 10%$-1.91M / $-1.81M
Equity multiple0.66×

This retains the original fleet throughout the hold. Revenue bills flat for the take-or-pay contract term; at renewal it re-contracts at the rate the revenue-growth trend has reached since the stabilized year. Sustaining spend is a cash deduction and creates no replacement fleet; tax life controls deductions only. A refresh requires a separately funded cohort model. Exit proceeds are the stated multiple of final-year EBITDA, with remaining debt repaid at exit. Taxes use illustrative straight-line depreciation, an interest shield and a zero floor, with no NOL carryforwards or working-capital model. DSCR = CFADS ÷ scheduled interest and principal during ownership; exit debt payoff is shown separately. Loan covenants use their contract definitions. One entered rate discounts both project and equity cash flows. IDC uses a simple average-balance estimate allocated evenly across construction years → Ch 2.5, Ch 1.8.

Annual cash-flow bridge

-3.40.7close 0: $-0.644Mbuild 1: $-3.402Mops 2: $0.742Mops 3: $0.729Mops 4: $0.714Mops 5: $0.014Mops 6: $0.478Mclose 0ops 3ops 6
Annual bridge ($M except DSCR). Cash flows include closing and exit; CSV retains unrounded values.
Lineclose 0build 1ops 2ops 3ops 4ops 5ops 6
Capital expenditure08.504—————
Debt drawn for capex05.102—————
IDC capitalized (average-balance allocation)00.179—————
Equity funding03.402—————
Reserve funding0.6440—————
Revenue——3.1543.1543.1541.9371.646
Operating cost——0.7880.7880.7880.4840.412
EBITDA——2.3652.3652.3651.4531.235
Tax depreciation——0.850.850.850.850.85
Levered cash tax——0.240.2540.2680.0920.063
Unlevered cash tax——0.3180.3180.3180.1260.081
Sustaining capital expenditure——0.0950.0950.0950.0580.049
Cash available for debt service——2.032.0172.0021.3021.122
Interest——0.370.3050.2370.1630.084
Principal——0.9180.9831.0511.1251.204
Debt service——1.2881.2881.2881.2881.288
Debt before exit payoff05.2814.3633.382.3291.2040
DSCR (ratio)——1.5761.5661.5541.0110.871
Operating equity cash flow——0.7420.7290.7140.014-0.166
Enterprise exit proceeds——00000
Exit debt payoff——00000
Reserve released——00000.644
Project cash flow-0-8.5041.9521.9521.9521.2681.105
Equity cash flow-0.644-3.4020.7420.7290.7140.0140.478
Worked decision — stated assumptions

All ledger inputs are assumed teaching values chosen to exercise this chapter’s method; they are not market quotes, OEM performance claims or operating records. Arithmetic uses the full entered precision.

Assumed inputs
InputValue
Total capex100 $M
Construction period0 yr
Debt / leverage50 %
Interest rate0 %
Debt term4 yr
Revenue (stabilized)40 $M/yr
Ramp to stabilized0 yr
Opex25 % of rev
Cash tax rate20 %
Tax depreciation life3.5 yr
Sustaining capex0 % of rev
Revenue growth0 %/yr
Hold period4 yr
Exit multiple0 × EBITDA
NPV discount rate / stated equity hurdle10 %
DSRA0 mo
Grace period0 yr
Retained fleet earning period4 yr
Project minimum DSCR1.5 ×

Illustrative retained-fleet case, all amounts in $M: assume capex 100, immediate operation, debt 50 at zero interest amortized over four years, revenue 40/year, opex 25% of revenue, cash tax 20%, tax depreciation over 3.5 years, no sustaining spend, no growth, four-year hold, zero exit proceeds and no reserve. Assume the original fleet supports all four earning years. These tax and earning periods are independent assumptions.

Closing equity is 50. Annual EBITDA is 30. Tax depreciation is 28.5714 in years 1–3 and 14.2857 in year 4, totaling 100. Cash tax is 0.2857 in years 1–3 and 3.1429 in year 4. Annual principal is 12.5; minimum DSCR is 26.8571 / 12.5 = about 2.15. Equity cash flow is 17.2143 in years 1–3 and 14.3571 in year 4. At a stated 10% hurdle, equity NPV is −50 + Σ[17.2143 / 1.1ᵗ, t=1…3] + 14.3571 / 1.1⁴ = about 2.62.

The case passes the assumed 1.50 covenant and positive-NPV hurdle. A stated covenant of 2.20 fails. An unestablished earning period leaves the return unresolved; a tax depreciation schedule does not supply that evidence. The bridge shows the complete annual lines, including zero terminal proceeds.

Primary method: Microsoft NPV — end-of-period cash flows and initial investment. Method and handoff: Chapter 2.5 — Project Finance & Capital Formation (Mechanics).

Then turn the sizing into dates: the lead-time planner reverse-schedules every long-lead PO from your ready-for-service target.