Organization

Set up your companies, branches and locations here before anything else: every document, stock movement and report is tagged with them. Create the company first, then a branch, then a location, and expect most company-level configuration to appear only after you save the record and reopen it in edit mode.

Overview

The Organization applet (menu name Organisation Applet) is where a tenant administrator defines the legal Company, its operating Branches and the physical Locations that every document, stock movement and report is tagged with. A tenant is your organisation’s whole BigLedger subscription — one isolated database, one login realm — and everything this applet manages lives inside it; a group with several legal entities almost always runs them as several Companies in the same tenant (see A second company, or another branch? below), not as separate tenants. It is also the home of a set of company- and branch-level switches that other applets never show but read at FINAL: the Knock Off Configuration that decides whether a finalised document opens a queue for the next document, the company e-Invoice and Peppol registration, the default tax codes, the timezone, the branch main / delivery location and the branch marketplace (EcomSync) rules. Around the core hierarchy it keeps reusable classification records (Company / Branch / Location Groups and Labels, Category Groups) and the Notification Templates used for WhatsApp, SMS and e-mail messages on document events.

Create the Company first, then a Branch, then a Location (or let the branch create its default location). Most company-level configuration only appears after the record is saved and reopened in edit mode.

Where it fits

A second company, or another branch?

This is the most expensive decision made in this applet, and neither screen helps you with it.

A branch is a place the same legal entity trades from. It shares the company’s chart of accounts, its default GL codes, its tax defaults and its e-Invoice registration — it can carry its own tax registration number, but not its own ledger. Every document raised at it rolls into one set of books and one return.

A company is a separate legal entity. Its own registration number, its own chart, its own primary ledger, its own submissions to LHDN. Two companies inside the same tenant share no trial balance, and moving stock or money between them is a transaction on both sides, not an internal note.

So the test is not size, it is filing: if the two operations file one return, they are branches. Adding a branch costs you a row; adding a company commits you to a second chart of accounts, a second set of default GL codes and a second e-Invoice registration. Make one when the law makes you — a separate e-commerce entity, a separate distribution entity — and not because an operation feels big enough.

The costly mistake is making a company where you wanted a branch. You then maintain two charts, two sets of default GL codes and two e-Invoice registrations for one business, and every internal movement needs an intercompany pairing or it gets keyed twice. The mistake in the other direction surfaces later and hurts more: a branch where you needed a company gives you no separate ledger to produce a return from.

What the organisation tree does not divide

Everything above divides documents. It does not divide master data, and that is a design decision rather than an omission.

Customers, suppliers, items and prices are one list for the whole tenant. Not per company, not per branch. A user whose permission set is scoped to one branch still opens the customer listing and sees every customer in the group, and there is no setting anywhere that changes it. The reason is operational: a shopper who buys at one branch and returns the item at another has to be the same customer record, found by both counters, or the second counter has no record to take the return against and the loyalty balance splits in two. Scoping the master would break the group’s own trade, so the layer that got the scoping is the document layer, where “whose trade is this” actually means something.

Whether a listing applies your permission’s company / branch / location scope is decided listing by listing, not by one switch: the document listings apply it; the customer and supplier listing does not.

Three consequences worth planning around:

• A branch manager can read the group’s customer list. If that is a problem for you — a franchise, a joint venture, two brands that must not see each other’s trade — the boundary you need is a separate tenant, not a separate company. Companies and branches will not give it to you.
• Bulk export is a different matter and it does refuse. The customer export checks your scope properly, so “can see on screen” and “can take away” are not the same permission here. See Set up your team.
• Document listings really are scoped, by company, by branch and by delivery branch, on the server. So the report a branch manager runs is theirs; the customer list they browse is everyone’s.

And it does not divide a customer’s e-invoice facts. The TIN, identity, e-invoice address, Skip e-Invoice flag, self-billed flag, running-number override and Peppol identifiers on a customer or supplier record are read for whichever company raised the document: the customer’s skip flag is looked up by the customer alone, with no company in the question; the running-number override is resolved from the buyer before the issuing company’s own pattern is consulted; and the self-billed flag on a supplier is what every company’s purchase screens pick up. Skip a customer for one company’s convenience and you have skipped them for the group. The full per-level map for e-invoice — what is the tenant’s, the company’s and the branch’s — is on the My E-Invoice Admin applet page.

What breaks elsewhere when something here is wrong

Almost nothing on these screens fails on these screens. A company or branch record is read at FINAL by the posting steps of five other modules, so one wrong value here surfaces as an unrelated-looking failure somewhere else, minutes later, usually to somebody who did not make the change: accounting stops at MISSING_DEFAULT_GL_CODE after the document has already posted to stock; sales and purchasing lose the link between a document and its source, with nothing logged; inventory quietly puts stock in the branch default location instead of where you meant; e-Invoice silently collects nothing, because a new company starts DISABLED; and every dated report cuts its days in Asia/Kuala_Lumpur while the timezone is blank. Symptom by symptom, with the messages you will actually see, is in Troubleshooting below.

What it pairs with in practice

Chart of Account, always. A company is not postable until its Default GL Codes are mapped there, and that mapping is not part of creating the company here. Treat the two screens as one task. Cashbook and Tax Configuration come next — the branch Settlement tab and the company Tax tab are pickers over records those applets own, so an empty picker means you are in the wrong applet.

