ERP Audit: Risks, Controls and Approach
In an ERP, most controls are settings and roles. Audit those, layer by layer.
An enterprise resource planning (ERP) system runs purchasing, sales, inventory, production, HR and finance on one database. A goods receipt posts to inventory and the general ledger in the same step; a vendor invoice matches against a purchase order and receipt without anyone re-keying it. That integration is the point of an ERP, and it is also what changes the audit.
In a stand-alone accounting package, many controls are manual and visible. In an ERP, most of them are configuration settings and role assignments. The question is less "was this voucher approved" and more "who could have changed the tolerance that let this invoice through, and who can post without approval at all".
You save ₹450
- Full-length timed mocks
- Module-wise practice
- Emerging-tech coverage
One payment, no subscription · Valid for 2 months
Where ERP Risk Sits
Configuration
Typical risk
Tolerances, posting periods, matching rules or approval limits set wrongly or changed without control
What to test
Key settings against the approved design; change history of those settings
Access and segregation of duties
Typical risk
One user can create a vendor and pay it, or post and approve the same entry
What to test
Role design, a segregation of duties conflict analysis, privileged and generic IDs, emergency access use
Master data
Typical risk
Unauthorised changes to vendor bank accounts, credit limits or prices
What to test
Change logs for sensitive master fields, with approvals
Interfaces
Typical risk
Data lost or altered between the ERP and banks, the GST portal, payroll or e-commerce platforms
What to test
Interface reconciliations, error queues and who clears them
Change and transport
Typical risk
Custom code or configuration moved to production without approval or testing
What to test
Forward and reverse tests of changes; who can move changes
Reports
Typical risk
Audit relies on ERP reports whose logic was never checked
What to test
Report parameters and logic, and completeness against source tables
| Area | Typical risk | What to test |
|---|---|---|
| Configuration | Tolerances, posting periods, matching rules or approval limits set wrongly or changed without control | Key settings against the approved design; change history of those settings |
| Access and segregation of duties | One user can create a vendor and pay it, or post and approve the same entry | Role design, a segregation of duties conflict analysis, privileged and generic IDs, emergency access use |
| Master data | Unauthorised changes to vendor bank accounts, credit limits or prices | Change logs for sensitive master fields, with approvals |
| Interfaces | Data lost or altered between the ERP and banks, the GST portal, payroll or e-commerce platforms | Interface reconciliations, error queues and who clears them |
| Change and transport | Custom code or configuration moved to production without approval or testing | Forward and reverse tests of changes; who can move changes |
| Reports | Audit relies on ERP reports whose logic was never checked | Report parameters and logic, and completeness against source tables |
ICAI's Own SAP Case
Module 1 includes a sample proposal for a logical access review of SAP at a software company with over 500 SAP users. The scope reviews access in layers: operating system, telecommunications software, the database, and SAP itself, where configuration of parameters and access controls is named as the major focus. Application controls over input, processing, output, storage, retrieval and transmission sit on top.
The layering is the lesson. A clean SAP role design means little if a database administrator can update tables directly, or if operating system access lets someone bypass the application. Test each layer an attacker or insider could use.
An ERP Audit Approach
- 1
Understand the landscape
Modules in use, customisations, interfaces, hosting (on-premises or cloud) and who supports it.
- 2
Map business processes to the system
Trace procure-to-pay, order-to-cash and record-to-report through the modules, top down, as the SAP case does.
- 3
Identify key automated controls
Three-way match, credit checks, approval workflows, period locks and validation rules.
- 4
Test general controls first
Access, change management and operations. If they fail, automated controls cannot be relied on beyond the date tested.
- 5
Test the automated controls
Inspect configuration and run a test transaction; one well-evidenced test per control can be enough when general controls hold.
- 6
Analyse data
Use CAATs on extracted tables for duplicate payments, segregation of duties breaches actually used, and postings outside normal hours.
Quick practice on audit concepts. No signup.
The Statutory Audit Link
Under the Companies (Accounts) Rules, companies keeping books in electronic form must, for financial years from 1 April 2023, use accounting software with an audit trail (edit log) of each change that cannot be disabled, and the statutory auditor reports on this under Rule 11(g) of the Companies (Audit and Auditors) Rules. For an ERP, that means checking the edit log is enabled for the relevant tables and kept, not only that the package offers the feature. Confirm current dates and ICAI's implementation guidance on icai.org before relying on them.
How the DISA Assessment Test Tests This
- check_circleMost important area in an ERP access review: segregation of duties and privileged access, not password length
- check_circleWhy general controls come first: automated controls are only reliable while access and change controls hold
- check_circleIntegration means one error spreads across modules, so preventive controls at the point of entry matter more
- check_circleThe trap: auditing the application layer and ignoring direct database or operating system access
FAQs
What is ERP audit?expand_more
A review of the controls in and around an ERP system: configuration, user access and segregation of duties, master data, interfaces, change management and the reliability of reports used for financial reporting.
What are the key risks in an ERP system?expand_more
Segregation of duties conflicts, excessive privileged access, uncontrolled configuration and master data changes, interface failures, and reports trusted without checking their logic.
How is SAP access reviewed in an IS audit?expand_more
Layer by layer: operating system, database, network software and the SAP application itself, with role design and segregation of duties analysis at the application layer. ICAI's Module 1 includes a sample proposal for such a review.
Why test IT general controls before ERP application controls?expand_more
An automated control keeps working the same way only if nobody can change it or bypass it. Access and change controls are what give that assurance over the whole period.
Next steps
- Application Controlsarrow_forward
- Change Managementarrow_forward
- Data Migrationarrow_forward
- Logical Accessarrow_forward
Assessment Test format, timed and scored.