Setting Up a Group: What We Recommend

Every other page in this module answers how does this setting work. This one answers which way should I set it — and that is a different kind of sentence, so it is written differently and it is signed by somebody. If you are about to configure BigLedger for a group of Malaysian companies with shops in them, this page is the argument you would otherwise have to have three times with three different people: one tenant or three, one chart of accounts or one per company, a second company or another branch, letter codes or numbers, and which handful of switches genuinely has to be right before the first invoice is finalised. Reading it takes about twenty-five minutes. Doing what it says takes a couple of days spread over a week, most of which is agreeing things with your accountant rather than typing.

This page does not replace the setup order, which is the sequence each applet’s own prerequisites impose and is not a matter of opinion. It sits on top of it. Follow that order; use this page to decide what to type into it.

Meet GadgetSphere

GadgetSphere Sdn Bhd (GS) sells consumer electronics from 22 shops across the Klang Valley, Penang, Johor Bahru, Kota Kinabalu and Kuching. GadgetSphere Online Sdn Bhd (GSO) runs the web store out of a single fulfilment centre. GadgetSphere Distribution Sdn Bhd (GSD) wholesales to corporate accounts. Three registered companies, one finance team of six, about 5,200 active stock-keeping units, 28 places money sits, and roughly 1,800 documents on a good Saturday. Everything below is decided for that group, and every recommendation says which part of it the advice depends on — because a group of three companies with 22 shops and a two-company holding structure with none want genuinely different answers to about half of these questions.

How to read this page

There are two kinds of statement here and you should never have to guess which you are looking at.

Facts read like the rest of the wiki. They describe what the software does, and the sources: map in this page’s front matter says where each family of them came from — a reference page, a measured aggregate, or the backend.

Recommendations always look like this — this one is real, and you will meet it again under One tenant, or one per company:

Recommendation — keep one tenant for the whole group.
Why: permissions, reporting and intercompany all work inside a tenant and stop at its edge.
Cost: a shared item master, a shared entity master and tenant-wide applet settings.
Suits: any group whose companies trade with each other or share stock, staff or customers.

Four labelled parts, every time; a long Why may run to two paragraphs. If a recommendation cannot state its cost, it is not a recommendation, it is a preference, and it does not belong here.

Where we genuinely do not know which way is better, the page says so and marks it, rather than picking one and sounding confident. Those are collected under What this page does not tell you.

The order a new tenant sets things up in

There is no setup wizard and no checklist screen. The order below is derived from what each applet’s own page says it requires before it can be used — every arrow is a prerequisite one page states, cited in that page’s Before you can use it table. Where two applets require each other, the page says which half comes first.

    flowchart TD
  TA["Tenant Admin<br/>rank OWNER / ADMIN · install applets · roles"] --> ORG["Organization<br/>Company → Branch → Location"]
  COA0["Chart of Account<br/>a chart (or the DEFAULT one)"] --> ORG
  ORG --> COA["Chart of Account, per company<br/>ledgers · Default GL Codes · fiscal year · set of books"]
  COA --> TAX["Tax Configuration<br/>tax codes"]
  COA --> CB["Cashbook<br/>cashbooks → settlement methods → branch links"]
  CB --> ORGB["Organization › Branch<br/>settlement, default pricing"]
  COA --> FX["Forex<br/>only for foreign-currency trade"]
  ORG --> ENT["Entity code prefixes, then<br/>Employee · Customer · Supplier · Merchant"]
  TAX --> ENT
  CB --> ENT
  TAX --> ITEM["Doc Item Maintenance<br/>pricing schemes · category groups · items"]
  COA --> ITEM
  ITEM --> INV["Inventory Item Maintenance<br/>auto-created from a Basic Item"]
  ITEM --> PB["Pricebook"]
  ENT --> PB
  TA --> WF["Workflow Design<br/>only if a status track is wanted"]
  ORG --> WF