And, for groups, the intercompany pairing — the scenario this applet exists to make survivable. A group runs three companies inside the same tenant. The distribution company imports a pallet and the retail company takes half of it; the online company’s fulfilment centre ships goods the retail company sold. Every one of those is the same commercial event needing to exist as two documents, in two companies, facing opposite ways, agreeing with each other. The question that reaches support is never “does BigLedger do intercompany?” — it is “we raised the invoice in the selling company, why is there nothing in the buying company?”, asked by someone who already assumed the second document would appear. It does appear; what they are missing is the pairing that tells it to. A row on the Branch › Intercompany Configuration tab is one sentence — when a document of this type is finalised at this branch, and the document names this rule, create a document of that type in the other company — either AUTO, which creates it the moment the first is finalised, or MANUAL, which leaves a row for someone to press Confirm Intercompany Transaction on. Either way the new document arrives as a draft unless the rule’s Auto Final Target Doc box is ticked, so without it nothing posts in the buying company until somebody there finalises it. Both modes are right for different groups, and a group whose two companies have different accountants needs MANUAL, because a document nobody agreed to is worse than typing it twice.

The sale must bill the buying company’s own record. Every company has an entity record of its own, usually created with the company and carrying its name. The pairing finds the buying company from the company that owns the customer on the document; bill any other customer record — a trade customer that happens to share the name — and it refuses, because the buying company’s own entity record is not on the document. That record starts life with no roles and no AR/AP type, so give it the customer role (the sales invoice’s customer picker lists customers only) and an AR/AP type. The type is best set per company, with a Company Linking row on the record in the Entity applet: a linking row for the posting company wins over the record’s own type. Left blank, the document is finalised with no journal behind it — the receivable (or, on the buying side, the payable) line is left out and the posting refuses the unbalanced journal. Give the selling company’s own record its type too, since it is the supplier on the counterpart.

It resolves a branch, not just a company. The rule row names the selling branch only. The receiving branch is chosen on each document: on the sales invoice’s Account › Intercompany sub-tab you pick an Intercompany Branch of the customer record, and the receiving branch is the one that has that entity branch as its Default Entity Branch. If none does, the pairing fails because that entity branch is not the default of any branch — “I know which company you are selling to, but not which of its branches should receive this”. A test entity set up and never linked is the commonest way to meet it. The stock lands in the first location linked to the receiving branch in the system’s own order — not its Main Location — so a receiving branch with a single location is the safe arrangement.

What the new document holds. The counterpart is built from the source line for line: items, quantities, unit prices, discounts, tax codes and amounts, the totals, currency, reference and remarks. Its supplier is the selling company’s own record, and its description reads Auto Created From the source type and number. Nothing on the buying side prices it again — there is no pricing scheme per side on an ordinary pairing (the pricing-scheme fields on this tab belong to Auto Purchase Stock only), so the transfer price between your companies is whatever the seller typed. And it is dated when the pairing runs, not with the sale’s date: at Finalise for AUTO, at Confirm for MANUAL. A sale dated 31 March and finalised on 2 April gives a purchase invoice dated 2 April, in the other month. Correct the draft’s date before finalising it.

Once created, the two documents are independent. Where a void is allowed at all, voiding either one leaves the other standing, and the counterpart does not block the void. And do not take a paired document back to Draft and finalise it again — the sales invoice screen does not offer that, but some order screens and the API do: every finalise runs the pairing afresh and nothing looks for the first counterpart, so the other company gets a second one. Correct a paired sale with a return — a sales return pairs to a purchase return the right way round — and read the cautions on the Purchase Credit Note and Sales Debit Note pages before pairing a note, because both note pairs arrive pointing the wrong way.

One rule row per selling branch per document pair is enough, because the receiving branch is picked on each document. A branch’s own rows are what its invoices offer: a sales invoice’s Intercompany sub-tab lists only the rules of the invoice’s branch for sales invoices, so a branch with no row simply offers nothing to choose — and a document with no rule chosen pairs with nothing, silently. Rows can be written once at company level and copied to every branch with Copy configs to branches.

A failed pairing is recorded but not shown. When the pairing throws — any of the refusals above — it writes a row carrying the error into the intercompany queue, but no screen shows that row’s status or message: it sits under Unprocessed in the Intercompany menu looking exactly like a MANUAL row waiting to be confirmed. Since AUTO never leaves a row there, a row whose Used Config is an AUTO rule is a failure. The check that always works is the other side: open the buying company’s Purchase Invoice listing and look for the Auto Created From description with the sale’s number. Fixing the setup does not, by itself, raise the missing document for a sale already finalised. Once the setup is fixed, tick the failed row under Unprocessed and press Confirm Intercompany Transaction: that runs the pairing again for the sale, removes the row when the counterpart is created, and, if the pairing is refused again, shows the refusal as an error message. Check the buying side first, because confirming a row whose counterpart already exists creates a second one.

Branch, profit centre, and the dimensions a document carries

Read this before you design a chart of accounts for a multi-branch group, because the usual mistake is made in the chart and paid for here.

A document knows seven things about where it happened, and it knows them line by line. The header and every line carry the same seven dimensions side by side: company, branch, location (the store stock moves through), profit centre, segment, project and GL dimension. Two of those are structure — the company you traded as and the branch you traded at — one is physical, and the remaining four are free analysis dimensions you define in the chart of accounts. Branch and profit centre are independent columns — a profit centre is not another word for a branch. The branch is where you traded; the profit centre is a second, unrelated cut for whatever else you want to measure: a business line, a department, a project.

