Web & Software

ERP Audit Checklist: What an ERP Audit and ERP Security Audit Should Check

Web & Software articles

An ERP audit is a structured review of who can do what in your ERP, whether changes and master data are controlled, and whether the system produces reliable, recoverable financial records. An ERP security audit is the part of that review focused on access, privileged accounts, logging and technical hardening. This guide gives you the full checklist, explains how IT general controls (ITGC) feed into your external financial audit, and shows how to run the audit from scope to remediation. It applies equally to SAP, Oracle, Microsoft Dynamics, Odoo and NetSuite.

Key takeaways

  • Most serious ERP findings come from access: excessive roles, segregation of duties conflicts and unmonitored super-users.
  • External auditors rely on IT general controls; weak ITGC means more substantive testing, more cost and possible control deficiencies in their report.
  • Every checklist item needs evidence: a system report, a log extract, a signed review or a ticket, not a verbal assurance.
  • Rate findings by severity and likelihood so the business fixes the dangerous items first, not the easy ones.
  • A remediation plan needs an owner, a deadline and a retest for each finding, or the same issues return next year.

What an ERP audit is (and what it is not)

An ERP audit examines the controls around your ERP: access, configuration, changes, data and operations. It answers one practical question: can management and auditors trust the numbers and transactions this system produces? It is different from a functional review of whether the ERP fits your processes, and different from a post-implementation review of project delivery, although all three often overlap.

An ERP security audit narrows the focus to confidentiality, integrity and availability: user and role design, privileged access, authentication, logging, interfaces, patching and backups. Many companies commission ERP audit services before an external financial audit, after a go-live, after a merger or company split, or when they suspect fraud or data problems. The checklist below covers both the control audit and the security audit in one pass.

ERP audit vs ITGC vs external financial audit

External financial auditors are required by auditing standards (for example ISA 315 under the international standards, and SOX section 404 for US-listed companies) to understand and, where they rely on them, test the IT general controls around systems that produce financial data. ITGC usually fall into four areas: access to programs and data, program changes, program development and computer operations. Your ERP sits at the centre of all four.

If ITGC are effective, the auditor can rely on automated controls and system reports and reduce detailed testing. If they are weak, the auditor tests more transactions manually, the audit takes longer and costs more, and deficiencies may be reported to management or those charged with governance. An internal ERP audit run a few months before year-end lets you find and fix these issues before the external team does.

Review typeWho runs itMain questionTypical timing
Internal ERP audit / ERP security auditInternal audit, IT, or an independent consultantAre ERP controls designed and operating well?Annually, or before the external audit
ITGC testingExternal auditor (or internal audit for SOX)Can we rely on the system and its automated controls?Interim and year-end audit fieldwork
External financial auditIndependent audit firmDo the financial statements give a true and fair view?After year-end
Post-implementation reviewProject sponsor, PMO or consultantDid the ERP project deliver what was promised?3 to 6 months after go-live

User access, roles and privileged accounts

Access is where most ERP audit findings come from. Start by extracting the full user list with roles, last login date and status, then compare it to the HR leaver list and the organisation chart. Every active account should belong to a current employee or an approved service, and every role should match a documented job need.

Privileged accounts deserve separate attention. Examples include SAP users with SAP_ALL or SAP_NEW profiles and default users such as SAP* and DDIC, Oracle E-Business Suite SYSADMIN, Dynamics 365 System Administrator, NetSuite Administrator or Full Access roles, and Odoo users in the Settings / Administration group or with developer mode. These accounts can bypass most business controls, so they should be few, named, monitored and ideally used only through an approved break-glass or firefighter process.

  • Joiner, mover, leaver process: new access needs an approved request; leavers are disabled on or before their last day.
  • No shared or generic accounts for business transactions; service accounts are documented and cannot log in interactively.
  • Periodic user access review (typically quarterly or semi-annually) signed off by business owners, with evidence of removals.
  • Default and vendor accounts locked or passwords changed; no default passwords remain.
  • Strong authentication: SSO or MFA for remote and privileged access, password policy and session timeout configured.
  • Super-user activity logged and reviewed by someone independent of the user.
  • Emergency access is time-boxed, ticket-referenced and reviewed after use.

Segregation of duties (SoD) conflicts

Segregation of duties means no single person can complete a sensitive process end to end without a second person. Classic ERP conflicts are create vendor plus pay vendor, create purchase order plus approve it plus post goods receipt, maintain customer credit limits plus post sales invoices, and post journals plus approve them. The risk is not only fraud; it is also undetected errors.

