Category: Uncategorized

A typical pitfall you might fall into, when designing financial controls, is to take what I call the “Bottom-Up, Control-Based” approach (as opposed to the Top-Down, Risk-Based” approach as guided in Auditing Standard No. 5 (AS 5) issued by SEC/PCAOB).

That is, without the proper yard stick (i.e., the Top-Down, Risk-Based approach) that guides you through in identifying key financial risks (i.e., critical data-paths, LSPM (Likely Source of Potential Misstatement as defined in AS 5), or WCGW (What Could Go Wrong)), you would end up with either missing key risks and/or corresponding controls (in which case the controls would be ineffective) or identifying them redundantly (then the controls would be inefficient).

By applying the Top-Down, Risk-Based approach, when defining key financial (or misstatement) risks at a process level or at each LSPM in an end-to-end transaction cycle (e.g., Order to Cash, Procure to Pay), you would be able to identify all critical data-paths, or LSPM, (not less or not more than necessary) within each process cycle; thereby ensuring that you define all the key financial risks, with proper financial statement assertions, and design effective internal controls.

Practically Applying the Top-Down, Risk-Based Approach at a Process Level

For example, in order to identify the LSPM’s, you would start from the Reporting phase, where the LSPM would be related journal entries getting posted to the G/L (general ledger), and move on backwards to identify another LSPM where the underlying journal entries are Recorded to the sub-ledger. Then, you would further move on to the Processing and Initiating the underlying data before the Recording phase.

The approach would be “Top-Down” because you would start from the Top, or the G/L, and proceeding back, or Down, towards the Processing/Initiation phases when identifying the critical data-paths (LSPM’s) within a process cycle.

Now that you have identified all the critical data-paths/LSPM’s (and not more or not less than necessary/complete), you should be able to define key financial/misstatement risks with proper financial statement assertion (i.e., Existence, Completeness, Valuation).

The approach would be “Risk-Based” because you would define the key financial Risks first so that you can Base on those when designing key controls to adequately mitigate the Risks.

Note that you are NOT supposed to start designing the key financial controls that you think you should have (which would be what I call the “Control-Based” approach) because, if you did, you would never know what (and how many) financial risks (and underlying LSPM’s) are necessary and complete to begin with.

Note also that you would NOT start identifying the critical data-paths from the (data) Initiation phase (which I call the “Bottom-Up” approach) because you would want to avoid the situation where you mistakenly identify a data-path to be critical when it’s actually not; i.e., it’s not critical if the data-path you have identified does NOT flow into or affect the financial statements .

Examples of Common Mistakes (in Identifying “Risks”)

For example, “A budget is inaccurately measured/valued” is NOT a financial/misstatement risk as it will NOT affect the financial statements in any way; therefore, even if the budget is initiated and recorded in a computer application somehow, it cannot be a critical data-path.

Another example that could be caused by taking the inappropriate “Control-Based” approach; “Sales manager does not review/approve a customer sales order.” is NOT a financial/misstatement risk (or an inherent risk as in the CRA, Combined Risk Assessment, considered by external auditor) but a control risk (as in the CRA), which means that the “sales manager’s review” is a control and NOT a critical data-path (or a LSPM).

(In other words, the description is simply stating the fact that the particular “sales manager’s review” control does not exist.)

The proper description of the particular LSPM would be something like, “A fictitious customer sales order is inputted in Salesforce by sales personnel (Assertion: Occurrence/Existence.),” and/or “Sales order inputted in Salesforce is incomplete (Assertion: Completeness),” etc.

Those are the reasons why and how the Top-Down, Risk-Based approach needs to be appropriately applied at a process level (in compliance with the AS 5 as guided by SEC/PCAOB).

Work Sample of the Order-to-Cash Flowchart

This flow-chart is presented with the LSPM being referred to as WCGW, or What Could Go Wrong (and w/ the Assertions being referenced as E/O (Existence/Occurrence), C (Completeness), etc.).

Another Common Pitfall

Speaking of the “pitfalls,” another one that is commonly found would be related to the Reporting (or Record-to-Reporting/R2R, depending on the preference of how to call it) cycle.

Nowadays, the Revenue (i.e., Order-to-Cash) and AP (i.e., Procure-to-Pay) cycles, particularly the part of the Recording and Reporting phases, are automated (e.g., typically the records on the sub-ledgers are automatically posted to the G/L); therefore, when it comes to the Reporting cycle, the most important LSPM would be typically a manual journal entry, whether it’s AR reserves, contra-sales entries, investment valuation adjustments, pension liabilities, taxes, stock compensation, etc. etc.

The pitfall I am talking about here is the fact that management tend to consider “WHETHER or not the numbers (i.e., the manual entries) are accurate” a control testing while, in fact, the proper control testing of any of the manual entries would be “HOW effectively the management mitigates the risk of related misstatement, or LSPM.”

Here, to test “WHETHER or not the manual entries are accurate” is a substantive testing (as auditors would perform) and not the control testing.

Auditors test the manual entries (i.e., numbers) “substantively” to assess their Audit Risk (as in their Combined Risk Assessment, or CRA) whereas, if they want to assess Control Risk (as in the CRA), they would test “whether or not the related internal controls are effective (under SOX 404),” or “HOW effectively the management mitigates the risk of related misstatement (at LSPM)”.

The Delegation of Authority/Accountability

I discussed the delegation of authority being the core concept behind SOX. Note here that the flip side of the management’s authority, delegated by the company shareholders (through the board of directors), must be their accountability to the BoD/shareholders.

