An ERP audit tests whether the business system that holds the books is controlled: who can do what, how changes reach production, whether master data is protected and whether reports can be trusted. The auditor needs read-only access to users, roles, change records and data, and should never need the power to post. Ask for that access early.
Last reviewed: 17 October 2026. Facts checked. We opened the Wikipedia article "Systems Applications Products audit" and read its list of audit areas and its vendor-creation and invoice-payment example. Wikipedia is not an authoritative source, so we use it only for broad, generally accepted audit areas. Our searches for ICAI or ISACA material on SAP audit returned vendor and government-audit pages. We did not open any of them, and we did not open SAP's own documentation. We name no SAP table or authorisation object that we did not check. For tables, see our own SAP tables guide.
What an ERP audit covers
The same areas apply to SAP, Oracle, Microsoft Dynamics or a local ERP.
| Area | What the auditor asks |
|---|---|
| Access and security | Is every user real and authorised? Are roles designed to prevent conflicts? |
| Segregation of duties | Can one person do two steps that should be separate? |
| Privileged access | Who has super-user rights, and is it watched? |
| Change management | Are changes tested and approved before they reach production? |
| Master data | Who can create or change vendors, customers and items? |
| Interfaces | Does data flow correctly between systems? |
| Data safety | Are backups taken and is recovery tested? |
| Financial controls | Do reconciliations, approvals and period locks work? |
The article we read lists these same themes: segregation of duties and access, change management across development, test and production, data integrity (interfaces, backups, recovery), financial controls and master data.
The classic example
Take a user who can create a vendor and also pay that vendor's invoice. The Wikipedia article gives this pair: XK01 (create a vendor) and FB60 (pay an invoice). A user holding both could create a fake vendor and pay it. This is a segregation-of-duties conflict. Auditors build a conflict matrix and test users against it. See our guide to designing and testing a conflict matrix.
What access the auditor needs
Ask for the narrowest access that lets you test. Read-only is the rule.
| Need | Why |
|---|---|
| List of all users with status and last login | Find dormant, shared or leaver accounts |
| Roles assigned to each user, including inherited roles | Effective access, not just direct assignments |
| Role definitions and what each role allows | Test the design |
| List of privileged and emergency accounts | Test the highest risk |
| Change and transport records | Test change control |
| Read-only view of master data and its change history | Test master data control |
| Standard reports or data extracts for the audit period | Population for testing |
Where the company has a governance tool for access risk, ask for its conflict reports and the mitigation records. Do not accept a summary alone. Ask for the underlying list.
Two cautions. First, never take a login that can post transactions. It breaks your independence and puts you inside the control you are testing. Second, record who gave you each extract and when. Data you cannot trace to a source is weak evidence.
How to test, step by step
- Get the user population. All users, with status.
- Match users to people. Compare to the HR list. Look for leavers who still have access.
- Test effective access. Roles, including those inherited through composite roles.
- Run conflict tests. Compare to your conflict matrix. Ask management how conflicts are mitigated.
- Review privileged accounts. Who uses them, how often, and is use reviewed?
- Test change control. Pick a sample of changes and trace approval, testing and release.
- Test master data. Who changed vendor bank details? Was it approved?
- Test key reports. Does the report an auditor relies on pull the right data?
Our user access review guide covers steps one to three in more detail. The ITGC audit workbook is a free place to record your tests.
What the auditor should write up
- Scope, system and version
- Date and source of each extract
- Population and sample for each test
- Each finding with the user, role or change involved
- Management's response and fix date
Frequently Asked Questions
Is an ERP audit the same as an ITGC audit?
They overlap. ITGC covers general IT controls such as access and change. An ERP audit applies them to the business system and may also test application controls inside it. See our ITGC guide.
Does the auditor need admin access?
No. Read-only access, or extracts produced by the company's own team, should be enough.
How far back should the user list go?
Cover the whole audit period. A list taken only at year end hides users who left in the year.
What if the ERP is not SAP?
The same areas apply. The names of transactions and tables differ.
What should the auditor never ask for?
Any login that can post or approve transactions. It breaks independence and puts the auditor inside the control being tested.
Related Articles
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error