SOX Compliance: Easy or Difficult?
It’s not easy but does not have to be difficult if one approaches it the right way. Generally, a SOX compliance project involves operational elements (i.e., getting things done) and technical elements. A lot of SOX work boils down to coordinating the work of accounting, payroll, sales and other departments to ensure all proper control activities are documented, executed, and tested on time. Although a SOX compliance project has technical aspects, they are generally based on common sense and, therefore, easy to understand.
SOX Concepts and Literature
There are a few sources of information that will help you comply. Theoretical foundations of SOX compliance are formulated in COSO framework. You can find it at coso.org, option Guidance, section Internal Controls. There are a number of downloadable files that will explain how to establish and maintain a compliant system of internal controls.
At a high level, COSO internal control framework is based on the following five components:
- Control Environment
- Risk Assessment
- Control Activities
- Information and Communication
- Monitoring of Controls
Another important source of information to consider is Audit Standard No. 5 (AS 5) published by Public Company Accounting Oversight Board (PCAOB). The standard is called “An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements”. Strictly speaking, the standard applies to external audits of internal controls. However, it still provides a good source of knowledge of the effective system of internal controls for everyone, not just auditors.
High level, the design and operation of internal controls should ensure that a) Company’s assets are properly safeguarded; b) Company’s financial statements comply with US GAAP. First aspect has to do with security of company’s assets, the second one has to do with accurate and complete accounting information as disclosed in the financial statements.
Although some controls are executed and tested in a mechanical manner, it’s important to ensure that the way controls are designed and operate addresses the risk of potential misstatement. This serves as a high-level goal for folks involved with designing and testing of internal controls.
SOX Implementation Plan
SOX implementation takes extra effort. First off, try not to turn the whole project into a compliance exercise only. Instead, try to make it helpful to your company by virtue of a) understanding relevant risks and b) designing the controls to address them, i.e., reduce to an appropriately low level. Internal control requirements were implemented for a reason and, in theory, it’s a good one: making sure that Company’s assets are safeguarded and financial information is free of material errors.
Here is the 4 step process to implement SOX:
Step 1: Risk assessment, identify key financial reporting cycles, document key flow of information and activities taking place in each cycle.
Management should start by understanding the risk of material misstatement in company’s financial statements. As part of the process, management analyzes the risk by significant transaction and account balances and their respective assertions. Financial statement assertions are existence or occurrence, completeness, valuation or allocation, rights and obligations, presentation and disclosure.
The above risk assessment is a foundation for developing appropriate control documentation including identification of key controls described below.
Examples of the financial reporting cycles are Revenue and AR, Purchases and AP, Treasury, Payroll and HR, Equity Transactions (stock compensation, stock issuance, etc.), Income Taxes, Financial Close, etc. Sometimes, especially for a larger or even mid-sized organization it makes sense to also identify sub-cycles or sub-processes. For example, a revenue cycle can include the following sub-cycles: contract signing, processing order, delivery of goods and services, revenue recording, etc.
You’ll need to document the flow of key activities taking place at noted processes and sub-processes. The documentation should include clear indication of activities performed as well as folks involved with the activities, their roles and responsibilities.
Step 1 serves as a foundation for other steps of the implementation program. It’s important to get it right.
Ideally, Step 1 is documented in form of narratives and diagrams. Visio software is often used to show flow of information and sequence of action in form of diagrams. Narrative information provides process description that can’t be easily conveyed through diagrams (e.g., individual roles, examples of approval forms, example of supporting calculations, etc.). For a smaller SOX compliance project, a thoughtful narrative without diagrams may be enough. Similarly, for a smaller SOX compliance project, a diagram only with substantive narrative commentary may suffice.
Step 2: Identify and document key controls within each financial reporting cycle.
Key controls are defined as those activities that mitigate the risk of material misstatement.
A control itself can be defined as a specific check or activity performed to ensure the control objective is met. As a refresher, control objective is twofold: a) safeguarding of Company’s assets and b) ensuring that the financial information compliance with US GAAP. Examples of controls include review and approval of bank reconciliation, approval of POs issued to vendors, review of vendor invoices, ensuring access to the accounting system is protected, etc.
There are multiple classifications of internal controls. Controls can be divided between Entity-Level, Divisional or Transactional. Controls can be Detective or Preventive, Manual or Automated. Automated controls are sometimes referred to as Information Technology Application Controls or ITACs. Such controls operate as part of a specific software. For example, one of ERP functionalities will calculate straight line depreciation of all depreciation fixed asset items every month.
A separate class of controls is referred to as Information Technology General Controls or ITGC.
Key controls should be documented. The documentation is often time taking place in the same document where managed documented Company’s processes and sub-processes as part of Step 1. Documented processes along with relevant controls are often referred to as Control Narratives. In certain cases, controls are described in the so called Control Matrix, being an excel file that lists all control with indication of key controls.
Many companies identify and describe all relevant controls first and then identify those considered to be key.
Step 3: Perform and document walk-through of key internal controls to ensure their design is appropriate.
Generally, there are two parameters used in the assessment of internal controls: assessment of the design and assessment of operating effectiveness. Assessment of the design ensures that a control was developed or designed to address the risk of material misstatement. Operating effectiveness is concerned with the fact that the control is actually operated or executed as designed.
Step 3 is specifically concerned with controls’ design. Walk-throughs are performed by following one transaction from the beginning to the end. In practice, a walk-through is based on testing of one instance of a control. Let’s say the control in question has to do with matching PO with the vendor invoice and delivery note (a 3-way match). A tester can select one set of 3 documents and check how the match works. We address the documentation of the walk-through as part of Step 4 below.
Step 4: Test and document results of testing over key internal controls to ensure they operate effectively. Evaluate exceptions.
There are four main types of procedures performed as part of the control testing:
- Inquiry;
- Observation;
- Inspection;
- Reperformance;
Inquiry involves asking appropriate questions and getting answers about operation of a control. Observation has to do with visually observing how the control is performed by the person responsible. Inspection is the review and examination of documentation supporting execution of the control in question. Reperformance involves tester’s re-performing of all activities of the key control.
The question is how many control instances should be tested. Many CPA firms developed testing tables indicating the amount of controls to test depending on the frequency of the control and risk involved. Control’s frequency can be annual, quarterly, monthly, weekly, daily, multiple times a day or ad-hoc. Generally, for automated controls testing one instance is sufficient provided ITGC controls operate effectively.
Many companies also develop so called Control Testing Templates where actual testing work is documented. The template includes control description, testing attributes, description of testing procedures performed, date of testing, roll-forward testing performed, among other details.
Sometimes walk-throughs performed as part of Step 2 are documented in the same templates where the testing is documented. However, walk-throughs should be performed before the actual testing is.
It may be helpful to have one central depository of key controls referred to as Control Matrix. The Matrix will include the description of each control, financial cycle it belongs to, unique #, indication if it is manual or automated, estimated frequency for manual controls (e.g., monthly, quarterly, ad-hoc).
Other SOX Questions
Top-Down Approach
AS 5 requires auditors to use a Top-Down approach as part of their testing strategy. The approach establishes an order in which a control project is executed. Understanding of controls system and controls risk assessment come first. Testing of controls comes after. Entity level controls should be tested before transactional ones. Overall, the approach promotes healthy project management mindset and is relevant to external audits as well as SOX implementation.
As part of the approach, management should perform proper scoping of IT systems to identify which systems should be covered by SOX procedures. IT systems can be managed in-house or outsourced to third-parties in which case they may be covered by a SOC report.
Accuracy of Underlying Information
Another standard topic relevant to SOX effort includes the accuracy of the underlying information used in the execution of a control. For example, let’s assume that per the control description the Controller performs Balance Sheet variance analysis on a quarterly basis. Part of the control is to ensure there is a variance analysis with relevant explanations. Besides mere execution of the control description, one needs to ensure that the balance sheet being analyzed is the most recent one and not one of the older versions without later adjustments. In other words, one needs to ensure that the underlying information used in the execution of the control (i.e., the balance sheet) is accurate. The above topic, i.e., accuracy of underlying information used to execute a control, is sometimes referred to as Information Provided by the Entity (IPE).
ITGC
Information Technology Controls (ITGC) is a distinct type of controls that cover such areas as password policy, system operation including segregation of duties and system changes. More specifically, ITGC has the following three components: 1) access, including use of passwords, 2) program changes and 3) computer operations. Computer operations include backup, restore procedures and incident handling. Access controls cover both physical and logical access. ITGC are viewed the basic and overarching controls that can be applied to systems and processes to ensure their integrity, security and reliability. More specifically, ITGC can also be viewed as overarching controls ensuring accuracy of underlying information (IPE). Conceptually, ITGC are subject to the same or similar SOX procedures that other controls are. Specifically, SOX implementation manager should form and document understanding of ITGC (including IT environment), identify key controls, perform walkthroughs to assess the design and perform testing procedures. Testing of ITGC is similar to testing of other automated controls.
SOC Reports
SOC stands for Service Organization Controls (SOC), being the controls implemented at the service organization. Service organization is a third-party providing “user entities” (i.e., reporting entities) with services that are relevant to user entities’ internal control for financial reporting. An example can be a payroll processing company where the processing service impacts the accuracy and completeness of payroll records including payroll payments. A SOC report provides information on the effectiveness of an organization’s internal controls. Reporting entities review SOC reports and document their review using a specific format referred to as SOC mapping. A key part of the review is to assess the impact of any control exceptions on reporting entity’s SOX compliance. As part of this process, SOC mapping includes mapping of certain service organization controls to reporting entity’s user controls, i.e., the controls established on the reporting entity level and completing controls established at a service organization level. If a user organization, for example, uses a service organization to process its payroll transactions, the user organization may establish controls over the submission of payroll information (e.g., new hires, terminations, etc.) that could prevent or detect material misstatements.
Overall, review of SOC reports has been gaining importance as many reporting entities outsource some of their systems and processes to third-party providers.
Proper scoping of ITGC and Service Organization starts with proper system scoping. As part of the system scoping exercise, a SOX specialist needs to determine relevant in scope, i.e., such systems that include either a) original files that contain data to be used in financial reporting or b) workflow approvals impacting financial reporting.
404(a) vs. 404(b)
Last topic we wanted to cover here is the difference between 404(a) and 404(b) compliance. 404(a) and (b) are two sub-sections or paragraphs of the Sarbanes Oxley Act introducing certain requirements relevant to internal controls over financial reporting. Paragraph 404(a) requires management of U.S. public companies to assess and report on the effectiveness of internal controls. Section 404(b) of the Act requires a registered public accounting firm to report on the assessment made by management as part of the 404(a) requirement.
Some companies are subject to 404(a) only. For examples, all non-accelerated filers have to comply with 404(a) but not 404(b). Non-accelerated filers include smaller reporting entities and debt filers. Smaller reporting entities are defined based on their public float at the end of the most recent second quarter and/or revenue. The so-called Emerging Growth Companies are subject to 404(a) and not 404(b) for five years. First time filers can extent 404(a) and 404(b) compliance until filing their second annual report (10K). Last but not least, 404(a) and 404(b) compliance for newly acquired companies can be deferred by a year.
Important Note: FinAcco is not responsible for, and no person should rely upon, any advice or information presented on this website. Note that entity’s financial statements, including, without limit, the use of generally accepted accounting principles (“GAAP”) to record the effects of any proposed transaction, are the responsibility of management. Therefore, any written comments by FinAcco about the accounting treatment of selected balances or transactions or the use of GAAP are to serve only as general guidance. Our comments are based on our preliminary understanding of the relevant facts and circumstances and on current authoritative literature. Therefore, our comments are subject to change. FinAcco does not assume any responsibility for timely updates of its website overall or any information provided in the Insights section of the website, specifically.