Open source accounting software and SOX ITGC

How open source accounting software supports SOX IT general controls

If you must show Section 404 controls over a self-hosted general ledger, start with a fact that shapes everything else: no SEC rule or PCAOB standard publishes a catalog of IT general controls. Management decides which IT general controls support reliable financial reporting, and the external auditor tests the ones you pick. Under Section 404 of the Sarbanes-Oxley Act (15 U.S.C. 7262), management assesses internal control over financial reporting every year, and for accelerated and large accelerated filers that are not emerging growth companies, an auditor attests to that assessment. The ledger platform is one input to that assessment. Access, change management, database administration and backups around it are what the auditor will examine, and they belong to your control design, not to the software vendor.

COSO's 2013 framework, in its Principle 11, asks the organization to select and develop general control activities over technology that support its objectives. The PCAOB's risk assessment standard, AS 2110, asks the auditor to understand the IT general controls that matter to automated controls, such as a posting rule, an approval threshold or a three-way match that runs inside Odoo, ERPNext or LedgerSMB. SEC Release 33-8810 adds that you only need to evaluate the IT general controls necessary for other controls addressing financial reporting risk to operate properly. Write that scope down first: list the automated controls the close depends on, then trace each back to the access, change and operations controls that keep them reliable. Confirm the exact control wording with your external auditor before the first test cycle.

DeployOpen plans, implements, hardens and documents the self-hosted platform, and prepares controls and evidence for your assessment. DeployOpen does not issue audit reports, attestations or opinions. Those come from your independent auditor, and your own management owns the conclusion. In a scoping workshop, ask the platform partner to map each control in your matrix to a system setting, a log source and a recurring evidence artifact, and to state in writing which responsibilities stay with your team and which move to the partner. Fixed-scope agreements make that split easier to enforce, because the deliverables and the evidence they produce are written down before work starts.

Which IT general control areas the ledger must cover

This table maps the SEC guidance areas and COSO Principle 11 to the controls a self-hosted Odoo, ERPNext or LedgerSMB ledger needs to show. Read each row as a question the assessor will ask, with the evidence to keep each quarter. The main takeaway is that which controls are in scope depends on your own risk assessment, and the FTC Safeguards rows apply only if you are a covered financial institution.

Control area	What the ledger must show	Evidence to keep each quarter
Program development and change control	Custom modules, reports and server scripts are reviewed, tested and approved before they reach production	Change tickets, test sign-off, deployment logs and a list of enabled custom code
Program changes and version upgrades	Upgrades to a new major version are tested on a copy of the database before production cutover	Upgrade test plan, test results, approval record and rollback steps
Computer operations	Scheduled jobs, batch imports and month-end processing run as expected and failures are investigated	Job logs, failure tickets and reconciliation of processed batches
User access reviews	Named users and roles are reviewed on a set cadence, with leavers removed promptly	Signed access review reports, user list exports and termination tickets
Segregation of duties in roles	No single user can create, approve and post the same transaction, including role changes to their own account	Role matrix for the ledger, conflict report and approval of exceptions
Database and backup controls	Only named administrators reach the database, and backups are tested by restore	Database access list, restore test records and backup job reports
Logging and activity monitoring	Posting, role and configuration changes are logged with user and timestamp, and logs are protected from editing	Audit log extracts, log retention settings and periodic review sign-off
Authentication (FTC Safeguards, covered institutions only)	Multi-factor authentication for anyone accessing the system, plus encryption in transit and at rest	MFA configuration export, identity provider settings and encryption settings
Risk-based scoping (all entities)	Which controls are tested depends on your risk assessment of financial reporting, not on a fixed list	Documented ICFR risk assessment mapping each control to a financial reporting risk

Which open-source ledger fits a SOX-scoped environment

Each candidate changes who controls the code, the upgrade path and the configuration evidence an auditor will ask for. The cards below cover the decisions that matter for IT general controls: license terms, plan limits, upgrade obligations, support windows and the self-hosting method. They describe fit, not ranking, and every choice should be confirmed against the scope of your ICFR assessment.

Odoo Community as the open core

Odoo Community is published under the LGPL-3.0 license and is the open source core on which the paid Enterprise edition is built. For change management, the question is what your team owns: a Community deployment gives you the source, but you carry the upgrade, patching and testing work yourself. Confirm which accounting features and security updates you need from Enterprise before you commit to the Community path, and document who approves each custom module that touches posting logic.

