Building the FDD Databook: The Transaction Services Analyst's Core Deliverable

Ask any Transaction Services analyst what they actually did today and the honest answer is almost never "wrote the report". It's "built the databook, refreshed the databook, re-tied the databook after the client sent a new trial balance at 6pm". The databook is the Excel workbook sitting underneath every page of an FDD report — the machine that turns a data-room dump into the numbers, charts and bridges the buyer reads. The report is the shop window. The databook is the engine room, and it is where the analyst lives.

Master it and you become the person the manager hands live deal work to without checking every cell. Fumble it and your output has to be re-performed line by line before anyone dares put it in front of a client. This article walks through what a databook is, how a good one is put together, the modelling discipline that separates a clean book from a liability, and — with a fully worked mini-example — how the databook produces the three analyses every deal turns on.

What a databook actually is

A databook is a single Excel workbook that ingests the target's financial data and converts it into the analysis the FDD report presents. It takes the raw material — trial balances, management accounts, statutory accounts, system extracts pulled from the data room — and restructures it into a consistent, period-by-period view that can be sliced, adjusted and bridged.

Crucially, it is not the report. The report is a narrative document (usually Word or PowerPoint) that explains findings to a deal team. The databook is the working file that produces those findings. One sits behind the other:

• The databook holds every number, calculation and adjustment.
• The report quotes a curated subset of those numbers and tells the story.

Every figure in the report should be traceable to a cell in the databook, and every cell in the databook should be traceable to a source. That chain of traceability is the entire point. When a client's advisor emails at 9am asking "where does the £2.1m adjustment come from?", the analyst who built a clean book answers in ninety seconds. The one who didn't spends the morning reverse-engineering their own workbook.

Rule of thumb: if you cannot get from any number in the report to its original source document in three clicks, the databook isn't finished — it's just full.

How the databook is structured

Databooks vary by firm, but the architecture is remarkably consistent. A well-built book runs left to right: raw inputs on the left, polished outputs on the right, and the analytical tabs in between. Data flows in one direction only.

The discipline of inputs flow to outputs in one direction is what makes a book auditable. When source data lives in its own tabs and is never edited in place, you can always refresh it, reconcile it and prove where a number came from. The moment someone types over a source figure to "make it tie", the traceability is gone and so is the trust.

A worked mini-example: building the adjusted EBITDA line

Abstract advice about "modelling hygiene" is easy to nod along to and hard to picture. So here is the smallest useful slice of a real databook: turning reported EBITDA into the adjusted EBITDA the report will headline. Assume the target is a services business and the source is the FY25 management P&L.

Two things make this a databook rather than a note on the back of an envelope. First, every line carries its source — a reviewer can click to the evidence without asking. Second, the reported figure 4,200 is a link to the P&L tab, not a typed number; if the client resends the accounts, the P&L refreshes and this schedule moves with it. The 4,700 is never hardcoded anywhere else in the book — every downstream tab (the EBITDA bridge chart, the valuation summary, the multiple calculation) references this cell. Calculate once, reference everywhere.

If a manager later challenges the grant add-back, you change one input line and the whole book updates coherently. That is the difference between a model and a mess.

Modelling discipline: the habits that matter

The gap between a databook a manager trusts and one they re-perform comes down to a handful of habits. These are also, not coincidentally, exactly the modelling hygiene points an interviewer will probe.

• Consistent periods. One period per column — the same twelve months, in the same order, across every tab. Mixing calendar and fiscal years, or letting a tab drift by a month, is how errors hide in plain sight.
• Source referencing. Every input traces to a named source: "FY25 statutory accounts, p.14" or "Sage GL extract, 03/2026". A reviewer should never have to ask where a number came from.
• No hardcoding into formulas. Never bury a number inside a formula (=B12*1.2). Put the 1.2 in its own labelled cell. Hardcodes are invisible, unexplained and impossible to audit.
• One calculation, one place. Don't recompute the same margin three ways on three tabs. Calculate once, link everywhere. Duplicated logic silently drifts out of sync.
• Checks that are visible. Build cross-checks — does the cash flow tie to the movement in net debt? Does the sum of segments equal the total? — and flag them with a loud PASS/FAIL so a broken link screams rather than whispers.
• Colour conventions. Blue for inputs, black for formulas, green for links to other tabs. It sounds trivial; it is the fastest way for a reviewer to read your intent at a glance.

A clean book is one where someone who has never seen it can open it, find the source of any number in seconds, and trust that the totals tie. That is the standard, and it is entirely learnable.