Tenant Admin first. You need rank OWNER or ADMIN on the tenant to open it at all; from there applets are installed for users, tenant roles are created, and permission sets are targeted at companies, branches and locations — which is why the Organization page lists applet installed and server-side permissions granted as its own first prerequisite. A permission target has to be a company or branch that already exists, so you will come back here after step 3.
A chart of accounts before the company. Create Company requires a chart; the + beside the field creates one coded DEFAULT if you have none, seeded with 200 template codes you did not design, so decide the chart before you press it. Sections, categories and codes can be built or imported before or after — but nothing can be mapped until the company exists.
Organization: Company, then Branch, then Location. Creating a company also creates its CORPORATE entity, its PRIMARY ledger in the company currency and the stock-in-transit location. It does not create default GL codes, a branch, knock-off rows or a cashbook — each of those is a later step. A branch can create its default location for you.
Back to Chart of Account for the company. Map Default GL Codes — the posting job that runs after a document goes FINAL throws MISSING_DEFAULT_GL_CODE: <type> for any type the document needs that is not mapped, leaving a FINAL document with no journal — create a fiscal year covering today (documents are validated against the period of their transaction date), and a set of books if you want financial reports. The page’s own order: verify the company → ledgers → codes → default GL codes → set of books → fiscal year.
Tax codes. The applet itself needs nothing, but its codes are useless until the company’s OUTPUT_TAX and INPUT_TAX default GL links exist with a subledger — without them the tax line of every journal is dropped without an error and the customer’s or supplier’s line absorbs it, so the journal posts with your tax account short. Once codes exist, the Organization company Tax tab picks the default sales and purchase code.
Cashbooks, then settlement methods, then branch links. A cashbook needs a company and a GL code in that company’s chart (the backend rejects a mismatch); settlement methods need a cashbook; the transaction applets filter settlement methods by the branches linked to them. Only then can Organization › Branch › Settlement link them to a branch.
Forex, only if you trade in foreign currency. Both currencies must be in the tenant currency list and the company base currency set; the pair only appears on a document applet whose SHOW_FOREX_DATA_SOURCE setting is on (off by default), and settlement needs FOREX_GAIN / FOREX_LOSS mapped in step 4.
Set the entity code prefixes, then the people and businesses. The typed applets generate customer / supplier / employee / merchant codes from a running number plus the tenant’s per-type prefix — there is no screen for the prefix today (the Supplier applet’s control is commented out), so ask BigLedger to set it before the first record if you want codes like C1000000 (the prefix, then a plain running number from 1,000,000 — no zero-padding) — see Document numbering. Then:
- employees (the create form requires a branch; a login link needs the person to have accepted an invitation first) — before customers if you want a default sales agent on the customer;
- customers (receivable GL code from the chart, tax codes, credit terms and limits created in the applet, a category group bound to each category slot in its Application Settings);
- suppliers (payable defaults, tax codes, categories; self-billed e-Invoicing needs the company enabled in Organization);
- merchants (a contract company, tax codes, GL codes with subledgers for the merchant branch control account, settlement methods for Payment Config).
Items. Doc Item Maintenance needs tax codes, GL codes, companies and branches, and its own pricing schemes and category groups bound to slots before prices or categories can be entered. A Basic Item creates and links its inventory record; an item created directly in Inventory Item Maintenance has no doc item and cannot appear on a document until one is linked. Per-location min / max levels need the locations from Warehouse Management (Inventory module).
Price books last — they match on items, categories, pricing schemes, customer and employee categories, companies and branches, and member classes from Membership Admin. Nothing is applied until Default Selection → Default Pricebook is set in POS General, Sales Invoice, Sales Order or Sales Quotation.
Workflow Design, if at all. It needs roles with users (a transition with no Role row is invisible to everyone) and a company; a process that is never linked to a company and an applet is inert. It is not where approvals are configured.
T2T Admin is not part of first setup: it needs a second, existing tenant with a registered database connection, and companies, branches and items on both sides before anything can be mapped.

The grain of the product, and why it decides half of this

Before any individual choice, one thing about BigLedger’s design is worth understanding, because a setup that works with it is calm and a setup that fights it generates work forever.

BigLedger separates the moment of sale from the moment of reporting, and it puts corrections on the reporting side. You can see the same decision from a dozen screens once you know to look for it. The till does not stop a sale when the buyer’s tax details are incomplete — the queue keeps moving and the e-Invoice buyer block is completed afterwards, by someone with time to get it right, in the My E-Invoice Admin applet.

A customer over their credit limit is not refused at the till: nothing on the server checks a limit at the moment of sale. What stops them is an optional check at FINAL on the sales order and sales invoice screens, or a blacklist sweep that refuses their next documents after it has run — and that sweep runs only when somebody schedules it, which we recommend. A document pool waits indefinitely rather than filing something incomplete with the tax authority. A tax code’s rate is copied onto a line when the line is saved, so changing the rate tomorrow never rewrites yesterday.

The consequence for setup is direct: put your controls where the product puts them. The things that actually stop bad data in BigLedger are the fiscal period locks, the month-end close, the default GL code mapping and the reports that name what did not post. The things that do not stop it are credit limits (unless you switch on that optional check), most of the per-company switches people expect to be enforcement, and any hope that a cashier will be prevented from doing something in the middle of a queue.

Recommendation — design your controls for the reporting side, not the counter.
Why: the product deliberately does not block at the point of sale, so a control placed there will be either absent or worked around, while a control placed at the period close is absolute.
Cost: you accept that mistakes are made and then found, which means somebody must actually run the checks — the close is a job with an owner, not a button.
Suits: every shape of business, and most urgently any group with tills, where the alternative is a queue of customers waiting for a supervisor.

Decide the shape before you touch the tenant

The setup order is a chain of prerequisites, and it is unforgiving in one particular way: several of its early steps write values that are painful or impossible to change later, and you reach them within the first twenty minutes. So the first thing to do is not in BigLedger at all.

Recommendation — settle six things on paper before you create the company.
Why: company, branch and location codes, the GL code convention, the chart’s shape and the entity code prefixes are all either impossible or painful to change afterwards, and all of them are asked for in the first half hour.
Cost: a meeting with your accountant and whoever runs the shops, before anybody gets to click anything.
Suits: every shape of business.

