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.

Separating the duties, at a glance

Decide which separations you need, in a table that says, for each one BigLedger cannot enforce, who checks instead and when (Step 1).
Set the roles, knowing which permissions the server enforces and which only hide a button (Step 2).
Review the week’s manual journals every Friday, by somebody who did not key them (Step 3).
Know what a locked period stops, and prove it did not move: save the month’s journal list and net profit when you lock it, and compare them at the next month-end (Step 4).
Correct a posted entry so the evidence survives: reverse it by default, or post an adjustment for the difference that says what it adjusts (Step 5).

Steps 1 and 2 are on this page; Steps 3 to 5 are on Review, lock and correct.

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. Only the purchase order and purchase requisition screens can submit a document to BigLedger’s document-approval engine, 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.

Who watches the owners and administrators. Nobody reviews their own work, so what an owner or administrator posts is read by somebody who is not one. At GS the senior accountant does it in the Friday review (Step 3): the listing’s search covers Created By and Updated By, so every journal an owner or administrator created or updated that week is found by name. Once a quarter, a director who is not on the list compares it with the administrator’s user list and signs it. You know it held when the quarter’s list is signed, every name on it has a written reason, and every journal by a name on it carries the initials of somebody who is not on it.

Before you start

Whoever administers your users, for about an hour. Step 2 sets the rights in each applet’s permission settings, and who belongs to which team.
A list of everyone in finance and the role each holds today, so the Step 1 table starts from what is true now.
The names of everyone with owner or administrator rank. No right in the table binds them (Two things to know first), so the list comes first.
The finance manager’s time. Step 1’s outcome is a table agreed with them.

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. For a month you have locked, the journal list saved at the lock (Step 4) catches a deletion whatever accounts it touched. What this cannot catch: a journal keyed and deleted between two Fridays changed no figure, but it leaves no evidence either
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.

Next: Step 3, review the week’s manual journals.

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

In brief: the lock is checked when a manual journal is created and when a document is finalised. Journals written by documents still post into a period locked for GL only, an existing journal can be edited, deleted or cloned into a locked month, and anyone who can update the fiscal year can set a period back to open with no approval. So the control is who holds those rights, plus a check that the month did not move: save the month’s journal list when you lock it, and compare at the next month-end. The full step, with the check, is Step 4 on Review, lock and correct.

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, the weekly sheets showing that every reviewed journal was still there a week later, and for every locked month the journal list saved at the lock with today’s comparison, (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)