ERPNext for SOX IT general controls

How ERPNext supports SOX IT general controls in your financial systems

ERPNext can host configured controls that support SOX IT general controls, but management owns the control design, the assessment and the conclusions. An external auditor forms its own opinion under the PCAOB standards. A finance or IT leader should treat the software as one component of the control environment, not as the control itself. The platform helps with several requirement areas: user access through roles and permissions, segregation of duties between people who create and approve transactions, ledger integrity through settings that stop silent edits to closed history, change control over custom apps and scripts, and the logs and reports that serve as audit evidence. It does not decide which controls are key, does not write the risk assessment, and does not make a self-hosted deployment compliant by default.

The SEC's interpretive guidance in Release 33-8810 gives a useful scoping frame. In plain terms, management needs to evaluate only the IT general controls that keep other financial reporting controls operating properly and consistently, not every IT process that affects efficiency. For an ERPNext environment, that usually means starting from the financial reporting risks and working back to the access, change and operations controls that protect them, such as who can post to a period, who can alter a master record, and who can deploy a script that changes how journal entries are created. The guidance also notes that the relevant areas vary by company, so the scope should be written down and agreed with your auditor before configuration starts. The settings that matter most are the immutable ledger and the Accounts Frozen Till Date control in accounts settings, which must be confirmed against your version's documentation.

DeployOpen prepares the system, the configuration baseline and the evidence set, and documents how each control is designed and operated. DeployOpen does not issue audit reports, attestations or certifications, and it does not replace your internal audit or external auditor. Ask any implementation partner to state in writing which controls they configure, which they only document, and which remain entirely with your team, such as periodic access recertification and the review of exceptions. Confirm with your auditor which evidence format and retention period they expect before the first test cycle begins.

Mapping SOX IT control requirements to ERPNext capabilities

This table pairs each SOX IT control area with the ERPNext capability that addresses it and the configuration an assessor will ask about. Read each row as a starting point: the control requirement comes from the supplied SEC and PCAOB guidance, while the ERPNext settings must be verified in the client's own version and environment. The main takeaway is that ERPNext supplies building blocks for these controls, but the evidence and the operating procedures around them remain the client's responsibility.

Control area	ERPNext capability	Configuration needed and what to confirm
Segregation of duties and privileged IT personnel (AS 2110, B4)	Role permissions, user permissions and document-level sharing	Map each finance task to a distinct role and review roles for overlapping create, submit and approve rights. Confirm the role permission report in the client's version and test with sample users.
Unauthorized changes to master data	Role permissions on master DocTypes, Track Changes and version logs	Restrict edit rights on suppliers, customers, items and bank accounts to a named master-data role. Confirm which master DocTypes have Track Changes enabled and how logs are retained.
Immutable ledger	Enable Immutable Ledger accounts setting	Decide whether reversal entries will replace edits to posted history. Confirm the setting's behavior on existing data and whether it is enabled before go-live, since the client should check the accounts settings documentation for effects on migrated records.
Frozen accounting periods	Accounts Frozen Till Date and a designated frozen-entries role	Set the frozen date at each period close and limit the editing role to a small, named group. Confirm who approves exceptions and that the date changes are logged.
Program change control for custom apps and scripts	Server Scripts gated by server_script_enabled, custom apps in version control	In version 15 and later, Server Scripts are disabled by default. Confirm whether the setting is enabled, restrict who can write scripts, and move approved code through a tested release process outside the production site.
Access to programs and data (directory-based access)	LDAP login with group-to-role mapping at each login	Map directory groups to ERPNext roles and confirm the mapping runs at each login so removed users lose roles. Confirm TLS settings and test a deprovisioning case.
Access to programs and data (single sign-on)	Social Login Key for OAuth or OpenID Connect providers	Configure the identity provider for ERPNext sign-in and confirm that local password logins are restricted where policy requires. Confirm which providers the client's identity team supports.
Computer operations and recovery evidence	Scheduler, background jobs and the client's own backup process	ERPNext does not supply this control by itself. Confirm the backup schedule, restore tests and job monitoring with the client's operations team and document the results as evidence.

Which audit evidence ERPNext can produce and how to keep it

Auditors testing IT general controls ask for evidence that access was granted deliberately, that accounting history stayed locked, and that changes were approved and reviewed. The cards below map each common request to the ERPNext record that answers it and the retention habit that keeps it usable. Auditors decide whether any item is sufficient for their testing.