Because both live at line level, one document can carry lines belonging to different branches, or to different profit centres. On a sales invoice line, Item Details › Main Details has its own Branch picker, and the Department panel beside it has Segment, GL Dimension, Profit Centre and Project (each shown or hidden by that applet’s own Field Settings). The bulk file imports accept a branch code per line and fall back to the header’s only when a line leaves it blank, so a single imported document can span branches — that is what the line-level dimension is for.

At FINAL, the postings inherit those dimensions, and not all of them the same way:

• Revenue, tax and charge journal lines take the document line’s branch and profit centre, falling back to the header’s only when the line left them blank.
• The receivable or payable line takes the header’s, always. Split one invoice across two branches and the revenue splits per line while the debtor balance lands whole on the header’s branch. Know that before you build a branch profit and loss statement that has to tie to an aged debtors listing.
• The inventory transaction line takes the document line’s branch with no header fallback, while the location on the same line falls back four deep — line delivery location, line store, header store, branch default location. Stock always lands somewhere; the branch tag on the movement is only ever what the line carried.

The consequence for your chart of accounts is the point of this section. A journal line already knows its branch. So SALES-SMARTPHONE-KV01 — a revenue code per product per branch — is a code you never needed: twenty-two branches by forty product lines is 880 codes, recreated every time a shop opens, to produce a split a report gives you from a column. Worse, you would have spent your one free dimension on the branch you already had, and still have no way to cut revenue by business line. Keep one SALES-SMARTPHONE and let the branch come from the document. Cash and bank codes are the exception and should keep their suffix — CASH-PRI-KV01 is a separately reconciled balance, not a slice of one.

Profit centres are not created here. There is no profit-centre screen in this applet; profit centres are maintained in Budgetary › Profit Center, where a profit centre is also the owner of a budget. Profit centres — and segments, GL dimensions and projects beside them — are opt-in dimensions: nothing creates them, nothing requires them, and the ledger reports perfectly well without one ever existing. That is the other half of the argument above. If the cut you want is by branch, you already have it, free.

Nothing derives a profit centre for you. It is typed on the document or supplied by an import row, and from there it is copied verbatim — onto the journal line, the inventory line, and any document created from this one. No screen defaults it from the branch, the user, the item or the customer. And no behaviour anywhere keys off which profit centre a line carries — control accounts, tax, costing and posting all ignore it. Its whole job is to be there when a report groups by it, so a blank one is not an error that surfaces anywhere until a report is short. One naming trap: the panel that holds these fields on most document screens is labelled Department, and the picker inside it is a profit-centre tree.

Where a report can and cannot take those cuts. The ad-hoc Profit Loss Report groups by exactly one of branch, GL dimension, profit centre, segment or project, restricted to the values you tick, and it drops any journal line whose value for that dimension is blank. There is no branch-by-profit-centre cross-tab, and there is no “everything” run. The mechanics, and the three other ways its total differs from a statutory statement, are on Financial Report.

A location belongs to a branch twice over

Worth knowing before you reorganise, because the two links are written together and read apart.

A location carries its own branch on its record (and a company alongside it), and there is a separate branch-to-location link list — the one the Location tab on Branch Edit maintains. Creating a location through this applet writes both at once, from the same value, so on a tenant that has only ever created locations that way the two agree and the distinction never shows.

They are read by different things, which is when it shows:

• The location’s own branch is what the Location listing is permission-scoped by — this is one of the few listings that really does apply your branch scope on the server — and what the core listing queries filter on.
• The link list is what the shopping-mall sales report joins stock balances through, what the older branch queries join, what a purchase-requisition printable reads, and what marketplace order ingestion falls back to when it cannot find a store for the branch any other way.

The practical shape: a location can be linked to more than one branch through the list while its own record names only one, and the many-to-many is genuinely used. If a location has stopped appearing for a branch after a reorganisation, the two places are the two places to look, and the record’s own branch is the one the permission check reads.

Screens and menus

Every screen here is the same two-column pattern — a listing on the left, a create or edit panel on the right — so the useful thing to say about them is what they do not show you.

Create is not edit. Most of what a company or branch record carries does not exist on the create form. Company Timezone, Main Branch and Entity; branch Main Location, Delivery Location, Default Entity Branch, Timezone, Default Pricing, Skip E-Invoice and Tax Applicable — all edit-only. A record created and never reopened is half-configured, and that is the origin of most of Troubleshooting.

Listings hide things, differently. Company and Branch load ACTIVE rows only, so a company you closed is filtered out rather than missing; Location shows ACTIVE and INACTIVE unless you filter. The company search covers Company Name and Registration Number only, and rejects keywords shorter than three characters.

Company Edit has twelve tabs — Details, E-Invoice, Peppol Config, Tax, Branch, Location, Labels, Knock Off Config, Employee, Engagement Access, Address, Intercompany Configuration — reorderable per tenant in Settings › Default Selection › Details Tab Ordering. If the E-Invoice tab is missing entirely, the HIDE_E_INVOICE_TAB key is set (see Configuration; there is no toggle for it). Branch Edit has twelve tabs and none is conditional — the Marketplace tab is there even on a branch that sells nothing online.

Two captures that sat here were withdrawn: every frame in that session showed a signed-in staff e-mail address in the top bar. Recaptures from a synthetic demo tenant will replace them.

