A key control is one that, on its own or with others, is relied on to prevent or detect a material misstatement. A risk and control matrix (RCM) lists each risk, the control that answers it, who performs it, how often and what evidence proves it. The rows below are illustrative examples for order-to-cash (O2C) and procure-to-pay (P2P). Adapt them to the actual process; they are not a complete or prescribed set.
Last reviewed: 17 October 2026. Facts checked. The RCM layout and assertions follow common SOX practice and the structure of PCAOB AS 2201, as described in secondary summaries. PCAOB standards are primary documents that were not opened for this guide. The example controls are teaching illustrations, not extracted from any company, and contain no thresholds or sample sizes because those are company decisions.
How to read the tables
- Assertion is what the control protects. Common ones: existence or occurrence (it happened), completeness (all of it is recorded), accuracy and valuation (right amount), cut-off (right period), rights and obligations, and presentation.
- Type: preventive (stops an error) or detective (finds it afterwards).
- Nature: manual, automated or IT-dependent manual (a person uses a system report).
- Frequency: how often it runs.
Key controls from automated systems still depend on ITGCs. See SOX ITGC testing.
Order-to-cash example rows
| ID | Risk | Control | Assertion | Type / nature | Frequency | Evidence |
|---|---|---|---|---|---|---|
| O2C-01 | Orders accepted from customers not approved or beyond credit limit | System blocks sales orders over the customer's credit limit; release needs credit manager approval | Occurrence, valuation | Preventive, automated plus manual release | Each order | Credit block log, release approvals |
| O2C-02 | Prices or terms differ from the approved price list | Price master changes need approval; system uses master price on orders | Accuracy | Preventive, automated | Each change | Change approvals, master data log |
| O2C-03 | Revenue recorded without delivery | Invoice is generated only after goods issue or delivery confirmation | Occurrence, cut-off | Preventive, automated | Each shipment | System configuration, sample of delivery and invoice records |
| O2C-04 | Shipments not invoiced | Monthly report of goods issued but not invoiced is reviewed and cleared | Completeness | Detective, IT-dependent manual | Monthly | Report, reviewer sign-off, clearing entries |
| O2C-05 | Revenue recorded in the wrong period | Month-end cut-off review of shipments around period-end | Cut-off | Detective, manual | Monthly | Review checklist, adjustments |
| O2C-06 | Credit notes issued without authority | Credit notes above approval limit need senior approval before posting | Occurrence, valuation | Preventive, manual workflow | Each credit note | Approval trail |
| O2C-07 | Customer receipts misapplied or unapplied | Cash receipts are matched to invoices; unapplied cash is reviewed | Accuracy, existence | Detective, IT-dependent manual | Weekly or monthly | Unapplied cash report, review evidence |
| O2C-08 | Receivables overstated, doubtful balances not provided | Ageing is reviewed and the bad debt provision approved by finance head | Valuation | Detective, manual | Quarterly | Ageing, provision workings, approval |
| O2C-09 | Subledger does not agree to the ledger | Receivables subledger to general ledger reconciliation reviewed | Completeness, accuracy | Detective, manual | Monthly | Signed reconciliation |
For a fuller O2C checklist from an internal audit angle, see O2C internal audit checklist.
Procure-to-pay example rows
| ID | Risk | Control | Assertion | Type / nature | Frequency | Evidence |
|---|---|---|---|---|---|---|
| P2P-01 | Purchases made without authority | Purchase requisitions and orders need approval by delegated authority limits before release | Occurrence | Preventive, automated workflow | Each order | Approval log, authority matrix |
| P2P-02 | Fictitious or duplicate vendors | New vendor and bank detail changes need independent approval and verification | Occurrence | Preventive, manual | Each change | Vendor form, verification evidence, change log |
| P2P-03 | Paying for goods not received or not ordered | System three-way match of order, goods receipt and invoice; exceptions blocked until resolved | Occurrence, accuracy | Preventive, automated | Each invoice | Match configuration, blocked invoice log |
| P2P-04 | Duplicate invoices paid | System duplicate-invoice check on vendor and invoice number | Occurrence | Preventive, automated | Each invoice | Configuration, duplicate report |
| P2P-05 | Liabilities understated: goods received not invoiced | Month-end review of goods received but not invoiced and accrual posted | Completeness, cut-off | Detective, IT-dependent manual | Monthly | Report, accrual journal, review sign-off |
| P2P-06 | Payments released without authority | Payment run proposal reviewed and approved; bank release needs a second authoriser | Occurrence, accuracy | Preventive, manual | Each run | Payment proposal, approvals |
| P2P-07 | Payments to wrong bank accounts | Payment file bank details agreed to the vendor master before release | Accuracy | Detective, IT-dependent manual | Each run | Comparison evidence |
| P2P-08 | Payables subledger differs from the ledger | Payables to general ledger reconciliation and vendor statement reconciliation for key vendors | Completeness, accuracy | Detective, manual | Monthly | Signed reconciliations |
| P2P-09 | Segregation of duties conflicts (create vendor and approve payment) | Role design and periodic conflict review | Occurrence | Preventive and detective | Quarterly or as set | Conflict report, mitigations |
See also the P2P internal audit RCM checklist.
Writing a good control description
A common failure is a vague row. Compare:
- Weak: "Finance reviews receivables."
- Better: "The AR manager reviews the ageing report each month, investigates balances in the oldest bucket and proposes provisions; the finance head approves the provision."
A good description names who, what, when, what they look at, what they do with exceptions and what evidence is left. A tester should be able to repeat the test from the description alone.
Mapping a control to the risk
Before listing a control as key, ask:
- Which financial statement line and assertion does it protect?
- Is it precise enough to catch a material error?
- What would happen if it failed?
- Is there another control covering the same risk, making this one redundant?
Keep the key control list lean. Too many "key" controls spread testing thin. How to test them is covered in walkthroughs and testing.
You can build an RCM in the RCM builder.
Frequently Asked Questions
What makes a control "key"?
A control is key when it is relied on to address a significant risk of material misstatement, and no other control covers that risk as well.
Are these rows ready to use?
No. They show the format and the thinking. Real RCMs depend on the company's systems, structure and risks.
What is the difference between preventive and detective controls?
Preventive controls stop an error before it happens, like a system block. Detective controls find it afterwards, like a monthly reconciliation.
Do IT-dependent manual controls need extra testing?
Yes. The person's review and the report used in the review both need testing. Confirm the report is complete and accurate.
Related Articles
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error