How to Lock Down Journal Entries in NetSuite

A posted journal entry that someone else created was unlocked, the GL account changed, and the entry resubmitted. As Controller you now see the wrong account and a broken audit trail, with no way to confirm what the original posting looked like. This is a controls gap, and it is fixable with the right permission set and an approval workflow. Here is how NetSuite actually handles this, and how to lock it down properly.

The Audit Trail Is Still There

Before you change anything, know that NetSuite preserves the record of that edit. The System Information subtab on the journal entry holds the full history, but only users with the right permission can read the detail.

Open the journal entry and go to the System Information subtab. Under it you'll find the Workflow History and the System Notes. The System Notes log every field change: who made it, when, the old value, and the new value. For line-level changes, click the History link on the far right of each line. That window shows the action, the user, the timestamp, the old value, and the new value for the affected field.

The catch is visibility. If you only see the total amount and the original poster's name, your role lacks the permission to read the detail. Users need the Financial History permission to view transaction history. Some roles have this by default, such as accounting clerks and sales administrators. Grant that permission to your finance roles so you can pull the old GL account and the new one.

The audit trail is fully reportable. Go to Transactions > Management > View Audit Trail to see system notes for multiple transactions filtered by field values. You can also run the Transaction Audit Trail report, which is available by default to CEO, CFO, and Support Administrator roles. Custom roles need the audit trail permission assigned to access it. Once that permission is in place you can export the history for your files. Your auditors will thank you.

Why "Book a Correcting JE" Is the Wrong Reflex

Your instinct to post a separate adjusting entry is natural, and it is how accountants are trained. In NetSuite it is usually the wrong move. The platform assumes you correct the original transaction, not that you reclassify around it.

The reason is transaction type. NetSuite's native reports and subledgers key off the original transaction. If you post a journal entry to your inventory account instead of correcting the source transaction, the native inventory reports don't know about it. The same logic applies to vendor bills, invoices, and payments. Slamming in a journal entry that "makes the financials right" leaves the subledger out of sync with the general ledger.

So the fix for the incorrect GL account is not to book a reclass entry. It is to correct the original journal entry, then document why the correction happened in the memo. The audit trail stays intact, and the subledger and GL stay aligned.

Lock the Record With an Approval Workflow

The real controls problem is that the entry was editable after posting. NetSuite's native behavior allows edits to posted journal entries in the current period unless you restrict them. The standard control is the Journal Entry Basic Approval Template in SuiteFlow.

Enable the Require Approvals on Journal Entries preference first. Go to Setup > Accounting > Accounting Preferences, then the General subtab. Check the box labeled Require approvals on journal entries.

Then create a workflow from the Journal Entry Basic Approval template at Customization > Workflow > Workflows > New. That template does three things that matter here:

• It sets the approval status to Pending Approval on submit and locks fields like Journal Created By, Approval Status, and Journal Approved By.
• It routes the entry to the preparer's supervisor or an administrator for approval.
• Once approved, the record is locked to all users except administrators.

That last point is the control you want. An approved journal entry cannot be edited by anyone without the Administrator role. The person who changed your entry would have needed to be an administrator to do it, which is itself a red flag worth investigating.

One nuance from the template: if the user who creates the journal entry has no supervisor, that user can approve their own entry. If your org chart has gaps, that self-approval path is a hole. Edit the workflow to use an approval group or a specific approver role instead of the supervisor hierarchy.

Tighten the Permissions That Let This Happen

The approval workflow is the primary lock, but permissions can still open the door. Several settings weaken the control if left wide:

• Override Period Restrictions (Setup > Users/Roles > Manage Roles > Permissions > Setup subtab). This lets a user add and make general ledger impacting changes in a locked or closed period. It should sit only on a small set of senior finance roles.
• Journal Entry > Create and Journal Entry > Edit permissions. Scope these to the roles that actually prepare and approve entries. A reporting role should not gain edit rights silently.
• Make Journal Entry and Approve Journal Entry permissions. Separate the preparer from the approver so no single role does both.

Build One Role So You Stop Switching

You mentioned jumping between three roles to do your job. That is a configuration problem, not a NetSuite limitation. NetSuite lets you build a single custom role that combines the permissions you need.

Open Setup > Users/Roles > Manage Roles, click New, and copy the most powerful of your three roles as a starting point. Add the missing permissions from the other two, then assign that one role to your user record. You keep the audit trail of what you do under a single role, and you stop the context-switching that invites mistakes.

Restrict Cross-Subsidiary Approval

Your second concern is that users in other subsidiaries can approve parent journals. That usually means the approval workflow is routing to a generic approver role rather than to a role scoped to the parent subsidiary.

In the workflow, change the approval step to route to a specific role or approval group tied to the parent subsidiary. Then verify the Subsidiary field on the journal entry and the approver's role both align. If a user at another subsidiary still sees the Approve button, their role has the Approve Journal Entry permission at a scope broader than their subsidiary, and that permission needs to be narrowed.

What to Fix First

Start with the approval workflow, because it locks the record and closes the exact gap you hit. Then narrow the Override Period Restrictions and journal entry edit permissions. Then consolidate your roles so a Controller works from one role instead of three. The audit trail was never lost; it was just hidden behind a permission you did not have. Grant the view, lock the record, and the next time someone changes a journal that is not theirs, you will not only see it, you will stop it from happening.