Contracting 101: CDRLs & DIDs — Who, What, When and Where
If you've been following the Contracting 101 series, we've spent a lot of time talking about finding the requirements buried throughout your contract. CDRLs are where some of those requirements turn into something your company actually has to produce and deliver.
CDRL stands for Contract Data Requirements List. In Department of Defense contracts, you'll typically see these on DD Form 1423. Depending on the contract, the list might include monthly status reports, financial reports, test reports, technical documentation, plans, drawings, security-related documents or any number of other required data items.
But knowing what CDRL stands for isn't particularly helpful if nobody is managing them.
For Contracts Administration, the practical questions are much simpler:
What do we owe? Who owns it? When is it due? Where does it go? And can we prove we delivered it on time?
That's where I start.
First, Find All of Them
If your contract includes a CDRL package, don't just save it in the contract file and move on. Review every CDRL and identify every required delivery.
Pay particular attention to whether a deliverable is one-time or recurring. A monthly report isn't one requirement that you add to a tracker and revisit each month. If the contract requires that report every month for a 12-month period of performance, I want all 12 required deliveries loaded into my tracker from the beginning.
The same goes for quarterly, annual and event-driven requirements where the dates can reasonably be identified.
Why? Because I don't want my system to depend on someone remembering to add the next requirement after the current one is complete.
If a modification extends the period of performance, adds or removes a CDRL, or changes a delivery requirement, updating the tracker should be part of processing that modification.
Read the CDRL — But Don't Stop There
The CDRL gives you the contractual delivery requirement. It helps tell you what is being delivered, when it is required, where it needs to go and other instructions associated with that delivery.
But you'll often see another reference on the CDRL: a Data Item Description, or DID.
This is where people sometimes get confused about the relationship between the two.
A simple way to think about it is:
The CDRL tells you about the delivery. The DID tells you what the data product is supposed to contain and how it should be prepared.
If your CDRL references a DID, go get it and read it. Don't hand someone a line that says "Monthly Status Report" and expect them to magically know what the Government expects to see in that report.
The Defense Logistics Agency's ASSIST Quick Search is a useful place to locate current publicly available DIDs. Make sure you're looking at the DID and revision applicable to your contract.
And don't forget to read the CDRL itself for tailoring or other instructions. The DID may establish the standard requirements for the data item, while the contract can tailor what is required for your particular acquisition.
Who Owns It?
Every deliverable needs an internal owner.
That doesn't mean Contracts Administration has to prepare every CDRL. In fact, Contracts may prepare very few of them.
A Program Manager may own the monthly status report. Project Control may prepare a financial report. Security may own a security-related deliverable. Engineering, Quality, Accounting or another functional area may be responsible for others.
Put the owner's name or function in the tracker so there is no question about who is responsible for getting it done.
But here's the distinction I think is important:
The functional owner owns the deliverable. Contracts Administration owns the oversight.
Assigning a CDRL to someone else doesn't mean Contracts should forget about it until the due date passes.
Contracts should know what's coming, follow up with owners before due dates, make sure requirements aren't falling through the cracks, and maintain visibility over the full CDRL schedule.
In other words, Contracts gets to be the persistent reminder. There are probably less polite names for that role, but we'll stick with that one.
What Exactly Are We Delivering?
Don't rely solely on the title.
Read the CDRL. Read the referenced DID. Follow any references back into the Statement of Work (SOW), Performance Work Statement (PWS), specifications or other applicable contract documents.
If the DID requires specific content, understand it. If the CDRL tailors that requirement, understand the tailoring. If the contract requires a specific format, make sure the person preparing the deliverable knows that before they build it.
And don't forget about template attachments. As we discussed in the Section J article, some contracts include a Government-provided template that you're expected to use for a particular deliverable. If one exists, make sure the functional owner has the correct template and is actually using it. The DID may tell you what information is required, but the contract may also tell you exactly how the Government expects to receive it.
This is also why simply forwarding a CDRL to a functional owner isn't enough. They need the information necessary to prepare the contractually required deliverable, not just their interpretation of what a report with that title should look like.
When Is It Due?
This sounds obvious until you start reading the actual delivery instructions.
"Monthly" doesn't necessarily mean the last day of every month. A requirement might be due a certain number of days after month-end, a certain number of days after contract award, before or after a specific event, or according to another schedule established by the contract.
Determine the actual due date for each required delivery and put it in the tracker.
For recurring CDRLs, load the expected deliveries for the life of the contract. Now Contracts can look ahead instead of backward.
That's the difference between managing a requirement and discovering one.
Where Does It Go?
This one is easy to overlook.
Don't assume the deliverable goes to the person your team normally communicates with. Review the contract requirements to determine the required recipient, distribution and submission method.
Depending on the contract, there may be multiple recipients or specific delivery instructions.
Your internal process should answer two questions:
Where does the contract say this deliverable goes?
And:
How are we going to prove we sent it there?
Delivered Does Not Always Mean Accepted
This is why I like separate Delivered and Accepted columns in a CDRL tracker.
If we sent the report on October 8, I want to record October 8 as the delivery date. If the Government formally accepted or approved it on October 10, that's a different event.
Not every CDRL will result in a separate formal acceptance document, and I'm not suggesting we manufacture an administrative process the contract doesn't require. But when acceptance or approval is required or provided, I want to capture it.
It also helps distinguish a deliverable that is simply awaiting Government action from one that hasn't been delivered at all.
Keep the Evidence
This may be my favorite part because it's incredibly simple and saves so much frustration later.
The tracker tells you what should have happened. The contract file proves what actually happened.
For each delivery, retain as much of the complete record as reasonably possible in the contract file:
The final version that was delivered
Proof of timely delivery
Government acceptance or approval, when applicable and available
Proof of delivery might be a sent email, system confirmation, transmittal or another record showing when and where the deliverable was submitted.
I also like organizing recurring CDRLs so someone can easily follow the history. It doesn't have to be complicated. A folder for the CDRL, organized by year or reporting period when necessary, can contain the final deliverable, proof of delivery and acceptance documentation.
The goal is simple.
If someone asks two years from now, "Did we submit A001 on time in October 2026, and was it accepted?" I don't want Contracts searching through someone's Outlook, the Program Manager's desktop and an old Teams conversation trying to reconstruct what happened.
I want to open the contract file and answer the question.
Your CDRL Tracker Does Not Need to Be Fancy
I've created a simple CDRL Tracker you can download and use as a starting point.
At a minimum, I want:
CDRL | Deliverable | DID | Owner | Due Date | Delivered | Accepted | Notes |
A001 | Monthly Status Report | DI-MGMT-XXXXX | Program Manager | 11/10/26 | |||
A001 | Monthly Status Report | DI-MGMT-XXXXX | Program Manager | 12/10/26 | |||
A001 | Monthly Status Report | DI-MGMT-XXXXX | Program Manager | 01/10/27 | |||
A002 | Financial Report | DI-FNCL-XXXXX | Project Control | 11/05/26 |
That's it.
If A001 is monthly for the entire period of performance, load every expected A001 delivery. Assign the owner. Put in the due dates. Then use the tracker to monitor delivery and acceptance throughout performance.
You don't need a complicated system to manage CDRLs well. You need a system someone will actually maintain.
Contracts Administration Keeps the Whole Picture
This is the part I don't want small businesses to miss.
The person preparing a deliverable may only be thinking about their deliverable. The Program Manager is worried about the status report. Project Control is worried about the financial report. Security is worried about its requirements.
Contracts Administration should be looking across all of them.
What's due next week? What's still outstanding? What was delivered but is awaiting acceptance? Did a modification change anything? Is an owner leaving the company? Did we retain proof of submission? Are we approaching a reporting requirement nobody has started yet?
That's the oversight role.
A CDRL tracker isn't just a list of due dates. It should help Contracts answer three questions quickly:
What do we owe, did we deliver it on time, and can we prove it?
That's Contract Administration.
Comments