The night before the board meeting, my forecast broke.

A financial model should be able to survive a bad afternoon.

I do not mean a meteor strike.

I mean an ordinary finance bad afternoon: a source file changes, a link breaks, someone inserts a column, the forecast needs an update two hours before a meeting, and the person who built the workbook is not available.

That is when model architecture stops being an aesthetic preference.

It becomes operational resilience.

I design for the moment something breaks

Most models are built while everything is working.

Inputs are available. The builder remembers the logic. There is time to investigate.

I like asking what happens under pressure.

Can another person trace the inputs? Are assumptions visible? Do checks identify where the break occurred? Can we produce a reliable partial answer if one feed is unavailable?

A model that only works in ideal conditions is more fragile than it looks.

External links deserve suspicion

Linked workbooks can be convenient.

They can also create a dependency graph nobody can see.

A file moves folders. Someone renames it. A SharePoint path changes. The workbook opens with old cached values and looks fine.

For critical models, I prefer controlled data ingestion where possible—Power Query, governed source files, planning-system feeds—or at minimum a clear inventory of external links and checks that confirm they refreshed.

“Update links?” should not be the control framework.

Helper tabs are not bad

I am defending the humble helper tab.

A clear staging area can make a model easier to audit.

The problem is the mysterious helper tab that feeds six outputs, contains undocumented overrides and has been hidden since 2022.

I like separating raw data, transformations, assumptions, calculations and outputs.

Call the tabs whatever you want.

I want the flow understandable.

Circular references should be intentional or eliminated

Some financial models legitimately contain circular relationships—interest and debt, for example.

Excel can iterate them.

I still want the circularity documented and controlled.

An accidental circular reference buried in a helper calculation is different.

If the workbook requires iterative calculation, another finance person should know why before they spend an hour trying to “fix” it.

I want visible model checks

Balance sheet balances. Cash flow reconciles. Beginning balances tie to actuals. Revenue schedules sum to the P&L. Headcount totals reconcile to the roster.

Checks should be obvious enough that a user sees a failure before sending the output.

I like a dedicated control section or summary with clear status.

A model should not require someone to remember 17 manual places to inspect.

Control totals are cheap insurance

If I import a transaction file, I want row count and dollar total.

If I transform it, I want to know what was excluded.

If I allocate costs, I want allocated totals to reconcile to the source.

These are not sophisticated controls.

They are effective because they catch the boring failures that cause spectacular meetings.

Finance does not need every error to be interesting.

Version control matters before the board meeting

“final.xlsx” is not a version-control strategy.

Neither is “final_final_v4_reallyfinal.xlsx,” although it does communicate emotion.

I want a clear owner, location, naming convention and process for locking the version used for a management or board output.

If assumptions change after the deck is produced, preserve what changed.

The ability to reproduce the reported forecast later is part of model governance.

Inputs should look like inputs

One of the easiest ways to create model risk is mixing hard-coded assumptions with formulas without a clear convention.

I want users to know where they are allowed to type.

That can be formatting, protected ranges, an assumptions tab or a planning interface.

The exact technique is less important than making the boundary visible.

Accidentally overwriting a formula should be difficult enough to notice.

Hard-coded numbers inside formulas deserve review

A formula that multiplies by 1.07 may be correct.

Why 1.07?

If it is a management assumption, I probably want it labeled somewhere.

If it is a permanent mathematical constant, fine.

Important business assumptions should not hide inside formulas because that makes scenario changes and review harder.

Named ranges can help—and hurt

Meaningful names can make formulas easier to read.

Too many names, stale names or workbook-scoped names nobody understands can create another layer of mystery.

I use them when they improve comprehension.

I do not use them to make the workbook look sophisticated.

The standard is always the same: can the next capable person trace the logic?

I test the model with deliberate damage

Delete an input. Add a new department. Change a source row count. Move a date. Put zero in a denominator. Add a customer category the mapping table has never seen.

What happens?

Does the model fail loudly, produce an exception, or quietly generate a plausible answer?

I am especially interested in the third outcome.

Stress testing a model is partly about discovering how it lies when confused.

Scenario analysis is also a model test

Revenue down 20%. Hiring delayed. Margin compressed. Collections slower.

Does the workbook behave like the business?

Fixed costs should not magically become variable. Cash should respond. Capacity assumptions should move where they are linked.

A model can calculate the base case perfectly and reveal its architecture only when management asks a real “what if?” question.

Performance matters when it changes behavior

A workbook that takes five minutes to recalculate discourages iteration.

People stop testing scenarios. They avoid refreshing. They make manual copies.

At that point performance is not just an annoyance.

It is affecting the finance process.

I look for volatile formulas, huge ranges, repeated calculations, unnecessary links and data volumes that belong somewhere else.

Sometimes the best Excel optimization is moving part of the work out of Excel.

Documentation should explain the model, not narrate every cell

I want purpose, source systems, major assumptions, update steps, important controls and known limitations.

I do not need a 90-page manual nobody will maintain.

A concise model guide can save hours when ownership changes or a problem appears under deadline.

Documentation is especially valuable for the things that are not obvious from the workbook itself.

Key-person risk is model risk

If one person is the only human who can update the forecast, the company has a continuity problem.

That person may be brilliant.

They also take vacations, get promoted and occasionally decide to work somewhere else.

I like periodic handoffs or backup ownership for critical models.

The test is simple: could another capable finance person run the process next month if necessary?

Source lineage should be short enough to explain

Where did this number come from?

I want a sensible answer.

