Which ERPNext audit trail records help with ICFR evidence
A finance or controls lead at a US-listed or SOX-scoped company running self-hosted ERPNext needs to show auditors who changed financial data, which amended documents changed and who exported or printed what. ERPNext's Track Changes version logs, the Audit Trail for amended submittable documents, the Access Log for prints and exports, and the immutable ledger can supply much of that evidence. They support internal control over financial reporting (ICFR), but they do not make a control effective. Designing the controls, testing them and deciding whether they meet the standard remain the company's job, and the auditor's attestation remains the auditor's.
Section 404 of the Sarbanes-Oxley Act (15 U.S.C. 7262) requires management to assess ICFR each year. For accelerated and large accelerated filers that are not emerging growth companies, an external auditor must also attest to that assessment. SEC guidance in Release 33-8810 says that management only needs to evaluate the IT general controls that keep other financial reporting controls operating properly and consistently. The first task is therefore to list which financial controls depend on ERPNext records, then decide which logs answer which question. For example, a change to a posted sales invoice may need the Audit Trail, while a bulk export of customer balances may need the Access Log. Confirm with your auditor which of these records they will accept, and how far back they will sample.
DeployOpen prepares the ERPNext configuration, log retention settings, and evidence folders so that your team and auditor can test these records. DeployOpen does not issue audit reports, attestations or certifications, and it cannot confirm that your ICFR design is sufficient. Before the work starts, agree in writing which DocTypes are in scope, who holds the System Manager role, where exported logs will be stored, and which evidence the auditor expects. Those decisions shape the scope and cost of the work more than the number of logs enabled.
Mapping SOX requirements to ERPNext audit capabilities
This table maps the SOX-related control areas that auditors test against the ERPNext features that produce evidence for them. Read each row as a question an assessor may ask, the ERPNext feature that answers it, and the configuration you must confirm. The main takeaway is that the SEC says relevant IT general controls vary with each company's facts, so the mapping is a starting point for your own control design, not a fixed checklist.
| Control area | ERPNext capability | Configuration needed |
|---|---|---|
| Program changes (SEC Release 33-8810 example area) | Version log from Track Changes records edits to each enabled DocType, while Audit Trail compares at most five previously amended versions of a submittable document | Enable Track Changes in Customize Form for each in-scope DocType, and confirm the field list captured for each |
| Access to programs and data (SEC Release 33-8810 example area) | Access Log, introduced in version 13, records prints, private file downloads and XLSX or CSV exports | Restrict System Manager access to a named group, and confirm the Access Log is retained on your version |
| Computer operations (SEC Release 33-8810 example area) | Scheduled jobs and background activity are not covered by the document logs described here, so operations evidence comes from your own hosting and job records | Document which operational records you keep outside ERPNext and who reviews them |
| Role and access permissions | Role permissions control who can view, edit, submit or cancel documents, and who can see Access Log entries | Map roles to job duties, remove conflicting combinations, and export the permission matrix for review |
| Immutable ledger and amendments | Submitted accounting entries are amended by cancel and amend, so the Audit Trail links prior versions for review | Confirm period closing and frozen-period settings, and test that cancelled and amended entries appear in the trail |
| COSO Principle 11 over technology general controls | COSO Principle 11 asks management to select and develop general technology controls that support objectives, which these ERPNext logs can feed | Assign an owner for each technology control and record how the logs support the objectives in your control matrix |
| AS 2110 understanding of IT general controls for automated controls | Auditors test whether the automated controls in ERPNext depend on controls over changes and access, and the logs above are often the first evidence requested | Ask your external auditor which ERPNext logs and reports they expect, and confirm retention with them before testing begins |
How Track Changes, Audit Trail and Access Log differ
Track Changes, Audit Trail and Access Log answer three different audit questions, so reviewers should not treat them as interchangeable. Track Changes answers what was edited and when. Once you enable it for a DocType in Customize Form, ERPNext creates a Version log for each edited document of that DocType. The log records the field-level history of ordinary edits, which makes it the first place to look when an auditor asks how a master record or transaction reached its current state. It does not, by itself, show how a submitted financial document was amended, and it does not record who viewed or exported data.
Audit Trail answers how a submittable document changed across amendments. Frappe's Audit Trail compares at most five previously amended versions of a submittable document and shows the fields that changed and the child table rows that were updated, added or removed. Because of the five-version limit, a document amended more often than that will not show its full amendment history in this view, so confirm with your own controls how older versions are retained and reviewed. Access Log answers who took data out of the system. Introduced in ERPNext version 13, it records printing of forms and reports, private file downloads and XLSX or CSV exports, and it is available to System Managers.
Two points need deliberate planning. Enabling Track Changes is not retroactive, so edits made before the setting was switched on have no Version log, and you should document the enablement date for each DocType in your evidence pack. Coverage is also set per DocType, so do not assume a DocType is tracked because its neighbors are. Build a register listing each in-scope DocType, its Track Changes status, whether it is submittable for Audit Trail purposes, and who reviews Access Log entries. Confirm the current behavior of each feature against the ERPNext document versioning documentation and the Frappe Framework audit trail documentation in your release before you rely on them in a control narrative.
Evidence auditors request from ERPNext and how to keep it
Auditors rarely accept a live screen as proof. The items below are the records they ask for most often when they test financial controls in ERPNext, and each one needs an export taken on a known date and stored outside the application. Your retention period should come from your company's records policy and your auditor's requests, not from this page.
Version logs for financial DocTypes
Enabling Track Changes in Customize Form creates a Version log for each edited document of that DocType. Turn it on for the DocTypes your auditors will test, such as Sales Invoice, Purchase Invoice, Journal Entry and Payment Entry, and confirm the setting is in place before the period under review starts. To keep evidence, filter the Version list by DocType and date range, export it, and file the export with the period and the person who ran it. Note that the log only starts from the day tracking was enabled.
Amendment comparisons for submitted documents
The Audit Trail compares at most five previously amended versions of a submittable document and shows changed fields and child table rows that were updated, added or removed. For each amended invoice or journal entry in scope, capture the comparison view, including the amendment chain, and record the reason for the amendment from your own approval record. Confirm with a test document that the comparison shows the changes your auditors will look for, and plan for the five-version limit on documents amended more often than that.
Access Log exports for prints and exports
The Access Log, introduced in version 13, records printing of forms and reports, private file downloads, and XLSX or CSV exports, and it is available to System Managers. Auditors often ask who printed or exported a trial balance, a payment register or a customer statement during a close. Filter the log by report, user and date, export the result, and store it with the sign-off for the period. Confirm with a test print and a test export that the entries appear as you expect before you rely on them.
Role and permission exports
Auditors test who held System Manager or finance roles and whether that access matched approved duties. Export the User list filtered by role, the Has Role assignments, and any User Permission records for companies or cost centers, then compare them against the access approval for the same date. Repeat the export at each review point and keep a record of who approved each change. Changes made between exports will not appear in an older export, so take a fresh snapshot before each review.
Ledger and frozen period settings
Auditors will ask whether posted ledger entries can be changed and whether closed periods are locked. Export the Accounts Settings values for freezing the accounting period and the frozen-by role, along with the posting date restrictions and the Stock Settings for stock freezing. Record the values with the date and the person who changed them, and keep a copy of the change log for the settings themselves. Ask your implementation partner or ERPNext documentation to confirm which fields apply to your version before you rely on them.
Retention and off-application storage
Store every export in a system your finance and IT teams control, not only inside ERPNext, so the evidence survives a restore, a site change or a user leaving. Name each file with the DocType or report, the period, the export date and the preparer, and set a retention schedule from your company's records policy. Include the access controls on the storage location, and review the schedule with your auditor and legal team before the first audit cycle.
Configuration choices by company size and control design
A single legal entity with a SOX scope usually needs one consistent evidence set across the financial DocTypes. Start from the documents that feed the financial statements, such as sales and purchase invoices, payment entries, journal entries and stock transactions, and decide with your auditor which of them need Track Changes turned on in Customize Form. Access Log review is typically owned by the controller or a finance systems owner, who reviews prints and exports of sensitive reports on a schedule you define.
- Track Changes scope: Enable it on the financial DocTypes that auditors will sample, and record the list in your control narrative.
- Access Log ownership: Assign one named reviewer who is not a routine preparer of the reviewed documents.
- Evidence location: Keep periodic Access Log extracts and Version log exports in a controlled repository with restricted write access.
- Amended documents: Test how the Audit Trail displays cancelled and amended invoices before relying on it as evidence.
- System Manager access: Limit the role, since it reads the Access Log and can change configuration.
Confirm the in-scope DocTypes and review frequency with your auditor before the first audit period begins.
A group with several companies in one ERPNext instance has to decide whether evidence is kept per company or consolidated for the parent. Track Changes is configured per DocType, so the same setting applies to every company sharing that instance, which makes the coverage decision a group-wide one. Access Log reviews may need to be split by company, because a reviewer for one subsidiary may not be the right person to examine another entity's exports, and multi-company restrictions affect what each reviewer can see.
- Group-wide coverage: Settings apply to all companies in the instance, so document any company-specific exceptions in writing.
- Split review ownership: Assign reviewers per company or per entity, and define who reviews consolidated reports.
- Consolidated evidence: Decide whether parent-level auditors receive one combined extract or one per entity.
- Intercompany documents: Include intercompany invoices and journal entries in the coverage list for both sides.
- Access boundaries: Confirm that a reviewer can see the Access Log entries they are responsible for, and no more.
Ask your group auditor which entities are in scope and whether consolidated or entity-level evidence is expected.
An organization that already runs a governance, risk and compliance platform usually wants ERPNext evidence to flow into that system rather than sit in a separate folder. The GRC tool typically becomes the system of record for control definitions, test plans and sign-offs, while ERPNext remains the source of the underlying logs. This changes the design: you need to decide which ERPNext outputs are exported, in what format, how often, and how the GRC tool confirms completeness of each export.
- Control mapping: Map each ERPNext control, such as Track Changes coverage or Access Log review, to the GRC control record and its owner.
- Export design: Decide whether exports are scheduled extracts, manual downloads or API pulls, and document the format.
- Completeness checks: Record how the GRC tool or reviewer confirms that an export is complete for the period.
- Ownership split: Clarify who maintains the ERPNext configuration and who maintains the GRC evidence record.
- Retention alignment: Match ERPNext log retention to the period the GRC tool and auditors require.
Before building exports, confirm with your auditor and your GRC administrator which evidence they accept as the primary record.
Configuring audit records in ERPNext for an ICFR review
This sequence sets up the ERPNext records an auditor will ask for, from the agreed list of financial documents through to a documented test and a recurring evidence export. Each step ends with an artifact that management and the external auditor can review.
Agree the in-scope DocTypes and controls
Management, the internal audit or compliance lead, and the external auditor agree which financial DocTypes fall within the ICFR evaluation, such as Sales Invoice, Purchase Invoice, Journal Entry and Payment Entry, and which controls each one supports. Only IT general controls that keep financial reporting controls working need evaluation, so the list should stay tied to financial risks rather than every DocType in the system. The output is a signed scope list that names each DocType, the control it supports and the owner responsible for it.
Enable Track Changes for scoped DocTypes
A System Manager opens Customize Form for each in-scope DocType and turns on Track Changes. From that point, each edited document of that DocType creates a Version log entry. Changes made before this setting was enabled are not captured, so the date of activation must be recorded in the change log. The check is a sample edit on a test site, after which the Version list shows the old and new values for the changed fields.
Confirm Access Log behavior on a test site
On a test site, a System Manager prints a form and a report, downloads a private file and exports a list to XLSX and CSV, then opens the Access Log to confirm each action is recorded with the user and the document. The team should also confirm which report or print paths are covered in the version in use, since coverage is a documented feature rather than a guarantee for every custom print format. The output is a test record showing which actions appear in the log and which do not.
Restrict the System Manager role
The System Manager role can change configuration, customize DocTypes and read the Access Log, so the list of holders should be short and reviewed. The implementation team removes the role from users who only need transactional access, assigns it only to named administrators, and records who holds it at the start of the evaluation. The output is a role assignment report that the auditor can compare against the access review. Segregation of duties between posting users and administrators should be confirmed against the scope list from the first step.
Set frozen accounting periods
The accounting team sets a frozen accounts period so that closed months cannot receive new or changed postings, and limits who may change the freeze date. Testing covers an attempted posting into a closed period, which should be blocked for ordinary users, along with a review of the list of users allowed to edit the freeze date. The output is a documented freeze date, the approver for changes to it, and the test result.
Test the amendment comparison on a sample invoice
A tester creates a sample Sales Invoice, submits it, amends it and changes a field and a child table row. The Audit Trail should compare the amended version with the previous one and show the changed fields and the child rows added, updated or removed. Frappe's Audit Trail compares at most five previously amended versions, so the test should note the number of amendments the scoped process could produce. The output is a saved test record with screenshots and the exported comparison.
Document the test under change control
The team records each configuration change, the test scripts, the expected and actual results and the approver in the change control system. Any custom server script or client script that alters posting, validation or the audit fields must go through the same change control, because scripts can change behavior that the tests rely on. Server Scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting, so enabling them is itself a change to record. The output is a change record that links each test to the control it supports.
Schedule periodic evidence exports
The team sets a recurring task, owned by a named person, that exports the Version log, the Access Log, the role assignment report and the frozen period settings for each period. Exports are stored in a location with restricted write access and retained according to the records policy the auditor agrees. The output is a dated evidence folder for each period, and a periodic check that confirms the exports ran and match the scope list. Ask the auditor which periods and formats they expect before the first export.
What ERPNext does not cover for SOX
ERPNext records many financial changes, but several parts of a SOX control environment sit outside the application. Each card below is a gap to confirm against your own deployment, and each one needs an owner, a control or a compensating process before an auditor asks.
Version history stops at five amendments
Frappe's Audit Trail compares at most five previously amended versions of a submittable document. If your policy requires a longer history of changes to invoices, journals or master data, you need an archive outside the application that keeps every version. Confirm how far back your retained evidence actually goes for your most sensitive DocTypes.
Access Log is not a full read log
The Access Log records prints, private file downloads and XLSX or CSV exports. It does not record every read of a record inside the application, such as a user opening a ledger in the desk. Decide whether your auditors need read tracing for sensitive data, and if so, test whether your current logs or a separate monitoring layer provide it.
Database, backups and servers sit outside records
Changes made directly in the database, restores from backup, OS-level administration and changes to the web or worker servers do not appear as application records. Confirm who holds database and server access, how those actions are logged at the infrastructure layer, and how you show that a restore did not alter financial data.
Key controls are your decision
ERPNext does not decide which controls are key, design them, test their operation or issue an attestation. Management must identify the controls that address financial reporting risk, document them, and test them over the period. Confirm the control owner, test frequency and evidence for each one, and whether an independent auditor will rely on them.
Enabling Server Scripts changes controls
From version 15, Server Scripts are disabled by default and must be turned on with server_script_enabled. Once enabled, users with the right permissions can run Python that changes data on document events, so the change control, review and access over those scripts become part of your ICFR scope. Confirm who can enable them and how each script is reviewed and recorded.
Operational-only IT controls may be excluded
SEC guidance says management need only evaluate the IT general controls necessary for the proper and consistent operation of controls that address financial reporting risks. Controls that only affect operational efficiency need not be evaluated. Document which ERPNext controls you treat as in scope and why, so the scoping decision itself is evidence that auditors can review.
Questions CFOs and controllers ask before hiring help
Does ERPNext alone satisfy SOX requirements?
No. ERPNext is software, and SOX Section 404 places the obligation on management to assess internal control over financial reporting each year, with an auditor attestation required for some issuers. ERPNext can supply features such as Track Changes, the Audit Trail, the Access Log and role permissions, but those features only become evidence once management has decided which controls matter, how they operate and who reviews them. Under the SEC's guidance (Release 33-8810), the IT general controls you need depend on your company's facts and circumstances. Confirm the scope with your external auditor before configuring anything.
What does the configuration and evidence work cost, and what drives it?
Cost depends on the work scope, which is agreed in writing before the engagement starts. The main drivers are the number of DocTypes that need Track Changes or review, the number of sites and companies, the number and complexity of custom apps and scripts that touch financial documents, and whether your company already has a documented controls framework and control owners. A company with a mapped control matrix usually needs less discovery than one starting from scratch. Ask for a quote that separates one-time configuration from recurring evidence collection and any retained support. DeployOpen does not publish prices.
How long does the work take, and what depends on the auditor's timeline?
Duration depends on how many controls are in scope, how many systems and sites are involved, and how quickly your team can review draft configurations. The auditor's fieldwork calendar also sets deadlines, so the work is usually planned backward from the period the auditor will test. Ask for a timeline that lists discovery, configuration, a test period in which evidence is generated, and sign-off. Also ask what happens if the auditor requests a change in sample selection late in the cycle.
What must our company provide during the engagement?
The engagement needs more from your side than from the implementer. Expect to provide:
- A named process owner for each financial process in scope, such as order to cash or procure to pay
- System administrator access in a non-production environment, and a supervised path to production
- Sample transactions and historical documents for testing amendments, exports and prints
- Access to your control documentation and the auditor's requests
- Written sign-off from process owners and the controller on the final control design
Confirm who in your organization can approve each item before the work starts.
Can our internal team do this without an implementation partner?
Often yes, if the team has ERPNext administration experience, understands the controls the auditor will test, and has time to run the evidence process for the full audit period. The harder parts are usually the control design and the documentation that connects a feature, such as Track Changes, to a specific risk and owner. Teams that lack Frappe experience often struggle with custom apps and server scripts, which are disabled by default from version 15 and need the server_script_enabled setting. Assess your team against the controls in scope before deciding.
What is the SEC's estimate of savings from exemption from the auditor attestation?
The SEC estimated in 2020 (Release 34-88365) that an issuer newly exempt from the Section 404(b) auditor attestation 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 describes the regulatory cost effect of an exemption for qualifying issuers. It is not a price for configuring audit trails in ERPNext, and it does not show what your own engagement will cost. Check with your auditor whether your filer status changes your attestation requirement.
What should a quote list before we sign?
A written quote should list the following:
- The controls and processes in scope, with the ERPNext DocTypes and features used for each
- The sites, companies and custom apps covered
- Deliverables, such as configuration records, test scripts, evidence procedures and a control narrative
- Who performs each task and what you must provide
- The test period and how evidence will be retained
- Recurring items, such as evidence review or retained support, separated from one-time work
- Exclusions, including anything the auditor must decide, such as attestation
Request a clear statement that DeployOpen prepares evidence and does not issue audit opinions.
How DeployOpen scopes and delivers audit evidence setups
DeployOpen starts every audit evidence setup with a written, fixed scope agreed before work begins. The scope names the DocTypes that carry financial or access-sensitive data, such as Sales Invoice, Journal Entry, Payment Entry, Purchase Invoice and the Customer and Supplier masters, and states which of them get Track Changes turned on through Customize Form. It also records whether Access Log coverage is needed for printing, private file downloads and XLSX or CSV exports, and which roles are expected to read those logs. Deliverables, timelines and the acceptance steps are written down so the client can compare the quote against the work it actually receives. Because the Audit Trail only compares up to five previously amended versions, the scope should also say how the client expects to retain older evidence if a document is amended more often than that.
Delivery runs on a non-production site first. DeployOpen configures the settings, makes test edits, amends a submitted document, exports a report and prints a form, then confirms that the Version log and Access Log show what the evidence process expects. The output is a short set of runbooks: how to review the logs, who performs each review, how exports are retained, and what to do when a log entry looks wrong. DeployOpen prepares these systems, controls and evidence, but it does not issue audit reports, attestations or certifications. The client's external auditor decides whether the evidence is sufficient for the engagement, so the scope should be agreed with that auditor's expectations in mind. Where a client wants ongoing review of log configuration after an ERPNext upgrade or a custom app change, DeployOpen offers retainers for that continuing work.
