Migration to new accounting software 1791
-
What documentation, if any, is neccessary in support of the migration to a new accounting software system? If required would this be captured in a SDLC proc?
-
Hi,
A new accounting system implementation will have significant impact on SOX documentation and related evidence to support the controls over financial reporting.
Yes, the SDLC can be used to support effective change management processes. However, the application controls in the new accounting system will need to be reviewed and tested to ensure that transactions are accurately processed in the new system. Also, significant linkages and data interfaces between source systems and the new accounting system should be reviewed. Data migration issues from the old system to the new system might also require assessment.
Additionally, the SOX business process documentation that addresses the ICFR under the older system might need to be reviewed and updated. If you are simply going to a newer version of an existing accounting system, the upgrade and migration will likely require less effort.
However, the implementation of a new accounting system will generally have a significant impact on SOX process documentation, application controls, and possibly general controls too.
A lot of useful information may be found at eitoolkit.com. The software vendor should also be able to provide technical and user documentation that might be helpful to develop SOX process documentation and design/implement tests of controls.
Hope this helps,
Milan
-
Hi Jed - I’d recommend checking with the audit on this for specific requirements , as I’ve seen quite a bit of variability among companies. The SOX 404 (IT) and other standards are written generically for a wide range of IT systems and technologies. Also YMMV depending on your external auditors requirements. %0A Several promising links here (add www and paste to browser)%0Agoogle.com/search?hl=en-and-lr=-and-q=sox+new+system+implementation+requirements I’m in IT and have designed standards for SOX in the past. Here’s a few ideas to start with that I’ve used as applicable: %0A RECOMMENDATIONS FOR FINANCIAL SYSTEMS DEVELOPMENT IN THE SOX ENVIRONMENT %0A1. Formal Project Plan%0A2. Formal write up of SOX controls to be used - make this a standard for the team%0A3. Formal and rigid change control on source promotions (e.g., alpha to beta to QA to production)%0A4. Very Detailed and complete accountability of all financials in the conversion from old to new %0A5. Appoint SOX coordinator (I’ve been that on a few projects)%0A6. Invite Internal Audit to participate and give guidance up front %0A7. If applicable, invite external Auditors to participate and give guidance up front%0A8. Documentation standards%0A9. Create an e-Library of documentation (contrary to popular belief you can do SOX using a paperless aproach.%0A10. Look at low-cost tools if needed%0A11. Educate the team in SOX standards, basics, and in-depth as needed%0A12. Streamline workflows for efficiency … Do it right so you don’t have that 30% overhead as a drag on the project. You still might have some (e.g., 5-10%) as doing the extra work for SOX ain’t gonna happen by itself. %0A13. Have an emphasis of SOX being an important deliverable to the team in the development process as well as the application%0A14. Work with the users to design and use the best practices for workflow.%0Aetc …%0A15. Obtain senior managements support for the extra time and requirements … That will do wonders for your project.%0A16. Security, Security, Security … Best the best controls, autonomy levels, protect workstations and servers, etc.%0A17. Reconciliation Reports - plan on developing a # of these to compare old v. new systems%0A18. Make signoffs on the financials a part of the user approval process (it puts the best interest on users to matilously examine test material)%0A19. Log project history (Promotions, Change control history, correspondence, test plans) in the e-library%0A20. Revisit your SOX standards and progress at least quarterly.