# The Due Diligence Report: Structure and Template

- url: https://www.tryplox.com/blog/due-diligence-report
- date: 2026-07-01
- tags: Due Diligence, Data Rooms
- excerpt: A due diligence report is the written record of what an investigation found. It takes weeks of reviewing contracts, financials, code, customer data, and legal filings and turns it into a document that

A due diligence report is the written record of what an investigation found. It takes weeks of reviewing contracts, financials, code, customer data, and legal filings and turns it into a document that a decision maker can actually act on. I've sat on both sides of this. I've written reports as a buyer trying to talk an investment committee through risk, and I've been the founder watching an acquirer's advisors compile one about my own company. The report is where diligence stops being a pile of files and becomes a recommendation: proceed, proceed with conditions, renegotiate, or walk.

This guide covers what goes in a due diligence report, who writes it and when, a step-by-step process for producing one, a checklist you can reuse, the red flags that should make you slow down, and how a [virtual data room for due diligence](/blog/virtual-data-room-due-diligence) makes the whole thing faster to assemble. If you want the wider context first, start with our [due diligence](/blog/due-diligence-guide) overview and come back here for the deliverable itself.

## What a due diligence report actually is

The report is the output of a diligence exercise, not the exercise itself. The work happens in the room: someone requests documents, the other side uploads them, questions get asked and answered, and findings accumulate. The report is the synthesis. It pulls every workstream into one place and answers the only question the deal team cares about: given everything we now know, what should we do?

A good report does three things. It states the facts that were verified. It flags the risks that were found, sized and ranked. And it makes a clear recommendation tied to those risks. A report that lists problems without a view is half a report.

Reports vary by deal type. A financial buyer running [financial due diligence](/blog/financial-due-diligence) wants a quality-of-earnings view: normalized EBITDA, working capital, debt-like items. A strategic acquirer cares about integration and product, so the [technical due diligence](/blog/technical-due-diligence) findings carry more weight. A full [M&A due diligence](/blog/ma-due-diligence) report stitches every stream together, including legal, commercial, HR, and tax. The structure below works across all of them; you scale the sections to match the deal.

## Who writes it, and when

The report is usually owned by the lead advisor or the deal team running the buy side. On a venture or growth deal that might be an associate or partner at the fund. On a mid-market acquisition it is often an external advisory firm coordinating specialist sub-streams, each of whom contributes a section. The legal report comes from counsel, the financial section from the accountants, the tech section from a CTO-for-hire or an engineering reviewer.

Timing follows the deal. A preliminary report or "red flag" memo often appears after the first pass through the data room, before the buyer commits real money to confirmatory work. The full report lands near the end of the confirmatory period, just before the decision to sign. On the sell side, vendors increasingly prepare their own [vendor due diligence](/blog/vendor-due-diligence) report up front to control the narrative and speed up the buyer's process, though that is a separate document with a different author and audience.

The honest version: most reports are written under time pressure in the last few days before a deadline, by people who have been buried in the room for weeks. The quality of the report tracks the quality of the room. If documents were organized, versioned, and easy to find, the report writes itself. If the room was a dumping ground, the writer spends the final week chasing files instead of forming a view.

## A step-by-step process

Here is the sequence I follow when I'm responsible for the deliverable.

1. **Scope the report before you read a single document.** Agree with the deal team on what decisions the report needs to support and which workstreams are in scope. A report that tries to cover everything equally covers nothing well.
2. **Set up the index first.** Map the data room structure to your report sections so every document you review has a home. Cross-reference findings to source files by name as you go, not at the end.
3. **Review by workstream, log findings as you read.** Don't save analysis for later. The moment you spot an issue, write it down with the file reference and a first guess at severity. Memory fades fast across a multi-week review.
4. **Size and rank each finding.** A risk that is unquantified is just an opinion. Put a number, a range, or a clear "cannot be quantified with available data" against every item.
5. **Draft the executive summary last, but write to it throughout.** Everything in the body should ladder up to the recommendation on page one.
6. **Circulate to specialists for sign-off.** The legal lead owns the legal findings. Don't paraphrase another stream's conclusion without their review.
7. **Pressure-test the recommendation.** Before it goes out, ask whether a skeptical reader could read the same findings and reach the opposite conclusion. If they could, your recommendation needs more support.

## What goes in the report: structure and template

Most diligence reports share the same skeleton. You can lift this directly.

| Section | What it contains | Who usually owns it |
|---|---|---|
| Executive summary | Recommendation, headline risks, deal-breakers, conditions | Lead advisor |
| Transaction overview | Target description, deal structure, sources of information | Deal team |
| Financial findings | Quality of earnings, working capital, debt-like items, projections | Financial reviewer |
| Legal findings | Corporate structure, contracts, litigation, IP ownership | Counsel |
| Commercial findings | Market, customer concentration, pipeline, competition | Commercial lead |
| Technical / product | Architecture, code quality, security, technical debt | Technical reviewer |
| Tax | Exposures, structuring considerations, prior filings | Tax specialist |
| People & HR | Key-person risk, contracts, comp, culture | HR / deal team |
| Risk register | Every finding, ranked by severity and quantified | Lead advisor |
| Appendices | Source document index, working papers | Whoever assembles |

The risk register is the heart of it. Each row should name the issue, point to the source document, state the potential impact in money or time, rate the severity, and note the proposed mitigation, whether that is a price adjustment, an indemnity, a condition to closing, or a reason to walk.

