Since the release of the Public Company Accounting Reform and Investor Protection Act of 2002 - more commonly known at the Sarbanes-Oxley Act (SOX) - companies of all sizes have struggled to demonstrate compliance with Section 404, the assessment of internal control.
If you’re using Sage 300 (aka Accpac) with mandates to comply with SOX, there are a number of modules and best practices available to facilitate compliance.
In this article, we’ll take a closer look at those modules and best practices.
Generally, compliance consists of putting controls into place and periodic testing of the effectiveness of those controls. It is important to understand that the way a given software package is used determines its efficacy and not the software package itself.
There are four key areas in setting up a proper compliance regimen:
NOTE: Privately held organizations that do not have compliance requirements should also consider implementing parts of the core concepts of SOX because many of them would be considered good business practices of any organization.
A strong internal control environment can be beneficial for all organizations, regardless of the entity’s legal structure. Organizations with strong internal controls often experience increased confidence in the company’s internal financial reporting and a reduction in fraud exposure. Additionally, good financial controls often result in better business processes resulting in improved operating results and more robust data for improved analysis.
Disaster recovery is a concern that all organizations must address. Regardless of entity structure, a disaster could happen to any organization and reasonable precautions should be in place to allow the organization to rapidly recover and resume the ordinary course of business. Maintaining a rigorous approach to software change control and project planning as a part of SDLC will help a small business avoid unexpected deviations from desired outcomes.
The primary goal of security administration is maintaining comprehensive security of the IT infrastructure and the financial data it contains. Sage 300 provides organizations with multiple levels for protecting their system and data.
Protection begins with the fundamental system and security architecture of Sage 300 including:
Sage 300 allows for a client-server network setup. This provides controls that limit access to the database and the underlying application only to authorized individuals. To accomplish this, Sage 300 utilizes the full Microsoft Windows toolset to administer the system.
Application security is provided within Sage 300 and the Administrative Services module. The User Maintenance function allows for creation and maintenance of individual users. When used in conjunction with Windows Active Directory, single sign on and password policies can be administered. From within Sage 300, users can be further restricted in their overall system access based upon work schedules and have their access limited to selected days of the week and/or hours of the day.
Within each Sage 300 company, a concept of security groups is utilized to assign security rights to each individual. Security groups control which functions are permitted based on a common role, such as customer service, inventory clerks, purchasing, etc. All of the security groups in a given system database are available to be used in all company databases tied to the system database. In a multi-company environment, users can be assigned to one security profile in company A and a different profile in company B.
Often, an organization needs a more granular approach to security than merely allowing or disallowing a user to access certain software functions. The UI Profile Maintenance function enables system administrators to customize individual screens and turn off various screen features to limit a user’s access to see or input data. These changes are applied on a user by user basis.
See Also: 
It is essential to evaluate all IT and manual controls at the business-process level on an integrated basis. Defining processes by creating system- based internal controls and compensating manual controls is required under SOX and companies who must maintain full compliance need to have the controls routinely tested for compliance and effectiveness.
Companies not subject to mandatory SOX requirements can still benefit from maintaining a well-defined system of internal controls. Sage 300 enables organizations to utilize security groups to create workflows to control the processing of transactions so that distinct users must enter, review and approve data.
For example, User A can be assigned to a security group allowing them to create an Accounts Payables invoice batch and entries but not approve and post them; while User B can be configured to prevent the user from creating AP invoices but allow the user to review and post invoices.
G/L Posting Security is a feature of the General Ledger module that can limit the accounts that individual users can view or work with to minimize the risk of unauthorized activity. G/L Security allows an organization to control which users can access specific G/L accounts, including restricting access to entire account segments or only the most sensitive accounts (for example, Payroll, Sales, Retained Earnings, Common Stock and Preferred Stock).
Financial data control is also maintained by the fiscal calendar. By controlling on a module-by-module basis the fiscal periods that are open for transaction posting, organizations can ensure the integrity of their financials over time.
There are additional options to extend and enhance the base functionality for even stronger controls. Here is a list of a few key Sage 300 modules available:
View Extender adds additional functionality through enhanced Monitoring and Logging, Security, Validation and Alerting.
Purchasing Workflow provides a simple and efficient requisitioning interface; setup options are available to optimize or restrict the interface depending on configurable user roles or specific user settings such as dollar amount approval limits.
Audit Logger captures a register of user actions performed against each specific view that can be later analyzed and reported on. Audit Logger also captures other user actions performed in Sage 300 such as changes to security settings, batch posting, and clearing history.
SOX Second Sight provides a way to ensure that the Sage 300 user posting a General Ledger, Accounts Payable or Accounts Receivable batch has not been involved in the preparation of that batch. While Sage 300 separates the data entry and posting permissions, it may be that all users can perform both functions and a requirement exists to ensure that two different users see the processing of each batch.
SOX Check Approval extends the Sage 300 check management process. Checks for one or more companies are approved by executives from an easy-to-use, central console. Payment batches are prepared by staff and submitted for approval. One to Three levels of executive approval are required. Unapproved checks are removed from the payment batch and approved checks are released for printing and distribution. A complete audit log is maintained for all submission and approval activity.
Experience shows that it is rare to find a solution that meets every requirement out of the box. In many cases the software, including enhancements, will meet a company's needs.
For those instances when it does not, Sage 300 customization can fulfill the remaining requirements. Making the software match your business, not the other way around, is critical to any software implementation and is especially important when designing SOX compliant business processes.
Every business should have a data backup and recovery plan, also known as a disaster recovery plan. There are a number of reasons why data might need to be recovered.
There are countless stories of untimely hardware or software failures causing business interruption. Effective disaster recovery controls ensure that critical operations can be quickly restarted after a loss of infrastructure. Every organization should have a disaster recovery plan in place. How this is accomplished varies by organization and a thorough cost benefit analysis should be done.
Full SOX compliance requires companies to have a well-documented disaster recovery plan in place and to test it routinely. The key components of a data backup and recovery plan are:
Daily or weekly backups of your company’s data are meaningless if they are stored on the same the server and are not accessible after a disaster happens.
Optimally, backups are stored in a location separate from the main data center so that an incident impacting more than one machine does not also impact the data backups. Additionally, backups should be load tested periodically to test for potential corruption in the backup process.
Most Sage 300 implementations on versions 2014 and earlier (and all implementations starting with version 2016) have an underlying Microsoft SQL database. There are tools available, starting with Microsoft SQL Server Management Studio, to facilitate and automate routine backups.
Storage of the backups is the next piece of the equation. There are two different options for this. The backup can either be saved to magnetic media, stored off site, or a copy of the data can be transferred to a backup service or cloud storage.
In the past, many companies have been reluctant to deviate from storing media somewhere under their control or in a secure warehouse due to concerns about control and safety of their data. Those fears are subsiding as companies that host data backup storage continue to improve their security, monitoring and support.
Additionally, as people experience the speed of access to their data and ease of storage with hosted back up systems, the hassle of more traditional storage options becomes more apparent.
See Also: 
Disaster recovery involves more than just data backups. Being able to get the backup on working hardware is a critical component of a well-rounded plan. Larger organizations have the resources to have multiple data centers and servers on standby, ready to carry on business with a moment’s notice. The cost of this is prohibitive for most small businesses.
There are two solutions for a small business. One is to outsource servers to a trusted partner. With hosted servers in a private cloud, a small business can have the best of both worlds.
Utilizing the services of Amazon, Google, Microsoft or another provider, they can be assured of 99.9%+ availability. Users are not aware of when a server is taken off line, either due to routine maintenance, or replacement, as their data exists on a virtual machine that is seamlessly migrated as needed from server to server. And these servers might not even be in the same data center, so small businesses are protected from service outages due to natural occurrences at the data center.
Another option, in addition to backing up data, is to take images of the servers and back them up along with the data. Provided that the company has replacement hardware or has identified a source of new hardware that can be delivered in a time frame acceptable to the business, outages can be reduced to a reasonable time frame.
Of course, both of these solutions have tradeoffs. The skills and resources of an organization must be considered. Organizations with no IT staff might be better off utilizing the services of an outsourced provider, whereas those with an established IT team and infrastructure may have confidence in “going it alone”.
The final major component of SOX 404 compliance is Software Development Life-Cycle or SDLC. Since technology can directly impact financial data, SOX dictates that software have strong change management control applied.
Much of the burden of SDLC is reduced by using a COTS (commercial off-the-shelf) package like Sage 300. With each version release of Sage 300, Sage maintains strong internal controls regarding the implementation and testing of new features. However, a small business using COTS still has obligations to fulfill to be compliant with SOX.
When selecting a new software package or evaluating an enhancement, due care should be taken to gather a complete set of requirements and have the project reviewed and approved by executive management.
A project plan should be developed to clearly define roles and responsibilities of resources assigned to the project. Key tasks should be identified and tracked as the project progresses to ensure that requirements are met and issues are identified and remediated.
A testing plan should be developed and performed by software users to ensure business processes can be successfully performed and the results of the tests are satisfactorily met. Planning and preparation for release, including contingency planning, should be reviewed by management and all involved parties should have a clear voice in the decision to release the software package or enhancement.
If you’re using Sage 300 (aka Accpac) with mandates to comply with SOX, the guidance and best practices provided in this article should help you to ease the burden.
If you would like company-specific guidance or a detailed system review, be sure to contact the Sage 300 (Accpac) experts at Equation Technologies for a free consult.