Role and user permission exports

Export the role assignments for every user, the Role Permission Manager settings for sensitive DocTypes, and any User Permission restrictions, dated at each review. Auditors use these to test whether anyone holds privileges beyond their duties, the segregation of duties risk that PCAOB AS 2110 raises. Keep a dated snapshot before and after each quarterly review, and record who approved each change. Store the exports outside the ERPNext site so an administrator cannot quietly edit the only copy.

Frozen period and immutable ledger settings

Keep a dated record of the Accounts Frozen Till Date value and the Enable Immutable Ledger setting, along with the role allowed to edit frozen entries. Auditors compare these values against the close calendar to confirm that closed periods could not be changed by ordinary users. Capture a screenshot or settings export each time either value moves, and retain the change request that authorized it. Confirm with your auditor how they want the history of the setting itself presented.

LDAP and SSO configuration records

Retain the LDAP Settings and Social Login Key configuration, including SSL/TLS options, the group-to-role mapping, and the identity provider each login uses. Auditors test whether authentication is centralized and whether role assignment from directory groups matches approved access. Export the configuration at each change and keep the directory group membership reports that support it. Confirm how deprovisioning in the directory flows through to ERPNext logins, since disabled users must lose access.

Data Import logs for bulk loads

Bulk loads of customers, suppliers, items and opening balances through the Data Import tool are changes to master data, a risk AS 2110 names as unauthorized changes to master files. Keep the source spreadsheet, the template version, the import log showing created and updated records, and the approval for each load. Auditors look for evidence that loads were reviewed before posting. Import in batches of a few thousand records, as the documentation advises, so each batch can be reconciled on its own.

Approval and change records for code

Custom apps, client scripts and server scripts that affect financial documents need the same change control as production code. Keep them in version control with reviewed pull requests, tagged releases tied to each deployment, and a record of who approved each merge. Server Scripts are disabled by default from version 15 and must be enabled explicitly, so keep the setting change itself in the evidence file. Confirm with your auditor which change tickets they will sample.

Periodic access review records

Keep signed access reviews that list every user with finance-relevant roles, the reviewer, the date, and the removals made. Auditors test whether reviews happened at the frequency management defined and whether the reviewer had enough information to judge the access. Pair each review with the user list exported from ERPNext and the directory group list, so differences are visible. Retain these reviews for the full audit period, and ask your auditor what review frequency they expect for your risk profile.

How the access, ledger and change controls depend on each other

The access, ledger and change controls in a SOX-scoped ERPNext instance form a chain, and a weak link early in it undermines everything after it. The identity source comes first. If users sign in through LDAP, which ERPNext supports against Active Directory or OpenLDAP with group-to-role mapping applied at each login, or through a Social Login Key connected to your identity provider, then the directory decides who holds which role. Roles then determine who can create, submit, amend or edit documents. Because ERPNext maps LDAP groups to roles at login, a change in the directory flows into ERPNext on the user's next sign-in, so auditors will ask whether joiner, mover and leaver steps are tested against that flow, not only against the Desk screens.

The ledger controls sit on top of those roles. Setting Accounts Frozen Till Date blocks ordinary users from creating or changing entries on or before the date, and only a designated role can edit frozen entries, so that role's membership becomes a key-person control to review each period. Enabling the immutable ledger setting makes corrections post reversal entries instead of rewriting older ledger history. Confirm in your release's accounts settings documentation how these two settings interact with amended documents and with the roles you assign, and test both on a non-production site before you rely on them.

Change control is the last link and the one that differs most by hosting choice. Custom apps, client scripts and Server Scripts can alter how posting and approvals behave, so every change to them needs the same approval trail as a change to a financial rule. Server Scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. A self-hosted deployment can allow them, which means you own the review and release process for that code. Decide early whether Server Scripts are needed at all, because the answer changes the scope of your change-control design. Confirm the exact behavior for your version before you finalize the control narrative.

Configuration sequence for a SOX-ready ERPNext

This sequence moves a self-hosted ERPNext from a supported version to a tested state where access, posting and change controls can be shown to an auditor. Each step closes with evidence that the control works, so the final review rests on records rather than on memory of how the system was set up.