Odoo Enterprise and the upgrade service

The Enterprise edition's source code is not publicly available and requires a subscription or partner access. On-premise use of the upgrade service requires an Enterprise subscription, and the Community edition has no access to it. Upgrades are tested on a copy before production, so your change records should show who ran the test, what was compared and who signed off. Ask the vendor how the upgrade test database is produced and retained as evidence.

Odoo Custom plan for controlled hosting

According to Odoo's pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. If your ledger spans several entities or needs API-driven access controls, the plan choice sets the hosting boundary before any control design starts. Ask the vendor to confirm the current plan contents in writing, because the features in each tier are the basis for your access and change scope.

ERPNext under GPL-3.0

ERPNext is licensed under GPL-3.0, while the underlying Frappe Framework is licensed under MIT. Both are open source, so the auditor's question becomes operational: which version runs in production, who applied each patch and where the build came from. Keep the version of ERPNext and Frappe together in your configuration baseline, because the two are released and supported as a pair.

Frappe version support dates

Frappe lists version 14 as end of life from January 31, 2026, version 15 as supported until the end of 2027 and version 16 until the end of 2029. Warranty coverage from Frappe depends on running a listed version and holding a matching Frappe Cloud support plan. An end-of-life date becomes a control issue when a ledger is still running on it, so your change calendar should show when each upgrade must be finished, not only when it is convenient.

Server Script defaults from version 15

Starting from version 15, Server Scripts run Python on document events or as API endpoints, and they are disabled by default. They must be enabled with the server_script_enabled setting. Any enablement is a change to the production configuration that changes what code can alter ledger postings, so record who turned it on, why and under which approval. Frappe Cloud public shared benches do not allow them, which affects where you can host custom logic.

Self-hosting ERPNext with Docker Compose or bench

ERPNext can be installed on Frappe Cloud, with Docker Compose, or manually with the bench command line tool. The frappe_docker project provides production images and Compose files with services for MariaDB, Redis, workers, the scheduler and Nginx, while its single-file demo setup is marked for short-lived evaluation only. Your auditor will ask for the deployed image digest, the database access path and the backup schedule, so pick the method your team can reproduce and document from the same pipeline.

LedgerSMB as a candidate to confirm

LedgerSMB is a third candidate for a self-hosted general ledger. This page does not include supplied version, release or support facts for it, so treat it as a candidate to confirm against your requirements. Ask the project and any implementation partner for the current release, the security patch policy, the supported database platforms, the available audit trail for postings and how user access is administered before comparing it with Odoo or ERPNext.

How hosting model changes who produces ITGC evidence

On Odoo Online and Odoo.sh, Odoo operates the hosting layer, so much of the infrastructure evidence sits with the vendor. Your team still controls application users, roles, approval workflows and configuration settings inside the database, and those produce the access and change records you show auditors. Odoo's support model also shapes your patching timeline, because standard support covers the first three years after a major release, while Odoo SaaS versions are released every two to three months and cannot use extended support. Major upgrades are mandatory every two years on these platforms, so the upgrade itself becomes a change event you must document.

Access logs: Ask Odoo which infrastructure and administrator access logs it retains and whether you can obtain them for audit periods.
Patching: Track which supported version you run and plan upgrades inside the standard support window, since SaaS cannot move to extended support.
Backups: Confirm backup frequency, retention, restore testing and who can request a restore, and obtain that in writing.
Change approvals: Keep your own approval records for configuration changes and custom code, because the vendor does not approve your business changes.
Vendor evidence: Request the service description, the independent assurance reports the vendor holds, and any penetration test summaries it will share.

Confirm with Odoo, in writing, what hosting evidence it will provide to your auditors and on what timeline.

Evidence auditors ask for each quarter

This table maps each control area in a self-hosted Odoo, ERPNext or LedgerSMB general ledger to the evidence an assessor usually requests, the component that produces it, and what to confirm. Read it as a quarterly collection checklist, and confirm retention periods with your external auditor before you set any schedule.

