Spreadsheet controls 222

  • To mention it again, IT has to focus on key controls. It is not the decision of IT which spreadsheets are SOX relevant or not. Neither IT has to do something like a spreadsheet inventory and then assess which are in scope or not. This is a business side decision. If in a bigger company of course.
    Or do you expect that IT which always liked chaos theory is able to not do it in that case :twisted:
    The business knows exactly which spreadsheets are used to reconcile data from bigger systems, or just reconciling the data from their closing seasons process.
    This is just a waste of time and manpower.
    After you have identified the spreadsheets you can assess them like the PwC document shows. But be aware if taking safeguarding of assets into account. There might be formulae in this sheets which IT just CAN’T test. There is much business knowledge into them. What should IT do? Higher an actuary? This should be adressed by an peer review in the team which created the spreadsheet. (You might have a problem with the segregation of developer and tester - but there is one rule: Knowledge over independency, if your management takes that risk in their decision - off you go)
    Then you just have to ensure that the accessrights to the location of the spreadsheet is properly set (reliance on ITGCs). And maybe its a good idea to create something like ‘light’ ITGCs for End-User-Applications.
    Versioning, ChangeMgmt, AccessControl

  • Syed,
    You may need to reevaluate whether or not these spreadsheets are part of your key processes. If a process is merely in place to help manangement make good operational and financial decisions and does not affect the financial statements, by definition the process itself is not key and therefore, the spreadsheet does not need to be reviewed.
    Key controls should only be controls that have an effect on the financial statements as reported to investors. Now that the PCAOB released new guidance in May, you should have good ammunition for removing some of these controls from your list when you discuss this with your auditors.
    Also, I would be careful in designing a spreadsheet testing plan. The PwC guidance provides a list of all controls that could be in place for spreadsheets, however trying to implement every one of those controls may actually keep your employees from doing their jobs. You should be able to argue that thru the use of entity-level controls such as good staffing and review practices you should be able to reduce the number of controls necessary over your spreadsheets.

  • SoxBriefs
    Thanks for your response. No, you’re absolutely right. If I looked to implementing all the controls recommended by PWC I think I won’t have many friends in the company.
    I’m taking the reasonable assurance view that as long as there is a review taking place by both the user and senior management, there is adequate access control, passwords in some places, appropriate naming convention is being used to reflect current version and any changes are being logged and approved than I’m happy to go with that. These controls in my mind are good busines practice. Furthermore, as you rightly pointed out with adequate ELCs in place such as good staffing we can safely avoid the situation of becoming an over controlled, cumbersome, inefficient working environment.
    Its worrying to think that some auditors are taking a very conservative approach which can lead to a very counter productive environment for businesses to operate.
    I’m finding that there is a severe lack of consistency in how spreadsheets should be managed in line with SOX. I’ve been told to look those regardless of whether they have an impact or not to the financial statements but because they are part of a key control on an operational level, therefore one should look it as part of this spreadsheet testing.

  • Hi Guys,
    Have read through the posts… and have seen that the word ‘review’ is used quite often. Is that the something we could use for an SOX assignments?

  • Our approach to deal with spreadsheets is the following:

    1. We identify and document all critical processes for financial reporting. If spreadsheets are part of the process they are documented in our process flows.
      With that approach we eliminate the need to keep spreadsheets and other small office tools in a separate inventory.
    2. Each process is evaluated for the existence of business controls to ensure correctness and accuracy of the data transferred to the annual report (Plausability checks)
    3. If no business check is made for the data, IT controls apply.
      We found less than 50 spreadsheets which needed to apply IT controls, our auditor is satisfied, we do have very little additional workload because of small office applications.
      However, everything depends on your setup. We do have the luck that we do not really depend on spreadsheets but use a set of professionally managed application for consolidation and reporting.

  • 😢
    I’m sorry to say that this is what is expected. I work for a leading Insurance Company in the UK and we will be auditing all ‘critical’ spreadsheets to ensure that they have been documented and that there are controls to manage changes and that they are tested before put into the production environment.
    Any spreadsheet that in some way contributes to the financial reporting of the company must be effectively signed off the by the executive concerned.
    Kind regards

  • Hey, does anyone have another link to Richards PWC spreadsheet documment…I can not find it.
    I am looking at the controls around spreadsheets and databases and need a starting point, can anyone suggest any other articles of interest.
    I work for a bank and we have hundreds of spreadsheets.

  • Here is the link to the PWC whitepaper if that is what you are looking for -

  • I think my situation is relevant to this thread and I wanted to see if I could get some feedback?%0AMy company uses Excel spreadsheets for calculating non-standard pricing requests from our customers. If a customer of ours needs a lower price in order to complete a deal, Excel is used to calculate what the impact to our profit margin of that deal is in terms of %, total USD, etc… Currently Excel is used only as a calculation, communication, and decision-making device between sales department and the business decision makers.%0AIf the lower pricing is approved, the Excel file is then sent to another group who uses the data from it to make changes in the actual price-quote (which is in an enterprise level database). All aggregate financial reporting of what was sold to whom for how much comes from the database.%0AAre there any compliance issues that stand out to anyone here? Any feedback at all is much appreciated.

  • There are no SOX compliance issues with this. Your risk is purely operational in that you could miscalculate your profit in the pricing and quote too high to get the sale or too low to make money on it.
    Any financial reporting risk comes after the sale when you record the sale and recognize the income from it. Now, if the spreadsheet is used somehow to calculate your cost of the item sold for financial reporting purposes. then you may have some risk if the spreadsheet is not properly reviewed and monitored for accurate formulas, input, etc.

  • Thanks Kymike. That is what I thought. I do believe the spreadsheet is used in some cases to calculate our costs. But this is limited to situations where we must purchase an item from a supply company that we do not normally warehouse ourselves. In which case, if there is an improper calculation, the supplier is quick to point it out and reject our purchase order. We then make the appropriate correction and resubmit.
    I am guessing this kind of natural ‘control’ is also compliant, am I right about that?

  • I am guessing this kind of natural ‘control’ is also compliant, am I right about that?
    Hi - Issues like this are subject to interpretation. Even things that are indirectly related to SOX compliancy might still be seen as needed sometimes.
    I’d suggest working directly with audit for the answer on this potential exposure related to financial risks. If it’s not too difficult, it’d be beneficial to err on the side of caution.
    As an IT person I may be wrong on this, as I’d recommend adding at least some controls for the following reasons:

    1. The supplier will most likely catch most billing discrepancies. However, what if they don’t have good systems or controls?
    2. For example, as long as they’re getting paid they may think it’s a partial or overpayment check and not always assume you’re paying the bill in full each time?
    3. What if you’re overpaying? Not all folks are ethical and they could at a minimum enjoy some ‘cash float’ for a few weeks or months. This is the exception rather than the rule, but it’s worth noting.
    4. I’ve seen enough billing errors in my 34 years of business experience to suggest it’s a good point to place better controls, reconciliation, and testing on this.
    5. At a minimum, I’d suggest capturing any occurrences from documentation standpoint. This way you’d know how much of a risk it truly is and whether it’s something that you need to go the next step on.
      The key point is you don’t want audit comments to go to the executives or board on failures to comply.

  • HarryWaldron brings up good points. There are very good reasons to have good controls over pricing and billing from a business operations perspective. In my responses, I am trying to ensure that we are identifying the controls that need to be documented and tested for minimum SOX compliance.

  • Thanks Waldron, definitely good points, and I am sure the ‘what if’s’ you bring up most likely have occurred at some point in my company. Law of averages makes it almost a certainty.
    We do have internal controls on the spreadsheet (in the form of macros and password protection, etc… many of the things mentioned in the PWC white paper) and the group that actually makes the adjustments in the database have check procedures, etc…
    I am stuck in the middle of a debate at my company and trying to come up with a balanced solution. One group of folks at my company think that the use of Excel for anything at all constitutes SOX violation. The other group thinks it is actually quite difficult for spreadsheets to trigger violation unless they are specifically for financial reporting.
    I am sure the answer is somewhere in the middle. The thing is that this current spreadsheet is a vast improvement over previous versions designed for the same purpose. We used to have several different spreadsheets floating around the company, different spreadsheets for different product lines, created by different people. They each had vastly different look, formulas, processes, etc… Not to mention no protection or version control. Now we have just the one which accomodates all product lines in a uniform fashion and has protection, version control, centralized management, etc…
    I’ve got to believe that auditors consider this when doing evaluations. If a company cannot afford to put certain functions into an enterprise level data base right away, but is making a conscious effort to make their spreadsheet methods more compliant, would this be enough to avoid violation? Or do you think the only way to be sure is to follow every single guideline in the PWC paper?
    Our company does eventually want to move as many functions as possible to our database, but to do all of it at once would be financially impossible. Spreadsheets seem to be a nice way to bridge that gap and get some level of compliance without having to invest huge dollar amounts, time, resources, etc… It seems to me they at least allow business decision makers the option of delaying costly IT investments while still addressing compliance.
    We are contemplating the creation of a business unit primarily dedicated to spreadsheet creation and management for this reason. I wonder how many others are contemplating making this move and what was can be gained from those who already have this in practice?
    Thanks a ton for the great feedback. I think I will get with our auditors to discuss this now that I feel more well equipped.

  • All
    We are based in South Africa and provide spreadsheet services.
    South African companies are not required to comply with SoX but as we have spreadsheet experience we have tried to put together some ideas on how to address spreadsheet risks using Excel’s inbuilt features, the tool we distribute and some common sense.
    The problem is we are not sure how ‘common’ this common sense is as there is no easy way to test it with limited companies to test against.
    We would appreciate some feedback from a group like yourselves on whether the free advice is practical and useful. If not please make suggestions. The page is auditexcel.co.za/sox_S404.html .

  • Hi,
    You might check out the Spreadsheet Documentation Guide for additional information.
    Hope this further helps,

  • I am stuck in the middle of a debate at my company and trying to come up with a balanced solution. One group of folks at my company think that the use of Excel for anything at all constitutes SOX violation. The other group thinks it is actually quite difficult for spreadsheets to trigger violation unless they are specifically for financial reporting.
    I think you’re right on track, as some education and negotiations are required. Certainly SOX standards don’t require you to rewrite everything into database applications and they specifically support the use of spreadsheets with best practices (as noted in prior posts). Going too far with SOX standards can drive up costs and create resistance when you truly need to address real issues
    With your recent work in version control, security controls, autonomy levels, and standardizing the process , place your company in a good position to meet SOX spreadsheet requirements. Any financial risk management aspects of this still might need to discussed and possibly resolved if it’s needed. Otherwise your current position looks good to me 🙂

Log in to reply