The six: how many companies, the company codes, the branch and location code shape, one chart or several, the GL code convention, and the entity code prefixes for customers, suppliers and employees. The rest of this page is how to decide each of them. Then follow the twelve-step order, and prove it with one finalised invoice per company before anyone else is let in.

What to settle before the first finalised document, and what can wait

This section and the next are the short form of everything that follows: what has to be right before the first finalised document, what can wait, and what costs most to undo. Read both before you start, then use the sections after them to decide each item.

Settle before the first document	Why it cannot wait
Company, branch and location codes	A later change rewrites only the record; nothing already issued under the old code is rewritten (expensive to reverse)
One chart or several, and the code convention	A code can be edited later, but whatever was posted to a wrong account stays there until GL Code Merge moves it, so a convention changed after go-live costs a merge per code
Entity code prefixes for customers, suppliers, employees	There is no screen for them; the engine skips numbers already taken, so a tenant that creates records first has generated codes jumping over them for years
The default GL code mapping, per company	A document finalised without it is FINAL with no journal, and nobody is told
A fiscal year covering today, per company	Documents are validated against the period of their transaction date, and a company with no year is never locked
The knock-off pairs you use, per company	Read at FINAL; a document finalised earlier leaves nothing behind
Tax codes and the company’s default sales and purchase code	Every document of that company pre-fills from it
Whether e-Invoicing is switched on for the company	Documents finalised while the company is disabled are never queued retrospectively

Can wait, safely	Why
Price books and pricing schemes	Nothing applies a price book until a consuming applet’s default pricebook setting points at one
Marketplace branch configuration	A marketplace is a branch; add it when you open the channel
Intercompany document pairs	Nothing reads them until you raise a document that mirrors into another of your companies; add them when that day comes. Then the sale must bill the buying company’s own entity record — created with the company, with no customer role and no AR/AP type — so give it both first (what the pairing needs)
Tenant-to-tenant mapping	Explicitly not part of a first setup
Workflow Design	A process never linked to a company and an applet is inert, and it is not where approvals are configured
Document approvals	Only purchase orders and purchase requisitions run the full approval loop (Stock Requisition has approval settings but no submit step, a known gap); turn it on when purchasing volume justifies it
Printable format defaults per branch	The default layout works; per-branch layouts are a refinement

The decisions that are expensive to reverse

Decision	What reversing it actually costs
Branch and location codes	An owner or administrator can change the code to one no other branch or location holds. Everything already printed, exported or agreed with outsiders under the old code keeps it, so plan it like a company code change
Company code	An owner or administrator can replace it with a unique code, but existing document numbers and permission-set names already carry the old one, so it is a migration wearing a settings change
GL code values	A typo in the code itself is fixed on Chart of Account › GL Code › Edit (the GL Category’s own GL Code tab shows the code read-only), and a code the chart already uses is refused. History posted to the wrong account is the expensive part: it stays in every report until GL Code Merge moves its journal lines onto the right code
Entity code prefixes	Set for you before the first record (setup order, step 8); retrofitting leaves permanent jumps in the generated sequence
The fiscal calendar	One monthly calendar per company, and a second overlapping set of periods is refused. Changing a year end means deleting the old year, and editing period dates after postings silently re-files every historical document

Everything else on this page can be changed later at the cost of a conversation and an afternoon. These five cannot.

One tenant, or one per company

A tenant is the whole installation. Companies live inside it, and so does everything else — the item master, the entity master, the tax code list, the applet settings, the permission model and the document counters.

Nothing about a tenant assumes a single company. Every boundary that matters to a group — permission sets, Sets of Books, default GL codes, fiscal years, intercompany document pairs — is drawn per company inside a tenant, so keeping a whole group inside one tenant is the arrangement the design is built around rather than a compromise.

Recommendation — one tenant for the whole group.
Why: permission sets are targeted at a company, a branch or a location, so one tenant already keeps GSD’s books away from the people who run GS shops. A Set of Books can span two companies’ ledgers for a group management view. Intercompany document pairs are configured company by company inside a tenant. All three of those stop at the tenant boundary; cross that boundary and you are in T2T Admin, mapping companies, branches and items by hand, and the Core module is explicit that this is not part of a first setup.
Cost: one item master, one entity master, one tax code list and one set of applet settings for the whole group — several applets save their settings tenant-wide, so a change one finance clerk makes applies to every user of that applet in every company. And the tenant-level document number is shared: GS, GSO and GSD sales invoices draw from the same Doc No (Tenant) sequence.
Suits: any group whose companies trade with each other, share stock, share customers or share a finance team. Which is the shape of nearly every Malaysian retail group.

Recommendation — use a second tenant only when the two businesses share nothing.
Why: the only things a second tenant buys you are a separate item master, a separate entity master and separate tenant-wide settings. If the two businesses genuinely need different item-code formats, different category structures or different people administering them, that is worth the cost. If they merely have different shareholders, it is not.
Cost: no shared reporting, no in-tenant intercompany, and every cross-tenant flow goes through tenant-to-tenant mapping that has to be maintained on both sides.
Suits: an unrelated acquisition, a franchise you administer but do not own, or a business in a different industry with its own catalogue.

