Most of the controls that matter in a modern finance process are not performed by people. The three-way match that stops an invoice from paying against a short receipt, the tolerance that blocks a price variance, the workflow that routes a journal above a threshold to a second approver, the posting-period lock, the credit limit, the depreciation run: each is a rule configured in a system, operating hundreds of times a day without anyone watching. Auditors trained on manual controls approach these badly in one of two directions. Some sample forty invoices, find the match “worked” in all forty, and conclude, which tests nothing the rule could have got wrong. Others declare the control “IT” and leave it to a specialist who never arrives. The method in this guide is the third way: understand exactly where the rule lives, prove it is configured as described, prove the configuration has not changed, test it once properly, and let the IT general controls carry the rest of the year.
This is a non-IT auditor’s method. It sets out the seven types of automated control and where their logic lives, explains why a single well-designed test can support a conclusion for a whole period and exactly when it cannot, gives the four ways to test a configuration and the evidence standard for each, walks through the method step by step with a configuration test workpaper template, lists the configuration items that matter most in each financial cycle, and works three examples at MidState Beverage, a drinks distributor whose ERP override workflow turned out to let the requester approve their own override. It relies on two companion guides: ITGC versus application controls, which explains the dependency this method exploits, and how to audit IT change management, which is where that dependency is tested.
In this guide
- The seven types of automated control, and where the logic lives
- Why one good test can cover a year, and when it cannot
- The four ways to test a configuration
- Evidence standards: what a configuration screenshot has to show
- The method, step by step
- The configuration test workpaper template
- The configuration items that matter, by financial cycle
- Interfaces and scheduled jobs: the automated controls nobody lists
- Three worked examples at MidState Beverage
- When the configuration is wrong: evaluating what you found
- Common mistakes
The seven types of automated control, and where the logic lives
An automated control is a control whose operation is performed entirely by a system according to configured or programmed logic, without human judgment at the point of operation. The category is broad, and the first job in any test is to name which type you are dealing with, because the type tells you where the logic lives and therefore what to inspect. The table gives the seven types found in nearly every financial system. The eighth row is not an automated control at all but is constantly confused with one: the IT-dependent manual control, where a system produces a report and a person acts on it. That control is tested as a manual control plus the completeness and accuracy of the report, and mixing the two up is the most common design error in SOX control matrices.
| Type | Example | Where the logic lives | How it fails |
|---|---|---|---|
| Calculation | Depreciation run; route settlement computation; interest accrual; tax calculation | Program code or calculation rules plus master data parameters (rates, methods, useful lives) | Wrong parameter; changed formula; master data edited outside change control |
| Matching | Three-way match of purchase order, receipt and invoice; bank statement auto-reconciliation | Matching rules, tolerance settings, exception routing configuration | Tolerance widened; matching switched off for a vendor class; exceptions auto-cleared |
| Validation and edit checks | Required fields on vendor master; duplicate invoice check; valid account combinations | Field-level configuration, validation rules, table constraints | Validation disabled; duplicate check limited to exact matches; rule bypassed by an interface |
| Workflow and routing | Journal above a threshold routed to controller; purchase requisition approval chain; override approval | Workflow definitions, approval matrices, threshold tables, delegation settings | Threshold raised; requester allowed to approve; delegation left permanently active |
| Limits and tolerances | Credit limit block; price variance tolerance; payment run maximum; posting period lock | Parameter tables and period control settings | Limits set high enough never to trigger; period reopened without control |
| Interfaces and transfers | Sub-ledger to general ledger posting; payroll file to bank; sales system to ERP | Interface mappings, scheduling, completeness and error handling configuration | Records dropped silently; error queue never cleared; mapping change misposts |
| System-enforced access and segregation | Only the treasury role can release payments; a user cannot both create and approve a vendor | Role and permission configuration; SoD rule sets | Roles expanded; emergency access left in place; rule set not maintained |
| IT-dependent manual control (for contrast) | Controller reviews the system-generated aged receivables report and posts an allowance | Report logic (system) plus a human review (manual) | Report incomplete or wrong (IPE failure) or review perfunctory (manual failure) |
Why one good test can cover a year, and when it cannot
A manual control is sampled because people are inconsistent: the reviewer who was diligent in March may have been rushed in September. An automated control is not inconsistent. Given the same configuration, it produces the same result every time, so the question is not “did it operate correctly on forty occasions” but “was the configuration correct, and did it stay that way for the period.” The first part is answered by a test of design and implementation: inspect the configuration, and test one instance to prove the configuration does what the description says. The second part is answered by the IT general controls: if change management prevents unauthorized changes to the configuration and access controls prevent unauthorized changes through the front door, and both have been tested for the period, the configuration you inspected in October is the configuration that operated in February. That is the logic behind what practitioners call a test of one, and it is sound only as a whole; the single test without the ITGC reliance is a test of design with no evidence of operation over the period.
PCAOB AS 2201 makes the dependency explicit in two places. Paragraph 47, among the factors affecting the risk of a control, notes that an automated control would generally be expected to be lower risk if relevant IT general controls are effective. Appendix B, paragraphs B28 to B33, describes the benchmarking strategy for subsequent years: if general controls over program changes, access to programs and computer operations are effective and continue to be tested, and the auditor verifies that the automated control has not changed since the baseline was established, the auditor may conclude that the control continues to be effective without repeating the prior year’s specific tests. The appendix adds that the baseline should be re-established after a period whose length depends on circumstances, and that benchmarking is especially effective for purchased software where program changes are remote. The table turns that logic into the testing decision an internal auditor actually faces, which depends on what the ITGC work found.
| ITGC status for the system | What a single configuration test supports | What else is needed for a period conclusion |
|---|---|---|
| Change management and access effective, tested for the period; configuration change history available and clean | Design and operating effectiveness for the period | Nothing beyond the configuration change history check |
| ITGCs effective; configuration changed during the period through the controlled process | Effectiveness from the change date; design of the previous version from the change record | Test the previous configuration from the change record or evidence of its operation before the change |
| Change management effective; access control deficient (privileged users could edit configuration) | Design only | Test the configuration at several points across the period, or analyze outputs for the whole period to show the rule held |
| Change management deficient (unauthorized changes possible) | Design only | Output analysis for the full period, or direct testing of multiple instances across the period; benchmarking unavailable |
| Prior-year baseline exists; ITGCs effective this year; no change to the control | Benchmarking: continued effectiveness without repeating the instance test | Verification that the control has not changed (compilation or configuration dates); baseline re-established periodically |
The bottom two rows are where auditors get into trouble. When the change-management audit finds unauthorized changes reaching production, the automated controls in that system cannot be relied on for the period on the strength of a single test, and the shortfall has to be made up with period-wide evidence. The good news is that period-wide evidence is often cheap for automated controls: a query over every invoice paid in the year showing none exceeded the tolerance without an approval is a complete test of the rule, not a sample, and takes an afternoon. The accounts payable analytics catalog and the journal entry analytics guide are full of tests that double as period-wide evidence for automated controls.
The four ways to test a configuration
There are four methods, and a good test usually combines two. Inspection of the configuration proves what the rule is set to. Re-performance proves that the rule, as set, produces the right answer for a real transaction. Test data proves what the rule does at its boundaries, including the cases that never occur in production. Output analysis proves, across the whole period, that the rule’s effect is visible in the data. Inspection alone is the weakest, because a parameter can be set correctly and ignored by the program that is supposed to read it; output analysis alone is the strongest for operating effectiveness but says nothing about why the rule worked. The table sets out when each is the right choice.
| Method | What it proves | Best for | Evidence produced | Limits |
|---|---|---|---|---|
| Configuration inspection | The rule is set as described, in the production system, at the date of inspection | Tolerances, thresholds, required fields, period locks, workflow routing, role definitions | Screenshots or table extracts meeting the evidence standard below; change history of the item | Does not prove the program honors the setting; a snapshot in time |
| Re-performance | For a real transaction, the system’s result equals the result the rule should produce | Calculations, matching, interface postings | Independent recalculation with inputs and comparison; one or a few instances | Proves the instances tested; relies on ITGCs for the period |
| Test data in a controlled environment | Behavior at the boundaries: exactly at tolerance, just above, negative, zero, duplicate | Validation rules, limits, workflows whose triggering cases are rare in production | Test cases, expected and actual results, evidence the test environment configuration equals production | Requires a test environment proven to match production; never run in production without a reversal plan |
| Output analysis | Across the whole period, no transaction escaped the rule | Period-wide evidence when ITGCs are weak; high-volume controls | Query logic, population completeness, results (ideally zero exceptions), investigation of any hits | Absence of exceptions could mean the rule never triggered; combine with a boundary test |
A practical pairing for most controls is inspection plus one re-performed instance, backed by the change history of the configuration item. For workflows and validations whose failure case rarely occurs in production, the invoice exactly at tolerance, the journal exactly at the threshold, add a test-data case in the test environment after proving that environment’s configuration matches production for the item in question. For any system whose ITGCs are doubtful, add output analysis for the period. Whatever the combination, the selection of the instance is the auditor’s, not the system owner’s, and the instance is chosen to exercise the rule rather than to pass it.
Evidence standards: what a configuration screenshot has to show
Configuration evidence fails review for predictable reasons: the screenshot could have come from any system, any environment, any date; the parameter shown is not the one that governs the transaction; the extract was edited in a spreadsheet before it reached the file. The standard below is the one to hold every item to, and it is the same standard the audit evidence guide applies generally. Where the evidence is a table extract rather than a screen, it is information produced by the entity and the IPE questions apply: who ran the query, what were the parameters, can the auditor re-run it, and does the row count reconcile.
- System and environment identification. The system name and the environment or client (production, not test) visible on the screen or in the extract header.
- Date and time. The system date and time captured on the screen or in the extract, not added afterwards.
- User. Who was logged in when the evidence was captured, preferably the auditor observing, or a named system owner.
- Navigation path. The menu path, transaction or table that holds the parameter, so a reviewer can find it again and so it is clear this is the governing setting rather than a display copy.
- Full screen, uncropped. Cropping removes the identification and invites the question of what was cut off.
- The parameter and its scope. The value, and the organizational scope it applies to: company code, plant, vendor group, document type. A tolerance set for one company code says nothing about the others.
- Change history of the item. When the value was last changed, by whom, and under what change record; this is the link to change management and the basis for the period conclusion.
- Baseline reference. Where a baseline exists from a prior year, the comparison of current to baseline values.
The method, step by step
The method has eight steps, and the first three are done before anything is inspected. Most failed automated-control tests failed at step one or two: the control was never described precisely enough to know what to look for, or the auditor inspected a parameter that was not the one governing the transaction. The control description guide covers the first step in depth; a description that names the system, the rule, the parameter and the scope is the map for everything that follows.
| Step | What to do | Output | Where it goes wrong |
|---|---|---|---|
| 1 Describe the control precisely | From the walkthrough, write what the system does, to which transactions, under what condition, with what result, and where the rule is configured | Control description naming system, rule, parameter, scope and outcome | “System performs three-way match” with no tolerance, scope or exception handling stated |
| 2 Locate the logic | With the system owner or administrator, identify the exact configuration item, table or program that governs the rule, and any master data it depends on | Navigation path; list of dependent parameters | Inspecting a display setting or a report parameter rather than the governing rule |
| 3 Establish ITGC status | Determine from the ITGC work whether change management and access are effective for this system and period | Reliance decision per the table above | Assuming ITGCs are fine because nobody said otherwise |
| 4 Choose the methods | Select inspection plus re-performance, test data or output analysis according to the control type and ITGC status | Test approach in the workpaper | Sampling forty passing transactions and calling it a test |
| 5 Obtain configuration evidence | Capture the governing configuration to the evidence standard, in production, with the auditor present | Screens or extracts with identification, date, user, path, scope | Screenshots emailed by the system owner with no identification |
| 6 Test the instance | Select a transaction, or construct a boundary case, and prove the rule produced the described result | Re-performance or test-case record with expected and actual outcome | Letting the owner pick a transaction that obviously passes |
| 7 Test the change history | Obtain the change log for the configuration item for the period; trace any change to an authorized change record; confirm the value was the same throughout or evaluate each version | Change history with tracing | Not asking; discovering later that the tolerance was raised for a month |
| 8 Record the baseline | Document the tested values so next year’s test can start from the comparison | Baseline entry in the workpaper | Re-inventing the test every year at full cost |
The configuration test workpaper template
The workpaper is one page per control, and it follows the eight steps. It is deliberately more specific than a generic test sheet because the specific fields are the ones reviewers ask about. The workpaper example shows the layout conventions the template assumes, and the risk and control matrix template is where the control description in step 1 comes from.
Automated control test. Control reference: ________ System and environment: ________ Prepared by: ________ Date: ________ Reviewed by: ________ Date: ________
1. Control description. [System, rule, transactions covered, condition, result, exception handling, and the configuration item that governs it.]
2. Control type. [Calculation / matching / validation / workflow / limit / interface / access. If a report plus review, stop: test as an IT-dependent manual control.]
3. Governing configuration. [Navigation path or table; parameter names; organizational scope; dependent master data.]
4. ITGC reliance. [Status of change management and access for this system and period, with workpaper reference; resulting test approach.]
5. Configuration evidence. [Reference to captured screens or extracts; confirmation each meets the evidence standard: system, environment, date, user, path, scope, uncropped.]
6. Instance test. [Transaction or test case selected by the auditor; inputs; expected result per the description; actual result; conclusion.]
7. Change history for the period. [Changes to the configuration item from ________ to ________; each traced to an authorized change record or evaluated as an exception; conclusion on constancy.]
8. Period-wide evidence (where required). [Output analysis query, population, results, investigation of exceptions.]
9. Baseline. [Values recorded for comparison next period; date baseline established.]
10. Conclusion. [Design effective / not effective; operating effectively for the period / not; exceptions and their evaluation reference.]
The configuration items that matter, by financial cycle
Every ERP has hundreds of configuration items; perhaps thirty of them decide whether the financial statements can be relied on. The table lists the ones that recur in SOX programs and internal audit control matrices, by cycle, with the question each test has to answer. It is a starting inventory, not a complete one, and the right list for a given organization comes from its own risk and control matrix. The cycle guides on this site, accounts payable, payroll, revenue recognition and journal entries, describe the processes these items sit inside.
| Cycle | Configuration items | The question to answer |
|---|---|---|
| Purchase to pay | Three-way match activation by vendor and document type; price and quantity tolerances; duplicate invoice check parameters; vendor master required fields and bank-detail change workflow; payment run limits and approval; purchase order approval matrix | Can an invoice pay without a receipt, above tolerance, twice, or to a bank account nobody approved? |
| Order to cash | Credit limit checks and blocks; pricing condition maintenance rights; discount and rebate limits; revenue recognition triggers (goods issue, invoice, milestone); automatic dunning parameters | Can a sale ship over credit limit, at an unauthorized price, or be recognized before the trigger? |
| Record to report | Posting period open and close control; journal approval thresholds and workflow; automatic account determination; foreign exchange rate source and update; intercompany matching rules; sub-ledger to ledger reconciliation settings | Can a journal post to a closed period, above threshold without approval, or to the wrong account by design? |
| Fixed assets | Depreciation keys, useful lives, capitalization thresholds, asset class account assignment | Is depreciation calculated on the parameters the policy states? |
| Payroll and HR | Pay rate change approval workflow; overtime and premium rules; tax jurisdiction tables; bank file generation and approval; termination processing rules | Can a rate change, an overtime rule or a bank detail change take effect without the designated approval? |
| Inventory | Cycle count tolerances and posting; standard cost update rights; goods movement types and their account determination; negative stock allowance | Can inventory value change without an approved cost update or a counted variance? |
| Treasury | Payment release limits and dual control; bank account master change workflow; interface to banking platform with file integrity checks | Can a payment leave the company on one person’s authority or to an account changed without approval? |
| Cross-cycle | Segregation of duties rule set and its enforcement; emergency access settings; interface error handling and completeness checks; audit trail activation on key tables | Are the enforcement mechanisms themselves configured and switched on? |
Interfaces and scheduled jobs: the automated controls nobody lists
Two kinds of automated control rarely appear in control matrices and account for a disproportionate share of the misstatements that automated controls are supposed to prevent. The first is the interface: the nightly transfer of sales from the point-of-sale or route system into the ERP, the payroll file to the bank, the sub-ledger posting to the general ledger. An interface is a chain of automated steps, extraction, transformation, transfer, load and posting, and it fails in a characteristic way: records are dropped or rejected, the rejection lands in an error queue, and nobody clears the queue. The control is not the interface running; it is the completeness check that reconciles what left the source to what arrived at the destination, and the error-handling routine that forces rejected records to be resolved. Testing it means inspecting the completeness control’s configuration (record counts, hash totals, control totals), re-performing one reconciliation, and, for the period, examining the error queue and its clearance history. An error queue with items older than a few days is the interface equivalent of a bank reconciliation with unexplained reconciling items.
The second is the scheduled job: the depreciation run, the month-end allocation, the settlement batch, the dunning run, the interest accrual. Each is a calculation control that operates on a schedule, and its failure mode is silence: the job does not run, or runs partially, and the absence is not noticed until a balance looks wrong. The controls are the job schedule itself, the monitoring of completion and failure, and the re-run procedure. Testing them is a small ITGC exercise inside the application audit: inspect the schedule for the in-scope jobs, obtain the job history for the period, examine every failure and its resolution, and confirm that a failed financial job cannot be silently skipped. Both interfaces and jobs sit at the boundary between this guide and the ITGC primer, which treats computer operations as a domain; in practice the auditor testing the application controls is the one best placed to notice that the settlement batch failed twice in August and nobody re-ran it.
Three worked examples at MidState Beverage
MidState Beverage distributes drinks across three states from twelve depots and three hundred routes, on an ERP with a route-accounting module installed in 2013. Its six-person audit function has no dedicated IT auditor; the analytics and IT auditor, with the senior who led the FY27 route cash engagement, tested three automated controls during that engagement and the ICFR support engagement that followed. The three illustrate the three outcomes a configuration test can have: a control that works as described, a control whose configuration is wrong by design, and a calculation that is right but whose ITGC dependency failed. The FY27 plan and the route cash report referenced here are described in full elsewhere on this site.
The first was the three-way match tolerance on supplier invoices. The control description, rewritten at step 1, read: the ERP blocks any supplier invoice for payment where the invoice price exceeds the purchase order price by more than 5 percent or 250 dollars, whichever is lower, for all company codes, and routes blocked invoices to the purchasing manager for release. Step 2 located the tolerance keys in the invoice verification configuration; step 3 confirmed that change management over the ERP had been tested in the same engagement with the results described in the change management guide, which meant ITGC reliance was not available for the period. The team therefore combined inspection, a re-performed instance and output analysis. The configuration showed 5 percent and 250 dollars, scoped to all company codes, last changed in 2019 under a documented project. The auditor selected an invoice from the period with a 312-dollar variance and traced it to the block and the purchasing manager’s release. The output analysis ran over all 22,400 invoices paid in the nine months: none had been paid with a variance above tolerance without a release record. The control was concluded effective for the period on the strength of the output analysis, with the configuration inspection and instance test as design evidence.
The second was the override approval workflow in the route-accounting module, which was supposed to route every settlement override to a depot manager for approval. Step 1 produced a description that the system owner could not complete: nobody could say what the routing rule was, only that “overrides go to the manager.” Step 2 found the workflow definition. Its routing rule sent the override to the depot manager role, and the requester’s own account was excluded from approving only if the requester was not also assigned that role. Eleven depot managers processed their own overrides as a matter of routine, and the configuration allowed them to approve them. The test-data case in the test environment, after confirming the workflow configuration matched production, showed a depot manager creating and approving an override in under a minute. Output analysis then quantified it: 1,412 of 37,400 overrides in the period had been approved by their own requester. This was a design deficiency, not an operating failure; the control had operated exactly as configured, and the configuration was wrong. It became finding two of the route cash report, rated High.
The third was the route settlement calculation itself, the program that computes each driver’s cash due from deliveries, returns, discounts and collections. The auditor re-performed one settlement in full from source documents and matched the system to the cent; the calculation logic was correct on the day. The change history, however, showed a change to the discount handling routine during the period that had no ticket, one of the six direct data and program changes the change-management test had found. The re-performed instance post-dated the change; the pre-change version could not be reconstructed. The team’s period conclusion therefore rested on output analysis: recomputing the discount element for every settlement in the period from the price and discount tables and comparing to the system’s figure. The recomputation matched for all but a nine-day window in which the rounding of multi-line discounts differed by a few cents per settlement, which the finance team had been correcting manually without knowing why. The calculation was concluded effective except for the window, and the finding was written against change management rather than the calculation.
| Control | Type | Methods used | Configuration finding | Period conclusion |
|---|---|---|---|---|
| Three-way match tolerance | Matching with limit | Inspection; one re-performed instance; output analysis over 22,400 invoices | Configured as described; unchanged since 2019 | Effective for the period (output analysis) |
| Override approval workflow | Workflow and routing | Inspection; test-data case; output analysis over 37,400 overrides | Routing rule allowed requester to approve when holding the manager role; 1,412 self-approvals | Design deficient; finding rated High |
| Route settlement calculation | Calculation | Re-performance of one settlement; change history; output recomputation for the period | Correct at test date; unauthorized change to discount routine mid-period | Effective except for a nine-day window; finding written against change management |
When the configuration is wrong: evaluating what you found
A configuration finding has a property manual-control findings lack: it tells you exactly which transactions were affected, because the rule applied to all of them. That makes the evaluation more precise and more consequential. A tolerance set at 15 percent instead of 5 percent for the whole year means every invoice with a variance between 5 and 15 percent paid without review, and the exposure can be computed from the data rather than extrapolated from a sample. The deficiency evaluation guide sets out the severity logic; the specific step for automated controls is to quantify the affected population before rating, because the quantification usually settles the rating. Three further points. A design deficiency in configuration is a deficiency for the whole period the configuration was in place, whether or not the failure case occurred; the override workflow was deficient from the day it was configured. Where the configuration is right but its change history is dirty, the finding belongs to change management and the automated control is evaluated on the period-wide evidence. And where the configuration is right, the instance test passes and the ITGCs are effective, the control is effective, and the auditor should resist the reviewer who asks for forty more samples; the design versus operating effectiveness guide is the reference for why that request misunderstands the control.
Common mistakes
- Sampling an automated control like a manual one. Forty passing invoices prove the rule triggered forty times; they do not prove it is set correctly or that it held all year.
- Testing a display setting instead of the governing rule. Locate the parameter the program reads, with the administrator, before capturing anything.
- Ignoring scope. A tolerance for one company code or vendor group is not a control over the others.
- Skipping the ITGC question. Without effective change management and access, the single test is design evidence only.
- Accepting screenshots by email. Capture configuration in production with the auditor present, uncropped, with system, environment, date, user and path visible.
- Letting the owner choose the instance. Select a transaction or build a boundary case that exercises the rule.
- Not pulling the change history. The value today is not the value in February unless the change log says so.
- Confusing IT-dependent manual controls with automated controls. A report plus a review is tested as a manual control and as IPE.
- Running test data in production. Use a test environment proven to match, or use output analysis.
- Forgetting the baseline. Record the tested values so next year’s test is a comparison, not a rediscovery.
Related guides
- ITGC vs application controls: the dependency everyone gets backwards
- How to audit IT change management
- IT general controls: the complete primer
- IPE: testing information produced by the entity
- Test of design vs. operating effectiveness
- How to write a control description
- Audit evidence
- Control deficiency evaluation
- Accounts payable analytics
- Journal entry analytics
- The risk and control matrix template
- SOX ITGC scoping
- RCM Workbench
Leave a Reply