Control area	Evidence to keep	Producing component
User access reviews	Signed review extracts of active ledger users, roles and approvers, with reviewer sign-off and remediation tickets	Odoo or ERPNext user and group records, plus LDAP or social login configuration exports
Segregation of duties	Role matrix mapping posting, approval, vendor master and bank rights, with conflicts documented and accepted	Odoo or ERPNext group and permission definitions, exported and compared quarter to quarter
Change management for customizations	Change tickets linked to each custom module, server script or upgrade, with test and approval records	Source repository history, code review records and the deployment pipeline logs
Upgrade test results	Test database upgrade outputs, reconciliation of trial balances before and after, and production go-live approval	Odoo upgrade service test database or ERPNext staging bench, with comparison reports
Database administrator access	Logs of privileged sessions, account creation and password resets on the ledger database, reviewed by someone other than the administrator	PostgreSQL or MariaDB logs, forwarded to a central log store
Backup and restore testing	Dated restore test records showing a backup was recovered to a separate environment and ledger totals matched	Backup tooling job logs, restore run reports and checksum outputs
Audit log exports	Quarterly exports of posting, reversal and configuration change activity, with the period covered and the reviewer named	Application audit trail and the database and web server logs supporting it

Running the ITGC cycle each quarter

The quarterly sequence turns IT general controls from a one-time project into repeatable evidence that shows access, changes, backups and privileged database activity stayed controlled for the period. Each step names what is pulled, who signs it off and what the file should contain before the next step starts.

Pull user lists and role changes
The application administrator exports the active user list for the ERP, with each user's roles, company or entity assignments and status, and pulls the change log for joiners, movers and leavers during the quarter. Records should come from the application itself and from the identity provider if sign-in is federated, so the two can be compared. The step is complete when the population is frozen with a date, a hash or a saved export, and the counts reconcile to the change tickets raised in the HR and access workflow. Confirm with your platform team how the export is generated and who can alter it.
Perform the access review and sign off
The control owner, usually a finance leader who understands each role, reviews every user against the job they hold and marks retained, changed or removed access. Segregation of duties conflicts, such as one person able to create vendors and approve payments, are flagged from the role matrix and resolved or documented as accepted exceptions. The review is done when each reviewer signs the report, the removals are shown as completed in the system, and open exceptions have a named owner. Auditors typically look for evidence that the reviewer had the information needed to judge access.
Review change requests and upgrade tests
The change manager lists customizations, configuration changes and version upgrades that were requested, approved, deployed or left pending during the quarter. For each item, the file should show the request, the approval, the test evidence from a non-production copy and the deployment record. Custom code, such as server scripts or custom modules, should appear in the same list as configuration changes, and any change deployed without approval should be recorded as an exception. The step is complete when every production change traces to an approved ticket and every upgrade has a signed test result.
Verify backups with a restore sample
The platform operator confirms that backups ran on the expected schedule for the database and file store, and that failures were detected and resolved. A sample backup is then restored to an isolated environment, and the restored ledger is checked against known balances or a trial balance from the source. The operator records the backup job logs, the restore steps and the reconciliation result. The step closes when the restore test produces a matching result and the evidence shows who performed it and when, without exposing live finance data to unnecessary staff.
Collect privileged database access records
The database administrator exports the logs of administrative sessions, direct database connections, schema changes and privileged account use for the quarter. These are compared against approved maintenance requests and the list of people authorized for database administration. Any access outside a change window or without a ticket is investigated and documented. The step is complete when each privileged session can be matched to a reason, and the list of accounts with database rights is reviewed and signed. Confirm that logs are retained and protected from the administrators whose activity they record.
File evidence in a controlled repository
The compliance lead gathers the outputs from each step into a single quarter folder in a repository with restricted write access, version history and an index that maps each file to its control. Sign-offs should be stored as signed documents rather than informal messages. The lead checks that the index has no gaps, that each exception has a remediation owner and that the retention period in the company policy is applied. The sequence closes when the folder can be handed to internal audit or the external auditor without further reconstruction.

What the software and the partner cannot settle alone

A self-hosted ledger gives you the controls to point at, but it does not decide which controls matter, who signs off on them, or whether they operated. The cards below cover the decisions and evidence that remain with your finance, IT and audit teams, and with your independent auditor.

Management's ICFR assessment and sign-off