Confirm supported version and update cadence
Finance systems and IT leads choose a major version that is still within Frappe's published support window and record who watches release notes for both ERPNext and the Frappe Framework. Frappe's supported versions page lists the end-of-life dates, and the GitHub releases page shows frequent minor releases on each supported line. Confirm whether a Frappe Cloud support plan matching your version is part of your plan, since the vendor's warranty coverage depends on it. The output is a written version decision, a named owner for patch intake, and a test environment where each minor release is applied before production.
Deploy self-hosted with a chosen install method
The platform or infrastructure team selects bench on Linux, Docker Compose from the frappe_docker project, or another method the organization already runs, based on its operating standards. The chosen method sets how backups, TLS, database services and background workers are maintained, so it should be recorded alongside the configuration. Production deployments should not use the single-file demo setup, which the project marks for short-lived evaluation only. The step is done when production, test and development sites are separate, each reachable only from approved networks, and a backup has been restored into the test site.
Connect identity through LDAP or social login
The identity team connects ERPNext to the directory that already governs staff accounts, using LDAP against Active Directory or OpenLDAP, or Social Login Key with an enterprise OpenID Connect provider. With LDAP, group membership maps to ERPNext roles at each login, so removing a person from a directory group removes their system access at the next sign-in. Confirm which option your identity provider supports, enforce TLS for directory connections, and document which accounts remain local, such as a break-glass administrator. The output is a login test showing that a leaver's account is blocked and that role mapping matches the design from the next step.
Define roles and the segregation of duties matrix
Finance leadership and the controller agree on which duties must stay apart, such as creating vendors, approving payments, posting journal entries and administering users, then map each duty to an ERPNext role. The matrix records every role, the documents it can create, submit, cancel or amend, and the people assigned to it. Watch for users who hold system administration rights alongside business roles, because the PCAOB's risk guidance lists privileges beyond job duties as a threat to segregation. The step is complete when the matrix is approved by the business owner, and a user report confirms that no single account holds conflicting combinations.
Enable immutable ledger and set accounts frozen date
The finance owner enables the Enable Immutable Ledger setting so that corrections post reversal entries instead of rewriting older ledger history. The same owner sets Accounts Frozen Till Date to the close date of the last locked period and names a single restricted role that may edit frozen entries when a documented exception is approved. Ask the vendor or your implementation partner to confirm how the setting behaves with your existing data before enabling it in production. The output is a test in which an ordinary user cannot post into a frozen period, the designated role can, and the exception produces a logged reversal.
Restrict server scripts and custom app deployment
Developers and the change board agree that server scripts, custom apps and customizations reach production only through a controlled pipeline with version control, peer review and a test sign-off. In Frappe version 15 and later, Server Scripts are disabled by default and must be enabled through the server_script_enabled setting, so keep that setting off in production unless a reviewed change requires it. Limit who can create or edit client and server scripts to the developer role, and record every exported customization in source control. The step is done when a production change is traced from a reviewed commit to a deployment record, and a test confirms that an ordinary user cannot create a script.
Test access and posting controls
An internal audit or controls team, separate from the people who configured the system, runs scripted tests against the test site. They attempt the prohibited combinations from the matrix, post into a frozen period, change a master record such as a bank account or vendor bank detail, and attempt a script change by a non-developer. Each test records the expected result, the actual result and the user, role and timestamp. Failures return to the owner for correction and are retested. The output is a signed test workbook, which becomes the primary evidence the auditor sees for these controls.
Set a recurring access review
The control owner schedules a periodic review in which managers confirm each user's roles, the directory group memberships that drive them, and any open exceptions to frozen periods or script restrictions. Access removed for leavers and transfers is compared against the directory and the ERPNext user list. The review cadence is set by the company's own policy and the auditor's expectations, so confirm it with them before the first cycle. The step closes when the first review is signed, each exception has an approver and an end date, and the signed review is filed with the test workbook for the audit period.

Questions CFOs and IT leaders ask before a SOX audit of ERPNext

Does installing ERPNext make us SOX compliant?

No. ERPNext is software, and SOX Section 404 applies to the controls your management designs, operates and evaluates. ERPNext can host controls such as role permissions, approval workflows, an immutable ledger and frozen accounting periods, but each control needs a documented owner, a defined procedure and evidence that it operated. The Sarbanes-Oxley Act requires management's annual assessment of internal control over financial reporting, and the auditor decides whether your evidence supports the conclusion. Treat the software as one component of a control environment that your finance and IT teams own.

