The difference between manual and automated internal controls comes down to who or what performs them: a manual control depends on a person taking an action — reviewing, approving, counting, signing off — while an automated control is executed by a system running pre-configured logic. That single distinction shapes almost everything else that matters about them: how consistently they operate, how well they scale, what they cost to run, how auditors test them, and what happens when they break. Most companies use both, along with hybrid controls that combine system-generated data with human review.
What a Manual Control Is
A manual control is any procedure that works only if a person carries it out. A warehouse supervisor conducting a physical inventory count is running a purely manual control. So is a finance director who reviews and approves journal entries above a set dollar threshold before they post, or a manager who signs off on a wire transfer before it’s released.
The strength of a manual control is judgment. People can weigh ambiguity, notice patterns that no rule would catch, and handle non-routine transactions that no one anticipated when the systems were configured. That flexibility is exactly what estimates, complex contract evaluations, and impairment assessments require.
The weakness is just as fundamental. People get tired, skip steps, misread information, and interpret policies inconsistently. A reviewer who rubber-stamps approvals during a busy quarter is technically executing the control but providing no real assurance behind it.
What an Automated Control Is
An automated control is executed by an IT system based on pre-configured rules. Once it’s set up correctly, it runs identically every time without anyone intervening. A three-way match in an ERP system, where the software compares the purchase order, receiving report, and vendor invoice before releasing payment, is the textbook example. System-enforced access rules, like requiring multi-factor authentication, are another.
Automated controls fall into two categories inside the IT environment. IT General Controls, or ITGCs, govern the underlying technology infrastructure: who can change program code, who has access to production systems, how operations are monitored. IT Application Controls, or ITACs, sit inside specific business applications and govern individual transactions — preventing a negative quantity from being entered into inventory, for example, or automatically calculating sales tax on an invoice.
Every automated application control depends on the ITGCs beneath it. If change management is weak, someone could quietly alter the three-way match logic without authorization, and the control would stop working as intended without anyone noticing. That dependency is the single most important idea in automated control design.
IT-Dependent Manual Controls: The Hybrid
In practice, plenty of controls sit between the two extremes. An IT-dependent manual control uses system-generated information as input, but a person makes the final decision. A system generates a report listing user accounts that haven’t been accessed in 90 days; an administrator reviews the list and decides which accounts to disable. The report is automated. The judgment is manual. The control fails if either half breaks — the report could be incomplete, or the administrator could be ignoring it.
These hybrids are everywhere. A manager reviewing a system-generated aging report to decide which receivables to write off is performing an IT-dependent manual control. So is a compliance officer reviewing automated exception reports that flag transactions over a threshold. Management review controls often land in this category too.
How They Differ in Practice
Consistency and Error Profile
An automated control executes identically every time. That’s its greatest strength and a subtle risk. When the logic is correct, the control operates flawlessly across millions of transactions. When the logic contains a defect, or someone misconfigures a table the control relies on, every transaction is affected. The failure is systemic, not random. A manual reviewer might catch 95 errors out of 100 and miss five. A broken automated control misses all 100.
The PCAOB’s auditing standard notes that automated controls “are generally not subject to breakdowns due to human failure,” but conditions that assurance on the integrity of the surrounding IT environment.1PCAOB. AS 2201 – An Audit of Internal Control Over Financial Reporting
Scale and Speed
An automated control handles growing transaction volume without adding staff or time. Double the invoices next year and the three-way match still runs instantly. A manual document-matching process would need more people and more hours. Automated controls also trigger in real time, rejecting a transaction the moment it violates a rule — an attempt to exceed a customer’s credit limit, for instance. Manual controls introduce delay by nature: review queues, approval chains, the time it takes a person to open an email.
Audit Trail
Automated controls produce time-stamped, often immutable logs showing exactly what the system did and when. Proving that a manual control ran requires retained evidence: a signed checklist, an email chain, a notation on a document. That evidence can be lost, misfiled, or fabricated. The quality of the evidence directly affects how much additional testing an auditor needs to perform.
Preventive and Detective Versions of Both
Both manual and automated controls can play either a preventive or a detective role. Preventive controls stop errors before they happen — an automated system rejecting a duplicate invoice, or a supervisor approving a wire transfer before it goes out. Detective controls identify errors after the fact — an automated reconciliation flagging discrepancies, or a manual review of exception reports the next morning.
Preventive controls are generally preferred because they keep errors out of the system to begin with, but detective controls remain critical for catching what prevention missed. A well-designed environment usually pairs automated preventive controls for high-volume screening with manual detective controls, such as management reviews of financial results against expectations, for the judgment-intensive anomalies that no rule set can fully anticipate.
When to Use Which
The choice comes down to two factors: how much judgment the task requires, and how many times it runs.
Manual controls belong where the decision is subjective. Estimating the allowance for doubtful accounts, evaluating whether a complex contract should be recognized as revenue, assessing impairment of a long-lived asset — these involve economic judgment that no rule engine can replicate reliably.
Automated controls belong in high-volume, rule-based transaction streams: payroll calculations, sales tax computation, data validation at point of entry, access management. Anywhere human error in a repetitive process could lead to a material misstatement, automation should be the default if it’s technically feasible.
Hybrid IT-dependent manual controls fill the middle ground, where the system can surface the right information but a person still needs to evaluate it.
Cost Profile
Manual controls are cheap to set up and expensive to sustain. Implementation means writing procedures and training people. Ongoing costs include supervision, performance management, recurring training, and the disruption that comes with turnover. When a key employee leaves and takes institutional knowledge with them, the control’s effectiveness drops until a replacement is fully trained. Cross-training and detailed procedure manuals reduce that risk without eliminating it.
Automated controls carry higher fixed cost upfront: configuration, development, and rigorous testing through a structured development lifecycle to confirm the logic works as intended. Ongoing maintenance means managing patches, operating system updates, and application upgrades through a formal change management process, which is itself a foundational ITGC. The marginal cost per transaction, though, is essentially zero. Once the control is running, it handles its millionth transaction for the same cost as its first.
For organizations evaluating governance, risk, and compliance software to manage their control environment, modern platforms typically range from roughly $7,000 to over $100,000 annually depending on the organization’s size and complexity, with multi-year enterprise implementations running significantly higher.
How Auditors Test Each Type
Manual Controls
Because manual controls depend on people, auditors have to verify that the person actually did what the control requires, and did it consistently throughout the period. That means selecting a sample of transactions and inspecting each one for evidence of execution: a signature, an approval timestamp, a documented review. Auditors also observe employees performing the control and walk through the process with them.
Sample sizes depend on how often the control runs and how much assurance the auditor needs. Common practice calls for roughly 25 items for frequently operating controls, scaling upward as risk rises. A high-risk control may warrant a sample of 60 or more items.
Automated Controls
Because an automated control runs identically every time (assuming no one has changed the code), the auditor’s main job is verifying that the logic is correct and that the system hasn’t been altered. The PCAOB permits a “benchmarking” strategy: the auditor tests the control once to establish a baseline, then in later periods confirms that ITGCs over program changes, access, and operations remain effective and that the control itself hasn’t changed. If those conditions hold, the auditor can conclude the control operated effectively without repeating the full test.1PCAOB. AS 2201 – An Audit of Internal Control Over Financial Reporting
Benchmarking works especially well for off-the-shelf software where the vendor doesn’t allow source code modifications, because unauthorized changes are unlikely. After a period of time, with the length depending on the stability of the IT environment and the consequences of a control failure, the auditor should reestablish the baseline by retesting directly.1PCAOB. AS 2201 – An Audit of Internal Control Over Financial Reporting
The complete transaction logs automated controls produce also open the door to continuous auditing. Auditors can programmatically test the entire population instead of sampling — a significant advantage when the goal is assurance over millions of transactions.
Hybrid Controls
IT-dependent manual controls require both approaches. The auditor tests the system-generated report or data for completeness and accuracy, then samples the human review for evidence that the person actually evaluated the output and took appropriate action. If the automated report feeding the control is unreliable, no amount of diligent human review can make the control effective.
What Happens When Controls Fail
Not every failure carries the same weight. The PCAOB recognizes two levels of deficiency that matter for financial reporting. A significant deficiency is important enough to deserve the attention of those overseeing financial reporting, typically the audit committee, but not so severe that it threatens the reliability of the financial statements as a whole.2PCAOB. Auditing Standard 5 Appendix A – Definitions
A material weakness is more serious. It means there’s a reasonable possibility that a material misstatement in the financial statements would not be prevented or detected on a timely basis.2PCAOB. Auditing Standard 5 Appendix A – Definitions Public companies must disclose material weaknesses.
The manual/automated split shows up clearly in how failures behave. A manual control failure is usually isolated: one reviewer made a mistake or skipped a step during a specific period. An automated control failure can be systemic. If the programmed logic was wrong, or a configuration table was corrupted, every transaction processed through that control is potentially misstated. That systemic risk is why ITGC failures over change management or access security are treated so seriously. A single ITGC breakdown can undermine the reliability of every automated application control that depends on it, which is a scope of damage no single manual control failure can match.