Set of Books, Fiscal Years and Fiscal Periods

You have three companies to close every month and a group accountant who wants one set of statements per company, and you have just discovered that BigLedger will happily let a cashier finalise a cash bill dated last February. By the end of this page you will have a Set of Books for each company that the financial reports can read, a fiscal year with twelve periods for each, and the closed months locked so that the February cash bill is refused — and you will know exactly which lock refuses what, because the three locks do not do what their names suggest. Setup takes about twenty minutes for three companies. There is nothing to install.

The screens are all in the Chart of Account applet; that page lists every field. This page is about what the records mean and what the system does with them.

Meet GadgetSphere

GadgetSphere Sdn Bhd (GS), GadgetSphere Online Sdn Bhd (GSO) and GadgetSphere Distribution Sdn Bhd (GSD) each keep one primary ledger in MYR and close on a calendar year. The group finance team closes each company’s month by the 10th of the next month, after which nobody in the 22 branches should be able to post a sale into it, while the accountants themselves can still post adjusting journals. Once the auditor signs off the year, the accountants stop too. That is two different locks at two different moments, which is exactly what the periods are for.

Three things, and what each one is for

The thing	What it decides	Whether you need one
Set of Books	Which ledgers a financial report reads. A report is generated for one Set of Books (a name, a code, a currency) and covers every ledger linked to it	Yes, before any financial report will run. One per reporting basis — a second ledger kept under a different accounting standard or currency gets its own
Fiscal year	The date range a company reports on — not necessarily January to December	Only if you want date locking. One per company per year, and nothing creates it for you
Fiscal period	One slice of the year, and the only thing that can be locked. Each period carries a closing status that decides whether documents and journals dated inside it are accepted; twelve per year in practice	Only if you want date locking. The screen generates them twelve at a time from the year, and a period is the only record a lock can sit on

Before you start

Each company exists in Organisation, and each has a primary ledger — the Chart of Account applet’s Companies → Ledgers tab shows it. A Set of Books with no ledger linked is refused by the report engine with Set of Books is missing primary ledger configuration.
You can open the Chart of Account applet with rights to create Set of Books and Fiscal Year records. Whoever can edit a fiscal period can unlock it — there is no approval step — so restrict this to the people who close the books.
Nothing is created for you. A new company has no fiscal year and no Set of Books, and a company with no fiscal year is never locked: the lock check counts matching locked periods and finds none. If you have been running for a year without one, every date has been open the whole time.

Step 1: Create a Set of Books per company

Chart of Account → Set of Books → Create

The outcome: a named bundle of ledgers that Month End Processing and the Financial Report can be pointed at.

Give it a name — GS Statutory, GSO Statutory, GSD Statutory — and on the Ledgers tab link the company’s primary ledger. One ledger per Set of Books is the normal case; the reason a Set of Books can hold several is that the report engine sums every ledger linked to it, so a management-reporting Set of Books that spans two companies’ ledgers is one record here, not a consolidation feature elsewhere.

The name is the only thing the screen asks for, and it is the only thing you will ever see again — the Financial Report’s listing shows it in a Set of Book column. Name it for the company and the purpose. The backend validates nothing about the name or code; it only checks that a currency, if you supply one through the API, exists.

If you skip this step, Month End Processing cannot be created at all — its form requires a Set of Books — and there is no financial report for the company.

Step 2: Create the fiscal year and let the screen build the periods

Chart of Account → Fiscal Year → Create

The outcome: twelve OPEN periods for the company, one per month.

Pick the Company, type a Name (FY2026), and choose the Start Date and End Date. The screen snaps both to whole months — the 15th of January becomes the 1st — and generates one period per month between them, named January 2026, February 2026 and so on, every one with closing status OPEN. A year that runs April to March produces twelve periods just the same, starting at April 2026; the calendar year is not assumed.

Do this once per company. GadgetSphere needs three fiscal years, 36 periods.