Section 404 requires management to assess internal control over financial reporting each year, and the assessment must be documented and signed off by management. Software cannot make that judgment for you. Your team must decide which IT general controls support reliable reporting, test whether they operated during the year, and record the conclusion. Check that the assessment names the ledger, its database and its integrations, and that the owner of each control is named in the document.

Auditor testing is independent

External auditors test ICFR under PCAOB AS 2201 and assess IT risks under AS 2110, using their own samples and procedures. A vendor or implementation partner can prepare populations, screenshots and change tickets, but cannot stand in for the auditor's testing. Ask your auditor early which reports they will rely on, which system-generated populations they will need to validate, and how many periods of evidence they expect to see for each control.

Risk assessment that selects the ITGCs

No SEC rule or PCAOB standard publishes a fixed catalog of IT general controls. The relevant areas depend on your entities, reporting risks and how the ledger feeds the financial statements. Document which access, change, operations and data controls protect automated accounting controls, and which only affect efficiency. A customized Odoo or ERPNext instance with server-side scripts usually needs a wider set of controls than a stock installation, so reassess the scope after each new customization.

Vendor support limits and patch timing

Support windows decide which versions you can run under vendor cover. Odoo standard support covers the first three years after a major release, and security patches are only provided during standard support. Frappe warranty coverage depends on running a listed version with a matching support plan. Confirm in writing which versions you will run, when each one leaves support, and who applies security patches to a self-hosted instance. Build the upgrade plan into your change calendar.

Written change policy and approvals

Customizations, configuration changes and version upgrades each need a written procedure that defines who requests, who tests, who approves and who deploys. The software will not enforce that workflow on its own. Your policy should cover emergency changes, access to production code, and evidence that the tested build matches the deployed build. Your partner can help draft the procedure, but your change advisory board owns it and must sign the approvals that auditors sample.

Data retention and record decisions

The ledger keeps records only as long as your retention schedule and backup settings allow. Retention periods come from tax law, sector rules and your own policy, and they differ by record type. For example, SEC Rule 17a-4(b) sets a three-year minimum for certain broker-dealer records, with the first two years easily accessible. Decide what must be kept, where, for how long, and who may restore or purge it, and confirm these decisions with legal and tax advisors before configuring backups.

DeployOpen does not issue audit reports

DeployOpen plans, implements, hardens, documents and supports the self-hosted ledger and prepares controls and evidence for compliance assessments. We do not issue audit reports, attestations or certifications. Those come from your independent auditor, and the conclusions on your controls belong to your management. Ask any implementation partner to state this boundary in the statement of work, and agree in writing which evidence the partner will produce and which your team must review and retain.

Questions finance and IT leaders ask before a SOX ITGC rollout

Can an open source ledger pass SOX ITGC testing?

Yes, the license does not decide the outcome; the controls around the ledger do. SOX does not certify software. Management must evaluate the IT general controls that keep financial reporting accurate, and the external auditor tests those controls under PCAOB AS 2201 and AS 2110. Odoo Community, Odoo Enterprise, ERPNext and LedgerSMB can all support these controls if you can show user access reviews, segregation of duties, change management for customizations and upgrades, database access restrictions, backups and retained evidence. Confirm with your auditor early which controls they will rely on, because the scope of ITGC testing depends on each company's facts and circumstances, as the SEC's Release 33-8810 explains.

What drives the effort and cost of a SOX ITGC rollout?

Five factors move the effort most:

The number of custom modules, server scripts or patches that change financial logic, since each one needs its own change record and testing
The number of legal entities, currencies and integrations feeding the ledger, such as banks, billing systems and payroll
The upgrade path, because a major version upgrade retests every control that touches the ledger
How much evidence is collected automatically from logs and ticketing versus by hand each quarter
The internal time that process owners, reviewers and auditors spend, which is usually paid for by the company rather than the implementation partner

One-time costs cover design, configuration, control documentation and the first test cycle. Recurring costs cover access reviews, upgrades, backups testing and hosting. The SEC estimated in 2020 that an issuer newly exempt from the Section 404(b) auditor attestation would save about $210,000 per year on average, which shows how much the attestation itself costs. Ask any partner to quote by control area and entity.

How long does a SOX ITGC rollout take?

