Who May Change the Books

A finance team that keeps its books in BigLedger has to decide who may post, who may correct, who may delete and who may reopen a closed month. By the end of this guide you will have a one-page table of those rights for your team, the reviews that make up for the approvals BigLedger does not have, and a way to prove next month that a locked period has not moved. Setting it up takes about an hour with whoever administers your users. The monthly review takes about twenty minutes.

This page is for the finance manager who owns the controls, and for the auditor who will test them.

Meet GadgetSphere

GadgetSphere Sdn Bhd (GS) has a finance team of six: a finance manager, a senior accountant, three accounts clerks (receivables, payables, cashbook) and a part-time assistant who helps at month-end. The group’s IT administrator creates the users. Until now everyone in finance has had the same role, because it was quicker to set up. The auditors have asked who can post a journal, who can delete one, and who can reopen December.

Two things to know first

Nothing in finance routes for approval. A manual journal is checked for balance by the server and is in the ledger the moment it is saved. There is no draft, no posting step and no approver. BigLedger’s approval engine covers purchase orders, purchase requisitions and stock requisitions, and journals are not among them. So wherever this page says “approve”, it means a person reviews what was already posted. It is a detective control, not a preventive one, and it has to be run on a timetable or it is not a control at all.

Owners and administrators are not bound by any of the rights below. Every journal, GL code and fiscal-year action BigLedger checks lets a tenant owner or administrator through, whatever roles they hold. However carefully you separate the duties of your clerks, whoever holds owner or admin rank can do all of it. Keep that rank to as few people as the business can run on. Treat every one of them as holding every right in the table below.

Step 1: Decide which separations you need

The outcome: a table, agreed with the finance manager, of which duties must never sit with one person, and how each separation is kept.

Keep apart	Can BigLedger enforce it?	If not, who checks instead, and when	How they know it held
Keying a manual journal and approving it	No. The journal is live on save	The finance manager reads every manual journal created that week, every Friday (Step 3)	Every manual journal on the listing has the reviewer’s initials on the weekly sheet, and nobody reviewed their own
Keying a supplier payment and releasing it	Partly. Give the right to create a Payment Voucher and the right to finalise it to different roles. The bank transfer itself is released in your bank’s own system, with its own approvers	The finance manager, at each payment run	No payment voucher was created and finalised by the same user. The bank’s release log shows a second person
Maintaining the customer master and writing off a customer’s debt	As far as applet access goes: Customer Maintenance and the credit note applet are separate applets, so give them to different roles	The finance manager, at the quarter’s review	The person who approved a write-off did not also edit that customer’s record that quarter
Adding a GL account and posting to it	Partly. Adding a GL code is its own right. Do not give it to the clerks	The senior accountant, at month-end: export the chart and compare it with last month’s	Every new account has a written request behind it
Deleting a posted journal	Treat this as not enforced. The Journal screen has a delete right, and it is still worth keeping out of everybody’s day-to-day role, but it is not a control you can rely on to keep deletion away from any one person	The finance manager, every Friday, as part of the weekly review (Step 3): last week’s sheet is carried forward and every journal on it is looked for on the listing again. At month-end, the Step 4 check	Every journal on last week’s sheet is still on the listing. A deleted journal drops off the listing, so one that has gone was deleted, and the person who deleted it explains why in writing. What this cannot catch: a journal keyed and deleted between two Fridays leaves nothing to find, and a deletion that touches no profit-and-loss account does not move the Step 4 Profit Loss comparison
Reopening a locked month	Partly. Only someone who can update the fiscal year can do it, and there is no approval on it	The finance manager keeps a reopen log (Step 4)	Every reopening in the log has a reason and a re-lock date, and the close pack figures still agree (Step 4)
Editing a journal that a document wrote	Partly: the screen enforces it, the server does not. The Journal screen will not let anyone edit an automatic journal unless the Allow user to edit auto posted journal setting is on. That setting is read by the screen only, so treat it as a guard against a slip, not as a control	The finance manager: at each month-end, check the setting in the Ledger and Journal applet’s Application Settings. Every Friday, in the weekly review (Step 3), read the automatic journals updated that week as well as the manual ones	The setting is off, and if it was switched on for a repair, the log says when it went back off. Every automatic journal updated that week still agrees with its document. What this cannot catch: the listing shows when a journal was last updated and by whom, not what changed, so the comparison with the document is the only evidence that it still says what the document says

