Contracting 101: Building a Post-Award Compliance Matrix — Because Reading the Contract Isn't Enough
You've received the award, reviewed the contract, and started getting everything set up. The Program Manager understands the work, Accounting is establishing the project, and everyone is ready to get started.
But who is making sure someone caught that requirement buried in Section H? Or the training requirement referenced in an attachment? What about the clause requiring Government approval before certain costs can be incurred?
This is where a post-award compliance matrix becomes one of the most useful tools in Contract Administration.
And no, I'm not talking about the compliance matrix you built for your proposal. I'm talking about the one that helps you manage the contract you actually received.
What Is a Post-Award Compliance Matrix?
A post-award compliance matrix is a working inventory of your contractual obligations. It identifies what the agreement requires, where the requirement came from, and who within your organization is responsible for making sure it happens.
The concept is simple: Reading a requirement is not the same thing as implementing it.
You can have a perfectly organized contract file and still miss an important obligation because nobody realized it applied to their department.
The matrix helps close that gap.
Larger companies may have sophisticated contract management systems, but smaller contractors don't necessarily need expensive software or complicated processes to accomplish the same objective.
Sometimes a well-organized Excel workbook is exactly what you need.
Start With the Contract You Actually Received
One mistake contractors can make is assuming the awarded contract looks exactly like the solicitation or the proposal.
It may not.
Before building your matrix, start with the executed award and its incorporated documents. Review the applicable contract sections, Statement of Work (SOW) or Performance Work Statement (PWS), attachments, clauses, and any modifications already issued.
Don't assume a requirement disappeared because it isn't mentioned on the cover page. And don't assume something from your proposal became a contractual obligation unless it was incorporated into the agreement or otherwise made binding.
You need to understand what the Government actually awarded.
If you're working with a subcontract, the same principle applies. Start with the executed subcontract agreement, including applicable flowdowns and attachments, rather than assuming every prime contract requirement automatically applies to you.
Look for the Words That Create Obligations
When I review a contract for compliance requirements, I pay particular attention to words like shall, will, must, required to, and may not.
Those are good indicators that something needs to be captured.
For example:
"The Contractor shall submit a monthly progress report."
"All personnel must complete required security training before receiving facility access."
"The Contractor shall obtain written approval before incurring travel expenses."
"The Contractor shall maintain the insurance coverage specified in the contract."
Each of these statements creates something the contractor needs to do, maintain, submit, or demonstrate.
But don't blindly copy every sentence containing "shall" into your matrix. Some requirements apply to the Government, some are conditional, and others repeat obligations already captured elsewhere.
Also, don't limit your review to those specific words. Contractual obligations can be established through incorporated clauses, referenced documents, tables, and other instructions that don't necessarily use the word "shall."
The objective is to identify every applicable contractor obligation, not to create a spreadsheet containing every sentence in the contract.
And don't forget the attachments. Some of the most operationally important requirements are buried in the SOW/PWS, security documentation, reporting instructions, or other incorporated documents.
Give Every Requirement a Home
Here's where I like to simplify things.
Rather than creating a separate tracking process for every possible type of obligation, I divide requirements into three categories:
Category | What belongs here |
Deliverables | CDRLs, recurring reports, required plans, notices, and other submissions |
Training | Contract-required employee training, certifications, and renewals |
Other Requirements | Travel approvals, security procedures, insurance, staffing, recordkeeping, and other contractual obligations |
Every requirement goes into the master Requirements tab. The category tells us where, if anywhere, additional tracking is needed.
For example, a monthly status report is captured in the Requirements tab because it's a contractual obligation. But its due dates, submission history, and acceptance are managed in the Deliverables tab.
Likewise, a requirement for annual security training belongs in the master matrix, while the Training tab records which employees completed it and when renewal is due.
This gives us one inventory of obligations without trying to manage everything in one enormous spreadsheet.
Keep the Requirements Matrix Simple
For a small contractor, I don't believe the matrix needs twenty columns.
At a minimum, I want to know:
Where is the requirement? Identify the contract section and page number so someone can return to the original language.
What does it say? Capture the relevant contractual language or a faithful excerpt. Don't replace an important requirement with a summary that accidentally leaves out a deadline or condition.
What type of requirement is it? Categorize it as Deliverable, Training, or Other.
Who does it affect? Identify the functional area, such as Contracts Administration, Program Management, Accounting, Security, HR, or Purchasing.
Who owns it? Assign a responsible person or position.
What else do we need to know? Use a Notes field for clarification, exceptions, or references to supporting documents.
That's enough to make the matrix useful without turning it into another full-time job.
And assigning responsibility matters. A requirement that belongs to "everybody" has a funny way of becoming nobody's responsibility.
Don't Forget the Contract Brief
While we're already reviewing the entire agreement, why not capture the information we'll need repeatedly?
I like having a Contract Brief as part of the same workbook. It provides a quick reference for the contract number, customer, contract type, period of performance, financial information, billing requirements, points of contact, and significant contract-specific provisions.
That way, the Program Manager doesn't have to dig through 200 pages to find the travel approval instructions, and Accounting doesn't have to search through modifications to determine the current contract value.
For contractors subject to incurred cost reporting, a properly maintained contract brief can also support information that may be requested during a Defense Contract Audit Agency (DCAA) incurred cost audit.
FAR 52.216-7 identifies contract briefings as supplemental information that may be requested in connection with an incurred cost submission. Rather than creating an entirely separate document when that information is requested, I prefer capturing it as part of the regular contract administration process.
Of course, the workbook needs to contain the relevant information, and an auditor may still request supporting documents or additional details.
The point is to avoid doing the same administrative work twice.
Track Deliverables Separately
Deliverables deserve their own tracker because simply identifying the requirement doesn't tell you whether it was completed.
In our earlier Contracting 101 article on CDRLs and Data Item Descriptions (DIDs), we shared a simple deliverable tracker to help contractors manage required submissions and acceptance.
If you downloaded that tracker, you're already ahead of the game!
The workbook we're sharing today incorporates that same tracker into a broader contract administration tool. We kept the familiar columns — CDRL, Deliverable, DID, Owner, Due Date, Delivered, Accepted, and Notes — so you don't have to learn a different process or maintain two separate trackers.
And remember, not every contractual deliverable is a CDRL. Some reports, plans, notifications, and other submissions are required elsewhere in the agreement.
For those items, you can use the contract section reference in place of a CDRL number and leave the DID field blank when it doesn't apply.
If the Government provides a required template, I also recommend linking it in the Notes field so the person preparing the submission can easily find the correct version.
The objective is to know what's due, who's responsible, and whether it was delivered and accepted when acceptance is required.
Training Is a Compliance Requirement, Too
Training is another area where requirements can easily fall through the cracks, especially when employees join or leave a contract.
If the agreement requires specific training, the matrix should identify that obligation and the Training tab should document completion.
I prefer tracking training by employee, using Last Name, First Name, along with the required course, due date, completion date, and renewal date.
That makes it much easier to answer a simple question during an audit or customer review: "Can you show me that the personnel assigned to this contract completed the required training?"
And while a completion date is useful, remember to retain the actual training records or certificates when required.
Modifications Should Update More Than the Contract File
Here's another common issue: the contract gets modified, somebody saves the modification, Accounting updates the funding, and everyone moves on.
But did anyone review whether the modification changed a reporting requirement, period of performance, staffing obligation, deliverable, or special contract condition?
A modification can affect several parts of your compliance workbook.
That's why I include a separate Modifications tab that records the modification number, effective date, description, changes to contract value and obligated funding, and any impacts to performance or contractual requirements.
Our workbook also calculates cumulative contract value and funding from the original award and subsequent modifications. Those figures feed into the Contract Brief so they don't have to be maintained in two places.
But the numbers aren't the only thing that matters. Each modification should trigger a review of the affected requirements, deliverables, training obligations, and contract summary.
Saving a modification isn't the same thing as implementing it.
Make It Useful for the People Actually Performing the Work
A compliance matrix shouldn't live in a folder that only Contracts Administration knows exists.
Program Management needs to understand its performance obligations. Accounting needs to know about billing limitations and financial requirements. HR may be responsible for training or staffing provisions, and Security needs visibility into applicable access and information-protection requirements.
That doesn't mean everyone needs to maintain the spreadsheet. In a small company, one person may own the workbook and coordinate updates with the functional owners.
The important thing is that the people responsible for compliance understand what is required of them.
I also recommend reviewing the matrix during project setup, when significant modifications are received, and periodically throughout performance. The frequency should make sense for the size and complexity of the contract.
The goal isn't to create more meetings or administrative work. It's to prevent avoidable surprises.
A Free Workbook to Get You Started
To make this easier, I've put together an Excel-based Post-Award Contract Administration & Compliance Workbook designed with small contractors in mind.
It includes five tabs:
Contract Brief: Key agreement information, financial terms, billing provisions, contacts, and audit-support information.
Requirements: A master inventory of applicable contractual obligations.
Deliverables: The same familiar tracker from our earlier CDRL article, now incorporated into the larger workbook.
Training: Employee-specific training completion and renewal tracking.
Modifications: Contract changes, cumulative value and funding, and updates affecting performance.
It's designed to be straightforward enough for a small Contracts department — or the person who wears the Contracts, HR, Accounting, and Program Management hats on any given Tuesday.
The workbook provides the structure. You'll still need to review your agreement carefully, identify the requirements that actually apply, and make sure someone is responsible for them.
It's a starting point, not a substitute for a thorough contract review.
A Matrix Is Only Useful If You Use It
Building a compliance matrix isn't the end of contract review. It's the beginning of managing what you agreed to do.
You don't need an elaborate software platform or a dedicated compliance department to establish a good process. You need an accurate understanding of the agreement, clear ownership, and a practical way to track obligations throughout performance.
And if you're thinking, "This sounds like a lot of work," you're not wrong. Reviewing a contract thoroughly and identifying its requirements takes time.
But it's considerably easier to do that work at the beginning than to explain six months later why nobody knew a requirement existed.
The goal isn't to create a beautiful spreadsheet. It's to make sure the requirements in your contract become actions inside your company.
Ally Compliance Solutions, LLC helps federal contractors strengthen contract administration, program control, and compliance processes. Whether you need a comprehensive contract review, assistance developing a compliance matrix, or help implementing practical contract management procedures, we're here to help.
Comments