The duration depends on the scope agreed in writing, the number of systems in the financial reporting path, and how ready your process owners and evidence sources are. A single-entity Odoo or ERPNext instance with standard modules and few integrations generally takes less time than a multi-entity group with custom financial logic and bank feeds. Two timing points are worth planning around. First, the first audit cycle needs controls to have operated for a period before the auditor can test them, so design work and first operation run ahead of the audit date. Second, Odoo on Odoo Online and Odoo.sh requires major version upgrades every two years, so your control calendar should include upgrade testing. Ask a partner for a timeline tied to named milestones and to your audit calendar.

What does the company have to provide for the engagement?

The company must supply the people and access that make the controls real, because an implementation partner cannot approve your own access or sign off your own changes. Expect to provide:

Named process owners for revenue, expense, close, payroll and treasury, each accountable for their controls
Administrative access to the ledger, database and hosting accounts for the duration of the work, with a plan to reduce it afterward
Written approvers for change requests, access requests and control exceptions, separate from the people who build the changes
Identity provider access for single sign-on or LDAP integration, and the sign-off authority for production releases

Confirm with your auditor which sign-offs they require and in what format before work starts. DeployOpen prepares systems, controls and evidence for assessments, but does not issue audit reports or attestations.

Can our internal team run SOX ITGCs after the rollout?

Often yes, if the team can perform the recurring work reliably each quarter. Recurring tasks include reviewing user access and role assignments, checking the change log for every customization and upgrade, confirming backup restore tests, reviewing database access and privileged activity logs, and keeping the evidence file current. The harder part is independence: the person who builds a change should not be the only person who approves it. Smaller teams often use a retainer for upgrades, testing and periodic control reviews while keeping day-to-day evidence in-house. Ask any partner which tasks they would hand over, what documentation they would leave, and how knowledge transfer is verified before the engagement closes. DeployOpen offers ongoing support and upgrades as retainers.

Which evidence should we keep each quarter for ITGC testing?

Keep evidence that proves each control operated during the period, not only that it was designed. Typical items include signed user access review reports with the reviewer's name and date, role change tickets, segregation of duties conflict reports, change records linked to test results and approvals, upgrade test database results, backup job logs and restore test records, and database administrator access logs. Store them in a location that the people who operate the system cannot alter. For FTC or SEC record keeping, note that SEC Rule 17a-4(b) sets retention periods for broker-dealer records, which may apply if you are in that sector. Confirm your retention schedule with your auditor and legal counsel.

What if we customize Odoo or ERPNext heavily?

Heavier customization increases the number of ITGC controls you must maintain. Custom modules, server scripts and third-party apps each need version control, peer review, testing and a release record, and they must be retested after every platform upgrade. In ERPNext, Server Scripts run Python on document events and are disabled by default from version 15, so enabling them should itself be a logged, approved change. In Odoo, custom modules are available only on the Custom plan, and Enterprise source is not publicly available, so confirm your edition and upgrade rights before designing controls around them. Ask any partner to list every customization and assign it to a control owner before quoting.

How DeployOpen scopes and delivers SOX-ready ledger controls

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source accounting platforms inside the client's own infrastructure. We prepare the systems, access controls, change records and evidence that management and external auditors need for IT general controls, and we do not issue audit reports or attestations.

How we scope

Engagements are fixed-scope, with the in-scope ledger, modules, environments and control areas agreed in writing before work starts.
We map which ledger processes feed financial reporting risks, so the IT general controls in scope match what management must evaluate.
The written scope names user access reviews, segregation of duties, change management, database access and backups as separate deliverables.

How we build

We configure role-based access, approval paths and segregation of duties rules in the chosen platform before go-live, then test them with named users.
Customizations and upgrades go through a documented test database and change record, with test evidence kept before any production release.
Database access, backup schedules and restore tests are configured in your environment, and restore results are recorded as control evidence.

How we hand over

You receive control narratives, a control matrix, configuration baselines and runbooks that your auditors and internal audit can walk through.
We document the quarterly evidence set for each control, including access review exports, change tickets, backup logs and privileged access records.
Knowledge transfer sessions cover the people who will run reviews after handover, so the evidence process does not depend on DeployOpen staff.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing against your upgrade and release calendar.
We help your team prepare for each assessment cycle by refreshing evidence packs and re-testing controls after platform or customization changes.
Questions about what your external auditor will accept should be confirmed with that auditor, and we prepare the evidence to match the agreed scope.

Open source accounting software and SOX IT general controls