A control description in auditing is a short, structured narrative that spells out exactly how one business process prevents or catches a financial misstatement: who performs the control, what they do, how often, against what threshold, using which system or report, and what evidence they leave behind. Written well, it lets an auditor test the control without asking a single follow-up question. Written vaguely, it can be flagged as a design deficiency even when the underlying process works fine.
The rest of this guide walks through what to gather before drafting, how to classify the control, the fields the description must contain, how to handle system-generated data, a full worked example, and how to validate the draft before it becomes the governing document auditors rely on.
Gather the Facts Before You Draft
Good descriptions start with reporting, not writing. Before typing anything, pin down which financial statement assertion the control addresses. PCAOB Auditing Standard 2201 groups relevant assertions into five categories: existence or occurrence, completeness, valuation or allocation, rights and obligations, and presentation and disclosure.1PCAOB. AS 2201 – An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements A control that ensures every invoice gets recorded addresses completeness. One that confirms a reported asset actually exists addresses existence. Naming the assertion first anchors every later choice about scope and precision.
Then decide how material the underlying account is. SEC Staff Accounting Bulletin No. 99 makes clear that materiality isn’t just a percentage. The common 5% benchmark has, in the SEC’s words, no basis in accounting literature or the law when used as the sole criterion.2U.S. Securities & Exchange Commission. SEC Staff Accounting Bulletin No. 99 – Materiality Qualitative factors matter too: a small misstatement that flips a profit to a loss, masks an earnings trend, or trips a loan covenant can be material regardless of size. Materiality tells you how much precision the description needs to carry.
Now go to the people who actually do the work. Interview them. Walk the process end to end. Write down the ERP or reporting systems involved, the exact job titles that authorize, execute, and review each step, and the specific reports, logs, and approval forms they produce. Pull prior audit workpapers and process flowcharts so you know where auditors previously found gaps. Assumption-filled descriptions almost always come from skipping this step.
Classify the Control First
The classification you assign changes what your description has to say. Two dimensions matter.
Preventive or Detective
A preventive control stops an error or unauthorized action before it enters the records. A system-enforced approval that blocks purchase orders above a set threshold until a manager signs off is preventive. A detective control catches problems after they’ve happened, like a monthly reconciliation that surfaces discrepancies between two data sources. Most processes need both, and the description should make clear which role this particular control plays, because that determines what “operating effectively” looks like during testing.
Manual, Automated, or IT-Dependent Manual
A manual control relies entirely on human judgment, such as a controller scanning journal entries for unusual amounts. An automated control runs entirely inside a system, such as a three-way match that blocks payment unless the purchase order, receiving report, and invoice all agree. Between them sits the IT-dependent manual control: the system produces a report or exception list, and a person reviews and acts on it. Most SOX environments are full of the third type, and the description has to capture both the system’s output and the human’s response to it.
Write the Core Fields
A control description usually fills a structured template. Each field answers a question an auditor will ask.
Actor and Action
Open with an active verb: reviews, reconciles, approves, generates, verifies. Passive voice (“the report is reviewed”) hides who is responsible and defeats the whole purpose of the document. Name the specific role, not the department. “The Accounts Payable Manager” is testable; “the finance team” is not. This specificity also proves segregation of duties. The person who initiates a transaction should not be the same person who approves or records it, and if your description shows one role doing both, auditors will flag it.
Frequency and Timing
State how often the control runs: daily, weekly, monthly, quarterly. For close-cycle controls, name the exact timing within the cycle, for instance “within five business days of month-end close.” Frequency drives sample sizes. A daily control may be tested against 25 or more instances; a quarterly control may need all four. If the stated frequency doesn’t match what actually happens, the control fails before design is even evaluated.
Thresholds and Criteria
This is where most descriptions fall short. If a manager reviews only expenses above $5,000, the $5,000 threshold belongs in the description. If a reconciliation is considered complete when variances fall below a defined tolerance, state the tolerance. AS 2201 requires that controls operate at a level of precision that would adequately prevent or detect misstatements to relevant assertions on a timely basis.1PCAOB. AS 2201 – An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements A description that says “the manager reviews significant variances” without defining “significant” carries a design deficiency inside the wording itself.
Evidence Produced
Every control has to leave a trail. Name the artifact: a signed reconciliation spreadsheet, an approval stamp inside the ERP, a system-generated exception report with reviewer initials and date. If the description doesn’t identify the evidence, auditors have nothing to test, and the control is effectively undocumented no matter how well it runs in practice.
Handle System-Generated Reports Correctly
Many controls depend on data a system produces, and auditors treat that output as Information Produced by the Entity, or IPE. Under PCAOB Auditing Standard 1105, auditors must either test the accuracy and completeness of that information directly, or test the controls that ensure its accuracy and completeness, including the relevant IT general controls and automated application controls.3PCAOB. AS 1105 – Audit Evidence
So identify every system-generated report the control depends on, by its exact name or report ID. If the control is semi-automated, describe both what the system does and what the person does with the output. For example: “the system generates the Open Items Aging Report (Report #AR-401), and the Revenue Accounting Supervisor reviews all items aged over 90 days for collectibility, documenting resolution in the comments field.”
IT general controls sit underneath all of this. If system access isn’t restricted, an automated block on unauthorized transactions means little, because someone could change the rules. Individual control descriptions don’t need to repeat the full ITGC documentation, but they should reference the access and change-management controls the system relies on. Weak general controls over systems and data can undermine every application-level control that depends on them.
A Complete Example
What the fields look like when they come together:
- Control ID: AP-03
- Assertion: Completeness and accuracy of accounts payable
- Control type: Detective, IT-dependent manual
- Description: The Accounts Payable Manager reconciles the AP subledger to the general ledger monthly, within five business days of month-end close. The ERP system generates the AP Subledger-to-GL Reconciliation Report (Report #AP-220). The AP Manager investigates all variances exceeding $1,000 and documents the cause and resolution for each item in the reconciliation workbook. Variances resulting from timing differences are carried forward with notation. Unresolved variances above $5,000 are escalated to the Assistant Controller for review and approval. The completed reconciliation is signed and dated by the AP Manager and countersigned by the Assistant Controller.
- Frequency: Monthly
- Evidence: Signed AP Subledger-to-GL Reconciliation workbook with documented variance explanations; Report #AP-220
- IPE: Report #AP-220 (accuracy and completeness addressed by ITGC-02, system access controls)
A specific person performs a specific action at a stated frequency, with defined thresholds for investigation and escalation, producing named evidence. An auditor reading this knows exactly what to test and what to look for. Compare it to “Finance reconciles AP monthly and reviews differences,” which tells the auditor almost nothing.
Validate the Draft Through a Walkthrough
Once the description exists on paper, walk it. Take a single transaction and follow it from origination through the systems until it lands in the financial records, using the same documents and technology the process owners use. AS 2201 describes this technique for external auditors, and companies that run the same walkthrough internally, before auditors arrive, catch problems while they can still be fixed cheaply.1PCAOB. AS 2201 – An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements
Discrepancies surface constantly. The description says a supervisor approves; in practice a different role does. The stated threshold changed last quarter. A report name was updated during a system migration and nobody amended the narrative. Every mismatch has to be resolved before the description is finalized, either by rewriting the description or by correcting the process.
After the walkthrough, a departmental supervisor reviews the narrative for accuracy and the control owner signs off. That signature is a formal commitment that the description reflects how the control actually operates. Most organizations capture it electronically in their compliance platform, creating a timestamped record. From that point forward, the description is a governing document that auditors rely on.
Why Weak Wording Alone Can Fail You
A poorly written description can create a design deficiency by itself. If it lacks thresholds, omits the evidence produced, or doesn’t identify who performs the control, auditors may conclude the control isn’t designed to meet its objective, even when the underlying process works. AS 2201 defines a design deficiency as existing when a control isn’t designed so that the objective would be met, even if it operates as designed.1PCAOB. AS 2201 – An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements
The severity ladder above a design deficiency runs from a significant deficiency, which is less severe than a material weakness but important enough to draw the attention of those overseeing financial reporting, up to a material weakness, defined as a deficiency or combination of deficiencies where there is a reasonable possibility that a material misstatement will not be prevented or detected on a timely basis.4U.S. Securities & Exchange Commission. Final Rule – Definition of the Term Significant Deficiency Catching thin wording during interim testing, and rewriting the description before the external auditor sees it, is one of the cheapest fixes in the entire compliance calendar.
Do Smaller Companies Still Need Control Descriptions
Yes. Under 15 U.S.C. ยง 7262(b), emerging growth companies are excluded from the external auditor attestation requirement, and Section 7262(c) extends the same exemption to companies that are neither large accelerated filers nor accelerated filers, generally those with less than $75 million in public float.5Office of the Law Revision Counsel. 15 US Code 7262 – Management Assessment of Internal Controls The exemption covers Section 404(b) only. Section 404(a) still applies, so management at these smaller companies must still assess their own internal controls over financial reporting and include that assessment in the annual report. Control descriptions are still required to support that assessment, and companies approaching the accelerated filer threshold are usually better served building documentation to the full 404(b) standard well before they cross it than retrofitting an entire library under time pressure later.