## A reusable findings checklist

When I'm scanning a workstream, I'm checking for the same recurring gaps every time. This is the short version I keep next to the room.

- Are the financial statements audited or reviewed, and by whom?
- Does revenue tie to signed contracts and bank receipts, or only to a spreadsheet?
- Is customer concentration above a level that would survive one logo leaving?
- Who actually owns the IP, including code written by contractors and any open-source obligations?
- Are there change-of-control clauses in key contracts that trigger on the deal?
- Is there pending or threatened litigation, and is it disclosed or discovered?
- Are employment and equity arrangements documented for every key person?
- Do the security and compliance claims (SOC 2, ISO 27001, GDPR) have evidence behind them, or just assertions?
- Are there related-party transactions hiding in the numbers?
- Does the cap table reconcile to the legal documents?

For a deeper, deal-ready version organized by folder, our [due diligence data room checklist](/blog/due-diligence-data-room-checklist) is the one I hand to teams setting up a room.

## Common red flags to call out

A few patterns show up often enough that I treat them as defaults to investigate rather than exceptions.

**Disorganized or late disclosure.** When documents arrive in batches at the last minute, or the index doesn't match what's in the folders, it usually means either the seller isn't ready or something is being managed. Either way it raises the cost of the review and the temperature of the report.

**Revenue that doesn't reconcile.** If the management deck says one number and the bank statements say another, that gap goes straight to the executive summary. Quality of earnings problems are the single most common reason a price gets renegotiated after diligence.

**IP that isn't clearly owned.** Code written by a contractor with no assignment agreement, a founder's prior employer with a claim, or open-source licenses that conflict with a commercial model. These are quiet at first and expensive later.

**Key-person dependence with no retention.** If one or two people hold the relationships, the architecture, or the institutional knowledge, and there is nothing keeping them past close, that is a finding regardless of how good the business looks.

**Missing or thin compliance evidence.** A claimed certification without the report behind it, a privacy policy with no underlying process, a security posture that exists only on the website. Ask for the artifact, not the assertion.

## How a data room turns the report around faster

The report is only as good as the trail behind it, and the trail lives in the data room. The difference between a report that takes three days to finalize and one that takes two weeks is almost entirely about how the room was run.

A well-structured room gives you three things the writer needs. First, a stable index, so every finding can cite a source document by name and the reader can verify it. Second, version history, so when a financial model gets updated mid-process you can see what changed and when. Third, an audit trail of who viewed what, which matters both for the seller managing access and for the buyer reconstructing what was actually disclosed.

This is where the tooling earns its place. I run our raises and reviews out of [Plox](/data-rooms) because the structure that makes a room easy to navigate is the same structure that makes the report easy to write: granular folder permissions, link-level access controls, and a viewer log that tells you which investor or advisor opened which file. When the room mirrors your report outline from day one, the synthesis at the end is assembly, not archaeology. Other established platforms like iDeals, Datasite, and Ansarada do the same core job; the right pick depends on deal size, how many external parties need access, and your budget. If cost is the deciding factor, our breakdown of [virtual data room cost](/blog/virtual-data-room-cost) covers the pricing models (per-page, per-user, and flat-rate) so you can compare like for like.

The practical move is to build the room around the report you'll eventually write. Name the top-level folders after your report sections, keep one canonical version of every key document, and require that requests and answers happen inside the room rather than over scattered email. Do that, and the report stops being the hard part.

## Frequently asked questions

### How long should a due diligence report be?

There is no fixed length. A red-flag memo on an early-stage deal might be a few pages. A full report on a mid-market acquisition with multiple workstreams can run to several dozen pages plus appendices. The right length is whatever covers every material finding with a source reference and no padding. If a section doesn't change the recommendation, cut it to a line in the summary.

### What is the difference between a due diligence report and a due diligence checklist?

The checklist is the input, the request list of everything you want to review. The report is the output, your conclusions after reviewing it. You use the checklist to drive what gets uploaded to the room and the report to tell the deal team what you found. They map to each other section by section, which is why building the room around both pays off.

### Who is allowed to see the due diligence report?

Usually a tight circle: the deal team, the investment committee or board approving the transaction, and the specialist advisors who contributed sections. Because the report concentrates sensitive findings in one place, it is often the single most confidential document in the process. Many teams keep it out of the shared data room entirely and circulate it through controlled access only.

### Can the seller write their own due diligence report?

Yes. A vendor due diligence report is prepared by the sell side, often through an independent advisor, to give buyers a credible starting picture and speed up the process. It is a different document with a different audience than a buyer's report, and a serious buyer will still run their own confirmatory review rather than rely on it alone.

### What happens to the report after the deal closes?

It becomes a reference for integration and a record of what was known at signing. The risk register feeds the post-close plan, since unresolved findings often turn into integration tasks or conditions that were carried into the agreement. It also matters if a dispute arises later, because it documents what was disclosed and reviewed.

### How does a data room speed up writing the report?

By keeping every source document indexed, versioned, and access-logged in one place, so findings can cite specific files and the writer never has to chase missing documents in the final week. When the room's folder structure mirrors the report's sections from the start, assembling the report becomes a matter of pulling findings together rather than reconstructing where everything went. Our guide to the [best data room for due diligence](/blog/best-data-room-for-due-diligence) walks through what to look for.