Feeding the EBITDA bridge

The databook is where adjusted EBITDA is built, not asserted. The adjustments tab — exactly like the mini-example above — takes reported EBITDA from the P&L and layers on the normalising items: non-recurring costs, run-rate effects, pro forma changes, each referenced to its evidence. The output is a bridge from reported to adjusted EBITDA that the report reproduces directly.

If you're hazy on what belongs in that bridge, our overview of EBITDA adjustments sets out the categories and the logic, and quality of earnings 101 explains why buyers care so much about the sustainability of the number. The databook's job is to host every adjustment transparently, so the client can interrogate each line rather than swallow a single figure.

Feeding the net debt and working capital bridges

The balance sheet tabs do the same work for the two other deal-critical analyses.

• Net debt. The databook classifies every balance into cash, debt and debt-like items, producing the schedule that underpins the price. The mechanics — and the judgement over what counts as debt-like — are covered in our net debt definition for FDD.
• Working capital. The book builds the monthly trade and other working-capital series, normalises for distortions and derives the target peg. The approach is set out in our piece on normalised working capital analysis.

All three — EBITDA, net debt and working capital — ultimately resolve into the price the buyer pays via the equity bridge, as our enterprise-to-equity bridge guide sets out. The databook is the single source of truth that produces them consistently, which is why its integrity is non-negotiable: a hardcode in the net debt tab isn't a cosmetic sin, it's a potential mispricing.

From databook to report

Because the report quotes the databook rather than recreating it, a well-built book makes report-writing fast and reliable. Summary tables, charts and bridges are pulled straight from the outputs tabs; when the data refreshes, the report updates with it. If you want to see how the deliverables fit together, our guide to FDD report structure shows where each databook output lands in the final document, and the financial due diligence process piece situates the whole build within the deal timeline.

The takeaway: time invested in a clean, well-referenced databook is repaid every time the deal team comes back with a question — and they always come back with questions.

Common mistakes

• Editing source data in place. The instant you type over a raw extract to "make it tie", you've destroyed the audit trail. Paste sources untouched; do corrections in a separate adjustments layer.
• Hardcoding a total downstream. Copy-pasting 4,700 as a value into the valuation tab means the next data refresh silently breaks the link. Always reference the source cell.
• Inconsistent periods across tabs. A P&L on fiscal years and a balance sheet on calendar years won't reconcile, and you'll waste hours hunting a "difference" that's really a calendar mismatch.
• Invisible checks. A check that lives in your head isn't a check. If the cross-tie isn't on the sheet with a PASS/FAIL flag, a broken link ships to the client.
• One giant unstructured tab. Cramming inputs, workings and outputs into a single sprawling sheet feels fast on day one and is unmaintainable by day three.
• No version control on the control tab. When three analysts touch the book, an out-of-date "v_final_FINAL_2" is how the wrong number reaches the report.

The interview angle: modelling hygiene

Interviewers can't watch you build a databook in an hour, so they test for the mindset instead. Expect questions like "how do you make sure a model is auditable?" or "you've inherited a messy workbook — what do you check first?". They're listening for the hygiene habits above, and for evidence you think of a model as something other people have to read and trust.

In the interview, a strong answer sounds like:

"I keep raw source data in its own tabs, pasted in untouched, so it's always refreshable and reconcilable. Every input is referenced to its source document, and I never hardcode a number inside a formula — assumptions live in their own labelled cells. I calculate each figure once and link it everywhere it's used, so nothing drifts out of sync. And I build visible cross-checks — cash flow to net debt movement, segments to total — with a loud PASS/FAIL flag, so a broken link fails noisily rather than slipping into the report. The test I hold myself to is simple: could someone who's never seen the book open it, trace any number back to evidence in a few clicks, and rely on the totals without re-performing my work? If not, it isn't finished."

That answer signals exactly the hard skills TS teams screen for — and it tells the interviewer you can be handed a live workbook without your output needing to be rebuilt.

The databook is where a Transaction Services career is actually made. Reports get read once and filed; the discipline you bake into a workbook — the clean links, the traceable sources, the checks that fail loudly — is what earns you the reputation that opens the interesting work. Build every book as if the sharpest reviewer on the deal will open it cold tomorrow morning, because sooner or later, one of them will.

The Transaction Services Interview Programme (€119.99, one-time) includes a guided databook build — structuring source data, wiring the EBITDA, net debt and working capital bridges, and applying the modelling-hygiene checks reviewers look for. Enrol today.