If you keep one tenant, do this one thing about numbering

Doc No (Tenant) is a single sequence per document type across every company and every branch, and it is stamped the moment a document is created. Doc No (Company) and Doc No (Branch) exist too, but they are stamped at FINAL, and whether a listing shows them is decided per applet (Document numbering says which). None of the three carries a prefix, a year or zero-padding — they are plain integers, and the first one a tenant ever draws is 1,000,000.

Recommendation — make Doc No (Company) visible on the listings finance works from before the first document, and print it on statutory documents.
Why: with three companies sharing a tenant, the tenant number on a GSD invoice has GS cash bills interleaved through it. An auditor looking at a company’s invoice sequence wants the company’s own sequence, and it is already there.
Cost: three number columns on the listing instead of one, and a printable format that has to be told which one to show. Also: the company number does not exist on a draft, so anything you print before FINAL can only show the tenant number.
Suits: any tenant holding more than one company. A single-company tenant can ignore the distinction entirely.

A second company, or another branch

This one is not really a BigLedger question, and pretending otherwise is where groups go wrong. A company in BigLedger is a legal entity: it holds the registration number, the tax identification number, the Sales and Service Tax (SST) identification number, its own chart assignment, its own General Ledger (GL) ledger, its own fiscal calendar and its own e-Invoice registration with LHDN. A branch is an operating unit inside one of those.

Recommendation — create a company for each registered legal entity, and nothing else.
Why: everything a separate legal entity needs is a company-level record, and everything an operating unit needs is a branch-level one. A shop is not a legal entity. A division is not a legal entity. A second brand trading under the same registration is not a legal entity.
Cost: each company is a real setup — its own default GL code mapping, its own fiscal year, its own Set of Books, its own knock-off pairs, its own cashbooks. Budget a full pass of the setup order per company, not a copy.
Suits: every shape of business. GadgetSphere gets exactly three companies because it has exactly three registrations.

Recommendation — resist a fourth company “for reporting”.
Why: the reasons people usually reach for a company — separating the online business from the shops, separating wholesale margin from retail margin, seeing one region on its own — are all answered by a branch plus the reporting dimensions. The ad-hoc Profit and Loss report groups by branch, GL dimension, segment, profit centre or project, and defaults to branch.
Cost: you have to actually tag documents with the dimension you want to report on, and nothing forces anyone to.
Suits: every shape. The exception is a genuine statutory requirement to keep separate books, which is a legal entity again.

Branches and locations

A branch is an operating unit; a location is where stock physically sits. Creating a branch can create its location for you, and it records that location as the branch’s main location — the field that decides where stock lands when nothing on the document says.

Recommendation — one branch per trading site, one location per stockroom.
Why: the branch is what documents are tagged with and what reports group by; the location is what stock balances are keyed on. A shop with one stockroom needs one of each. A shop with a shop floor and a sealed back store benefits from two locations under one branch, because stock take and transfers then tell you which is which.
Cost: every extra location is another row in every stock report and another place a clerk can pick wrongly.
Suits: a retailer with shops. A two-company holding structure with an office and no stock needs one branch per company and can leave the auto-created location alone.

Recommendation — agree the branch code shape before the first branch, and never change it.
Why: only an owner or administrator can change a branch, location or company code, and the change rewrites the record and nothing else. Anything already issued, printed or exported under the old code keeps it, and for a company code the document numbers and permission-set names carry it too, so a change is a migration in all but name.
Cost: twenty minutes of argument up front about whether Penang shop 1 is GS-PEN-01 or PEN1.
Suits: every shape. GadgetSphere uses region and sequence — GS-KV-01, GS-PEN-01, GS-JB-01 — which reads correctly on a document number column and sorts sensibly at 22 branches.

Recommendation — set each branch’s main location deliberately, one branch at a time.
Why: it is the catch-all that absorbs every document where nobody said where the goods were, and a point-of-sale cash bill is refused at FINAL when the document’s location is not the branch’s main location. On a 22-branch retailer this is not a cosmetic default; it is where a great many movements actually land.
Cost: a minute per branch, once.
Suits: anyone who moves stock. A services company can take the default.

One chart of accounts, or one per company

The chart is a prerequisite of creating a company, so you meet this question before you have anywhere to put an answer. Two facts shape it: GL sections are shared across every chart in the tenant, and creating a second chart seeds another 200 template codes under those same shared sections. Between them those two facts decide the question: a second chart does not buy you separation, because the sections it hangs under are shared anyway, and it does cost you 200 more codes in every picker in the tenant.

Recommendation — one chart of accounts for the whole group.
Why: the companies are in the same business, the group consolidates, and a shared chart means GS, GSO and GSD results line up account for account with no mapping table in a spreadsheet. Default GL codes are mapped per company anyway, so the companies still post to different cash and receivable accounts — they simply draw them from the same list.
Cost: every company’s clerks see every company’s codes in the pickers, including 22 branch cash codes belonging to a company they never touch. There is no way to scope a GL code to one company. You manage this with naming discipline, not with a setting.
Suits: a group of companies in one industry that reports as a group. GadgetSphere.

