A standard architecture for the mid-market deal model

Most deal models are built the same way the last one was built — by an analyst working from memory and a prior workbook, reproducing a structure that has never been written down. The result is that every model is subtly different, every analyst’s version is idiosyncratic, and a reviewer has to relearn the architecture each time they open a file.

A defined architecture fixes this. When every deal model shares the same layered structure, the same build order, and the same source-tracing discipline, a partner can review the tenth deal as fast as the first, a junior can inherit work without rebuilding it, and the firm’s standard lives in the structure rather than in two senior analysts’ habits.

This reference sets out an architecture for the mid-market deal model: the layers it should be organized into, the order in which they should be built, and the conventions that make a model auditable and reusable.

The principle: separate inputs, logic, and outputs

The single most important architectural decision is the strict separation of three layers. Most modeling errors that survive review are caused by these layers being mixed — a hardcoded number buried inside a formula, an assumption that lives in three places, an output that has been manually overtyped.

Input layer. Every figure that comes from outside the model: extracted historical financials, management assumptions, market data, deal terms. Nothing in this layer is calculated. Everything in it is sourced.
Logic layer. Every calculation: the historical build, normalization, projections, the returns engine. Nothing here is hardcoded. Every cell references the input layer or another cell in the logic layer.
Output layer. Everything a human reads: summary financials, the returns dashboard, sensitivity tables, the figures that feed the IM. Nothing here is overtyped; every output traces back through the logic layer to an input.

If you can answer “is this a number someone gave me, a number I calculated, or a number I’m presenting?” for every cell, the model is architecturally sound. If you can’t, it isn’t.

The layers in detail

1. The source register

Before any numbers go into the model, the documents they will come from should be registered. For a mid-market deal this means cataloguing the relevant data room contents: which document holds the historical P&L, which holds the balance sheet, which holds the QoE adjustments, which version of the management accounts is authoritative.

This register is what makes traceability possible. Every figure in the input layer should point back to an entry here: document, page, line.

2. The historical build

The foundation of the model is a clean, normalized statement of historical performance, typically three years plus the latest twelve months.

Raw extraction. The P&L, balance sheet, and cash flow as they appear in the source documents, with original line-item labels preserved.
Mapping. A reconciliation of the raw labels onto a standard chart of accounts. This is where FY22’s “Other operating costs” and FY24’s “Sundry overheads” get mapped to the same line. The mapping should be explicit and visible, not done silently inside a formula.
Normalization. The bridge from reported EBITDA to adjusted EBITDA: add-backs, one-offs, owner’s remuneration normalization, run-rate adjustments. Every adjustment carries a rationale and a source. This is the most scrutinized part of any model in diligence, and the most common place for an indefensible number to hide.

3. The assumption set

All forward-looking and discretionary inputs, gathered in one place rather than scattered through the projection:

Revenue growth assumptions, decomposed by driver where possible
Margin trajectory and its operational basis
Working capital ratios (DSO, DPO, DIO) and their historical anchors
Capex as a percentage of revenue, split maintenance versus growth
Deal terms: entry multiple, leverage, fees, transaction costs

The discipline is that an assumption appears exactly once and is referenced everywhere it is used. A growth rate that lives in four cells is a model with four chances to be inconsistent.

4. The projection and returns engine

The logic layer proper: the forward P&L, the balance sheet and cash flow roll-forward, the debt schedule, and — for a sponsor-oriented model — the returns waterfall. The requirement here is not sophistication but transparency. Every projected line should be traceable to an assumption and a historical base. A reviewer should be able to walk from any projected number back to the assumption that drives it without leaving the screen.

5. The output and sensitivity layer

What the deal team and the partner actually read:

A one-page summary of historical and projected financials
The returns summary (IRR, MOIC, or the relevant strategic metrics)
Sensitivity tables on the two or three assumptions that actually move the answer
The specific figures and charts that flow into the Information Memorandum

Outputs are presentation, not calculation. The moment someone overtypes an output to “make it tie,” the architecture has broken and the model can no longer be trusted.

The build order

Architecture is also sequence. Building the layers in the wrong order is how models accumulate the structural debt that makes them un-reviewable.

Register the sources before extracting anything.
Extract and map the history before normalizing it.
Normalize before projecting.
Set assumptions explicitly before building the projection that consumes them.
Build the logic before designing the outputs.
Add sensitivities last, once the engine is stable.

The most common violation is building projections before the history is clean, which means every later correction to the historical base requires re-checking everything downstream.

Source-tracing as a discipline, not a footnote

The difference between a model that survives diligence and one that doesn’t is usually traceability. A buyer’s diligence team will pick a number — adjusted EBITDA, a working capital figure, a normalized margin — and ask where it comes from. A model with a source register answers in seconds. A model without one answers in a frantic afternoon, and the delay itself reads as a red flag.

Source-tracing means: every input-layer figure carries its document, page, and line. Every normalization adjustment carries a rationale. Every output can be walked back to its inputs. This is not documentation you add at the end. It is a property the model has from the first cell, or it never has it at all.

Why a shared architecture compounds

A single well-architected model is valuable. A firm-wide architecture, applied identically to every deal, is where the leverage is:

Review speed. A reviewer who knows exactly where normalization lives, where assumptions live, and where outputs are presented reviews on familiar ground every time.
Reusability. A model with clean layer separation and full traceability can be safely inherited, because the next analyst can verify rather than rebuild.
Portfolio consistency. When the partner can compare ten deals modeled the same way, cross-deal judgment — is this multiple rich, is this margin assumption aggressive relative to the others — becomes possible.
Onboarding. A new analyst learns one architecture, not one senior person’s idiosyncratic habits.

Where this is going

The natural endpoint of a shared architecture is that the foundation stops being rebuilt by hand. The source register, the raw extraction, the label mapping, the first-pass historical build, and the traceability that ties it all together — this is structural work that follows the same architecture on every deal. Increasingly it can be produced directly from the data room and handed to the analyst as a starting point, leaving the human to do the normalization judgment, the assumption setting, and the analysis the architecture was built to support.

The architecture is what makes that handoff safe. A model produced to a known structure, with every figure traceable to its source, is one an analyst can audit and trust — which is the whole point of writing the architecture down.