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 in the Core module, 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 in a moment:

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 lines, every time. 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 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 counter; a scheduled job recomputes credit status overnight and only then are certain documents refused. 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, 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 cannot be changed 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.

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.

What the shape of live installations looks like: across the 90 active tenants measured on 2026-09-16, 84 hold company records at all, and the median tenant holds two companies. Multi-company inside one tenant is the normal case, not the exception.

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; across two tenants 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 the listings hide them by default. 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 — turn on Doc No (Company) before the first document, and print it on statutory documents. Why: with three companies in one 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. The 90-tenant measurement puts the median tenant at 12 branches.

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: branch and location codes cannot be changed at all, ever, by anyone. A company code can at least be replaced by an owner or administrator, and even that is a migration in all but name because document numbers and permission-set names already carry the old one. 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. The measured shape is decisive — 73 of 90 tenants hold chart records and the median tenant holds one, while the median tenant holds two companies.

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, and 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; the chart also offers segments, dimensions, profit centres and projects for exactly this purpose.

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.

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.

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. Cost: somebody has to actually change 36 period statuses a year across three companies, on a date, every month. Put it in the close checklist, because nothing does it for you. Suits: every shape of business. GadgetSphere sets LOCK_TXN on the 10th and LOCK_ALL on the 20th.

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.

The mapping that decides whether anything posts

The company’s Default GL Codes tab — which lives in the Chart of Account applet, not on the company record — answers, once per company, “for this kind of movement, use this account”. There are 41 such roles across seven sub-tabs. Only 34 of 90 tenants hold any of these mapping rows at all, and where they exist the median company carries about 40 of them.

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; the journal then fails its balance check or reports that no journal was created. Either way the document is FINAL, has no journal behind it, and nobody is told. 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 document then fails at FINAL out of balance. It is the same symptom as a missing mapping with none of the same evidence. 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. The median tenant carries 47 tax codes.

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. The median tenant using cashbooks at all holds 39 of them and 190 branch-settlement links.

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 then the journal job fails its balance check — 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. Half the measured tenants — 50 of 90 — hold any knock-off rows at all, with a median of 17.

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 recovering that afterwards is not something to plan around. 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. It is empty on 84 of the 90 measured tenants, which 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 to settle before the first finalised document, and what can wait

The decisions that are expensive to reverse

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

What this page does not tell you

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

Which background jobs a retail group should have scheduled. The platform registers several hundred job processor codes and almost none is switched on by default. Which ones a group like GadgetSphere ought to have running — the credit-control sweep, the marketplace sync jobs, the costing rebuilds — is a real question with a real answer, and no page in the wiki carries it today. 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. A distribution arm sits at the boundary: its margin structure differs from retail’s, but its accounts largely do not. Both answers are defensible and the trade-off is an accounting judgement rather than a product fact.

Settled 2026-09-17 by Vincent: branch-suffixed revenue codes are not needed, and profit centre is not another word for branch. Both are columns in their own right, and both exist on the document header and on each line: guid_branch and guid_profit_center sit side by side on bl_fi_generic_doc_hdr and on bl_fi_generic_doc_line. So a journal line already knows its branch without the code spelling it out, and the profit centre is a second, independent cut you can use 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.

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.

Cash and bank codes are the exception and keep their suffix: CASH-PRI-KV01 is a separately reconciled balance, not a slice of one.

What success looks like

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

1. 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.
2. Check the opening balance view balances. Total debits equal total credits to the cent, with cash, debtors and inventory under current assets, 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.
3. Try to post into a locked month. Date a sales invoice in a month you have set to LOCK_TXN and save it: refused. Date a manual journal in the same month: it posts. That is the two-stage lock working.
4. 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.
5. 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.

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

Common mistakes

Related documentation

• Core module — the twelve-step setup order this page sits on top of, and what each applet requires before it can be used
• Chart of Accounts Setup — the step-by-step guide to building the chart once you have decided its shape
• Set of Books, Fiscal Years and Fiscal Periods — what the three locks actually stop, with the backend behaviour behind each
• Document numbering — the three numbers on every document and how to show the company and branch ones
• Organisation applet and Chart of Account applet — the field-level reference for every screen named above
• Cashbook applet and Tax Configuration applet — cashbooks, settlement methods and tax codes in full
• Inventory costing internals — what the inventory closing basis does to your profit and loss statement
• Financial Accounting — where the books this page sets up are actually read
• The course catalogue carries Set up a new company end to end, which walks the same ground mechanically, screen by screen. This page is its opinionated counterpart: that course tells you where to click, this one tells you what to decide