Open source ERP for SOX IT general controls

Auditors expect a traceable record for every program change showing the request, the business justification, the approval by someone other than the developer, the test result and the production promotion date. In a self-hosted Odoo or ERPNext system, the ticket usually lives in the client's own tracker (Jira, Azure DevOps or similar), so the gap usually sits between that tracker and the code repository. Check that each Git commit or custom app release links to a ticket ID and that no custom module reaches production without an approved ticket. Standard Odoo or ERPNext configuration changes made through the user interface need their own ticket and an export or screenshot of the before and after values, because the application itself does not hold the approval.

Auditors look for dated test scripts, the tester's name, the expected and actual results, and sign-off by the business owner before promotion. For Odoo or ERPNext, the strongest evidence is a repeatable test plan run on a non-production copy, such as an Odoo database duplicated and neutralized for testing or an ERPNext test site, with screenshots or exported results attached to the change ticket. A common gap is that testers run ad hoc checks with no written expectations, which makes it hard to show the control operated as designed. Confirm that test environments are separated from production and that the test data used is recorded.

A promotion log shows which build or code version was deployed, when, by whom and under which approved ticket. Auditors test whether the person who deployed was authorized and whether the deployed artifact matches what was tested. In a self-hosted deployment, this evidence comes from the CI/CD pipeline logs, deployment records for Docker images or bench-based releases, and server audit logs for the production host. Gaps appear when developers have direct shell access to production and can copy files without a pipeline record. Ask whether the production image hash or commit ID is recorded for each release.

Auditors ask for a complete listing of ERP users with their roles, status and last login, plus a documented periodic review in which a manager confirms that access still matches the job. In Odoo, the user list and access rights groups can be exported, and in ERPNext, the User and Role Permission Manager reports show roles and document-level permissions. The gap often sits in access granted through identity integration, because LDAP or social login can grant access that does not appear in a local role report. Confirm that terminated employees are disabled in both the directory and the application, and that the review covers segregation of duties conflicts, such as one user able to create and approve vendor payments.

Auditors care about changes to system parameters, tax rates, approval thresholds, number sequences and automated calculations, because PCAOB AS 2201 notes that automated application controls can depend on tables and parameters such as a rate table. In Odoo, configuration changes to settings and chart of accounts are recorded in the chatter or tracking fields for many models, but not every setting is tracked, so verify coverage for each parameter the controls rely on. In ERPNext, the Version doctype records changes to tracked documents, and Server Scripts, which are disabled by default from version 15, are a separate change surface that needs its own log. Build a parameter inventory mapped to each control and check that every item has a change record.

Privileged access logs show who used administrator, database or operating system accounts, when, and for what purpose, and auditors use them to test the risk that IT staff hold privileges beyond their duties. For a self-hosted Odoo or ERPNext system, evidence includes the Linux host login and sudo logs, PostgreSQL or MariaDB access logs, the application's superuser or Administrator activity, and the approval for any break-glass access. A typical gap is that the database administrator can change financial tables directly, bypassing application logs. Confirm that privileged sessions are recorded centrally, that the Administrator account is restricted, and that database changes outside the application are reviewed.

Auditors expect data conversion evidence showing that opening balances, open items and master data in the new system agree to the legacy system at cutover, with reconciliations signed by the owner of each balance. Evidence includes record counts, control totals for each entity and currency, trial balance comparisons, and documented exceptions. For Odoo or ERPNext, data is usually loaded through the import tooling, and the ERPNext Data Import tool documentation advises importing only a few thousand records at a time, so batch logs and load files should be retained with the reconciliation. The gap sits in unexplained differences that are carried forward without sign-off. Confirm who approves the cutover reconciliation and that the trial loads used the same process as the final load.

No platform passes ITGC testing by itself. Auditors test whether the controls around the system operate, and that depends on how the company runs it. SEC guidance (Release 33-8810) says the IT general controls relevant to an ICFR evaluation vary with each company's facts and circumstances, and no SEC rule or PCAOB standard publishes a fixed catalog. Self-hosting gives you control over change approval, access, parameters and data conversion, which is what auditors look at. Whether those controls are designed and operating well enough is a question for your independent auditor. DeployOpen prepares the systems, controls and evidence for that assessment but does not issue audit reports or attestations.

The timeline depends on scope, which is set in a written, fixed-scope agreement before work starts. The main drivers are the number of ITGC areas in scope, the state of existing change and access records, how many environments the system has, and how much historical data is converted at go-live. Auditors generally test controls over a period, so evidence has to exist for that period. Ask any partner to show how they break the work into phases and which evidence each phase produces. DeployOpen does not publish a price list or timeline; a quote follows from the scope you agree.

Expect to supply the following before a partner can design or test controls:

• A list of the financially relevant modules, companies and reports in the ERP
• Current user roles, access reviews and the people who approve access
• Your change management policy, ticket history and release records
• Configuration and parameter records, including any rate or tax tables that drive automated calculations
• The data conversion plan and reconciliation sign-off from the last migration

Auditor expectations on automated controls and their supporting tables are described in PCAOB AS 2201, so gathering these early avoids rework.

Yes, many finance and IT teams run ITGC programs internally, and the decision depends on skills, capacity and independence. Testing the same change or access control you designed, or that your own engineers operate, can weaken the evidence an auditor relies on. Internal teams need knowledge of the ERP's configuration model, its privileged roles and its upgrade process. A partner can help design controls, prepare evidence and run security tests, but management still owns the ICFR assessment under Rule 13a-15(c). Decide who will own each control before you choose the route.

Each upgrade is a program change, so it needs the same approval, testing and evidence as any other change. For Odoo, the upgrade service moves a database to a newer supported version through an upgraded test database that should be tested before production, and on-premise use requires an Enterprise subscription. Odoo's standard support covers three years after a major release, and Odoo 20.0 standard support is planned until September 2029. Odoo's documentation says major upgrades are mandatory every two years on Odoo Online and Odoo.sh. For ERPNext, Frappe lists version 15 as supported until the end of 2027 and version 16 until the end of 2029. Plan an upgrade test cycle and a regression test of key automated calculations each time.

No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors perform the ICFR attestation required under Section 404 for applicable issuers, and management performs the annual ICFR assessment. DeployOpen plans, implements, hardens and documents self-hosted open-source systems, prepares controls and evidence for compliance assessments, and runs security testing. Ask your auditor which evidence formats they accept and share that list with any partner before work begins.