Recommendation — a second chart only for a company with a genuinely different profit and loss shape.
Why: a manufacturing arm alongside a retail group, or a company reporting on a different accounting basis, has categories the retail chart has no room for, and forcing them into one chart makes both statements worse.
Cost: another 200 seeded codes to deal with, two charts to keep in step when a new expense category appears, and group reporting that needs a mapping somebody maintains.
Suits: a mixed group. Not a retail group.

Letters or numbers: the GL code convention

A GL code has a code (GL Code), a name, a category — and a second field, GL Code 3, which the built-in template uses to carry the numeric account number. Both are importable. That detail settles an argument that usually has no winner.

Recommendation — mnemonic codes in GL Code, and the numeric account number in GL Code 3.
Why: a clerk reading a journal line can tell SALES-LAPTOP from COST-LAPTOP at a glance and cannot tell 410201 from 410202; a mis-keyed mnemonic code looks wrong immediately and a mis-keyed number does not. And your accountant, your auditor and whatever they export to still get the numeric account number, in the field the product already keeps it in.
Cost: longer codes on every screen and every export, and a convention you have to police — nothing validates the shape of a code, so the first person who keys SALES_LAPTOP with an underscore has created a second account. Write the convention down and give it to whoever imports the chart.
Suits: a business whose finance work is done by people who are not trained accountants, which is most retail groups. A team of qualified accountants who have used numeric ranges for twenty years should use numeric ranges; the cost of retraining them is real and the benefit is theirs to judge.

Recommendation — set the seeded template codes you do not use to inactive rather than deleting them, and brief the item team.
Why: a code that has been posted to cannot be deleted — Delete refuses it while any journal line names it, and the only way to retire it is GL Code Merge, which moves its journal lines onto another code and then removes it — so building your own codes alongside the template is the honest alternative. Inactive codes leave the GL Code listing and the manual journal drop-down.
Cost: the item-level GL picker on sales and purchase lines does not filter on status, so it still offers every inactive template code. Anyone maintaining items needs to be told which codes are actually yours.
Suits: every group that does not adopt the template wholesale.

A GL code per branch, or the branch as a dimension

This is the question that produces the biggest charts, and it deserves a straight answer. Every journal line already carries its branch, and the ad-hoc Profit and Loss report groups by branch by default. Branch and profit centre are separate fields, and both sit on the document header and on each line, side by side — so profit centre is not another word for branch. It is a second, independent cut for something else entirely: a business line, a department, a project, a campaign. Because both live at line level, one document can carry lines belonging to different branches or different profit centres. Segments, dimensions and projects are there too.

Recommendation — do not create a revenue or expense code per branch. Use the branch as a report dimension.
Why: at 22 branches, a code per branch per revenue category is hundreds of codes that every clerk in the group scrolls past, and the branch breakdown you wanted is already available from a report grouping that needs no codes at all.
Cost: the branch split does not appear on the face of the statutory profit and loss statement — you get it from the Profit Loss Report instead. If your board reads the statutory statement and expects branch columns in it, this recommendation costs you that.
Suits: any business with more than about five branches.

The practical consequence for your chart: one revenue code per product line, and let the two dimensions do the cutting. Twenty-two branches against forty product lines is 880 revenue codes the other way, recreated every time a branch opens — and you would still have no way to cut the same revenue by business line, because you would have spent the dimension on the branch you already had.

Recommendation — do create a code per real bank account and per cash drawer you count separately.
Why: these are not a reporting split, they are different balances that get reconciled separately against different statements. CASH-PRI-KV01 and CASH-SEC-PEN01 are two accounts because there are two balances.
Cost: GadgetSphere’s 28 cashbooks mean 28 cash GL codes, and they will be the longest section of the chart.
Suits: any multi-branch retailer. A single-site business needs one per bank account and one drawer.

Ledgers, sets of books and the fiscal calendar

Creating a company creates its primary ledger for you, in the company’s currency. Only a primary ledger carries the Opening Balance tab. A Set of Books names the ledgers a financial report reads, and the report engine sums every ledger linked to it.

Recommendation — one primary ledger per company, and do not create secondary ledgers.
Why: the ledger you were given is the one every default GL code mapping hangs on and the only one that takes opening balances. A secondary ledger is for a genuine second accounting basis, and creating one by accident produces a company whose Opening Balance tab has simply vanished, which reads like a permissions fault and is not.
Cost: none worth naming.
Suits: every shape of business.

Recommendation — one statutory Set of Books per company, named for the company.
Why: month-end processing and every financial report are created against a Set of Books, and its name is the only thing you will ever see again. GS Statutory, GSO Statutory, GSD Statutory.
Cost: three records instead of one, and three month-end closes instead of one.
Suits: every multi-company group.