One company, one set of periods, no overlaps — ever. When you save, the backend takes every fiscal period the company already has, from every fiscal year, and refuses the save if any new period’s start or end date falls inside an existing one (The date_start and date_end dates are overlapping with an existing fiscal period). This is what stops you creating FY2026 twice. It is also what stops the quarterly tax calendar the developers’ design note describes (quoted under What the backend actually checks): a second, quarterly set of periods for the same company is rejected as overlapping the monthly one. If you need a different year end, delete the old year first — and read What the backend actually checks before you do.

The commonest failure here is a year created with the wrong company selected. The periods save fine, the locks then apply to the wrong company, and you find out when a document in the right company posts into a month you thought was closed.

Step 3: Lock the closed months — in two stages

Chart of Account → Fiscal Year → (the year) → Fiscal Period → (the period) → Closing Status → Save

The outcome: branches cannot post into March; accountants still can, until the year’s audit is signed off; after that, nobody can key a new journal into it.

Lock a month only after it passes the check in the next section, How you know a month is really closed: a lock keeps people out of the month, and it does not tell you the month is complete.

Each period has a Closing Status with four values. The names are misleading, so here is what each one refuses, in plain terms:

Closing status	Sales, purchase, stock and payment documents dated in the period	Manual journals dated in the period
`OPEN`	accepted	accepted
`LOCK_TXN`	refused	accepted
`LOCK_GL`	accepted	refused
`LOCK_ALL`	refused	refused

LOCK_TXN is the month-end lock. Set it when the month closes: GadgetSphere sets March 2026 to LOCK_TXN on 10 April, once the check below passes. From then no branch can finalise a document dated in March, void one, or change its customer or supplier. Accounting continues — adjusting journals, accruals, the month-end journals the report engine writes. Each journal posted after the close changes March, so PROCESS March and every later closed month again, then REGENERATE the snapshots (If something lands in March after you have closed).

LOCK_ALL waits for the audit. When the auditor signs off FY 2026, set every month of the year to LOCK_ALL, and from then a journal keyed on the journal screen is refused too. LOCK_GL is the accountants’ lock alone and does nothing to the branches, so the routine does not use it.

What “refused” looks like: a document’s FINAL fails validation with The selected date falls within a locked fiscal period (a draft still saves; the lock is read at FINAL, at VOID and when the customer or supplier is changed); a new journal is refused at Save (HTTP 403) with the same sentence. Nothing is written.

Two exemptions are built in and you cannot switch them off. Stock transfers (outbound and inbound) finalise into a LOCK_TXN or LOCK_ALL period regardless, so a warehouse can still move stock dated in a closed month; voiding one is still refused. Journals the system writes itself — the ones flagged automatic, which is how month-end processing and document posting create theirs — ignore LOCK_GL and LOCK_ALL. That second exemption is why locking a period does not break Month End Processing, and it is also why a locked period is not a guarantee that its ledger balances are frozen: finalising a document in an LOCK_GL period is allowed, and its automatic journal posts.

LOCK_ALL keeps people from keying into an audited year; it does not freeze it. The lock is checked only where the table says. A manual journal can still be cloned (the clone keeps the original date), edited, re-dated or deleted in a locked month, and a journal file import does not check the lock at all. Moving the date of a FINAL document that has no stock lines does not check it either, and nor does a cash transfer. So after the audit, the control that tells you whether the year moved is the saved journal list, compared again (Who may review and correct the books).

Reopening is the same screen: set the status back to OPEN and save. Any status can be changed to any other, LOCK_ALL included, with no approval. It needs the owner or admin role, or a fiscal-year permission (API_TNT_DM_ERP_FI_FISCAL_YEAR_UPDATE, or the fiscal-year owner or admin permission). It is immediate and unlogged beyond the row’s updated by stamp.

How you know a month is really closed, before you lock it

Month End Processing can report success when part of the close was not written, and a document can be FINAL with no journal behind it. Neither shows on the screen you were using. So a month is closed when somebody has checked it, not when the button says so. At GadgetSphere that is the senior accountant, on the third working day, before the month is locked.