Build or adopt an SoD rule set listing conflicting functions, then map them to the actual permissions in your ERP (transaction codes, menus, access rights or role permissions). SAP and Oracle have dedicated governance tools for this, and for Dynamics, NetSuite and Odoo you can analyse role and permission exports in a spreadsheet or script. Where a small team cannot separate duties, document compensating controls such as a monthly independent review of vendor master changes and payments.

ConflictRiskTypical mitigation
Create/edit vendor + release paymentPayments to fictitious or redirected vendorsSplit roles; independent review of vendor change log
Create PO + approve PO + goods receiptUnauthorised purchases, inflated receiptsApproval workflow; three-way match enforced
Post journal + approve journalManipulated results, hidden errorsMaker-checker workflow on manual journals
Maintain customer credit + post invoices or credit notesBad debt, concealed write-offsCredit control in a separate role
Configure system + post transactions in productionControl bypass without traceNo business posting rights for IT or admins

Change management, transports and configuration

Every change to configuration, custom code, reports or integrations should follow a controlled path: request, approval, development, testing in a non-production environment, business sign-off and a controlled move to production. In SAP this is usually done through the transport management system; in Dynamics 365 through deployable packages and lifecycle services; in NetSuite through sandbox accounts and SuiteCloud deployment; in Odoo through a staging database and versioned custom modules in Git.

The auditor wants to see that developers cannot move their own changes to production, that direct changes in production are blocked or logged, and that a sample of changes has complete evidence. Check also that the production client or company is locked against configuration changes, that debug or developer modes are not left enabled, and that customisations are documented.

  • Separate development, test and production environments.
  • Change tickets with approval, test evidence and go-live sign-off for a sample of changes.
  • Developers have no deploy rights to production; deployment by a separate person or pipeline.
  • Production locked for direct configuration changes, with exceptions logged.
  • Emergency changes approved retrospectively within a defined period.

Master data controls: vendors, customers, items and bank details

Master data changes are a common route to fraud and error, especially vendor bank details. A changed IBAN on a real supplier record can divert a payment run without any unusual transaction appearing. Audit who can create and change vendors, customers, items, prices and chart-of-accounts entries, and whether changes are approved and logged.

Bank detail changes should require verification through a known contact (a call-back to a number already on file, not the one in the request email) and a second approver. Look for duplicate vendors and customers, inactive records still open for posting, and vendors with no tax or registration number. Where e-invoicing rules apply, for example ZATCA e-invoicing in Saudi Arabia, check that tax registration data on customer and supplier masters is complete and correct, because invoice validation depends on it.

Approvals, workflows and automated controls

Automated controls are the configured rules that the ERP enforces every time: approval limits, three-way match tolerances, duplicate invoice checks, credit limit blocks, mandatory fields and posting period locks. Because they run consistently, auditors can test them once and rely on them, but only if ITGC around them are effective.

For each key workflow, document the configured rule, test that it works (try to exceed a limit in a test environment), and confirm who can change it. Check that approval thresholds match the approved delegation of authority, that approvers cannot approve their own requests, and that there is no easy bypass such as posting directly to an account without the workflow.

Interfaces, integrations and data quality

Modern ERPs exchange data with banks, payroll, CRM, e-commerce, e-invoicing platforms, BI tools and other company entities. Every interface is a control point. Confirm that interfaces are inventoried, that API keys and integration users have minimum permissions, that credentials are stored securely and rotated, and that failed or partial transfers raise an alert and are reconciled.

Data quality checks should cover completeness and accuracy: record counts and totals reconciled between sending and receiving systems, error queues reviewed daily, and no manual edits to interface files. If you run inter-company flows between two legal entities in one ERP, check that inter-company balances reconcile and that one company's users cannot post in the other company without authorisation.

Financial close, logging, backups, patching, licences and performance

The financial close controls in the ERP should include posting period locks, controlled reopening of closed periods, review of manual journals, and reconciliations of sub-ledgers to the general ledger. Audit trails must be switched on for key tables and documents and retained for the period your regulators and auditors require; check that admins cannot silently delete or edit logs.

Operational controls complete the picture. Backups should be scheduled, encrypted, stored off-site or in a separate cloud region, and restored in a documented test. Versions and patches should be within the vendor's supported range, with security notes applied on a defined schedule. Licence usage should match what you pay for, because inactive named users waste money and wrong licence types can create compliance exposure. Finally, review performance: slow month-end jobs, failed batch jobs and growing database size are early warnings of availability problems.

  • Period locks configured; reopening a closed period requires approval and is logged.
  • Change logs and audit trails enabled on master data, journals, configuration and user administration.
  • Logs forwarded to a central log store or SIEM where possible, with retention defined.
  • Backups tested by an actual restore at least once a year; recovery time and recovery point objectives documented.
  • ERP version and database within vendor support; security patches tracked.
  • Licence count reconciled to active users; dormant users removed.
  • Batch job failures and performance alerts monitored and acted on.

