AI in FDD: where it helps today, where it will help tomorrow, and where it shouldn't

Financial due diligence (FDD) always follows the same process, but no two engagements look alike. Our view is that AI will not arrive in FDD as a system that runs the process end to end. It will arrive as a layer on top of a deterministic solution. Mainly because every deal is different: company size, industry, quality of financials, client's asks and overall transaction complexity all shape the work. That variability is what makes FDD hard to automate. Early LLMs have also proven better at reading documents than at analysing numbers, which is why legal DD ran ahead of financial DD. Nevertheless, recent gains from model providers such as Anthropic and OpenAI have been significant enough to make AI in FDD worth a serious look. This article walks through the FDD process step by step, looks at where AI is used today, and sets out where it should and should not go next.

FDD as a process

First, let's dive a bit deeper into the FDD process itself. There is no such thing as a typical FDD, but every advisor runs through these five main steps.

1. Data needs to be collected. Data arrives at any level of detail: management reports, trial balances, general ledgers. And it is rarely what the provider asked for (e.g., wrong periods, not the right details). Several days to weeks and rounds of emails later, the data set is finally 'complete'.
2. Data needs to be processed. Processing doesn't happen with the click of a button. It is usually the most frustrating part of the deal. No two data sets are alike as each accounting software has its own export type. Additionally, the work is manual and it happens in Excel, so human error is a permanent risk. A lot of time goes into reconciling what you received against what you ended up using.
3. Data needs to be structured into tables. Only now, often already weeks in, can the tables be built. Typical tables include a lead (monthly) P&L, balance sheet and cash flow, and a datapack that cuts the same numbers in different ways: contributive tables by entity, detailed splits such as opex by GL code, top suppliers and customers. These tables are always present but never standardised, because the underlying sources are always different.
4. Data needs to be analysed and questioned. Once the tables are ready and linked to the raw data, the analytical work starts. FDD professionals look at the numbers, analyse and raise questions for later Q&A sessions with the target management. During this analysis, normalisations (to EBITDA, Net Working Capital and Net Financial Debt) are flagged and numbers are adjusted.
5. Data findings need to be reported. Once the analyses are finalised and conclusions are drawn from management discussions, the provider reports its findings. That report is usually the final deliverable.

AI in FDD, today

Whilst AI is already widely accepted in tech, commercial and legal DD (everyone knows Harvey and Legora by now), adoption in FDD is still at a very early stage. FDD firms are experimenting but not yet embedding. The main reason is structural: general-purpose LLMs are strong at reading documents and weaker at the thing FDD starts with: inferring the shape of a messy general ledger and turning it into a reliable set of tables. Models have improved sharply at exactly this over the past couple of months - look at Claude for Excel for example. And so that's the first use case we see in the market. FDD professionals are putting structured data into models, together with analyses they have done before as a reference point, and asking the model to replicate them. Running these requests also means allowing the AI model access to potentially confidential client data. So, an M&A professional can only initiate such requests once this has been checked/approved by the company's responsible persons. The output itself usually looks good and gets quite close to the expected output, but it has to be checked at every step, because errors still arise. Especially when the source data isn't clean; a fully automated script leaves room for error, a.k.a. 'garbage in, garbage out'.

The second use case, and the one we understand is used most, is using LLMs to draft report commentary from structured findings. By providing a table or answers from target management on questions from the FDD team, write-up is generated. Models are also used to read full reports and check whether all numbers in the report reconcile.

Why FDD is not legal DD

It is tempting to read the legal DD adoption curve as a preview of our own. It isn't, and the reason lies in the deliverable of legal DD. A reviewer using AI to summarise four hundred contracts is working with text, and a differently worded summary of the same clause is still a correct summary. An FDD deliverable is a set of numbers that has to tie. The same general ledger must produce the same EBITDA today and in three weeks. The databook has to reconcile to the annual accounts. Every figure must be traceable to a source file the moment the other side's advisor challenges it. Text tolerates variance; a difference in numbers does not. That is why a deterministic core matters in FDD where it does not in legal DD, and why "the models will keep improving" is not on its own the answer.

AI in FDD, tomorrow

The use cases ahead are close to endless. But the more you can do with a model, the more you use it - and cost follows usage. The price per token keeps falling but consumption per task is rising faster. A couple of months ago, the big question in the market was "what is the best model to use in FDD?". Now it is "how can we make sure our employees don't use too many tokens?". Firms have given their teams access to models, and people experiment without much sense of what a query costs, resulting in an uncontrollable AI bill.

The way forward is a controlled environment with guardrails and an AI layer added on top. There are two reasons for this. First, to control two distinct failure modes. One is variance: you don't want a different output (e.g., different normalisations / Q&A suggestions) every time you feed in the same file. The other is grounding: you don't want a model inventing a figure, or lifting a number out of the context that gives it meaning. Second, so FDD professionals still understand their own work. As such, the answer is hybrid: an FDD data infrastructure layer as the foundation, rule-based and with guardrails, enhanced by AI on top. But the AI layer shouldn't try to automate FDD from A to Z. Instead, it should power workflows and features that keep the professional in control.

Importance of judgement

People, not models, are still the deciding factor in M&A. A merger or an acquisition isn't just about the numbers you analyse. It's also about how the target manages its client relationships, about understanding why related party loans or intercompany transactions exist, about judging whether a booking is genuinely recurring. Only context will help with providing these answers and drawing conclusions. A normalisation might theoretically be correct, but the decision on whether a normalisation survives the negotiation between buyer and seller is based on judgement and informed by deal context AI doesn't have.

The question of how much AI can take over from humans will not be settled soon, in FDD or anywhere else. But for now, the combination of an FDD data infrastructure layer, AI features and human control is the right one: rules keep the numbers trustworthy, AI speeds up the analysis, and professionals stay in charge of the judgement calls that are vital to any M&A deal.