Application Controls mapping to ITGc _and_amp; Testing 794



  • Well hello everybody
    it is kinda interesting that there is so confusing aspects about this SOX Act everywhere around the world. Philosophically interesting: There should be SOX which should control human beings working never at 100% completeness, accurateness to expect them working at 100%… 😛

    But not to go into this, I know that the world is turning still and maybe into another direction

    –My two cents finished –
    I have following questions:
    As we are starting to look at the Application Controls we are very confused how to test them. Say if the Business side declares two reports that come from different systems as manual control (business does reconcile them manually). We still have to have an application control which ensures that the reports are accurate, complete and so on?
    Second: How to do the testing for it? I cannot Baseline 150 Reports?

    Third: The idea to map such an Application Control to the ITGeneralControls regarding a proper testing in the state of development of the Application should satisfy AP Testing (for mentioned reports - they have been tested in development)? But what about applications which are in use for more than 10 years? Get to code level?

    I am a bit confused how deep evidence is required and I like to share my thoughts with experienced SOXXERS or great minds, how about you? Does this satisfy auditor needs?



  • no idea?



  • I’m afraid that the amount of testing required is normally made based on the experience of the auditor and the comfort that the auditor can get from other ITGC processes e.g. change control. All reports that are used by management and that have been scoped for SoX are requried to be tested by the organisation to ensure that the information reflected in the report is complete, accurate and valid. However, if the manual control involves reconciling the report to external data (i.e. data not in the sytem) Example: SAP R/3 payment run report with the bank statements recieved from bank, then in my opinion no further testing is required to ensure the integrity of the report, as comfort can be obtained from the external source. However, if not reconciled to an external source or to the original source documents, then comfort needs to be obtained concerning the integrity of the report. In addtiion to the normal General Computer Control testing the configuration of the controls ensuring the complentess and accuracy of the report (i.e. the retieval, processing and presentation of the report data) is to be tested. This could entail the following options:

    1. Select a report and manually reperform the processing control from the original data (probably have to be conducted by business)
    2. Review the configuration of the controls (processing controls). This I am afraid would entail source code reviews and is not recommended due to the expertise and timing involved (e.g. reports could be developed ina number of differnet and often ‘outdated’ languages).
      I hope this answer helps.


  • Someone in your finance/accounting group needs to identify the reports and verify their accuracy. Is it 2 or is it 150? Not real sure from your post. Identify all reports that have been verified for accuracy and that are being used in the closing/consolidation process. From that point forward, you will need to identify if any of those reports get changed and if so there must be a reverification process for those reports to insure their accuracy. Basically what you are doing is a benchmarking process. In your testing process, if you show that the reports have not changed, no further testing should be required. If they have been changed since the last test was performed, you need to have evidence that they have once again been verified for accuracy.



  • Well it depends on what to focus on. First we said we should only test reports that are necessary for financial reporting. Now, we changed the scope to safeguarding of assets and you can imagine what this means to either cost, time or quality…
    It blew up the count of reports in scope. Nevertheless, it is quite cumbersome if you have additional workforce from KPMG, PwC or other Consulting Firms. They all have a different understanding of scope. Not to speak about which controls are manual, automated or semi-automated.
    Manual:
    E-Mails sent, Approvals from Meetings
    Semi-Automated:
    All reconciliation reports (generated by systems) that are compared by hand. Some of the guys are so into documenting that they loose the big picture
    There is an interesting aspect of process-flow tools which also aggregate financial data and approval limits. They are in scope if you do safeguarding of assets.
    If you do not have evidence, that is a deficiency. But nevertheless it is possible to generate a testcase with data and then review for accuracy.
    I do not think that it is worth to do baselining and browsing through all your code. This is just too expensive in a greater company. AND(.) you have to ensure that your business is going on, not tackling your programmers to check code they have already checked before going live.
    I think it is not a big deal to fail the audit for the first time. I did not hear of any company which did not fail (maybe you know?). As I have read an article which states: ‘The SOX Act is a learning phase for all, CIOs, Consultants, Auditors’. I think the best way is to minimise costs, because SOX is an ongoing process, it will not ‘end’ like any other project.


Log in to reply