SOX 302 requires company CEO/CFO to certify the effectiveness of their internal controls.

This, then, naturally necessitates them to delegate the accountability to process/control owners, when it comes to process level controls (PLC’s), at a department management level. Accordingly, a public company needs to design the PLC’s in such a way as to hold adequately competent management accountable for relevant, underlying (financial) data (which would affect related journal entries ultimately posted to the accounting ledgers).

At the same time, strong leadership is necessary to hold financial control team accountable for SOX compliance, and for the team to;

 1. adopt the “top-down, risk-based” approach properly per Auditing Standards No. 5;

2. be able to define logical key risks (with relevant financial assertions) in each of the five phases from Initiation through Reporting, including the critical paths at which journal entries are recorded/posted to the sub-ledger/GL;

3. be able to support business departments to identify proper control owners for each proper, effective key controls, which mitigate each of the logically-defined key risks;

4. design Preventive controls, as opposed to Detective controls, to the extent possible;

5. provide stakeholders, including external auditors, with the legitimate rationality for the U.S. Company’s assessment of PLC’s under SOX; and

6. sustain CFO’s (and CEO’s) certification in the financial statements.

The Detective vs. Preventive Controls

The number 4 above is particularly important to keep in mind when designing controls because;

even if a Detective control was effective (and a misstatement was corrected thanks to the effective control), the misstatement would repeat as the root cause for the misstatement has not been rectified.

That’s why designing Preventive controls (e.g., application/access controls, management review of data input, etc.), as opposed to Detective controls (e.g., management review of reconciliation, etc.) effectively is important to design and operate the controls that are “effective” under SOX 404.

For a more detailed discussion about designing Preventive controls, see this post.

What SOX is all about is “Power” (or authority) and the delegation thereof.

The concept is inherited from COSO (Committee of Sponsoring Organizations of the Treadway Commission).

As widely known, what they call “COSO Framework” is the conceptual framework to sustain the integrity of a public organization, which is trusted, funded, and empowered by (oftentimes) numerous benefactors, fund-providers, investors, and other stakeholders, including citizens/taxpayers in case of the organization being a governmental body. Because the management/administration of such an organization is typically composed of elected/appointed/entrusted (board of) directors (as usually seen in the case of a public company), one of the primary concerns of the fund-providers and/or taxpayers would be corruption: i.e., the abuse of power.

Take the Watergate scandal for example. President Nixon abused his presidential power, or authority, by spending taxpayers’ money to benefit his personal gain; i.e., committing a burglary of the Democratic Party headquarters.

The scandal led to many other corporate illegal and corrupt activities, which were essentially a similar abuse of corporate management’s power, or authority, delegated by the corporate board of directors, or the representative body of the corporate shareholders.

The series of events prompted the U.S. Congress to enact the FCPA (Foreign Corrupt Practice Act) of 1977 and the COSO.

The COSO Framework consequently provides corporate governance with the conceptual framework of internal controls to mitigate the risks of the corporate management’s abusing their authority delegated by the board of directors.

The SOX Act 2002, in conjunction with correspondingly updated COSO Framework 2013, specifically deals with the financial information aspects of the public companies that are regulated by PCAOB (Public Company Accounting Oversight Board), part of SEC (Securities Exchange Commissions).

That is, the SOX Act (302) requires the corporate governance (of SEC listed companies), specifically CEO and CFO, to hold themselves accountable for reporting the financial statements (and footnote information thereof) that are fairly stated and disclosed (without a material misstatement in accordance with US GAAP) by establishing an effective system (of internal controls over financial reporting, or ICFR) – “based on criteria established in the” COSO Framework 2013 (as in a management’s ICFR effectiveness report in their 10-K) – to adequately mitigating the risks of misstatement due to fraud (as a result of abusing the authority/power: e.g., Management Override, Collusion, etc.) and/or due to unintentional error (as a result of lacking adequate accountability/competence).

Therefore, the objective of ICFR under the SOX and COSO Framework (2013) is for a public company management to “hold themselves accountable to their shareholders (to the extent of their authority delegated by the shareholders: i.e., the corporate owners) in their reporting/disclosing the fairly-stated financial statements (under US GAAP and SEC regulations), by controlling (to mitigate) the risk of (material) misstatements due to fraud and errors.“

Prior to SOX (the Sarbanes Oxley Act), if any material misstatements (which could lead to restatements, law suits by shareholders, etc.), Company sued their (external) Auditors.

The Trigger (for the SOX Act)

The high-tech bubble burst in 2000.

• SEC named names.

Accounting Malpractice (by Enron, WorldCom, etc.) and Misstatements/Restatements (by Amazon, etc.)

• The U.S. stock market needed to regain credibility.

The Purpose of SOX is;

To hold Company Management Accountable – NOT (external) Auditor

NOTE: What this means, for example, would be that the burden of proof, should the company be sued at all, would rest on CFO/CEO, who would need to prove their certification (under SOX 302; i.e., what the logic was when they said, “our internal controls are effective”).

(An example of the ill-conceived statements would be, “we did what our auditors told us to do.)

• CEO and CFO must certify (SOX302).

Consequence

Regardless of whether it’s fraudulent or not, if they certified that their internal controls over financial reporting (ICFR) was free from material misstatements when it was not in actuality;

• CEO and CFO could go to jail (SOX 906).

In short, the objective of the SOX Act 2002 appears to protect auditors (of an SEC listed company) from being accountable, or even convicted, for their SEC-listed client’s misinforming the public shareholders.