What drives the cost of an ERPNext SOX control review?

The cost follows from the written scope, not from a standard package. The main drivers are the number of roles and approval paths to design, how many custom apps, server scripts and client scripts need change control, how many integrations feed the ledger, and how your existing identity setup (for example LDAP or single sign-on) maps to ERPNext roles. Ask any partner for a quote that lists each area, the deliverables such as a role matrix and test scripts, and whether ongoing evidence collection or retesting is included or billed separately. DeployOpen does not publish prices and provides a quote after the scope is agreed in writing.

How long does a SOX-ready ERPNext configuration take?

Duration depends mostly on your audit calendar and on how quickly process owners decide on the control design. Controls need to operate for a period before an auditor can test them, so changes made close to fiscal year end leave little time for evidence to build up. Plan the work backward from your interim testing dates and your year-end. Ask for a timeline with fixed milestones for the role design, approval workflow testing, change control setup and evidence walkthrough with your external auditor, and confirm which dates depend on your auditor's availability.

What must our team provide before an implementation partner starts?

Your team needs to supply the business decisions that a partner cannot make for you. Typically this includes:

Named process owners for revenue, purchasing, payroll interfaces, close and financial reporting
A current role and access matrix, including who can post, approve, release payments and change master data
Approval limits and the people authorized to approve them
Read access to your ERPNext test and production environments, identity provider and hosting platform
A written change management policy that covers custom apps, scripts and configuration

If these inputs are unclear, the design phase will slow down. Confirm ownership of each input in the scope document.

Can our in-house IT and finance team do this without a partner?

Yes, if your team has Frappe and ERPNext skills, understands your financial reporting risks, and has enough time to design, test and document the controls. The work is less about configuration screens and more about proving that controls worked across a period. Many teams underestimate the testing effort, including negative tests where a user without rights attempts a restricted action. Assess your internal capacity against the role matrix, the change process and the evidence the auditor will request, and decide whether an outside review of your design is worth the cost.

Will our external auditor accept the evidence ERPNext produces?

The external auditor decides whether evidence is sufficient, and DeployOpen does not issue audit opinions, attestations or certifications. What you can do is agree the control design and the evidence format with your auditor before the period you need tested begins. Auditors under PCAOB AS 2201 test controls and assess IT risks under AS 2110, so expect requests for role assignments, change tickets, approval records and frozen period settings with their history. Confirm the sample sizes and the population definitions with your auditor early, because those choices decide how much evidence you must retain.

Does a SOX review of ERPNext justify skipping the auditor attestation?

Not on its own. The SEC estimated in its 2020 release on accelerated filer definitions (Release 34-88365) that a newly exempt issuer would save about 210,000 dollars per year on average, roughly 110,000 dollars in audit fees and 100,000 dollars in other costs. That figure concerns filer status under Section 404(b), which depends on your public float, revenue and status as an emerging growth company, not on your ERPNext configuration. Confirm your filer status with your legal and audit advisers before you plan around any exemption.

What ERPNext does not cover for SOX ITGCs

ERPNext can enforce some of the controls an auditor tests, but it cannot make the ICFR assessment, issue the auditor's opinion, or run the infrastructure under the application. The cards below name each gap and the party who owns it, so nothing is assumed to be covered by the platform.

ICFR design and management assessment

Management, not the software, must decide which controls address financial reporting risks and evaluate them at each fiscal year end under Rule 13a-15(c). ERPNext can produce evidence for those controls, but it cannot scope them. Your finance and internal audit leads own the risk assessment, the control matrix and the conclusion. Check that every ERPNext control in your matrix names an owner, a frequency and the evidence that proves it ran.

External auditor attestation

Where Section 404(b) applies, an external auditor tests ICFR under AS 2201 and assesses IT risks under AS 2110. That attestation is the auditor's work, and DeployOpen does not issue audit reports or attestations. Your auditor decides the samples, the population and the reliance on automated controls. Ask them early which ERPNext reports, configuration exports and logs they will need, and agree on the format before the audit period starts.

Infrastructure and data center controls

Backups, patching of the operating system and database, network segmentation, physical access and disaster recovery sit beneath the ERPNext application. Your infrastructure or hosting team owns them, whether the servers run in your cloud account or your data center. Confirm that database and file backups are tested by restoring them, that the restore evidence is kept, and that privileged access to the database bypasses ERPNext permissions only through a logged, approved path.