GS’s result: the three clerks get create rights for their own documents and manual journals. The senior accountant gets GL code create, finalise on payment vouchers and the fiscal-year update right. The finance manager keeps the delete right in a role nobody uses day to day, and the assistant gets read-only access.

What goes wrong if you skip this: everyone in the team can delete a journal, and when a figure moves in a closed month there are six people who could have moved it.

Step 2: Set the roles, and check what the screen does not tell you

The outcome: the rights in the table are actually assigned, at the level where they are enforced.

Settings > Permission Set / User / Team / Role Permission in each applet, and Teams and Permissions for who belongs to which team.

Know which kind of permission you are setting. A client-side permission only shows or hides a button in the browser. A server-side permission decides whether BigLedger carries out the request at all. For creating GL codes and updating the fiscal year, the server check is the one that counts. For deleting a journal, and for editing one that a document wrote, do not count on either: Step 1 treats both as not enforced, and the reviews in Steps 3 and 4 are the control. Settings and Permissions explains the difference in full.

How you know you got it right: ask the administrator for the list of roles and who is in each, and read it against your Step 1 table. The GL code create right and the fiscal-year update right sit only where the table puts them, the journal delete right sits in the one role nobody uses day to day, and no clerk is an owner or administrator. This proves the roles match the table. It does not prove that a clerk cannot delete a journal, which is why Step 3 looks for deletions every Friday.

Step 3: Review the week’s manual journals, every week

The outcome: every manual journal has been read by somebody other than the person who keyed it, within a week of it being posted.

Finance > Ledger and Journal > Journal Transaction

Switch on the Type, Created Date, Created By, Updated Date and Updated By columns. The listing is ordered by updated date, so the most recently touched journals are at the top. For each manual journal created or updated since last Friday, check four things:

Description and support. Every one says what it is for, and the calculation or document behind it is filed.
Account. Nothing posted by journal to a receivables, payables, bank or output-tax control account without a reason on file. Those accounts have a document-based list behind them, and a journal there opens a difference between the two (Reviewing a Set of Books, Step 2).
Date. The transaction date is in an open month. A journal created this week and dated into a month you have already reported on changes that month.
Who. The creator is not you. If it is, the senior accountant reviews that one.

Then two checks the manual journals alone would miss:

Automatic journals updated this week. For any automatic journal whose Updated Date falls in the week, open the document behind it (the Doc No column) and confirm the journal still agrees with it. If it does not, the document is the one to correct (Step 5).
Last week’s sheet, carried forward. Record each journal’s Journal No on the sheet. Look each of last week’s journals up on the listing again. The listing shows active journals only, so a journal that has gone was deleted since you reviewed it. Ask who deleted it and why, and write the answer on the sheet.

How you know you got it right: the weekly sheet lists every manual journal from the listing with initials against it, the count on the sheet matches the count on the listing, and every journal on last week’s sheet is either still on the listing or has a written reason for its deletion. The review cannot see a journal that was keyed and deleted between two Fridays; the Step 4 check at month-end is the backstop for one that moved a profit-and-loss figure.

Step 4: Know what a locked period stops, and prove it did not move

The outcome: you know exactly what the lock guarantees, and you have a check that catches everything it does not.

Master Data > Chart of Account > Fiscal Year > (the year) > Fiscal Period

In the occupation’s language, a closed period means no further movement without authority. In BigLedger it means less than that, and it is safer to know exactly how much less:

The lock is checked when a manual journal is created (lock GL or lock all) and when a document is finalised (lock transactions or lock all).
Journals written by documents still post into a period locked for GL only. The lock stops people keying journals, not documents posting.
An existing journal can be edited, deleted, or cloned into a locked month. None of those paths checks the lock.
Anyone who can update the fiscal year can set a period back to open, with no approval, and set it locked again afterwards.

None of this makes the lock useless. It stops the ordinary mistake, which is a clerk keying this week’s journal into last month. It does not stop a person with the rights to do otherwise, so the control is who holds those rights (Step 1), plus a check that the month did not move.

The check, for every locked month, at the next month-end:

From your close pack, take the month’s net profit and the closing balances of your bank, receivables and payables control accounts, as they were when you locked it.
Run the ad-hoc Profit Loss Report (Finance > Financial Report > Profit Loss Report) for the locked month. It reads the posted journals as they are now, not the stored month-end summary. Compare its result with the close pack.
Filter the Journal Transaction listing to transaction dates in the locked month and read the Created Date and Updated Date columns. Anything later than your lock date moved a closed month.
Keep a reopen log outside BigLedger: who reopened which month, when, why, what they posted, and when it was re-locked.

If the month did move, legitimately, re-run Month End Processing for that month and every month after it, in date order, then regenerate every Financial Report snapshot that includes those months. Each month’s opening balance is built from the month before, so a gap anywhere carries forward. If statements for that month have already gone to the bank, the auditors or the tax agent, they must be re-issued, and whoever received them told what changed and why.

How you know you got it right: for every locked month, the live Profit Loss result equals the close pack figure, and every journal created or updated after the lock date is in the reopen log.

Step 5: Correct a posted entry so the evidence survives

The outcome: every correction leaves both the mistake and its fix on the record, so a reviewer can see what happened.

There are three ways to correct a posted entry. They are not equally good:

Route	In BigLedger	What a reviewer can still see
Reverse	Open the journal, CLONE it, swap every debit and credit, then post the correct entry	The original, the reversal and the correction, all on the listing. The pair nets to zero and tells its own story. Use this by default
Adjust	Post a new journal for the difference only	The original and the adjustment. Clear, as long as the description says what it adjusts
Amend or delete	Edit the journal, or delete it from the listing	Only the result. A deleted journal and its lines are marked deleted and drop out of every balance, and no reversing entry is written. The listing no longer shows a pair a reviewer can read

Deleting is fine for a journal you keyed a minute ago that nobody has reported on. After that, reverse. A journal that a document wrote is corrected through the document: a credit note against the invoice, or a void. Do not edit the journal, because the document and its journal would then permanently disagree. That is why the Allow user to edit auto posted journal setting belongs off.

The auditor’s year-end adjustments

The auditor proposes the adjustments. The auditor does not post them. Give the audit team read access only, for the duration of the audit. The adjustments are posted by the finance manager or the senior accountant, like this:

Which period. The last month of the financial year, so that the audited accounts and the books agree. For GS that is December 2026, which is locked, so it is reopened for the purpose and the reopening goes in the log.
How. One manual journal per adjustment. The description quotes the auditor’s adjustment number (for example “Audit adj 4 — FY2026 bonus accrual”), and the auditor’s schedule is filed as its support.
Then. Re-run Month End Processing for December and for every later month already processed, in date order, regenerate the snapshots, and re-lock December.
The record. The adjustment journals, the auditor’s schedule and the reopen log entry go into the year-end close pack.

How you know you got it right: the Trial Balance for December 2026 agrees with the audited trial balance line by line, and every difference between the draft and the final accounts is an adjustment journal with the auditor’s number in its description.

What success looks like

In 30 seconds: you can hand the auditor (1) the Step 1 table with a name in every row, (2) a list of who holds owner or admin rank, (3) the role that holds the journal delete right, who is in it, and the weekly sheets showing that every reviewed journal was still there a week later, (4) twelve weekly journal-review sheets with initials, and (5) the reopen log, with a close pack figure that still agrees for every locked month. If any of the five is missing, that is the control the auditor will report.

Common mistakes

Mistake	What you see	What to do instead
One role for the whole finance team	Anyone can delete a journal, reopen a month or add an account	Split the rights as in Step 1
Separating the clerks and forgetting the admins	Every separation holds, except for the person who can do everything	Name every owner and admin, and keep the list short
Hiding a button and calling it a control	The button is gone and the request still succeeds from another route	Find out whether the server checks it (Step 2). Where you cannot rely on that, run a review that would notice (Steps 3 and 4)
Trusting the lock	A figure in a closed month changes and the lock never complained	Run the Step 4 check at every month-end
Deleting a journal that has been reported on	A figure that changed with nothing on the listing to explain it	Reverse by clone instead (Step 5)
Letting the auditor post	Adjustments nobody in finance owns, and an auditor who has audited their own work	Read-only access for the auditor; finance posts (Step 5)