At Satori, we have been providing assurance over the effective operation of financial controls for almost 20 years. One of the most common misconceptions we come across is that the implementation or upgrade to a new ERP will eliminate the need to check that controls are operating, are effective and achieving their intended objective. The reality is quite the opposite – the more reliance an organisation places on technology and automation, the more it needs to have an independent process to ensure that controls are working.
Advances with Enterprise Resource Planning tools have made them indispensable for most organisations. However, in our experience, they will not provide ongoing protection and independent assurance against errors, fraud, dirty data, policy changes, ensure easy access to your data and other common pitfalls.
Some statistics -> What can possibly go wrong with the implementation of a new ERP?
- 50% of ERP implementations fail the first time around.
- On average, ERP implementations take 30% more time than estimated.
- 51-54% of companies experience operational disruption when they go live.
- The top 3 problems faced by users with current ERP systems are UX, data accuracy, and analytics.
- 92% of current ERP systems represent a bottleneck for CIOs, often requiring manual/programmatic intervention to enable data sharing.
- 64% of ERP projects will spend more than the allotted budget.
- Testing and other related processes can shoot up ERP projects’ budget to 50% more than what was allotted.
- 44% of organisations say their ERP is inflexible and exploring options for extending it with a new system.
Source G2.com 2021
At Satori, we are often told that when an organisation is moving to an ERP in the cloud or upgrading an existing ERP, there is no longer the same requirement for ongoing independent assurance of their controls. Our experience is quite the opposite. In fact, the migration itself can precipitate the introduction of errors, data quality issues and open gaps for intentional or accidental non-adherence to corporate policies. A few real-life examples from our team confirm this observation.
Have we migrated all our IT controls to the new ERP?
One of our customers has over 200 branches around Australia. They believed that an inbuilt IT ERP control was ensuring branch employees were unable to give a refund credit back to a customer over $1000, without management approval. During a monitoring project with this customer, we identified that that the control was inactive. The IT vendor had put the control into pre-production, but not into the production environment, which meant that potentially any employee could give refunds of over $1000 without approval, to any customer, any number of times. Their ERP was not capable of detecting this issue. Had we not picked up this issue, the potential for ongoing abuse by staff, and the circumvention of procedures whether due to conflict of interest with customers or avoiding customer complaints, could have persisted for a long time and at a great cost to this company.
General Manager of Customer Success at Satori, Natalya Levenkova commented, “These issues can be easily identified with standard control testing with CCM, in this case, we were implementing a project for this customer, so we ran a test to detect any potential credits or refunds which were unapproved or over the limit. We could see quite a few of them which is how we discovered this example of the missing ERP control.” The ERP did not have the capability to detect this loophole.
Are we paying attention to the right things?
Satori Director, Troy Nicholson, also shared a similar example “In one case of ERP implementation, we discovered the delegation of authority information had gone missing. Resulting with the new system allowing any employee to approve their own invoices. Delegation of authority is an insurance policy against conflict-of-interest situations, an area receiving more and more attention by regulators and the media”.
Surely, we cannot allow for data to be residing in both old and new systems?
In another example, one of our customers was caught out when migrating gradually from an older ERP to a new improved version. As with many other organisations, one of the most common approaches that people take to migrate their systems is “lift and shift”. Very often it’s not possible to move all data in one go, so it is moved company code by company code. With this scenario the Vendor Master File must stay live and editable in both the legacy and new systems. This can easily be exploited for fraudulent purposes if a vendor becomes aware that they are transacting separately across two disconnected systems.
Levenkova expanded: “the same can apply to open purchase orders which often remain “open” across two systems”.
All transactions need to be checked across the systems, we find that this sort of cross-checking is not considered when migrating into an ERP.”
Data Quality – Garbage in, Garbage out
The success of any ERP (as with any other system) is closely linked with the quality of the underlying data in that system. At Satori we have come across numerous examples where the introduction does not alleviate this problem and on occasion, exacerbates it. Take the following real-world scenarios:
- A Vendor’s GST registration is out of date. The new ERP cannot know whether this has taken place and may incorrectly allow for the incorrect payment of GST
- When moving to a new system, some data fields get truncated which compromises the data quality leading to errors or inability to perform necessary matching
Who else needs access to the data?
As systems have improved and moved to cloud, surprisingly getting access to data becomes harder. There are disconnects between the teams implementing the project and those who need to use the system once it’s in place.
“The project is focused on a deadline, there is a new data lake or data warehouse, the data is then not available to the internal audit departments. At the end of these IT lead projects the business side has no access to its data. Business must keep doing business and often need to turn back to standard manual reports dumped into excel to get the business insights to do their job. Spreadsheets are labour intensive, surely this is the reason why a transition to an ERP was required in the first place?” said Nicholson.
Even with the best-laid plans we have seen unintended consequences
Nicholson shared an example, “Often, we have found that access to data for data assurance purposes is limited or a focus is placed on ERP vendors understanding the business processes and not necessarily the reporting requirements scoping phase of the project. ERP Vendors and IT communicate that any data required will now be provided in a data lake or data warehouse. Often this data is not adequate or have the required detail to provide the ability to monitor and tests controls. Further, the data in the lake or warehouse could have been manipulated or cleaned or have alternate foiled naming conventions to the actual ERP.”
Levenkova continued, “Another implication is that there is always some kind of data conversion or data manipulation between the ERP and the data lake. Often the data is incomplete or aggregated at some level, not giving the full picture.”
Sometimes a move to the cloud can make data access more complex
“Technically it should be easier! You should always have access via API but when you get to that, there can be limitations or access restrictions. This is difficult to factor into the initial testing! It could be internal IT restricting access or the vendor restricting access, we have one example of a 3rd party that manages the ERP and getting access to the data as often as before is more expensive than the ERP project, of course, the business is going to return to manual and outdated practices.” Nicholson said.
What does it take for a successful ERP migration?
It’s inevitable that more processes are moving into IT systems. What we have discovered with our customers is that you can’t build an IT control and expect it to work forever, it’s not always possible to check a control during implementation until the new system has been in place and working.
Levenkova recalled an interesting glitch, “One of our customers was implementing Oracle a few years ago and had a control in place to ensure that invoice payment dates could not be before the invoice dates. When we ran our tests, we discovered a handful of invoices. They said, ‘That’s impossible!’ We started testing and we discovered that yes, they couldn’t enter it, but they could edit and change it after entry! That’s why it’s important to have monitoring that’s ongoing.”
What are the best practices around cleaning and updating master data when implementing an ERP?
- A good start is to always get rid of your dormant records and then your duplicate records. The reason that we recommend this order is because most duplicate records will contain one side that is dormant.
- Check any fields that are mandatory or will be mandatory in your new system and check that they are complete, and no key data is missing.
- Check data for all fields and make sure they have current values such as GST registration.
- Test controls during, after implementation, and most importantly on an ongoing and independent basis!
We are moving to SAP in the cloud, what are some questions you should be asking of the project implementation team?
- Don’t get blindsided by IT. Find out how you will be able to access your data.
- The IT department needs to know your requirements and how you will need to access your data.
- Consider all the integration points that you had previously or reporting tools.
- Ensure that you have independent and continuous testing of key controls.
- Having the ERP test itself defeats the purpose of what assurance is all about.
WATCH the 2nd Webinar in our series “What is your ERP not telling you?” which focuses on Purchase to Pay.