A label is the thing you link; a group only organises labels. You link a label to a company, branch or location from the Labels tab on its edit screen. A group is never linked to anything. Category Groups are a separate list again, typed CP_COM or DOC_ITEM, and they feed the storefront and item categorisation rather than the organisation tree. What a linked label actually changes is different for each of the three kinds: see What a label changes once you link it below.

Notification Templates save as TEMP while you build them and only become ACTIVE on the final Save, so an abandoned draft is left inert rather than half-live; the Company and Branch tabs decide which records a template applies to. Nothing seeds a template for you — until somebody builds one, there is nothing for the Company and Branch tabs to apply.

Screenshot withdrawn; a recapture from a demo tenant is on the list.

Audit Trail lists back-office audit events with user names resolved from the tenant user profile. Settings carries the applet’s field toggles and default selection, the Outlet Type / Outlet Size master lists, the four Server Side Permissions screens that are the only real access control on this applet, the shared webhook Triggers screen and Release Notes. Personalization lists Field Settings, Default Selection and Sidebar, and mostly does not work — see Applet settings.

Screenshot withdrawn; a recapture from a demo tenant is on the list.

What a label changes once you link it

Company, branch and location labels look alike on screen. They are three separate lists, and each is read by different screens, or by none.

Location labels are a report filter. Stock Availability, and most reports in the Stock Report applet, offer a Location Label filter beside the location picker. Pick a label and the report runs for every location the label is linked to, so a label such as Johor Bahru outlets saves you ticking three stores each time. The screens combine the label with your location picks in two different ways. Stock Availability and the other stock reports with the filter add the label’s locations to any locations you also picked. The Stock Aging report uses the label instead: if you pick a label, the locations you ticked by hand are dropped. If a Stock Aging total looks too small, check whether a label was left in the filter.

Branch labels decide which staff spending limit applies at the till. An employee’s spending limit (on the Employee applet’s Spending Limit tab) can name a branch label. This matters only when a person has more than one limit in the same company. The POS General till then uses the limit whose branch label matches a label on the till’s branch. Once the cash bill is finalised, BigLedger adds the bill to the usage of the limit it picks by the same rule. Three cases behave differently:

• A branch with no label: the till checks the first limit it finds. After the bill is finalised, its quantity and amount are added to every enabled limit the person has in that company.
• A branch whose labels match none of the person’s limits: the till falls back to the first limit. After the bill is finalised, no limit is charged.
• A branch with several labels: only one of them is compared, and nothing decides which one.

So if staff limits are set per branch group, give each branch exactly one label and give every limit a label. With a mixed set-up, the limit the till enforces can be one that is never used up, and the one that fills up can be one the till never checks. Nothing on either screen shows this.

Company labels change nothing outside this applet. No other screen, report or posting reads them. They are a way to tag your own companies, for example Malaysia against Singapore, for your own reference.

Configuration

Before you can use it

Applet settings

Settings live in the applet’s own Field Settings and Default Selection screens (this applet does not use the shared settings component other applets do), plus a Personalization › Default Selection. The first two are saved per tenant; personal defaults are saved per user. Anyone who can open the applet’s Settings menu can change them — there is no permission check.

Field Settings (Settings › Field Settings). Every toggle below is declared, rendered, persisted and — except where stated — consumed.

Default Selection (Settings › Default Selection).

Keys read without a control. One applet setting, HIDE_E_INVOICE_TAB, is read by Company Edit but has no toggle: when it is true the company E-Invoice tab is not rendered. It can only be set or removed by editing the applet’s stored settings directly — ask support.

Personalization › Default Selection. Only Default Language works. Default Branch and Default Location write into a container that is never loaded, so changing them raises a console error and saves nothing. The Personalization sidebar also lists Field Settings, but no page exists behind that link, so it lands on the 404 page.

Outlet Type / Outlet Size (Settings › Outlet Settings). Two small master lists — Outlet Type Code / Name / Description and Outlet Size Code / Name / Description (code and name required) — that populate the Outlet Type and Outlet Size pickers on Location Edit.

Document behaviour settings

Not applicable — this applet creates no documents. The records it maintains change how other applets’ documents behave at FINAL, which is the next two sub-sections.

Company, branch and location settings that other applets and the backend read

Knock Off Configuration (Company › Knock Off Config › Knock Off)

This tab owns one row per company per source document type → target document type pair. It decides, for every document type, whether FINAL leaves anything for the next document to pick up.

A row is one sentence: when a document of this source type is finalised in this company, leave its open quantity where a document of that target type can find it. You pick Server Doc Type 1 (source) and Server Doc Type 2 (target) from the document-type list, and the grid’s Knock Off toggle saves immediately. Apply to pre-order item only narrows the row to lines whose item is flagged pre-order. Flow Type offers LINE and nothing else, although a header-level flow exists in the data model that the screen does not offer.

Two things about a row have no control anywhere in the applet, and one of them changes behaviour you will see. Every row this tab writes is a knock-off row — a Copy From variant exists in the data model, but its tab is switched off and does not render. And a row can carry a target posting status that the automatic converters read to decide what status the converted document arrives in — GRN → Purchase Invoice, GRN stock-in → Purchase Invoice (no stock-in), Delivery Order or Job Sheet → Sales Invoice, Sales Order → Sales Invoice or Purchase Order, Purchase Requisition → Purchase Order, and outbound → inbound stock transfer. If your converted purchase invoices keep arriving in a status you did not expect, this is why. The Auto Conversion tab beside Knock Off lists each automatic conversion rule with its New Document Status, read-only — ask support to change it. The tab arrived in an applet build of late September 2026; if your screen has no such tab, your build predates it, and support can read the rule for you. The row’s mode (AUTO / MANUAL) is used only in the loop check described below.

