Capex and Depreciation Model

Model architecture

• Split maintenance and growth capex.
• Model asset classes and in-service dates.
• Apply useful lives and residual values.
• Track disposals and impairment separately.

A professional model should make the decision logic visible. Inputs belong in a controlled assumption area; calculations should be formula-driven; outputs should state units, dates and scenarios; checks should be obvious and actionable.

Core inputs

• Capex plan
• Asset class
• In-service date
• Useful life and method
• Disposals and grants

Formula logic

Use the formulas as design relationships, not as substitutes for the accounting policy, contract definition or transaction facts relevant to the model.

Practical example

A ₹12 crore asset placed in service halfway through the year with a 10-year useful life produces approximately ₹0.6 crore first-year depreciation under a half-year convention used for planning.

How to implement

1. Load the historical base and reconcile it.
2. Put assumptions in dedicated cells.
3. Build the schedule from operational drivers.
4. Link outputs to financial statements and dashboards.
5. Run base, upside and downside checks.

Control checks

• Capex cash flow agrees with fixed-asset schedule
• Depreciation agrees with P&L
• Opening balances match audited statements
• No depreciation before ready-for-use date
• Disposals remove cost and accumulated depreciation

Common modeling errors

• Using tax depreciation for book forecasts
• Depreciating land
• Ignoring capitalised borrowing costs where applicable
• Failing to model CWIP
• Mixing maintenance expense and capex

Practical Q&A

Should the model contain all possible detail?

No. It should contain enough detail to answer the decision question and explain material risks. Excess detail can hide the drivers.

Should a formula ever contain a hardcoded number?

Only for constants that are genuinely universal or immaterial. Business assumptions should be linked to visible input cells.

What is the minimum review standard?

Reconcile historical data, test key formulas independently, scan for hardcodes and errors, verify scenario switches, and review outputs under downside assumptions.