Understanding internal controls in processes
You may have a wealth of knowledge about internal controls, but there can be pieces that slip through the cracks. For a familiar, or even seasoned public accounting professional, a quick review of internal control basics may shed light on new information that could impact and improve your processes.
This blog post by Preben Ormen outlines a high-level overview of internal controls.
When we try to understand something important about our business processes, sooner or later we have to consider the presence or absence of adequate internal controls and what to do about any gaps.
I have found that outside the public accounting profession most people do not really understand controls because this is not something that is taught much outside of public accounting.
The good news is that this is not that hard to get on top of - I know that because I have taught this to several teams over the years with good results. Since I am delving deeply into the meta-structure of processes I reviewed some of my old material on controls and thought I'd clean it up a little and post a review here.
Definition of internal controls
Internal control is broadly defined as a process, put in place by an organization’s board of directors, management, and other personnel, designed to provide reasonable assurance regarding the achievement of objectives in the following categories:
- Effectiveness and efficiency of operations
- Reliability of financial reporting
- Compliance with applicable laws, and regulations
Internal controls provide reasonable assurance that:
- Business objectives are met in a timely manner without undue expenditure of resources
- Transactions are recorded as necessary to permit preparation of financial statements in accordance with generally accepted accounting principles
- Unauthorized acquisition, use, or disposition of the organization’s assets that could have a material effect on the financial statements are prevented or detected in a timely manner
- No applicable laws or regulations are broken
What are controls?
Controls are specific activities that mitigate or eliminate certain risks or threats. Risks refer to the possibility or exposure to a chance of danger, harm, loss, or injury. Threats refer to indications of impending danger or harm.
Stated another way, risks and threats are simply all the ”what can go wrongs” we are exposed to.
Some “what can go wrongs” examples are:
- Something is initiated (started) that shouldn't be
- Something is authorized that shouldn't be
- Something is recorded that shouldn't be
- Something is recorded inaccurately
- Something is reported that shouldn't be
- Something is given a value that it shouldn't be
- Liabilities or commitments are assumed that shouldn't be
- Errors are made
Activities vs. controls
Activities and controls are frequently confused with each other. Just because an activity is important, even essential, that doesn’t make it a control.
The distinctions are:
- An activity is something (anything) done or performed—a deed of some kind
- A control is something done for the specific purpose of mitigating a risk or threat
- A control is “an activity with a mission”
- A control implies an act of checking or verifying something against something else (e.g., against independent information, a policy, a standard)
It is important, even essential, that all pertinent information is recorded on a PO (purchase order), but this is not a control.
A control would be:
- Definition of mandatory fields in the PO screen and forcing all mandatory fields to be filled in before saving the transaction (automated control)
- Review of POs for completeness and accuracy of mandatory information (manual control)
- A control ensures that important activities actually take place as intended
- Plan to report (a finance/accounting process)
- System will not allow duplicate journal entry numbers
- Bank accounts are reconciled on a regular basis
- Hire to retire (an HR process)
- Access to data and transaction files is appropriately restricted
- Supervisors review rate changes to the payroll master file
- Procure to pay (a supply chain process—inbound logistics)
- Vendor invoices are checked and authorized before posting
- System matches PO, receiving and invoice entries (3-way) before vendor payments are initiated
- Plan to fulfill (a demand chain process—outbound logistics)
- Contract and/or quotation terms are reviewed and documented and unique terms are considered before signing contracts or accepting quotations
- Specialists review completeness and accuracy of planning and forecasting estimates
- Order to cash (sales process)
- Authorized personnel approve overrides of the price master before posting
- Supervisors must approve voiding of POS (point-of-sale) transactions
A simple control checklist
The following questions are helpful in determining if an activity is a control activity:
- Without the activity would a significant likelihood of a control deficiency or weakness exist in the cycle/process?
- Is this activity relied upon to ensure completeness, e.g., in the processing of a transaction or of the flow through a process?
- Is the activity relied upon for appropriate segregation of duties or restriction of access to systems, facilities or assets?
- Is this activity relied upon for approval, validation or review?
- Is this activity relied upon to detect deviations/exceptions from the designed process?
- Is this an activity related to the initiation and processing of non-routine and non-systematic transactions?
- Is this an activity related to prevention or detection of errors or irregularities due to fraud?
- Is this an activity that directly impacts a material account or disclosure?
- Is this an activity related to prevention or detection of a material misstatement?
- Is the activity relied upon to meet the control objective(s) (i.e. if this control fails, is there a significant likelihood of the process being compromised)?
Internal control assertions
Control assertions define how the control activity mitigates or minimizes the identified risks or threats. For each identified control, we usually want to identify the applicable assertion about the control:
- C – Completeness: All recorded transactions are accepted by the system (once and only once), and any transactions that are rejected are addressed and fixed. Completeness also ensures that transactions are entered and accepted for processing in the proper time period.
- A – Accuracy: Key data elements (including master data) for transactions recorded and input to the computer are reasonably correct. Changes to master data are accurately input.
- V – Validity: Transactions, including changes to master data, are not fictitious, relate to the business, and are authorized.
- R – Restricted access: The organization is protected against unauthorized amendments of data to ensure confidentiality of data and segregation of duties. Company assets are physically and logically protected from theft and misuse.
Every transaction type will need controls that cover all assertions and a control can satisfy more than one assertion.
The mnemonic for the internal control assertions is CAVR pronounced like caviar.
Internal control types
There are two basic control types: Preventive or Detective
Preventive controls stop errors from occurring (e.g., supervisor review of journal entry/purchase order, automated input edit controls) and are designed to prevent fraud or misappropriation of assets. They typically occur before a transaction or event has been recorded (or committed) in a system of record.
Detective controls identify errors after they occur (e.g., reconciliations, validation of results), and are designed to monitor the achievement of the relevant control objectives, including identifying occurrences of fraud or misappropriation of assets. They typically occur after a transaction or event has been recorded (or committed) in a system of record.
Note: Preventive controls are generally considered stronger than detective controls.
Internal control methods
There are two basic control methods (that is, ways a control can be performed): Manual or automated.
Manual controls are performed by personnel within the business processes and activities that depend upon the actions of individuals, but may be dependent upon IT.
- Manually validating, calculating, or reviewing something
- Use of a database query or spreadsheet application to validate results of a process, or the use of a report from an IT application to support performance of a control
Automated controls are performed on data within the IT application, and embedded checks of data validity and accuracy and completeness of processing that requires no manual intervention
- Business rules based processing (gain on sale is calculated by the IT application based on business rules defined by the business process owner)
- Exception reporting for production runs, control totals, edit checks (do data input meet pre-defined parameters?)
- Electronic authorizations (transaction is rejected if supervisor did not authorize), and three-way matching
Internal control frequency
Internal controls can be performed at different times with different frequencies, for example:
Knowing the frequency can be helpful because controls performed frequently are generally considered stronger than controls performed infrequently.
Control frequency should generally be matched in some reasonable manner with the frequency of the underlying transactions, activities, or events you are trying to control or manage.
Internal control evidence
When we assess controls, we need to see some evidence of the control having been performed and with what results.
Control Evidence is the proof that the controls in a process are being practiced as intended.
Control evidence can be of several types, including but not limited to:
- Electronic signatures on authorized transactions
- Paper forms, documents or reports with signatures, or initials of the person giving the authorization or who performed the work, e.g.,
- Signed/initialed bank reconciliation by the person who reviewed and accepted it
- Signed/initialed purchase requisition by the person authorizing it
- Signed contract by someone with the right approval limit
When documenting control evidence, ask yourself:
- How can the control activities be verified?
- What proof would convince me that the designed control activities are being practiced as intended?
- Is the control evidence retained in a manner that is easy to obtain after the fact?
- Is the control evidence protected from tampering or unauthorized changes after the fact?
Internal control gaps
Control gaps (that is a difference between expected and actual performance) can occur for various reasons:
- Deficient control: Control is missing or not working as intended
- Deficient control evidence: Control Evidence is missing or incomplete
- Deficient standards: Standards (polices, procedures or guidelines) to explain how to perform a control are missing or incomplete
- Deficient practice: Personnel charged with performing a control e.g.,
- Do not know how to perform it or
- Are not following procedure
- Deficient technology: Inadequate technology support prevents performance of a desirable control e.g.,
- System not designed to capture an electronic signature for an approval
- Relevant information not available
Basic guidelines for control effectiveness
Here are some simple heuristics (rules of thumb) to help you think about control effectiveness:
|Less effective||More effective|
|Manual control||Automated control|
|Complex control (requires many steps, multiple calculations, etc.)||Simple control (single step, single calculation, etc.)|
|Control is performed by a junior, less experienced person||Control is performed by an experienced person in a position of responsibility|
|Detective control (designed to detect errors after a transaction is executed)||Preventive control (designed to prevent an error from being processed)|
|Single control||One in a group of overlapping controls|
|High-level control (analytics)||Detailed, transaction-level control|
|Control performed on a sample basis||Control performed on each occurrence|
|Control performed well after the transaction occurs||Control occurs as the transaction takes place or is processed|
This article is by Preben Ormen from prebenormen.com.