What happens at FINAL. Finalising a document is a separate action, not a save: it starts a primary posting job which fans out to secondary steps, and one of those steps is the open-queue step. It loads the enabled knock-off rows for the document’s company whose source is this document type. If the list comes back empty it does nothing, writes nothing and logs nothing. Otherwise every line with an open quantity — the line quantity minus what has already been knocked off — gets one open-queue entry per configured target type. Forex documents are processed through their local-currency shadow document. The downstream applet’s Search Document tab reads nothing but these entries, which is why a missing or disabled pair here is the first thing to check when “the invoice cannot find the order”.

Saving a row is validated on the server: an exact duplicate of company + flow type + source + target is rejected as a duplicate; a chain of AUTO rows that loops back to its own source is rejected as recursive. The server does not reject source = target — only the screen does.

The grid also refuses, on screen, to enable a second target in the GRN family (INTERNAL_PURCHASE_GRN_STOCK_IN, INTERNAL_PURCHASE_GOODS_RECEIVED_NOTE, INTERNAL_SALES_GOODS_RECEIVED_NOTE, INTERNAL_SALES_GRN_STOCK_IN) for the same source while another is enabled — toast KO Conflict Detected. This is a screen guard, not a server rule.

Pairs the other applet pages depend on (each page names its own): sales order → sales invoice / delivery order, purchase order → GRN / GRN Stock In, GRN → purchase invoice, blanket purchase order → purchase order, stock requisition → outbound stock transfer, consignment purchase order → consignment GRN, and the goods delivery note flows. A stock requisition’s own CREATE ST button copies lines directly and does not need a row; only the transfer applet’s Search Document › Stock Requisition path does.

Company Details tab

Company Tax tab

The default output tax code and inclusive flag (Sales sub-tab) and the default input tax code and inclusive flag (Purchase sub-tab) — pre-filled on new sales and purchase documents of the company; each document can override them.

Company E-Invoice tab

The tab owns the company settings the MyInvois pipeline reads. E-Invoice Status is forced to DISABLED when a company is created (the create form has no e-invoice controls) and is switched on here.

Saving with Status ENABLED, an LHDN environment and a TIN also configures the intermediary system for the company (toast Intermediary System Configured Successfully).

A blank LHDN Environment is not “unset” — it is the sandbox. The one read that decides the environment treats a blank as SANDBOX, so a company enabled without choosing the environment submits every document to LHDN’s sandbox. Nothing on the screen, on the document or on the e-invoice says which environment a submission went to: the sandbox returns the same statuses, the same LHDN unique identifier and the same QR code, and a document that reads Valid there has not been filed with anybody. This is the one field on the tab where the consequence of leaving it alone is silent and total, which is why it is worth setting before Status is switched to ENABLED rather than after. A newly created company starts with the field blank, and blank means sandbox — so the order in which you set these two fields decides whether your first live submission was ever filed.

Two failure messages, and they mean different things. If the company has no intermediary configuration for the environment it is pointed at, submission fails with “No intermediary config found for company with guid … in <env>environment” — nothing was ever configured for that side. If a configuration exists but carries no usable token, it fails with “Access Token not available” — the configuration is there and the authorisation behind it is not. The two are set up separately, so a company can be enabled for e-invoice and still have no active intermediary configuration for either environment — nothing on the enabling side checks the other.

Batch Line Logic records an intention; it does not select a run. The two automatic consolidations are separate scheduled runs — one groups by company and document type, the other groups by branch and builds consecutive document-number ranges — and which of them a tenant gets is decided by which one is scheduled, not by this field. A company set to BY_BRANCH whose tenant is scheduled for the by-document run is consolidated by document, and nothing on this screen will say so. The field is still worth setting correctly, because it is the record of what the company was promised and what support configures the schedule from; read it as a declaration, not as a control. The difference the two runs make to the finished e-invoice is on the My E-Invoice Admin applet page.

The three Disable … switches: what they do, and what they are not. No posting step reads them. What reads them is the Submission Type drop-down on a document’s E-Invoice tab, which drops CONSOLIDATED and SINGLE-GENERAL out of the list entirely for a company whose switch is on (on the sales side and the purchase side alike). That is not a broken control — it is enforcement at the point of choice, which is the right shape when the wrong choice is a person’s rather than a process’s. A distribution company where every sale is business-to-business and must be reported individually takes the option away, and no clerk can pick it by accident; the server needs no check of its own because it only ever acts on the submission type the document already carries. Alongside it: Individual and Single-General become selectable only once the document carries a buyer entity with a billing address, so a blank drop-down there is usually a missing address, not a company switch.

The limit, stated plainly: they govern what a person can choose. They are not a compliance control. A submission type set by anything other than that drop-down is outside what they can reach — the scheduled consolidation run stamps CONSOLIDATED onto documents itself. Whether a consolidation routine or a default set elsewhere can still produce a consolidated submission at a company with the switch on is an open question we have put to BigLedger and have not had answered. If your obligation turns on it, ask before you rely on the switch, and check the consolidation report at month end either way.