Written policies and periodic review

Access reviews, change approval rules, incident handling and retention periods must exist as written policies that your organization approves and reviews on a schedule. ERPNext can hold the roles and logs, but it does not decide who should hold them. Your security and finance owners write the policies, run the periodic reviews and sign them. Keep the signed review records with the exports they relied on, because auditors test whether the review happened, not only whether the setting exists.

Frappe version and support governance

Warranty coverage from Frappe depends on running a listed version and holding a matching Frappe Cloud support plan, so the version you run is a control decision. Your platform team owns the upgrade calendar, the test of custom apps against each release, and the record of which version was live during each audit period. Check the supported versions page before you commit to an upgrade path, and confirm with Frappe which support arrangements apply to a self-hosted deployment.

Controls outside the platform

Some controls happen outside ERPNext, such as a manual wire approval in a bank portal, a signed paper contract or a verbal sign-off on a journal entry. ERPNext cannot enforce those steps, so an auditor will test them as manual controls. Your process owners must record them, link them to the ERPNext document they affect and keep the approver's evidence. Map each manual step to a named owner before you rely on it in the control narrative.

Who owns which part of the control environment

Management owns the assessment of internal control over financial reporting, and that ownership does not move to a software partner or to the auditor. SEC guidance in Release 33-8810 says management only needs to evaluate the IT general controls necessary for the proper and consistent operation of other controls that address financial reporting risks, and need not evaluate IT general controls that only affect operational efficiency. That scoping point is the first decision to make. Before any ERPNext setting is changed, ask your audit firm which automated controls in the ledger, payables, receivables and inventory cycles depend on ERPNext, and which access, change and operations controls those automated controls rely on. That list defines what the ERPNext configuration must support.

DeployOpen can configure and document the ERPNext side of that list: role profiles and permission rules, approval workflows, the Enable Immutable Ledger setting, Accounts Frozen Till Date, the change process for custom apps and scripts, and the evidence those controls produce. DeployOpen does not own the controls themselves, performs no attestation, and does not issue audit reports. Your finance and control owners still approve who holds each role, who may edit frozen entries and when a period is closed. Your infrastructure and operations teams own the hosting layer, including identity providers, backups, database access, patching, network controls and the privileged accounts that sit beneath ERPNext. Those controls are outside the ERPNext configuration, and a gap there can undo an otherwise sound application design.

The external auditor tests the controls under PCAOB AS 2201 and assesses IT risks under AS 2110, so the auditor is the party whose expectations matter most for evidence format and sampling. Agree early on which reports, logs and screenshots the auditor will request, and who produces each one. Write down the handoffs between teams in a responsibility matrix that names an owner for each ERPNext control, each infrastructure control and each evidence artifact. Confirm this matrix with your audit firm before implementation starts, because changes to scope after build usually cost more than the matrix itself.

How DeployOpen scopes and delivers SOX-oriented ERPNext configuration

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including ERPNext. For SOX IT general controls, we start from the controls your auditors will test, configure ERPNext to meet them, and leave you with the evidence and runbooks your team needs to keep them operating.

How we scope

We map the financial reporting processes and in-scope ERPNext modules that your control owners and auditors agree matter.
The written scope lists roles, approval workflows, frozen periods, change control and evidence deliverables before any build starts.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing ahead of the work.
We confirm which ERPNext version, hosting model and custom apps are in use, since these change the control design.

How we build

We design role permissions and segregation of duties from a documented access matrix, then configure and test them in a non-production site.
We configure the immutable ledger and Accounts Frozen Till Date settings according to your period close calendar and approval rules.
We bring custom scripts and apps under version control with reviewed, tested release steps that match your change process.
We test each control with positive and negative cases, recording results that an independent reviewer can repeat.

How we hand over

You receive control descriptions, configuration records and test scripts mapped to the controls agreed in scope.
We document the evidence auditors typically request, such as role exports, approval logs and change records, and where each one is stored.
Operating runbooks cover access reviews, frozen period changes, emergency changes and periodic re-testing by your team.
We walk your control owners and administrators through the handover so the configuration can be operated without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can cover ERPNext upgrades and retesting of affected controls when custom apps or scripts change.
Support scope, response expectations and review cadence are written into the agreement before work starts.
Your independent auditor and certification bodies remain responsible for any opinion on your controls, and we prepare the evidence they test.