Best practices for financial modeling

A friend who's an avid pilot explained once how he reads weather forecasts before flying:

Weather forecasts are best used as directional guides, not as predictions of specific events. How accurate they are depends on your viewpoint. If you use them to determine if it's going to rain in one specific spot at one specific time, you'll view them as woefully inaccurate. If you use them as a guide that it will rain at some point today in an area near you, they're very accurate.

Same for financial models. Treat them as finished predictions and you'll be disappointed. Treat them as inputs into an organizational learning process — today's data informing tomorrow's decisions — and they become valuable, even when the numbers are predictably wrong.

Analysis, not artifact

The common complaint about financial models, especially for early-stage companies, is that they're BS:

A financial model is just a fancy equation with a bunch of input variables. If the input variables are mistaken, it doesn't matter how good the equation is, the whole thing is useless — or even worse than useless, as it breeds false confidence.

Framed as the iterative tool of a planning process rather than a static artifact, financial models become inputs into organizational learning and valuable tools for making decisions in an imperfect world.

That lofty goal requires effective spreadsheet design. Most spreadsheets are built as one-off analyses to address an immediate need — trading design for immediacy. But the future life of a model is unknown at conception. Once shared and used, models take on lives of their own, and the technical debt of the initial design gets embedded into the processes and decisions the model supports. Redesigning spreadsheets requires redesigning processes. That's backwards.

Principles

As the use of a model evolves, the model itself should evolve — without being rewritten. That requires a core set of design principles.¹

• Structure is everything.
• The decision matters more than the model. Optimize for the decision, not the artifact.
• Complexity should match impact. Don't over-engineer.
• Separate inputs, calculations, and presentation. Blue inputs, black formulas, presentation sheets first in the workbook.
• Make key insights obvious. Don't hide the takeaway in cell AD543.
• Notes explain intent. They help readers understand the model; they also help you remember why you built it that way.
• Visuals over tables when the point is directional.
• Don't make readers interpret. If a reader has to guess the takeaway, they'll guess wrong.
• Precision isn't accuracy. Three decimal places don't make a forecast more correct.
• Don't let detail obfuscate insight.
• Long formulas invite errors.²
• Atomize. Avoid hard-coding inputs into calculations.
• Range inputs beat point estimates. Ranges make scenarios and sensitivities natural.
• Spend modeling time on what matters to your business.

Frameworks over templates

The last point drives how Hemrock templates are built.

There's a perception that the only way to understand a model is to build it yourself and that templates are inherently bad. That's fair when templates are rigid, inflexible, and opinionated in ways that fight your business.

Hemrock templates are frameworks with prebuilt components, not monolithic spreadsheets. A core (usually the Forecast sheet) handles the main calculations, then swappable components handle specific jobs: financial reporting (Statements), management analysis (Summary, Key Reports, Breakdown, Budget, Sources and Uses), and revenue logic (Revenues in the Standard Model, or any of the stand-alone forecasting tools). Components swap in, out, replicate, or customize based on what you're modeling.

Bring your own model

The Bring Your Own Model approach uses the templates for everything that isn't a source of business insight, and reserves your time for modeling the mechanics unique to your business.

Products before spreadsheets. But if you have to build spreadsheets, build the things that matter.

Footnotes

1. The FAST Standard captures similar principles. Hemrock's approach is aligned but deviates in a few places for broader accessibility. ↩

2. Good spreadsheet design says to break long formulas into components for clarity and auditability. Hemrock models often use long formulas anyway. Why? A tradeoff: reduced formula clarity for a better overall user experience. The most common place is Forecast sheets, where nested IFs use driver inputs differently. Breaking it all out would create sections of zeros, block easy row insertion, and produce a visual mess. Selective rule-breaking for UX. ↩