Recommendation — add one group management Set of Books spanning the three primary ledgers, and be clear with everyone about what it is.
Why: it is a one-record way to see the group’s revenue and costs in a single statement, and it costs nothing to create.
Cost: the engine sums the ledgers. It does not eliminate anything. A sale from GSD to GS appears as revenue in one and cost in the other and both are in the total. This is a management view, not a statutory consolidation, and if anyone treats it as one your group revenue is overstated by every intercompany sale you make.
Suits: a group whose companies trade with each other lightly. A group with heavy intercompany trading should do the consolidation outside BigLedger, or accept that the number needs a manual adjustment every month. BigLedger is tracking intercompany elimination.

Recommendation — a calendar-year fiscal year per company with monthly periods, and a two-stage lock.
Why: the screen generates one period per calendar month and nothing else, and the backend refuses a second, overlapping set of periods for the same company — so you get exactly one calendar per company whatever you intended. Two stages because the locks are asymmetric and that asymmetry is useful: LOCK_TXN stops operational documents and still lets your accountants post adjusting journals; LOCK_ALL stops both, and belongs to a year whose audit is signed off.
Cost: somebody has to actually change 36 period statuses a year across three companies, on a date, every month, and 36 more after the audit. Put it in the close checklist, because nothing does it for you.
Suits: every shape of business. GadgetSphere sets each month to LOCK_TXN when it closes, around the 10th, and every month of the year to LOCK_ALL once the year’s audit is signed off.

Three things to know before you rely on the locks. A company with no fiscal year is never locked — the check counts matching locked periods and finds none, so a group that has run for a year without one has had every date open the whole time. Stock transfers are exempt from both document locks. And period dates must not be edited once documents are posted, because nothing is stamped on a document to say which period it fell in; every historical document silently belongs to whichever period now contains its date.

One invoice, and everything it reads from here

Nearly every value on a sales invoice was decided in this module: the customer’s details and the tax rate are copied when the invoice is raised, while the accounts it posts to, and the AR/AP type that decides the balance-sheet side, are read when the journal is built a moment after FINAL. The table for one RM 106 invoice, and why one entity can be both a customer and a supplier, are on Core concepts › One invoice, and everything it reads from here. The setup decision it leaves you: settle each entity’s AR/AP type before its first document, because it decides which control account every document with that entity posts to.

The mapping that decides whether anything posts

The company’s Default GL Codes tab, in the Chart of Account applet rather than on the company record, maps 41 roles per company to the account each kind of movement posts to, and creating a company creates none of them. A brand-new company starts with the tab empty, nothing prompts you to fill it, and nothing stops you finalising a document before you have. What a missing role does to a journal, worked through for a RM 106 invoice, is on Core concepts › The mapping that decides whether anything posts.

Recommendation — map every role that applies, for every company, before anybody finalises anything.
Why: the failure is silent in the worst possible way. Entity roles throw an error that names the missing key — annoying, but findable. Item, tax, charge and stock lines resolve their account by falling back through line, header, item-company link and company default, and when none is found the line is simply omitted.
On a sales or purchase document the customer’s or supplier’s line absorbs the missing amount, so the journal balances and posts with the receivable or payable account short, the document is FINAL, and nobody is told (the arithmetic).
Cost: an hour per company with your accountant, going through seven tabs.
Suits: every shape of business. This is the single highest-value hour in the whole setup.

Recommendation — check two pairs specifically: COGS with STOCK_BALANCE, and PROFIT_LOSS with RETAINED_EARNING.
Why: month-end writes the cost-of-goods-sold journal only when the first pair is mapped and the retained-earnings journal only when the second is, and a company missing both gets a month-end close that completes with neither journal and no message.
Cost: none. It is two checks.
Suits: every company that holds stock, which for a retail group is all of them.

Recommendation — confirm the output-tax and input-tax links have a sub-ledger, not just a code.
Why: a link that exists with an empty sub-ledger drops the tax line without an error, and the customer’s or supplier’s line absorbs the amount, so the journal posts and your tax account is short. Nothing fails, so nothing tells you — the same outcome as a missing link.
Cost: none.
Suits: every SST-registered business.

Tax codes

A tax code is a code, a type, a rate and a country. It has no GL account field — which account a tax amount lands in comes entirely from the company’s output-tax and input-tax default GL links. A document line copies the rate when it is saved, so changing a rate later never restates a saved document.

Recommendation — create only the codes you will actually use, and set the company’s default sales and purchase code.
Why: the line-level drop-down loads every code in the tenant and filters only on type, so every code you create is a code a clerk in any company can pick. Forty-seven codes on a drop-down is how a 6% service tax ends up on a line at 10%.
Cost: if you inherit historical codes from a previous tax regime you cannot delete the ones that have been posted to; set them inactive and check they have left the picker.
Suits: every shape of business.

Recommendation — do not plan a chart around splitting one tax across two accounts.
Why: you cannot. Tax posting is a company-level decision and two service-tax codes in the same company go to the same account. This is deliberate, and it is why the mapping is where it is.
Cost: if you need the split for a return, you take it from tax reporting by code rather than from the GL.
Suits: every shape of business.