Nothing FINAL is missing its journal. In Ledger And Journal, open Error Checking > Missing Journal. Set the month’s dates and run it once for each Server Doc Type you use. An empty list is a pass. Journal Not Balance is a different list: it should be empty too. The close writes each month-end journal to balance on its own, so one listed there comes from an older close or is rounding (Ledger And Journal › Error Checking tells them apart).
The close is there. For each ledger in the Set of Books, look for two journals described AUTO CREATED FROM MONTH END PROCESSING: one dated the last day of the month, one dated the 1st of the next. Dated the last day, also look for AUTO CREATED FROM RETAINED EARNINGS PROCESSING and, if you post cost of sales this way, AUTO CREATED FROM COGS PROCESSING. These two are refused without a message when their default GL codes are missing (the journal cannot balance), so a missing one points at the company’s defaults.
The statements agree with the lists behind them. Check four pairs. BigLedger compares none of these for you.
- The Debtor Report aging total at month-end against the receivable control accounts on the Trial Balance.
- The creditor aging against the payable accounts.
- Each cashbook’s Cash Level Closing against its GL code, with From set before the cashbook’s first transaction and To on the month’s last day. Cash Level opens at today → today and lists only the cashbooks that moved in the range, so count its rows against the Cashbook listing: a quiet cashbook has no row and is simply not tied (Cashbook › Balances on Cash Level).
- Bank Reconciliation Report 1, which should show no unexplained variance.
Reviewing a Set of Books has the tie-out sheet and says who ties which line. It also says what to do with a difference you cannot explain, which is to escalate it, never to post a balancing journal.
Lock it (Step 3). At the next month-end, confirm the locked month’s Trial Balance has not moved.

What it catches. In March, GadgetSphere opened its twelfth Klang Valley branch, GS-KV-12, and added an e-wallet payment button there. Nobody gave that settlement method a cashbook. Every cash bill paid with it finalised normally. Two jobs then ran after FINAL, one to write each bill’s journal and one to write its cashbook line, and both refused every bill with MISSING_CASHBOOK: STL_MTHD and the settlement item’s code. Nobody at the till saw a message.

Step 1 finds them: 41 cash bills on Missing Journal, RM 18,420 of sales that are in the sales report and not in the ledger. They are not in the cashbook either, so Cash Level and Bank Reconciliation are short by the same RM 18,420.

To fix it, give the settlement method its cashbook in the Cashbook applet. Write down the 41 bill numbers, then press Create on Missing Journal for those bills and read each row’s Remarks. SUCCEED means the journal was built. An error code means the cause is still there. A blank row means the rebuild did not save, and the Ledger And Journal page explains why Create should not be used on a document you linked a manual journal to.

Create rebuilds the journal only. Afterwards the 41 bills are in the ledger and still missing from the cashbook, so the cashbook’s GL code is now RM 18,420 more than its Cash Level, and Missing Journal no longer lists them. Each bill’s cashbook line is restored in the Financial Report applet: Error Checking › Trace Document, enter the bill, and press Resolve on its Missing Cashbook check. That takes one bill at a time and needs permission to create cashbook transactions. Where the cashbook watchdog clock is scheduled on your tenant, once the method has its cashbook the lines may appear without you (What a missing default or cashbook costs you says how often it retries).

For all 41 at once, use the Data Fix applet: Cashbook › Missing Cashbook. Pick the Server Doc Type INTERNAL_SALES_CASHBILL, set Date From and Date To to cover March, and press SEARCH. Both dates open on today, so a search left at the defaults finds only today’s bills.

The grid lists every FINAL bill in the range that has a settlement amount and no cashbook line. Tick the header box to select them all, press CREATE, and read Remarks: SUCCEED on each bill whose line was written, or the error code on a bill whose settlement method still has no cashbook. It is the same repair as Resolve, with the same permission, and running it twice does no harm, because a bill that already has its cashbook line is not written again. The screen covers cash bills, receipt vouchers, payment vouchers and cash transfers.

