Managing Contract Deliverables: CDRLs, Submission & Acceptance

Contract deliverables are tangible items, reports, data, or services you must provide to the government to fulfill contract requirements.

Types of deliverables:

• Technical deliverables — Hardware, software, prototypes, systems
• Data deliverables — Reports, documentation, drawings, datasets
• Management deliverables — Plans, status reports, schedules
• Service deliverables — Completed tasks, support hours, training sessions

Why deliverables matter:

• Payment trigger — Many contracts withhold payment until deliverable is accepted
• Performance measure — On-time delivery rate directly impacts CPARS
• Contractual obligation — Failure to deliver can trigger cure notice or default
• Technical proof — Demonstrates you're meeting technical requirements

Deliverable vs. milestone:

• Deliverable: Something tangible you provide to government
• Milestone: A point in time or event (may or may not have deliverable)

Example: "System design complete" is a milestone. "System Design Document" is the deliverable proving milestone completion.

What is a CDRL?

The Contract Data Requirements List is a formal list of all data deliverables required by the contract, defined using DD Form 1423.

DD Form 1423:

Standard DoD form specifying each deliverable's requirements:

• Block 1: Data item number/identifier
• Block 2: Title of data item
• Block 3: Subtitle or description
• Block 4: Authority (Data Item Description reference)
• Block 5: Contract reference (SOW paragraph)
• Block 6: Requirement code (TDP, TM, etc.)
• Block 7: Date of first submission
• Block 8: Date of subsequent submissions
• Block 9: Distribution (who receives it)
• Block 10-16: Frequency, format, and other details

Data Item Description (DID):

Standardized specification for common deliverable types (e.g., DI-MGMT-80368 for monthly status reports). DIDs specify format, content, and preparation instructions.

Common CDRL items:

• Monthly/quarterly progress reports
• Technical documentation (manuals, specifications, drawings)
• Test reports and results
• Plans (quality, security, transition, etc.)
• Meeting minutes
• Financial reports (cost-type contracts)
• Final reports and lessons learned

Non-DoD contracts:

Other agencies may not use DD 1423 but will specify deliverables in the SOW/PWS or separate deliverables schedule. Same principles apply.

Review CDRLs during proposal:

• Identify all deliverables and due dates
• Estimate effort to create each deliverable
• Include deliverable costs in your price
• Flag unrealistic requirements early (Q&A or proposal assumptions)

Standard submission workflow:

1. Internal review (before government submission):

• Technical review (content accuracy, completeness)
• QA review (formatting, compliance with CDRL/DID)
• Management review (consistency with contract requirements)

Never submit first draft directly to government. Internal QA reduces rejection risk.

2. Prepare submission package:

• Format per CDRL specifications (Word, PDF, hardcopy, etc.)
• Include required front matter (cover page, title page, etc.)
• Number pages and figures
• Create table of contents (if required)
• Include all required appendices/attachments

3. Submit via specified method:

• Email: To designated COR/CO email address
• Secure portal: Agency-specific systems (PIEE, eDocs, etc.)
• Hardcopy: Mailed or hand-delivered (rare but still happens)
• File sharing: SharePoint, Google Drive, etc. (with government access)

4. Document submission:

• Save proof of submission (email confirmation, upload receipt)
• Note submission date/time (timeliness matters)
• Track in deliverables log

5. Await government review:

• Government has specified review period (typically 10-30 days)
• Follow up if no response within review period
• Don't assume silence means acceptance

Submission timing:

• Submit early: Aim for 2-3 days before deadline when possible
• Avoid last-minute: System failures, email issues, or unexpected issues can cause late submission
• Coordinate if late: If you'll miss deadline, notify COR immediately and request extension in writing

Cover letter best practices:

Include transmittal memo/email with each submission:

• Contract number and deliverable reference (CDRL number)
• Due date (confirm you're on time)
• Brief description of deliverable
• Point of contact for questions
• Note any deviations from CDRL (with justification)

Inspection and acceptance:

Government has right to inspect deliverables before acceptance. Acceptance means government agrees the deliverable meets contract requirements.

Inspection methods:

• Document review — COR/SME reads and evaluates content
• Testing — Functional testing of software, equipment, systems
• Demonstration — You demonstrate functionality or capability
• Measurement — Physical inspection, measurement, or analysis

Acceptance outcomes:

1. Accepted:

• Deliverable meets requirements
• Government issues acceptance memo/email
• Payment processed (if tied to deliverable)
• Obligation complete

2. Accepted with comments:

• Deliverable substantially meets requirements
• Minor issues noted but don't prevent acceptance
• Comments may inform future deliverables
• Still counts as accepted for payment/performance

3. Conditionally accepted:

• Accepted pending minor corrections
• Specific changes required
• Payment may be held until conditions met
• Resubmit corrected version

4. Rejected:

• Deliverable does not meet requirements
• Government provides deficiency list
• Must correct and resubmit
• Payment withheld
• May impact schedule and CPARS

Acceptance timeframes:

Contract typically specifies government review period (e.g., "30 days after submission"). If no timeframe specified, "reasonable time" applies (usually 30 days).

Constructive acceptance:

If government uses/implements deliverable without formal acceptance (and doesn't reject within timeframe), may constitute constructive acceptance. Document this carefully if payment is delayed.

Get written acceptance:

Always get formal written acceptance. Verbal "looks good" doesn't count. Request acceptance memo if not provided within review period.

When a deliverable is rejected:

1. Understand the deficiencies:

• Request detailed rejection rationale in writing
• Schedule meeting with COR to discuss specific issues
• Clarify acceptance criteria
• Understand what "good" looks like

2. Assess root cause:

• Did you misunderstand requirements?
• Did requirements change or were they unclear?
• Was technical approach wrong?
• Was it formatting/compliance vs. technical substance?

3. Corrective action:

• Fix identified deficiencies
• Address root causes (not just symptoms)
• Have SME review before resubmission
• Consider requesting government review of draft before formal resubmission

4. Resubmission:

• Clearly mark as "REVISED" or "RESUBMISSION"
• Include cover letter noting what was changed
• Reference original submission and rejection
• Highlight changes for easy review

5. Prevent recurrence:

• Update internal templates/processes
• Brief team on lessons learned
• Strengthen QA for similar deliverables

Common rejection reasons:

• Incomplete: Missing required sections or information
• Non-compliant format: Doesn't follow DID or CDRL specifications
• Inadequate detail: Too superficial, lacks analysis or substance
• Incorrect technical approach: Doesn't meet technical requirements
• Poor quality: Errors, inconsistencies, lack of rigor
• Missed the point: Deliverable doesn't address the actual need

If you disagree with rejection:

• Document how deliverable meets contract specifications
• Reference specific SOW/CDRL requirements
• Request reconsideration from COR
• Escalate to CO if COR won't reconsider
• Consider filing claim if material impact (payment, schedule)

Impact of rejections:

• Delays payment tied to deliverable
• Consumes additional effort (uncompensated on FFP)
• Damages relationship with COR
• Lowers CPARS quality/management ratings
• May delay dependent work or milestones

During proposal phase:

• Create deliverables matrix listing all required items, due dates, and effort
• Price adequately — don't underestimate deliverable effort
• Challenge unrealistic requirements (Q&A or proposal assumptions)
• Clarify ambiguous deliverables before contract award

After contract award:

• Create deliverables schedule: Calendar with all due dates
• Set internal deadlines: 5-7 days before contract due date
• Assign ownership: Specific person responsible for each deliverable
• Track status: Dashboard or spreadsheet showing progress

During execution:

• Start early: Don't wait until deadline week to begin
• Use templates: Develop templates for recurring deliverables
• QA everything: Peer review + senior review before submission
• Request feedback: For early deliverables, ask COR "How can we improve next time?"

Communication:

• Notify COR 2-3 days before submission (heads-up)
• If running late, alert COR immediately and request extension
• After submission, confirm receipt and ask about review timeline
• If no feedback within review period, follow up

Quality control checklist:

Check	Status
Meets CDRL/DID format requirements	☐
All required sections included	☐
Technical content accurate and complete	☐
Proofread (no typos, grammar errors)	☐
Consistent with proposal commitments	☐
Figures/tables properly labeled	☐
References cited correctly	☐
Proper markings (proprietary, classification)	☐

Tools for tracking:

• Spreadsheet: Simple deliverables log (deliverable, owner, due date, status, acceptance date)
• Project management software: MS Project, Smartsheet, Asana
• Contract management systems: Costpoint, Deltek, Unanet

Management deliverables:

• Monthly status reports: Progress, metrics, issues (see status reporting)
• Project plans: Management plan, quality plan, security plan
• Schedules: Integrated Master Schedule (IMS), updated periodically
• Meeting minutes: Kickoff, monthly reviews, technical interchange meetings
• Risk register: Identified risks, mitigation plans, status

Technical deliverables:

• Design documents: System design, architecture, specifications
• Test plans and reports: Test procedures, results, acceptance test reports
• Technical manuals: User manuals, maintenance manuals, training materials
• Drawings and diagrams: Engineering drawings, schematics, network diagrams
• Source code: Software code with documentation (if government has rights)

Financial deliverables (cost-type contracts):

• SF 1408: Preaward Survey of Prospective Contractor
• SF 1411: Contract Pricing Proposal Cover Sheet
• Incurred Cost submissions: Annual submission of actual costs
• Cost performance reports: EVM reports (see earned value management)

Closeout deliverables:

• Final report: Summary of accomplishments, lessons learned
• Final invoice: Marked "FINAL" (see contract closeout)
• Property accountability: Final inventory and disposition
• Final technical data: As-built drawings, final documentation

Special deliverable types:

Draft vs. final:

• Some CDRLs require draft for government review, then final incorporating feedback
• Draft = working document, final = official deliverable
• Both may have separate due dates

Interim vs. final:

• Interim = periodic progress deliverables (monthly, quarterly)
• Final = end-of-contract comprehensive deliverable

Incremental deliverables:

• Delivered in phases or increments
• Common in agile/iterative development
• Each increment must be accepted before next

Format specifications:

• Native format: Editable source files (Word, Excel, CAD)
• PDF: Non-editable, preserved formatting
• Hardcopy: Printed/bound documents (increasingly rare)
• Electronic media: CD/DVD/USB (rare, typically secure portal now)

Naming conventions:

• Use consistent file naming (contract number, CDRL number, version, date)
• Example: N00014-26-C-1234_CDRL-A001_Monthly-Status-Report_v1.0_2026-04-15.pdf

Version control:

• Track version numbers for all deliverables
• Maintain version history (what changed between versions)
• Clearly mark revised submissions

Data rights and markings:

Government's rights to use, modify, reproduce, and disclose your deliverables depend on FAR 52.227 clauses:

• Unlimited rights: Government can do anything (typical for deliverables created under contract)
• Government Purpose Rights: Government can use for government purposes, not commercial
• Limited rights: Government can use but not disclose externally (protects your proprietary data)
• Restricted rights: Government can use but not modify (commercial software)

Marking requirements:

• If deliverable contains proprietary information, mark it properly
• Header/footer: "Contains Proprietary Information — Limited Rights"
• Follow FAR 52.227-14 legend requirements
• Don't over-mark — government pushes back on excessive restrictions

Security markings:

• Classified deliverables: Proper classification markings (SECRET, TOP SECRET, etc.)
• CUI (Controlled Unclassified Information): Mark per NIST SP 800-171
• ITAR/EAR: If export-controlled, mark accordingly