A risk control matrix is the map auditors use to decide what to test. A good one starts from what could go wrong in the financial statements and works back to the control that stops it, not the other way round. This template pairs each risk with a control, classifies it, names an owner, and ties it to the assertion it protects, with example rows for procure-to-pay, order-to-cash, close, and IT general controls. Pair it with our software category guides to see which tools fit your team. Once you have a shortlist, check the vendor profiles and the finance glossary for unfamiliar terms, then use our head-to-head comparisons before your first demo.
Built for: Controller, CFO, Internal audit, SOX manager
+1 more inside
Start with risks, not controls. For each significant process, list what could cause a material misstatement: fictitious vendors, revenue recorded early, unrecorded liabilities. Then find the control that addresses each risk. Controls with no risk attached are candidates for removal.
Describe each control so it can be tested. State who performs it, what they do, how often, what threshold applies, and what evidence remains. "Controller reviews JEs" is not testable. "Controller approves all manual JEs over [$50,000] in the ERP before posting" is.
Classify and mark key controls. Record whether each control is preventive or detective, manual or automated, and whether it is key. Key controls are the ones you rely on to address a risk and that auditors will test.
Link to assertions and evidence. In the second table, map each control to the assertions it covers and list the evidence and system reports. Reports used in a control need their own completeness and accuracy check.
Review annually and after system changes. Revisit the matrix at least yearly, and whenever a process, system, or team structure changes. An ERP migration can quietly remove automated controls.
Here's a preview. Unlock the free download to get all 4 sections (3 more below).
One row per control. Type is preventive (P) or detective (D); nature is manual or automated.
| Control ID | Process | Risk | Control description | Type / nature | Frequency | Key? |
|---|---|---|---|---|---|---|
| P2P-01 | Procure to pay | Payments to fictitious or unapproved vendors | AP manager approves vendor master changes; log reviewed | P / Manual | Per change | Y |
| P2P-02 | Procure to pay | Invoices paid for goods not received | ERP three-way match blocks payment outside tolerance | P / Automated | Per invoice | Y |
More free templates finance teams use alongside this one.
Segregation of duties rests on one idea: no single person should be able to both commit an error or fraud and conceal it. In practice that means separating custody of assets, authorization, recording, and reconciliation. This matrix lists the specific duty pairs that conflict, shows who can do what by role, and gives compensating controls for teams too small to separate everything.
The PBC list is the prepared-by-client request list your auditors send before fieldwork. Audits run late when the list is treated as a pile of emails rather than a project plan. This template turns it into a tracker with one owner and one due date per request, and includes the standard items requested in a financial statement audit so you can prepare most of them before the auditors ask.
Most approval matrices fail in one of two ways: every invoice goes to the CFO, or nobody can say who approves a $40,000 software renewal. This approval matrix separates PO-backed invoices, where approval already happened at the purchase order, from non-PO spend, where the invoice is the only control point. It also names a backup for every approver so invoices do not sit in someone's inbox while they are on leave.
A risk control matrix (RCM) is a table that links each significant financial reporting risk to the control that addresses it, with the control's owner, frequency, type, and the assertions it covers. Auditors and SOX teams use it to plan and document control testing.
At minimum: control ID, process, risk, control description, preventive or detective, manual or automated, frequency, owner, whether it is a key control, and the assertions covered. Many teams also add evidence retained and reports used so testers know what to inspect.
A preventive control stops an error or fraud before it is recorded, such as an approval before posting or a system block. A detective control identifies an error after it has occurred, such as a reconciliation or a management review. A sound matrix uses both.
They are not required to file a SOX 404 assessment, but many build one anyway. It helps with financial statement audits, lender or investor due diligence, and readiness for an IPO or acquisition, and it makes control ownership explicit as the team grows.
