A financial due diligence IRL that management can actually answer

An Information Request List is not an inventory of files that the seller may possess. It is the translation of mandate questions into requests that someone can understand, prepare and verify. I would start with the investment: how does the target make money, what risks affect its results, what will need to be financed at closing? General inquiries come next. A long standard list does not protect against forgetting a question specific to the business model.

The IRL must work for three people: the management who provides the data, the analyst who uses it and the manager who decides if the answer is sufficient. A line like “aged customer balance” leaves open the period, the entities, the currency, the accounting value adjustments or provisions for charges and the level of detail. Precision avoids reminders, but it must remain proportionate. Requesting all available fields for each file can slow down the process without improving a priority scan.

I would structure the IRL by analyses: financial basis, quality of results, turnover, costs, NWC, debt and commitments. The additional blocks depend on the file: ARR for a SaaS company, merchandise inventories for a distributor, autonomous costs for a carve-out. The same part can power several analyses. It is better to link a request to several uses than to request three incompatible versions of the same extraction.

The scope must be included in critical requests and in a common header: legal entities, operational units, periods, presentation currency and accounting framework. I would distinguish between the accounting closing date, the extraction date and the last available period. An export generated in January can relate to December; conversely, a file titled “December” may contain an intermediate situation. The file name is not proof of coverage.

A good model distinguishes between the content of the request and its processing status. The identifier must remain stable when the wording changes. Priority is used to organize the mission, not to declare that everything is urgent. The expected date should take into account necessary retrievals and other requests to the same person. I would keep significant changes in scope rather than silently replacing text.

The “received” status deserves to be separated from the “reviewed” status. If a tool automatically matches documents, its result is a link candidate. The team then checks the time period, scope and usability. This distinction protects against a completely green picture when analyzes cannot yet be run.

To test the December 2025 receivables of entities A and B, I would request details by invoice, age, accounting value adjustments or provisions for charges and subsequent collections available on a specified date. The total must match the accounting, with explanation of the differences. The request is used to examine the recovery and sufficiency of accounting value adjustments or provisions for charges, not just to calculate a customer total.

The target submits a consolidated PDF which displays the total and some age brackets. It can be useful as a first view, but it does not allow you to isolate B or select invoices. I would keep this piece and note exactly what is missing. The reminder would concern the detailed export, the accounting adjustments of value or provisions for charges and the accounting reconciliation, without requesting the information already received. The analysis can begin on the available perimeter with an explicit reservation.

A management response indicating that the receivables are all recoverable does not replace receipts or supporting documents. If complete extraction is impossible, the manager can accept alternative procedures and document their limitations. The status does not become "complete" because a meeting took place or because the report date is approaching.

I would keep a reference log with related documents, versions and open questions. A follow-up should explain the variance and its effect on the schedule or analysis. “Please complete” forces management to guess; “Entity B is missing and the invoice detail necessary for the collection test” allows action to be taken. A short prioritization meeting can unlock more work than a letter with fifty unordered requests.

New requests must be distinguished from clarifications. Adding a third ERP or a new period is a change in scope, not a simple technical update. I would discuss it with the mission manager: effect on deadlines, alternative procedures and possible adaptation of the SOW. The IRL is linked to the mandate; it must not extend the work indefinitely by accumulation.

AI can help adapt an initial list to the business model, suggest accounting reconciliations and summarize the responses. I would test for false positives on nearby files: good description but bad period, missing entity, old part or unusable PDF. High coverage without measuring these errors can be misleading. The profit must include the time spent checking connections.

In a workflow like the one presented by Solenor, the value sought is continuity between IRL, documents and professional review work. It remains to be verified on your authorized data. I would request an export where another member of the team can find the request, the part, the shortages and the decision. The template is successful when it allows this transmission, not when it has the most lines.