Claude Cowork for Financial Due Diligence in M&A

Financial due diligence is where M&A deals are won or lost, yet the work itself remains stubbornly manual. A typical target company hands over a data room containing thousands of files: trial balances, monthly management accounts, bank statements, payroll registers, revenue contracts, aged debtors, capex schedules, and three to five years of audited financials. The deal team then has weeks, sometimes days, to reconcile it all, normalize EBITDA, quantify working capital pegs, and surface the risks that will either reprice the deal or kill it outright.

The friction is not analytical difficulty. Most of the questions in diligence are known in advance: Is revenue recognition consistent year over year? Are there related-party transactions? What is the quality of earnings once you strip out owner compensation, one-off legal costs, and non-recurring government grants? The friction is volume. A single analyst can hold perhaps a dozen workstreams in their head at once, and the moment the data room is refreshed with a new upload, version control collapses and prior conclusions have to be re-verified by hand.

Claude Cowork changes the shape of this work. Instead of reading documents one at a time, you point it at a folder of markdown-converted financial files and it reads them completely, cross-references them, and produces structured findings against your own standards. It will not replace the judgment of a CFO or a deal lead, but it removes the mechanical extraction layer entirely, which is where most of the billable hours and most of the missed exceptions currently live.

Why markdown conversion matters before you start

The single highest-leverage preparation step is converting the data room into clean markdown before Claude touches it. Spreadsheets become pipe tables, PDFs become plain text with headers preserved, and scanned documents get transcribed. This matters because Claude Cowork reasons far more reliably over consistent, greppable text than over a mix of binary formats. It also gives you an audit trail: every finding can be traced back to a specific file and line, which is exactly what a quality-of-earnings report requires.

Once the data room is in markdown, you can run repeatable diligence passes. The two prompts below are built for that: the first produces a quality-of-earnings bridge, the second produces a working capital and red-flag memo. Both follow the same anatomy so you can adapt them to any deal.

I want to build a quality-of-earnings bridge from a target company’s historical financials so that the deal team can see normalized EBITDA and every adjustment that gets us there.

First, read these files completely before responding:
[target_pl_36m.md] — 36 months of monthly P&L, by entity and consolidated
[trial_balances_2023_2025.md] — year-end trial balances with account-level detail
[management_accounts_notes.md] — management commentary, one-off items, owner compensation detail
[chart_of_accounts.md] — target’s account structure and mapping to standard categories

Here is a reference for what I want to achieve:
[Upload a prior QoE bridge as markdown — a table with reported EBITDA, each adjustment line, rationale, and normalized EBITDA]

Here’s what makes this reference work:
Each adjustment is a single line with a clear label, a signed amount, and a one-sentence rationale citing the source file. Adjustments are grouped into owner-related, non-recurring, accounting policy, and pro-forma categories. Nothing is netted without disclosure. The bridge reconciles exactly to reported EBITDA.

Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: Markdown table plus a 400-word narrative summary
Recipient’s reaction: The deal lead should be able to challenge any single line and find the source in under a minute
Does NOT sound like: A generic summary that says “EBITDA appears stable” without numbers
Success means: Every adjustment is traceable to a named file, and the bridge foots to the penny

My context file contains my standards, constraints, audience. Read it fully before starting.
DO NOT start executing yet. Ask clarifying questions first.

Give me your execution plan (5 steps max) before you begin.

From bridge to working capital peg

The quality-of-earnings bridge answers what the business actually earns. The second question, and the one that most often causes post-closing disputes, is what level of working capital the buyer needs to fund on day one. This requires a different dataset: monthly balance sheets, aged debtors and creditors, inventory rolls, and a view on seasonality. It also requires a defensible normalization methodology, because every seller will argue for a lower peg and every buyer for a higher one.

The prompt below asks Claude Cowork to build that peg from the underlying ledgers rather than from a management summary, which is where most pegs go wrong. It also asks explicitly for red flags, because the same dataset that produces a peg will usually reveal the exceptions that belong in the representations and warranties.

I want to calculate a normalized working capital peg and surface red flags from a target company’s balance sheet history so that the SPA negotiation starts from a defensible number.

First, read these files completely before responding:
[monthly_balance_sheets_36m.md] — 36 months of balance sheet data by entity
[aged_debtors_creditors.md] — monthly aged listings with customer and supplier names
[inventory_rollforward.md] — monthly inventory by category with movements
[revenue_by_customer.md] — monthly revenue by customer for concentration analysis

Here is a reference for what I want to achieve:
[Upload a prior working capital peg memo as markdown — methodology, monthly averages, seasonality adjustment, proposed peg, and a red-flag appendix]

Here’s what makes this reference work:
The peg is built from a 12-month average, not a point-in-time balance. Seasonality is shown as a monthly index. Each red flag names the file, the amount, and the specific clause it should inform. Concentrations above 10% are flagged automatically. The memo states its own assumptions and where they could be wrong.

Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: Markdown memo, 800 to 1,000 words, plus a red-flag table
Recipient’s reaction: The CFO should trust the peg enough to defend it in a negotiation and see the risks before opposing counsel does
Does NOT sound like: A textbook description of working capital with no reference to this target’s numbers
Success means: The peg is reproducible from the files, and every red flag is traceable to a source line

My context file contains my standards, constraints, audience. Read it fully before starting.
DO NOT start executing yet. Ask clarifying questions first.

Give me your execution plan (5 steps max) before you begin.

The practical tip that matters most: run these prompts against a deal you have already closed before you run them on a live one. You will learn exactly where your context file is thin, where your markdown conversion dropped columns, and where Claude’s output needs a human correction. Fix those three things once, and every subsequent deal runs faster.

Try next: build a reusable context file that encodes your firm’s diligence standards, materiality thresholds, and reporting format, then version it alongside your markdown data room. The prompts above are the engine; the context file is the fuel, and it is the single artifact that compounds across every deal you touch.

Published on 17 September 2026 on growwithgpt.com