How to run an ERP audit step by step

A good ERP audit is evidence-driven and repeatable. You can run it internally, but an independent reviewer avoids people checking their own work. Plan for roughly two to six weeks for a single-entity ERP depending on scope and evidence readiness; multi-country or heavily customised environments take longer. These are typical ranges and vary widely.

  • Scope: list entities, modules, interfaces and the period under review; agree which risks and standards matter (ITGC, SoD, local regulations).
  • Walkthroughs: interview process owners and IT; document how access, changes, backups and close actually work.
  • Evidence collection: extract user lists, role permissions, change logs, tickets, backup reports and configuration screenshots directly from the system, with dates.
  • Testing: test design (is the control right?) and operating effectiveness (did it work across the period?) using samples.
  • Findings: describe condition, criteria, cause, effect and recommendation for each issue; rate severity.
  • Reporting: share draft findings with owners, agree management responses and deadlines.
  • Remediation and retest: track fixes, then retest to confirm closure before the external audit.

Findings severity table

Rating findings consistently helps management prioritise. Combine impact (financial misstatement, fraud, data breach, outage) with likelihood (how easy and how exposed). The table below is a practical scale you can adapt to your own risk framework.

SeverityDefinitionExamplesTarget fix time
CriticalDirect, likely path to material loss, fraud or breachActive leaver with payment rights; shared super-user; no working backupImmediately, within days
HighSignificant control gap that auditors would likely reportUnresolved SoD conflicts in purchasing or payments; developers deploying to productionWithin 30 days
MediumControl exists but is weak or poorly evidencedAccess reviews done but not documented; logs enabled but never reviewedWithin 90 days
LowImprovement or hygiene issueUnused roles, naming inconsistencies, minor documentation gapsNext planned cycle

Building the remediation plan

A remediation plan turns findings into dated actions. For each finding record the owner, the specific fix, the evidence that will prove it is fixed, the due date and the retest date. Fix root causes, not only symptoms: removing one leaver account is a quick win, but fixing the HR-to-IT leaver process prevents the next one.

Prioritise critical and high items before the external auditor's interim visit. Quick wins usually include disabling dormant accounts, locking default users, removing business posting rights from admins and turning on change logs. Larger items, such as role redesign to remove SoD conflicts or a proper staging environment, are projects in their own right and may need ERP services support or a review of how the system was originally configured, which our ERP implementation guide covers. Report progress monthly to management until every item is closed and retested.

Frequently asked questions

What does an ERP audit include?
An ERP audit typically covers user access and roles, segregation of duties, privileged accounts, change management, master data controls, workflow and approval configuration, interfaces, financial close controls, audit logging, backups and recovery, patching, licence usage and performance. Each area is tested with evidence taken from the system.
What is an ERP security audit?
An ERP security audit focuses on protecting the ERP and its data: role design, super-user and default accounts, authentication and MFA, interface credentials, logging and monitoring, patch levels, encryption and backups. It is usually part of a wider ERP audit but can be run on its own.
How are ITGC related to the external financial audit?
External auditors assess IT general controls over systems that produce financial data. If access, change management and operations controls are effective, they can rely on system reports and automated controls and reduce manual testing. Weak ITGC usually means more audit work and possible reported deficiencies.
How often should an ERP audit be done?
Most companies run a full ERP audit once a year, ideally a few months before the external audit, with user access reviews quarterly or semi-annually. An extra review is sensible after a go-live, a major upgrade, a merger or company split, or a suspected fraud.
What are the most common ERP audit findings?
The most common findings are leavers with active accounts, too many super-users, unresolved segregation of duties conflicts, undocumented access reviews, developers able to change production directly, uncontrolled vendor bank detail changes and backups that have never been test-restored.
How do I check an ERP implementation partner's testimonials?
Ask for references you can call at companies of a similar size and industry, using the same ERP, and ask them specifically about data migration, access design and post-go-live support. Published case studies help, but a direct conversation with a reference and a review of a sample deliverable tell you more than a quote on a website.
Does the checklist differ for SAP, Oracle, Dynamics, Odoo and NetSuite?
The control objectives are the same on every platform. What changes is where you find the evidence: transaction codes and transports in SAP, responsibilities in Oracle, security roles and lifecycle services in Dynamics 365, roles and saved searches in NetSuite, and groups, access rights and modules in Odoo.

Related reading & services

Want this handled for you?

We deliver all of this remotely — get a quote or start with a free audit.

Get a Quote Free Audit

← All articles