Cashbooks and settlement methods

A cashbook is a place money sits — a bank account, a drawer, a card acquirer’s settlement account, an e-wallet — tied to one company and one GL code in that company’s chart. A settlement method is a way money moves, and it must be linked to the branches that may use it, because that link is what the transaction applets filter on.

Recommendation — one cashbook per balance that gets reconciled on its own.
Why: bank reconciliation works cashbook by cashbook against a statement, and the cashbook Members tab is what limits a person to the cashbooks they may reconcile. One cashbook per real bank account, one per card acquirer, and one drawer per branch you count separately.
Cost: GadgetSphere’s 28 cashbooks each need a GL code, and each settlement method needs linking to the branches that use it. This is the most row-heavy part of the whole setup and it is worth doing with a spreadsheet and the import screens rather than by hand.
Suits: a multi-branch retailer that counts cash per shop. A two-company structure with no tills needs a cashbook per bank account and nothing more.

Recommendation — map the settlement-charges account before you create a method that carries charges.
Why: a charge line with no resolvable account is dropped, and the customer’s line absorbs the fee, so the journal posts with the card fee sitting on trade debtors — the same silent shape as the tax line.
Cost: one more default GL code per company.
Suits: anyone taking card payments, which for a retailer is everyone.

The knock-off pairs to enable on day one

The Knock Off Configuration on each company is one row per source-to-target document pair, and it decides whether finalising a document leaves anything behind for the next one to pick up. At FINAL the processor loads the enabled rows for that company and source type, and if the list is empty it creates nothing and logs nothing. The downstream applet’s Search Document tab reads exactly those rows, which is why “the invoice cannot find the order” is nearly always this. Nothing creates these rows for you when you create the company, and the pair you want may not be one of the ones somebody already added.

Recommendation — enable the pairs your workflow actually uses, per company, before the first document is finalised in that company.
Why: the rows are read at FINAL, so a document finalised before its row existed leaves nothing behind, and nothing on a timer goes back for it.
Recovery depends on the document: one that posts nothing can be taken back to Draft and finalised again where its applet offers Undo to Draft, while anything that posts — an invoice, a goods receipt, a cash bill — is re-queued from the Data Fix applet: Generic Documents › Missing Open Queue, pick the document pair, select the FINAL documents that never got their row, and create the queue. A document that already has its row is refused, so a second press does no harm; if you do not hold the Data Fix applet, BigLedger support can do the same (recovering documents finalised before the configuration was right). Creating the company does not create knock-off rows; nothing does.
Cost: a row per pair per company, so GadgetSphere writes them three times. There is no copy-to-company function.
Suits: every business running a document chain, which is every business.

For a retail group the working set is small: sales order to sales invoice and to delivery order; purchase order to goods received note (GRN) and GRN stock-in; GRN to purchase invoice; stock requisition to outbound stock transfer. Add the consignment pairs only if you trade on consignment, and the blanket order pair only if you use blanket orders.

Recommendation — enable one GRN target per source, not several.
Why: the applet refuses a second target in the GRN family for the same source with a KO Conflict Detected message. That guard is in the browser only — the backend accepts it — so an import or an API call can create the configuration the screen was protecting you from.
Cost: none, if you decide which GRN flow you use before you configure it.
Suits: anyone receiving goods.

Two settings people get wrong because nothing warns them

The company timezone. Left blank, the platform falls back to the tenant default and then to Asia/Kuala_Lumpur. For a Malaysian group that is the right answer by accident, which is exactly why nobody sets it and nobody notices — until a bank reconciliation window or a report row lands a day out.

Recommendation — set the timezone explicitly on every company even though the fallback is correct.
Why: it costs one field and removes an entire class of “the report is a day out” investigation.
Cost: none. It is on the company edit screen, not the create screen, so it is a second visit.
Suits: every shape of business.

The inventory closing basis. This decides which cost column values closing stock for the profit and loss statement, and its control is in the Chart of Account applet rather than on the company record. Nothing sets it when you create a company, and an empty setting means moving average.

Recommendation — leave the inventory closing basis empty, meaning moving average, unless you have deliberately enabled and rebuilt the FIFO job.
Why: choosing first-in-first-out on a tenant where that job is not running values closing stock at zero, and cost of goods sold then equals every purchase you made in the month. The last three options read columns nothing writes.
Cost: moving average is not everyone’s preferred basis, and if your auditor requires first-in-first-out this is a conversation with BigLedger about the job rather than a setting you flip.
Suits: every retailer. This is the one inventory setting on this page and the only safe default.

What posts, and what does not

Master data posts nothing. Cash Transfer is the one document in this module that posts a journal, Chart of Account’s Opening Balance writes one on the primary ledger, and deletes are soft and mostly unchecked, so retire a company or branch by marking it Closed. The diagram and the detail are on Core concepts › What posts, and what does not.

What this module has no engine for

Core has no approval on master-data changes, no save-time credit gate, no tax-to-GL mapping on the tax code, and nothing that applies a price book on its own; each is a job for a person, and Core concepts › What this module has no engine for says whose. The one that changes your setup is credit control: the overdue-customer sweep ships with no schedule, and each run clears hand-set stops first.