Enable high sales value validation is read in two places from two different settings. Switched on, the sales invoice screen shows an e-Invoice warning card and refuses to finalise while the buyer’s mandatory e-invoice fields are blank — a genuine block, chosen by the company. The buyer-details block on the document’s own E-Invoice › Submission tab, however, marks its fields required from a separate enforcement flag that is not part of the company record and is not written by this applet, so it falls to its default of on. Expect that tab to ask for buyer details whether or not you switched the company on.

Four more company e-invoice settings are read at submission time but have no control in this applet (set through the API or by support): the issuer type — ERP or INTERMEDIARY, default INTERMEDIARY (a blank counts as INTERMEDIARY too), which chooses the LHDN token: as an intermediary the call carries a token minted for this company’s TIN; as ERP it carries a single shared access token and the company’s own token configuration is never consulted; the forex posting logic — which of a foreign-currency document and its local-currency shadow is submitted, the foreign-currency document by default; and the running-number and line-description templates (an entity-level override wins).

Company Peppol Config tab

• Peppol Registration — the participant registration (special identifier 0230:<scheme><business id>, business card contacts, additional identifier scheme and value, supported document profiles) posted to the Peppol access point; Post sets the registration to FINAL, Sign uploads the signed KYC PDF.
• Peppol Ids — the company’s Peppol participant IDs, one flagged default (Verify Participant ID checks the directory), and the Peppol Status select (ENABLED / DISABLED).
• Notification Config — checkboxes peppol, email, other UCC channels, through customer portals.

Three of those controls reach the pipeline, and they reach different parts of it.

The older single Peppol Participant ID field on the company record is superseded, and nothing writes it any more. One posting-queue route still requires it and the customer’s equivalent to be filled — but the line in this applet that used to save it was switched off in the same release (June 2024) that introduced this tab’s multi-ID list. With nothing left to write it, it stays blank, and the route it gates never opens; see My Peppol Admin Applet. Register and default your IDs in the list above; there is no field for the old value to fill in.

Company Intercompany Configuration and Engagement Access

• Intercompany Configuration — config name / code, mode AUTO (execute upon FINAL) or MANUAL, and exactly one document pair per row (Sales Invoice → Purchase Invoice, Sales Invoice → Purchase GRN, Purchase Order → Sales Order, Sales Order → Purchase Order, Sales Return → Purchase Return, Purchase Return → Sales Return, Payment Voucher → Receipt Voucher, Sales Credit Note → Purchase Credit Note, Purchase Invoice → Sales Invoice, Sales Debit Note → Purchase Debit Note, Delivery Order → Purchase GRN). Copy configs to branches pushes the company rows to every branch. The branch-level screen (below) is what the intercompany posting reads for a document’s branch.
• Engagement Access — which other companies this company may reach in the Engagement applet.

Company columns with no control in this applet

The company member-point configuration decides which document type and posting status award membership points. It is not a field of the company record: it is a per-company configuration record (type MEMBER_POINT, code DEFAULT) naming the awarding document type and status. With no record, or blank values, points are awarded on INTERNAL_SALES_ORDER at FINAL — so a company with no configuration still awards points on finalised sales orders that carry a member. A second per-company setting lets a company include or exclude particular secondary posting steps at FINAL. Neither has a screen here or in the Membership Admin applet; they are set through the company API.

Branch Details, Pick Pack, Extension and Marketplace

Three branch pricing surfaces, and which one the counter uses

Three different records are all called some version of “the branch’s default pricing scheme”, and two of them decide the price a cashier sees — on different paths through the same counter. Knowing which is which is the difference between changing a setting and changing a price.

Location

The stock-in-transit location every company gets automatically (L-SIT-<company code> / L-STOCK-IN-TRANSIT-<company code>) is an ordinary BASIC location created with the company; the Stock Transfer applet excludes it from Location To.

Settings in other applets that control this applet

Feature visibility / permissions

This applet defines no client-side permission codes and checks none. Access is controlled entirely by the server-side permission screens under Settings (Permission Wizard, Permission Set, User Permission, Role Permission), which map users, roles and teams to the API_TNT_DM_* permissions of the Company, Branch, Location, Tenant, Applet, Team, Customer, Label, Currency, Pricing Scheme, Country and Chart of Account services. One rank check exists on screen: the Company Code on Company Edit is read-only unless the logged-in user’s rank is OWNER or ADMIN.

Fields

Company — Details and Address

Identification, contact details, website, description, abbreviation, logo and audit stamps behave as they look, and what Currency, Timezone, Chart of Account and Status do is in Configuration above. What the form itself will stop you doing:

On Address, Line 1, Postal Code, City, Country and State are required and State comes from the chosen country. Changing Country here is pushed into the E-Invoice draft — the one place this tab reaches outside itself.

Field detail for Tax, E-Invoice, Peppol Config, Knock Off Config and Intercompany Configuration is in Configuration, where the downstream consequences are. Employee, Labels, Engagement Access, Branch and Location are link pickers.

Branch — Details, Address and Marketplace

Codes are upper-cased. Like the company code, a branch code can be changed after creation by an OWNER or ADMIN only, to one that is unique (Branch code already exists! on a duplicate). Currency is pre-filled from the company. Address, contact details, three free-text branch references, tax registration number, GPS coordinates, opening hours, the store-locator flag and the logo behave as they look, and the edit-only fields — Main Location, Delivery Location, Default Entity Branch, Timezone, Default Pricing, Skip E-Invoice, Tax Applicable — are all in Configuration above, where their downstream consequences are. Two controls have no counterpart there:

The Marketplace tab is present on every branch, including branches that sell nothing online. Choosing a Marketplace Type reveals that platform’s own authorisation fields (Shopify, for instance, asks for an access token, store name and API version); the rest is the EcomSync configuration listed in Configuration. Publish Item only queues categories for publishing — it does not push listings when you press it.

Location — Details

Code and name are upper-cased, the code can be changed after creation by an OWNER or ADMIN only, and a duplicate gives Location code already exists!. Company and Branch are required and the branch list filters by company. Commencement date, currency, description and the address behave as they look, except that create shows one phone field and edit shows four; Location Class, Status, Outlet Size and Outlet Type are covered in Configuration.

Save failures show Failed to save location. Please try again. or Request timed out. Please try again. — the second is a 30-second timeout on the screen and the record may in fact have saved. Refresh the listing before retrying.

Groups, Labels, Category Groups, Outlet Types and Notification Templates

Groups, labels, outlet types and outlet sizes all take a code and a name, both required, plus a description; a label also takes an optional group and rejects a duplicate code with Label code already exists!. A Category Group adds a type (CP_COM or DOC_ITEM), a param code and name, a status, and — on edit only — a Categories tab with an image per category.

A Notification Template needs a code, a name, a Notification Type (WHATSAPP, SMS or EMAIL) and a Document Type before anything else is usable, and the three things worth knowing are that the Languages tab collapses to language and body for EMAIL templates, that a WhatsApp body is capped at 1,024 characters and a footer at 60, and that an AUTOFILL placeholder must name a Placeholder Source (NAME_CARD_URL, QR_CODE_URL, AGENT_NAME or CUSTOMER_NAME) or it saves empty. A template is stored as one header with one line per component and language.

Lifecycle and effects

This applet creates no documents, journals, stock transactions or queue rows of its own. It writes master data:

• Statuses. Company and branch status is edited as ACTIVE / CLOSED (the applet records the choice in the record’s extension entries and, for a company, closes its branches and locations too); location status is ACTIVE / INACTIVE shown as CLOSED. Listings load ACTIVE rows by default. There is no state machine — status is simply overwritten on update, and only its presence is validated.
• Delete is a soft delete: the record is marked DELETED and kept. No check is made for documents that reference the company, branch or location, so a deleted record simply disappears from pickers while its documents keep pointing at it. The delete button on Company Edit is switched off; branches and locations have a Are you sure you want to delete? confirmation.
• Creating a company (one transaction) also creates a CORPORATE entity when none is supplied, the company’s primary ledger in the company currency, the stock-in-transit location L-SIT-<code> (only if the company does not already have one), and fires the COMPANY_CREATED webhook. It does not create default GL codes, a branch, knock-off rows or a cashbook.
• Creating a branch with Create default location posts the branch, then the location, then updates the branch’s Main Location and its MAIN_LOCATION extension entry.

What other documents read from here at FINAL — the knock-off pairs, the company e-Invoice status and the branch and entity skip flags, the branch default location, the branch intercompany settings, the company member-point configuration and the company timezone — is set out in Configuration above, and what each one looks like when it is wrong is in Troubleshooting below.

Where the figures on your reports come from

This number is wrong, where did it come from? For company, branch and location the answer splits cleanly in two.

The dimensions are frozen. They are stamped onto the posting at the moment the document is finalised, not looked up when the report runs. The journal line gets its own copy of the branch and profit centre, and so does the inventory transaction line. So if you re-point a location to a different branch, rename a branch, or set a branch Main Location you should have set months ago, history does not restate: last quarter’s branch split will read the same next year as it does today. That is deliberate, and it is what you want from an accounting record. It is also why “I fixed the branch and the old report still shows the old split” is not a fault to report.

Costing is the one figure that arrives after you press the button. It is not on the document at FINAL. The inventory transaction lines are written first, then the moving-average, weighted-average, FIFO and LIFO costs are computed from them and written back onto the document line — which is why all four sit there side by side and why a costing report reads a stored figure rather than recomputing a history. A document whose cost still reads zero a moment after finalising has not failed; the chain has not finished.

Date boundaries are the opposite — recomputed live, every time you ask. A report row or a bank reconciliation window casts the stored timestamps into the company timezone at query time, falling back to Asia/Kuala_Lumpur when the company has none. Nothing was stored, so nothing needs restating — change the company timezone this afternoon and last month’s day boundaries move with it. That cuts both ways: it is how you fix a group whose days were being cut in the wrong zone, and it is how a figure someone printed last week stops matching the same report today.

Related applets

Almost every applet in the platform reads a company, branch or location, so a list of them all is a list of the product. These are the ones whose behaviour actually changes with what you set here.

Set up alongside this applet. Chart of Account — the chart is assigned here, but the company’s Default GL Codes, ledgers, fiscal years and sets of books are all maintained there, and a company is not postable until they are. Cashbook and Tax Configuration own the settlement methods and tax codes the branch and company tabs pick from. Entity, Customer Maintenance, Supplier, Employee and Merchant Admin supply the parties linked on the Customer, Supplier and Employee tabs — and the entity branch that intercompany pairings resolve through. Doc Item Maintenance, Pricebook and Forex supply rounding and group-discount items, pricing schemes and the currency list.

Reads the Knock Off Configuration at FINAL. Every document applet whose Search Document tab pulls from an earlier document: Sales Order → Sales Invoice and Goods Delivery Note; Blanket Purchase Order → purchase order → Purchase GRN and GRN Stock In → Purchase Invoice; Consignment Purchase Order → Consignment GIN; stock requisition → Stock Transfer. If one of those cannot find its source, start at Company › Knock Off Config, not at the document.