Data Fix is an administrator’s applet. If it is not on your menu, ask BigLedger support to add it to your login. Afterwards Cash Level for that cashbook rises by RM 18,420 and agrees with its GL code again.

What the backend actually checks

This section is short and worth reading, because it corrects three things a reader would reasonably assume.

Locks are computed from the date, every time. When a document is finalised or a journal is created, BigLedger counts the company’s active periods whose status is in the relevant lock set and whose date range contains the transaction date. One or more: refused. Zero: accepted. Nothing is stored on the document to say which period it fell in. The journal header has columns for a fiscal year and period, and posting never fills them, so you cannot use them to find out which period a journal was accepted into.

The consequence: if you later change a period’s dates, every historical document silently belongs to whichever period now contains its date. Do not edit period dates on a year that has postings.

The overlap check is per company, not per year and not per Set of Books. Every period of the company is compared against every other, whatever year it belongs to. That is the rule that gives you exactly one calendar per company.

The fiscal year’s link to a Set of Books is decorative. Both the year and the period carry a Set of Books column. Nothing validates it, and the only thing that reads it anywhere — backend or screen — is the optional listing filter on the fiscal-year query. The lock check is by company and date only; the report engine finds its ledgers through the Set of Books lines, never through the fiscal year. Leave the field alone; it changes nothing.

Only the Financial Report applet reads a Set of Books: Month End Processing resolves it to ledgers and processes each, and a Financial Report snapshot joins the general-ledger summary rows to the ledgers on its lines. Nothing else on the platform looks at it.

Why the records are shaped this way. Two design notes from the developers’ own notes explain it:

“A set of books may contains multiple ledger_header. One ledger for basic account reporting, another set of ledger base on different accounting standard, and another set of ledger base on different currencies etc.” — on the Set of Books

“In each fiscal year, there may be X number of fiscal periods. X can be 1, 2 (half yearly), 4 (quarterly), 12 (monthly), or 52 (weekly), or 13 or 14 or whatever number specified by the user. Different fiscal period could be used for different purpose, in different modules. For example: Company A has a financial year from May 2003 to April 2004 (12 periods), but the GST filing is done quarterly …” — on the fiscal period

The second is a design intent, and it is worth knowing that the product as shipped does the first half and not the second: the screen generates monthly periods and nothing else, and the backend refuses a second set of periods for the same company (the overlap check, above). The records that were meant to carry the other purposes stand empty.

What success looks like

Thirty seconds per company. Open a sales invoice screen, date a new invoice in a LOCK_TXN month, fill in one line and click FINAL: you get The selected date falls within a locked fiscal period and the invoice stays a draft. Open the journal screen, date a manual journal in the same month and Save: it posts. Then, in the Financial Report applet, create a Month End Processing record for that company and month and pick the Set of Books from the drop-down: it is there by the name you gave it, and PROCESS completes without Set of Books is missing primary ledger configuration.

Common mistakes

What people do	What actually happens	Do this instead
Set `LOCK_GL` on the 10th to “close the month”	Branches keep posting sales into it; only manual journals are refused	`LOCK_TXN` when the month closes, `LOCK_ALL` once the year’s audit is signed off
Assume a new company starts locked, or that last year is locked because it is over	A company with no fiscal year is never locked; a period stays `OPEN` until somebody changes it	Create the year, then lock each month as you close it
Create a second fiscal year for a quarterly tax calendar	Refused as overlapping	One monthly calendar per company; report quarterly from the monthly periods
Edit a period’s dates after the year has postings	Documents move between periods without any record of it	Delete and recreate a year only before anything is posted into it
Create the Set of Books and forget the Ledgers tab	Month End Processing fails with Set of Books is missing primary ledger configuration.	Link the primary ledger before you leave the screen
Rely on `LOCK_ALL` to freeze ledger balances	Stock transfers and system-written journals still post, and a manual journal can still be cloned, edited, deleted or imported into the month	Treat the lock as a gate on people keying new entries, and read the month-end snapshot as the frozen figures