Who can see what

A permission’s target (a company, a branch or a location) scopes documents and little else, a grant with no target is full access, a target narrows an answer without saying so, and owners and administrators pass every check. The four rules, with the GadgetSphere role they lead to, are on Core concepts › Who can see what; building the role is the Teams and permissions guide.

What this page does not tell you

Two things a reader of this page will reasonably want, which we are not prepared to make up.

Which background jobs a retail group should add to the defaults. When a tenant is created, BigLedger installs a set of default clocks, switched on: twelve e-Invoice jobs (submission, status checks, fetching from LHDN, the consolidated run, auto-cancel, e-mailing, classification codes and the intermediary token), the stock balance queue, the monthly deposit rollover, the monthly ageing snapshot, the clean-up of temporary documents and the task queue — and, since October 2026, the cashbook watchdog and the bank-reconciliation balance refresh. A tenant created before a default joined the set has it only if BigLedger has installed the defaults again since.

Everything else among the several hundred registered job codes waits for somebody to add a clock — and that includes jobs this page leans on: the Blacklist Overdue Customer sweep behind credit control, the marketplace inventory syncs and the first-in-first-out costing rebuild. You can see what your tenant actually has in the Scheduler applet, and how work actually runs explains why a clock existing is not the same as a job having worked.

One has a recommendation: schedule the Blacklist Overdue Customer sweep, daily and outside trading hours, knowing that each run clears every hand-set stop first (Scheduler). For the rest, which optional ones a group like GadgetSphere ought to switch on is a real question with a real answer that no page carries yet. Ask your BigLedger contact rather than guessing, and do not assume that a job described on an applet page is running on your tenant.

Whether a wholesale company should share the retail chart. We recommend one chart for a group in one industry, and a distribution arm like GSD sits on the boundary. Sharing the chart keeps the three companies’ results lined up account for account, and GSD’s different margin shows up in the numbers rather than in the account list. A second chart gives GSD room for wholesale categories a retail chart may not carry — rebates, volume discounts, freight recovered — at the price of another 200 seeded codes and a mapping somebody maintains for group reporting. Nothing in the product prefers either. It is an accounting judgement, and we have not found an implementation practice written down that settles it.

What success looks like

Half an hour, once the setup is done, before anybody else is let into the tenant. Do it per company.

Post one test invoice and find its journal. Use a service item, not a stock item — a stock item with no stock at that branch is refused at FINAL. Save, then set it to FINAL, because the journal is written at FINAL and not at save. You want three lines: a debit to the trade debtor code for the gross, a credit to the sales code for the net, and a credit to the output tax code for the tax. No cost-of-goods line — that is computed at month-end.
Check the opening balance view balances. Total debits equal total credits to the cent, with debtors under current assets (cash and stock come in by their own routes, not this view), creditors under current liabilities and capital under share capital. If those headings are wrong, your categories are not linked to their sections and no statement will ever be right.
Try to post into a locked month. Date a sales invoice in a month you have set to LOCK_TXN, save it and press FINAL: FINAL is refused, and the draft stays. Date a manual journal in the same month: it posts. That is the two-stage lock working.
Prove a knock-off pair. Finalise a sales order, open a sales invoice and look in Search Document: the order is there. If it is not, the row is missing or disabled, and it was missing when you finalised.
Look at the invoice’s number columns. With more than one company in the tenant, you should see a company number as well as the tenant number.
Sign in as a test user in the branch role. In Stock Availability their location picker should offer only GS-KV-01’s locations, and the report should cover only those. If they are offered every location in the group, a permission set in that role has no target.
Open the Scheduler listing. If you rely on the credit sweep, the row for the Blacklist Overdue Customer job (the processor named in Core concepts › What this module has no engine for) reads ACTIVE.

Seven checks, three companies, and you hand over a tenant whose gaps are known rather than discovered.

Common mistakes

Mistake	What you see	What to do instead
Creating the company first and reaching for the plus button beside Chart of Account	A chart coded `DEFAULT` you did not design, seeded with 200 template codes (`cashDraws`, `accReceivable` and so on, each with a six-digit account number)	Decide the chart first. The plus button is a convenience with a consequence
Treating the branch code as provisional	A code you cannot change on every document number the branch will ever raise	Agree the shape before the first branch
Assuming a new company is ready to post	A FINAL document with no journal and nobody told	Map the default GL codes, then post the test invoice
Assuming last year is locked because it is over	A cash bill finalised into February	A company with no fiscal year is never locked. Create the year, then lock each month as you close it
Reading the group Set of Books as a consolidation	Group revenue overstated by every intercompany sale	It sums; it does not eliminate. Name the record so nobody mistakes it
Expecting a credit limit to stop a sale	A customer well over their limit, served	Nothing checks a limit at the till. Switch on the optional check at FINAL on the sales order and invoice screens, and schedule the blacklist sweep, which nothing schedules for you; each run clears hand-set stops first