COST ACCOUNTING

i) Prevent mistakes and fraud through role-based security. This is an ERP feature not everyone understands. You must ensure the right people are assigned to the right activities and prevented from engaging in the wrong activities. Generally, this requires a separation of powers, as you don't want to allow one person to complete every activity within a business cycle—whether that cycle is orders-to-cash or purchase-to-pay. For instance, if a single person can create a supplier, create a purchase order for that supplier, purchase the product, and cut and send a check, how do you ensure that person's cousin doesn't suddenly become a supplier? If that person also has access to inventory records, he or she could make an adjustment to inventory to hide the fact that a product from his or her imaginary supplier was never received. Physical inventory would never catch it, but the company would have paid for the imaginary product, and before the discrepancy is detected, the perpetrator could have inventory-adjusted it out. Some enterprise applications simplify identification and elimination of role-based security risks (see figure 1).

Figure 1. Segregation of duties analysis (provided by IFS North America).

Even some companies that attempt to segregate all the necessary functions to deliver role-based security still employ a financial clerk. This clerk can perform a number of tasks for accounts receivable, accounts payable, general ledger, and inventory adjustments. This violates a number of rules of financial segregation, despite the fact that the company is using a major ERP system designed to deliver financial segregation and role-based security, and in some cases separates those duties in other positions.

Correctly segregating duties to manage risk requires analysis of a company's key business cycles to identify which administrative roles need to be separate and distinct. This is not as simple as it sounds: in a small or midsized department, three people may have different roles in the company, but they are also each other's back-up. As each employee goes on vacation or takes sick leave, others assume the absent employee's duties, often with help from a system administrator. When the employee returns to the office, often there is not a process in place to remove the system permissions. Without diligent attention to assigning and managing these user permissions, before long, role-based security disintegrates.

Role-based security must be built into an application, defined and configured during implementation—and then maintained.

ii) Implement detective as well as preventive controls. Sometimes a company's administrative staff is too small to segregate roles with enough granularity to truly benefit from role-based security; or, it may operate in too complex a manner to make role-based security practical. But even when good preventive controls such as role-based security are in place, it is critical that a company can monitor employees' access to its business systems, and track what they do with that access.

Let's say that according to your role-based security schema, an individual can create customers in the system, but normally does not set up a whole customer record, leaving some of the work for others. It makes sense to monitor this individual on a monthly basis to track that key activity (see figure 2). Another way detective controls can be useful is if a double approval of check is required. The system may have to be altered when the president, for instance, is out of the office. But when the president returns, he or she can review a log to see what checks were cut in his or her absence.

Figure 2. Activity and event tracking (provided by IFS North America).

Detective controls can also be used to ensure that preventive role segregation controls are not being circumvented. You can do this by checking to see who is changing people's access in the system. Reviewing audit logs of permission changes is one way to maintain good segregation of duties.

Some activities, however, require timelier tracking and validation than permitted by reviewing log files. Fortunately, some ERP systems proactively send messages when specific events occur (see figure 3). For instance, perhaps your chief financial officer (CFO) wants to be automatically notified when anyone writes a check for over $10,000.00.

Figure 3. Functional area conflicts (provided by IFS North America).

The general awareness that the ERP system can create these alerts may serve to prevent some large-scale fraud. But there are cases when an employee knows of a limit and engages in fraudulent transactions under that limit. So, in addition to established limits that alert you to checks over $10,000.00, you could also create a control that notifies you if two or more transactions for over $9,000.00 or $8,000.00 occur in a defined period of time (for example, in 14 hours). Tracking an accumulation of minor events is a smart thing to do, as those minor events can combine to make a major one. But you may want to avoid broadcasting these incremental controls, or they could be rendered ineffective.

iii) Manage IT-driven risks. Apart from managing regular users, an ERP system should offer preventive and detective controls to thwart system administrators, database administrators, and programmers from making mistakes or engaging in conduct that could present financial risk to the company.

As is the case in identifying risk on the business-administrative side, managing risk on the IT side of an ERP package starts with an analysis of where business risk and IT intersect. This involves determining how the application's architecture supports the IT side. Situations should be avoided where a single person has access to the source code of the ERP application and the database it runs on. In such cases, an IT manager or system administrator can do more damage than a simple user of the system, and moreover may have the skill to conceal any illicit behavior during an audit. So it's important to use the ERP application's multitiered environment to segregate roles on the IT side, ensuring the database is secured on a separate server from the source code of the application.

Only the database administrator should have access to the database server, and someone else—like the ERP manager—should have access to the source code or the system itself. This ensures that the database administrator can change the raw data in the database, but not the application's source code; and that the ERP manager can change the source code of the application, but not the underlying data it's running on.

IT preventive and detective controls need to be closely intertwined. For instance, log files can track changes to tables made by the database administrator. But many times a database administrator is only given entry access, and can therefore enter but not change data in the application's underlying tables. If a database administrator is particularly astute, however, he or she could get into the log files that track changes to that database and alter them to hide various database transactions. That why it's important to consider using an ERP application's capacity to track when a database administrator is logged onto the server, and keep that information on yet another server to which the database administrator doesn't have access permissions (see figure 4). Consequently, in the event that there are unexplained inventory changes or other anomalies, you can compare the timing of those events with the administrator's activity in the system.

Figure 4. Table showing log-in times (provided by IFS North America).

Some ERP systems have migration utilities—a development environment that allows technical staff to identify new segments of code and move them into a quality assurance (QA) environment for testing. After testing, the code goes into a staging area or even directly into production. In order to allow rapid recovery, in case that new code does not perform as anticipated within the application, there is also typically a quick back-out capability that returns the system to its previous state.

It is important to consider an application's capabilities in tracking the activities of employees involved in change management and in moving code from a development environment to a live one. A system administrator could maliciously change the application's source code or even create a program that changes the source code by using a migration tool (built into many enterprise applications) to hide a piece of code that executes functions a single time. This may result in the one-time transfer of $100,000.00 to a specific bank account. After performing its function, the code could be programmed to expunge the resulting log file—and finding the exact cause of that anomalous transaction is impossible without reviewing millions of individual lines of code.

There are two ways to deal with these risks from both preventive and detective standpoints. Detective controls include good cataloging to track the production environment, and who enters what code into production. Preventive controls involve, again, segregation of roles. A programmer's access would be limited, for instance, to the QA environment, while the ability to move code into production would be reserved for a system administrator. Once duties are segregated logically, it is a simple matter of determining how the ERP application can facilitate that separation of duties.

3. Enjoy the efficiencies that come with automated risk management.

The old axiom is that people will work harder to keep someone from stealing $10.00 from them than they will work to make that $10.00 to begin with. And while risk management is primarily about preventing loss, there is a real upside to automating processes that prevent costly mistakes and fraud. Implementing automated risk management practices within your ERP environment can help you document risk management and compliance activities. This can deliver efficiencies that you will appreciate during an audit, or anytime you need to document the safeguards built into your business systems.

Many ERP preventive and detective functions are automation tools that expedite the compliance and documentation processes a business may face. Once an ERP event engine (like IFS Applications) is configured to test for various exceptions and send notifications when they occur, you can document and use that exception reporting system to your advantage during an audit. To pass an audit, controls must be baselined, which means testing the controls and saving the test information so you can show your auditor that credit limits have not changed—and if they had, you would have been notified. Moreover, your ERP application should allow you to keep audit logs of every transaction in the system, providing additional documentation and detective controls.