Reads the branch or location. POS General is the one that fails loudly — cash-bill FINAL enforces the branch Main Location, and branch rounding and group-discount items override the company’s. Every stock applet — Stock Balance, Stock Availability, Stock Adjustment, Stock Take, Stock Report, Warehouse Management, Consignee Stock Transfer, Customer Consignment — is keyed by the locations defined here, uses the CCSG class to tell consignee locations apart, and excludes the auto-created stock-in-transit location from transfer targets. Delivery Installation carries branch and location on shipments and jobs.

Reads the company e-Invoice, marketplace and points settings. My e-Invoice Admin and MyPeppol Admin operate on the registrations owned here — and are where a buyer’s details get corrected, rather than on the document. EcomSync, CP Commerce Admin, Tiktok Sales Order and Shopping Cart Customer Access treat the branch Marketplace tab as the EcomSync branch record. Membership Admin, Commission Scheme, Claim and Claim Cycle are scoped per company or branch, and membership points are gated by a company configuration record with no screen in either applet.

Where the other dimensions live. Budgetary owns profit centres, segments, projects and GL dimensions; Financial Report, Ledger and Journal and Bank Reconciliation are where company, branch, location and profit centre become the axes you report on. Workflow Design assigns processes per company.

How you know it worked

Nothing on these screens confirms that a company is actually usable. Saving succeeds either way, and every one of the failures below is discovered by somebody else, later, in a different applet. Five checks, about ten minutes, and you can stop worrying about the company you just set up.

1. The company can post. Open Chart of Account › Companies › your company › Default GL Codes and confirm there is a row for at least DEBTOR, CREDITOR, SALES, PURCHASE, OUTPUT_TAX and COGS. If the tab is not even rendering, the company has no chart assigned — go back to Company Edit › Details first. A missing type is not caught until a document that needs it has already gone FINAL.
2. The knock-off chain is live. Finalise one real source document — a sales order, say — then open the downstream applet and look at its Search Document tab. Your order should be there. If it is not, the pair is missing or disabled, and nothing was logged to tell you.
3. The branch will accept a cash bill. Confirm Branch Edit › Details shows a Main Location, then finalise one cash bill at that branch. A refusal because the location does not match the branch’s default location means the branch’s Main Location field and its MAIN_LOCATION extension entry disagree — open the branch and save Main Location once, which writes both.
4. The e-Invoice pipeline is collecting. Finalise one document at the company and look for it in the e-Invoice pool within a minute or so. Nothing there and no error means one of three things, in order of likelihood: the company is still DISABLED, the branch has Skip E-Invoice on, or the entity does.
5. The day ends where you think it does. Run any dated report over a day whose figures you already know and check the boundary. A blank company Timezone silently means Asia/Kuala_Lumpur.

Recovering documents finalised before the configuration was right

There is no watchdog, the repair screen lives in another applet, and Undo to Draft is not the general repair it looks like. Taking a finalised document back to Draft releases its knock-off links and nothing else: it unposts nothing. Finalising it again re-runs the open-queue step — which carries no “already done” guard, so it now finds the pair and creates the rows — but it does not post the document again: each posting step refuses a second posting, the journal’s refusal lands in the background error table rather than on your screen, and the stock step reports success having written nothing. So the recovery depends on what the document is:

• A document that posts nothing — a sales order, a purchase order, a requisition — and whose applet offers Undo to Draft (it is hidden by default, and an administrator has to switch it on): take it back to Draft and finalise it again. For these the link release is the whole consequence, and the open-queue rows appear.
• Anything that posts — an invoice, a stock-in goods receipt, a cash bill: do not undo and re-finalise. If anything on it is changed while it is in Draft, the document and your ledger end up saying different things, and nothing tells you. Re-queue it instead, in the Data Fix applet: Generic Documents › Missing Open Queue. Pick the document’s type as Server Doc Type 1 and the target of the pair you just enabled as Server Doc Type 2, set Date From and Date To around the document’s date (both open on today), press SEARCH, tick the document and press CREATE. It runs the open-queue step alone, for an enabled pair only, and posts nothing; Remarks shows the result, and an open entry that already exists is not created twice. The grid lists every FINAL document of that type in the range, not only the ones missing their entries, so tick only the documents you know are missing. Data Fix is an administrator’s applet; if it is not on your menu, ask BigLedger support to add it to your login. For outbound stock transfers, the Stock Transfer applet’s own Error Checking › Missing Queue does the same for the transfer-to-inbound pair. If a document you expect is not listed, send support the document numbers and when they were finalised (what to send).

Undo to Draft is also refused, like a void, while any later document has been raised from this one. The full account of what it does and does not undo is in What a void undoes.

The cheap answer is not to need this: enable the pairs before the first document is finalised in a new company, which is why this check is on the list above and not in the troubleshooting table.

Troubleshooting

Related documentation

Read next: Chart of Accounts setup guide. A company created here does nothing until its default GL codes are mapped, and that guide is the other half of this page’s first section.

• Bank reconciliation guide — why the company timezone decides where a statement window falls
• Budgetary applet — where profit centres, segments and projects are created
• Core module — where the Organization applet sits in the platform
• e-Invoice module configuration — the company e-Invoice and Peppol settings in context