CRM to data warehouse to controlled extract to model. ERP actuals through a reconciled query. HR roster from the approved system.

If the answer is “this tab pulls another workbook that pulls a CSV somebody emails from a system,” we may still be able to operate.

I would also put modernization on the list.

The model should preserve prior forecasts

When assumptions update, I do not want history overwritten.

Save the prior forecast or preserve snapshots in the planning system.

Forecast-to-forecast analysis is one of the best ways to explain what changed and improve future assumptions.

A model that only contains the latest view loses the organization’s learning trail.

Board models need a reproducibility standard

If a number appeared in a board deck, I want to be able to reproduce it later.

That means preserving the source version, assumptions and relevant output.

Not because I expect a forensic investigation.

Because management decisions were made from that information.

Finance should be able to explain what it believed at the time.

I prefer graceful degradation to catastrophic failure

If one noncritical data feed fails, can the model still produce a clearly labeled partial forecast? Can we use the prior value temporarily? Do we know which outputs are affected?

Not every model needs elaborate failover.

But critical processes benefit from thinking about what can continue safely when one component is unavailable.

Resilience is partly refusing to make every dependency fatal.

The 2 a.m. test is really the “someone else” test

I do not want Finance working at 2 a.m.

I especially do not want to romanticize it.

The useful thought experiment is whether a tired person under deadline can tell what is wrong without having built the workbook.

Clear architecture. Visible checks. documented assumptions. controlled sources.

Those are the things that make a model trustworthy when conditions are less than ideal.

Trust comes from recoverability

No financial model is unbreakable.

Files corrupt. Systems change. Humans make mistakes.

I care about whether the model makes failures detectable, diagnosable and recoverable.

Can we find the bad input? Reproduce the last trusted version? Explain which outputs changed?

That is a stronger standard than “the workbook has never crashed.”

The best model is not the one that never has a bad afternoon.

It is the one that does not turn a bad afternoon into a bad board meeting.

Excel tables are one of the simplest resilience improvements

Structured tables expand more predictably than hard-coded ranges and make formulas easier to read.

I use them often for source data and assumptions.

They do not solve every modeling problem, but they reduce the classic failure where a new row appears just outside the formula range and quietly disappears from the report.

I still reconcile totals.

A table is a better container, not proof that the contents are correct.

Data validation can prevent errors before controls catch them

If an input should be one of five categories, I prefer a controlled list to free-form typing.

If a percentage must sit within a reasonable range, validation may help.

Preventive controls are useful because they reduce the exception population before review begins.

I am careful not to make the model so locked down that legitimate new situations become impossible.

Controls should guide the process, not freeze the business in amber.

Protection is useful when it protects the right things

Worksheet protection can prevent accidental formula overwrites.

It is not security.

I use it as a usability control: these cells are inputs, these cells calculate, these areas should not change casually.

For sensitive data and real access restrictions, permissions belong at the file, system and environment level.

Excel protection is a guardrail.

It is not a vault.

Materiality should govern model controls too

I do not need a forensic control around every $200 line.

I want stronger checks around the parts capable of moving the decision.

Revenue, payroll, cash, major working-capital drivers, debt, material CapEx.

That keeps the model review focused.

Controls become less useful when there are so many that users stop noticing which failure matters.

I like an assumptions change log for material updates

Who changed the assumption, when, and why?

This can be simple.

For a major forecast, preserving material assumption changes helps explain forecast movement and reduces the “I thought we were using 6%” conversation.

Planning systems may provide this automatically.

In Excel, Finance may need a deliberate process.

The sophistication of the tool does not change the need for memory.

Output tabs should not contain hidden calculation surprises

I prefer presentation outputs to be mostly presentation.

If the board P&L contains a special hard-coded adjustment nobody knows about, the output layer has become another calculation engine.

That makes reconciliation harder.

Keep complex logic upstream where possible, then let the output report it.

The closer a page is to management, the more boring I want its formulas to be.

A model review should include another person

Self-review has limits.

The builder knows what the model is supposed to do, which makes it easier to see the intended answer instead of the actual implementation.

For material models, I like a second capable person reviewing architecture, assumptions, key formulas and controls.

They do not need to recalculate every cell.

A fresh question can find a weakness the builder stopped seeing months ago.

There is a point where Excel should hand off

If the workbook requires millions of rows, many simultaneous users, complex permissions, constant integration or mission-critical transaction processing, I ask whether Excel is still the right layer.

That is not an insult to Excel.

A Swiss Army knife is useful partly because we do not ask it to become a forklift.

Good model design includes knowing when the problem has become a system problem.

Recovery should be tested before it is needed

Where is the last trusted version? Are backups actually available? Can someone restore the model? If a source query fails, is there a documented fallback?

These questions sound overly cautious until the file is corrupt two hours before a meeting.

I would rather spend fifteen minutes proving recovery works during a calm week.

Disaster recovery is a terrible hobby to begin during the disaster.

Model governance does not have to become bureaucracy

A lot of teams hear “governance” and imagine a committee approving formulas.

I do not want that either.

For most FP&A models, good governance can be lightweight: clear owner, controlled source, visible assumptions, change history, checks, documentation and backup.

The controls should match the consequence.

A board forecast deserves more rigor than a one-off exploratory analysis.

Judgment still applies.

The goal is a model people can challenge safely

If everyone is afraid to touch the workbook, the model is not robust.

I want people to be able to test a scenario, question an assumption and trace an output without feeling that one click might collapse the building.

That usually comes from clean separation, visible controls and understandable formulas.

A resilient model supports curiosity.

It does not demand reverence.