Controls summary
There are hundreds of possible internal controls for an organization to consider. Finding the right fit requires analysis of the organization’s operational activities, scale, and the related risks. The various activities and related risks determine the relevant control types, objectives, and techniques that surface as priorities. After these priorities are identified, organizations can select and establish specific controls to strengthen and protect their governance framework.
The following table summarizes the functional techniques that you can use by its control type and control objective. A functional technique might help with one or more control objectives:
| Functional technique | Control type | Completeness | Accuracy | Existence or ownership | Cut-off | Valuation or presentation |
|---|---|---|---|---|---|---|
Access and permissions | Preventative | X | X | |||
Master data | Preventative | X | X | |||
Document and transaction flow | Preventative | X | X | |||
Workflow | Preventative | X | X | X | ||
Reports | Detective | X | X | X | X | X |
Audit trails | Detective | X | X |
For examples of the wide range of internal control options for the 3 primary accounting workflows, see the following information:
Controls Testing
After you have selected and adopted your internal controls, it's important to identify the appropriate methodology for testing the various control techniques. The control options for the primary accounting workflows have each been assigned a recommended testing method as follows:
A workflow control ensures that transactions are routed correctly, usually through approval steps that are based on pre-defined parameters.
High-level testing steps:
- Understand the baseline: what should the workflow be? Is there a policy in place?
If applicable, inspect the configuration within Intacct to determine that the workflow has been applied.
Test one instance of each approval type. For example, if there are three tiers (no approval below amount X, one approval between amounts X and Y, two approvals above amount Y), then perform one test for each tier. Ensure the transactions flow as expected, as defined in step 1.
Test in a way that reflects how the application is configured. For example, if the same configuration drives the workflow in two entities but with different people, you do not typically need to repeat the testing. However, if the entities use different configurations or configuration tables, you might need to do separate testing.
A configuration control ensures that the system does something in an expected way. This could be validation of a transaction, moving a transaction from one place to another (for example, between interfaces or applications), changing something (for example, in a revaluation), or an automated calculation (for example, a VAT calculation that's based on the product master data).
High-level testing steps:
You can test automated configurable or coded controls in several ways. How you test depends on various factors, including the regulatory environment. The following steps are for general guidance only.
Understand how the configuration should work: what are the expected outcomes? Focus on the things that matter for the purposes of the control. For example, a validation control might require a valid vendor, which matters, and a description with no special characters, which likely doesn't matter for the control framework. In this situation, you only need to test the first characteristic.
Understand the dependencies that exist: which configurations or coded functionality is relied on?
For each variation of the process, test the important control characteristics by simulating the transaction. For example, try to create a transaction that breaks the validation rules to demonstrate that the transaction is blocked. Then change the transaction to work and note that the transaction is successful.
A review control uses information, usually a report, to identify discrepancies or inaccuracies in transactions or balances.
High-level testing steps:
What's sufficient evidence for a review control can vary between regulatory environments? The following steps are for general guidance only.
The key elements of a review control include the control being consistent and repeatable (for example, the threshold of what's "not significant"doesn't change between months) and being evidenced (for example, it's clear to some one who inspects the review that the reviewer completed all the review steps).
Determine the purpose of the control: what kinds of errors, fraud or other problems is the review control supposed to identify? For example, is the control used to find unusual transactions, errors in a spreadsheet calculation, or incorrect assumptions.
Understand the precision to which the control operates. For example, does the control find an error in the amount of 10,000 precise? Is there a threshold below which issues would be ignored?
Understand the source of information: what does the reviewer review? How is the reviewer comfortable with the accuracy of the source? If a report was used, how does the reviewer check that it was run correctly? A review of a manually assembled report is much riskier than a review of a report run straight from a system, although both might need steps to demonstrate the information is complete and accurate.
Understand how expectations are built up. Is this a review of a listing of transactions where every transaction is reviewed and checked? Is this a month-on-month review to identify unusual patterns or trends? How does the reviewer identify unexpected or unusual items for follow up? Evaluate whether this meets the objective set in steps 1 and 2.
Inspect the review and evaluate whether the reviewer correctly identified the items for follow up as defined in step 4.
Evaluate whether the reviewer correctly followed up on and corrected the items for follow up as defined in step 4.
If there's a second level of review, inspect evidence that this review has taken place and what exactly was checked.
As a separate exercise, test the completeness and accuracy of the reports used in the review control to ensure that the reports are correctly designed. This is not the same as step 3, which is concerned with the risk of running the report incorrectly.
A reconciliation control uses two or more sources of information to validate the completeness, accuracy and validity of one or both sources of information.
High-level testing steps:
Determine which source of information is being validated. Is there a source of truth, against which another source of information is being checked? Or are two sources of information being checked against each other, both of which might have the same error, which would then match or be reconciled?
Determine what granularity that the check is being done to. Balance/transaction?
Understand the sources of information. How does the control operator obtain the information? How do they check that the sources are complete and accurate (for example, the reports run correctly)?
Understand if there's a threshold below which differences will be accepted.
Inspect evidence to show that the control operator performed the reconciliation to the expected precision and followed up items above the threshold.
A restricted access control prevents inappropriate users from using certain functions.
High-level testing steps:
Determine the functionality that prevents access.
Understand the roles in Sage Intacct that allow access to that function.
Inspect access listings of the roles that allow access to the function. Evaluate whether the people who have, or have had, access are appropriate.
You might need a historical access report because access can change.
A segregation of duty control prevents users from having certain problematic access combinations.
High-level testing steps:
Determine the list of prohibited access combinations—those business functions that should not be combined.
Understand the roles that allow access to each type of access.
Inspect listings to determine whether there are users who have, or have had, access to the prohibited access combinations during the period being tested.
You might need a historical access report because access can change.
