A good DDL is not clerical; it tests whether the seller understands its own business and whether the story can be evidenced.
By Noah Green CPA CFE, Sheepdog Prosperity Partners LLC
The mistake this article is trying to prevent
The first mistake in The First Data Request List diligence is that the team sends a conventional request list that collects volume but does not test the seller’s ability to reconcile claims across systems. That mistake usually does not look reckless at the beginning. It looks efficient. The file has documents. The model has assumptions. The request list has been answered. The deal vocabulary feels familiar enough for the team to move quickly.
But diligence is not a speed exercise. It is structured doubt. The point is not to distrust every representation. The point is to make the representation carry its own evidentiary weight. A useful diligence process should be able to say, in plain English, what is supposed to happen, why it should happen, who has to perform, what documents prove it, what can interrupt it, and what the capital provider can do when the answer changes.
For this topic, the useful frame is narrow and practical: The first data request list should be designed as a diagnostic instrument, not a warehouse of generic requests. That is the discipline. It keeps the review from drifting into generic commentary and forces the team to build a decision-ready file.
Reduce the topic to mechanics
The mechanics are a staged request framework that asks for the minimum files needed to map cash, assets, controls, obligations, and exceptions before widening the scope. If the team cannot describe those mechanics without marketing language, it does not yet have a diligence frame.
A mechanics-first review asks what actually has to occur for cash to arrive. It identifies the operational steps, the contractual steps, the data steps, and the human decisions that sit between the asset and the money. It also asks which of those steps are routine only because nobody has applied stress. The best diligence questions are often basic: who sends the bill, who receives the money, who applies the cash, who can issue a credit, who keeps the records, who can change the system, and who notices when the pattern changes?
The answer should be written as a process map, not as a paragraph of comfort. A process map exposes handoffs. Handoffs expose control points. Control points expose failure modes. Once the failure modes are visible, the legal and credit analysis can stop speaking in abstractions.
Separate repayment from recovery
The source of repayment is reports that connect invoice, contract, order, payment, deposit, adjustment, and general-ledger activity into one cash-conversion trail. That source deserves its own underwriting. The team should test whether it is historical, contractual, behavior-driven, discretionary, recurring, concentrated, seasonal, platform-mediated, or dependent on continued sponsor execution. Each answer changes the diligence scope.
The source of recovery is different. Recovery is what remains when the ordinary-course payment path has been interrupted. It may be the same asset, a lien, a receivable pool, a contract right, a physical asset, a claim to proceeds, a reserve, a guarantee, or a remedy that depends on cooperation from third parties. Recovery should be evaluated under the conditions that created the need for recovery in the first place.
A common false comfort is to say that the asset is performing and therefore the collateral is sound. Performance is relevant, but it is not collateral analysis. Collateral analysis asks what the asset is worth, how it can be reached, how quickly it can be converted, and whether the recovery value is independent from the same stress driver that reduced cash flow.
Map control before relying on projections
Control matters because cash flow without control is an expectation, not protection. In this article’s topic, the control points include user roles, approval authorities, system permissions, bank-account access, payment instructions, change logs, and exception-handling procedures. These points should be identified before the team debates the final model.
Control is not limited to bank accounts. It includes data rights, document custody, reporting cadence, approval authority, reserve mechanics, notice procedures, replacement rights, and the ability to verify exceptions. It also includes negative control: who can prevent the capital provider from acting? A borrower, seller, servicer, account bank, customer, court, platform, landlord, utility, insurer, regulator, or contractual counterparty can all become practical gatekeepers.
The cleanest diligence files make control visible. They identify the party, the right, the required notice, the timing, the evidence, and the failure consequence. If a right cannot be exercised quickly when the asset is under stress, it should not be described casually as protection.
Evidence is not the same as a data room
The evidence package should include source files rather than summaries: transaction tapes, contracts, bank files, reconciliations, policies, audit trails, servicing notes, and sample support packages. The question is not whether those items were uploaded. The question is whether they reconcile.
A practical evidence review should distinguish four levels of support. First, there is management assertion. Second, there is internal documentation. Third, there is system or transactional evidence. Fourth, there is independent or third-party evidence. Diligence should try to move the most important assumptions as far down that evidence ladder as possible. Not every fact needs third-party confirmation. But every material assumption should have a clearly identified support level.
The team should also look for adverse evidence. Clean diligence is not the absence of exceptions. It is the disciplined treatment of exceptions. If the seller can produce only favorable files, or if exceptions are always explained but never logged, the file is not stronger. It is less testable.
What breaks first
The interruption risks include the places where incomplete data, inconsistent definitions, or delayed access reveal operational weakness before the substantive review is complete. These are not remote possibilities included for legal completeness. They are the first places the team should look when designing stress cases.
The most useful stress case is not necessarily the most dramatic one. It is the first plausible interruption that would change the decision. A small reporting delay may matter more than an extreme macro shock if the structure depends on fast trigger reporting. A modest increase in dilution may matter more than a catastrophic default if the advance rate has no room for ordinary commercial deductions. A servicing transition may matter more than asset performance if collections depend on daily operational execution.
The goal is to identify the earliest indicator that the thesis is changing. If the team cannot name that indicator, it may know the downside in theory but not in time to act.
Legal structure as practical risk allocation
The relevant legal questions include organizational documents, assignment language, consent requirements, restrictions, collateral descriptions, account-control materials, and counsel-generated issue lists. These issues require counsel-led review. The diligence team should not turn legal analysis into casual business advice. But the business team still has to understand what the legal structure is intended to accomplish and what assumptions it depends on.
A legal opinion, document checklist, or executed agreement is not the end of the analysis. The practical question is how the rights behave under stress. Can cash be redirected? Can the asset be sold? Can notices be delivered without delay? Can records be transferred? Are consents required? Are there setoff rights, anti-assignment provisions, priority issues, transfer limits, privacy limits, or jurisdictional constraints? Who has to cooperate for the remedy to work?
Legal structure manages uncertainty; it does not eliminate it. A strong file explains both the right and the operational path for using the right.
Downside before upside
The downside frame is what must be escalated when the seller cannot produce basic records, cannot reconcile them, or can only support the thesis through management explanation. This is where the review becomes decision-useful. Upside can explain why the opportunity exists. Downside explains whether the opportunity should be accepted, changed, priced differently, delayed, or rejected.
A disciplined downside analysis should not be a generic list of risks. It should be ranked. Which issue is fatal? Which issue changes the price? Which issue requires a closing condition? Which issue can be monitored after closing? Which issue is acceptable only because the expected return, structure, or strategic purpose justifies it? This ranking is the difference between a diligence report and a decision memo.
Decision frame
The first DDL has done its job when the team knows which claims are evidence-backed, which are narrative-backed, and which cannot yet be tested.
Practical diligence checklist
- Define the actual source of repayment for the asset without relying on the asset-class label.
- Map the cash path from source event to controlled account and identify every party that can interrupt it.
- Separate ordinary-course cash flow from recovery value and test whether those risks are independent.
- Identify the records that prove existence, ownership, amount, timing, and enforceability.
- Reconcile management summaries to source documents, bank activity, and exception reports.
- List the legal rights that must work on a bad day and assign counsel-led follow-up for open issues.
- Name the first three events that would make the base case unreliable.
- Classify every material issue as fatal, priceable, mitigable, monitorable, or acceptable only with explicit approval.
Red flags to escalate
- Management can explain the thesis but cannot reconcile the source data.
- The model assumes control that the documents or operating process do not provide.
- Definitions in the financing documents do not match the data fields used for reporting.
- Exceptions are handled manually but not logged or independently reviewed.
- The recovery analysis relies on the same condition that supports ordinary-course repayment.
- Legal rights are described as complete while consents, notices, or account controls remain unfinished.
This article is for educational purposes only and does not constitute legal, investment, accounting, tax, or credit advice. Examples may be simplified or fictionalized composites unless otherwise identified as public-source case studies. Author byline: Noah Green CPA CFE, Sheepdog Prosperity Partners LLC.