Core Module

Watch these as presentations — 2 on this page, slides with narration.

Four records, and the order they come in

7 slides · about 10 min · Set up a new company end to end, 1 of 8

10 slides · about 15 min · Set up a new company end to end, 8 of 8

Core is the module you finish before any document is raised. Nothing in it sells, buys, ships or pays; it holds the records those documents point at — the company and its branches, the GL codes a journal lands in, the bank accounts money moves through, the tax codes a line carries, the customers, suppliers, employees and merchants (one entity table with four flags), the items, and the price books — and the two consoles that decide who may open which applet. Every other module reads this data at FINAL, and most of the failures that look like a sales or purchasing problem (Default GL Code not configured, a tax line silently dropped, an item nobody can pick) are something missing here.

This page is a map, not a manual. Each applet’s own reference page carries its screens, settings, fields, validators and failure modes. This page says which applets are in the module, which other modules each one serves, the setup order their own prerequisites impose, and the two facts about this module that are most often stated wrongly: only one document in it posts a journal, and it has no approval engine.

Applets in this module

Membership is an editorial judgement — the product has no module↔applet relationship in its data — and it is written down in planning/specs/module-applet-membership.md. Core owns 17 registry applets: the master-data applets and the two tenant-administration consoles. Sixteen have a reference page; one does not, and the end of this list says why. The Also serves column is the modules: assignment from the membership table: the module whose documented workflow cannot complete without this applet.

Your organisation, and who may use it

Applet	What it is for	Also serves
Organization	The legal Company, its Branches and physical Locations that every document, stock movement and report is tagged with — plus the company- and branch-level switches other applets read at FINAL and never show: the Knock Off Configuration that opens a queue for the next document, the company e-Invoice and Peppol registration, default tax codes, timezone, branch main / delivery location, the marketplace branch rules	financial-accounting, inventory, e-invoice, ecommerce, pos
Tenant Admin Applet	The console an OWNER- or ADMIN-ranked user opens to run the tenant: catalogues, which applets are installed for which user, tenant admins, Tenant Roles, permission sets and their targets (company, branch, location), the Permission Wizard, custom fields and the applet audit trail. A user sees an applet only after it is installed for them here	—
T2T Admin	Connects two separate tenants (host and guest, by invitation) so companies and branches, items, and teams and roles can be mapped across the connection. Almost every write touches both tenants’ databases	—

Money — where it is classified, held, taxed and converted

Applet	What it is for	Also serves
Chart of Account	GL Sections → Categories → Codes; per company the ledgers, the Default GL Codes that tell sales, purchase, stock, forex and consignment documents which account to post to, the Sets of Books financial reports run against, the Fiscal Years whose periods can be locked, and month-end closing stock values	financial-accounting
Cashbook	Every place money is held (bank account, cash drawer, card acquirer, e-wallet) as a cashbook tied to one company and one GL code; every way money moves as a settlement method linked to branches; the Cash Transfer and Cash Adjustment documents; post-dated cheques; the cash enquiry screens; the weightage the Bank Reconciliation matcher uses	financial-accounting, pos
Tax Configuration	The tenant’s list of tax codes — code, type, rate, country. Master data only: the account a tax amount posts to comes from the company’s `OUTPUT_TAX` / `INPUT_TAX` Default GL Code links, not from here, and a rate change never restates a saved document	financial-accounting, pos, purchasing, ecommerce, e-invoice
Forex Applet	Currency pairs (Forex Data Sources) and dated buy / sell / mid rates. Document applets that have `SHOW_FOREX_DATA_SOURCE` switched on copy the latest rate into the document; gain / loss journals and base-currency shadow documents live in the document applets and the backend	financial-accounting, purchasing

Who you trade with — one entity table, four flags

Every customer, supplier, employee and merchant is a row in the same table (bl_fi_mst_entity_hdr) with is_customer, is_supplier, is_employee and is_merchant flags. The same person or business can carry more than one flag; the four typed applets are richer forms over the same row.

Applet	What it is for	Also serves
Entity Maintenance	The type-agnostic view: create a record with any combination of the four flags, see every entity in one listing, and maintain the four category trees (Entity, Customer, Employee, Supplier) the typed applets tag records with. Four of its tabs (Entity Category on edit, Login, Credit Term, Credit Limit) save nothing in the current code — use the typed applets for those	purchasing, hr-payroll, claims
Customer Maintenance	The customer master: identity and tax numbers, addresses and contacts, categories, the receivable GL code, and the credit term and credit limit the sales and receivables applets read. Whether a limit stops a sale is decided by the document applets, not here	crm-digital, financial-accounting, pos, e-invoice
Supplier	The supplier master: bank accounts and currency, AR/AP type, credit terms and limits, item pricing, branch and company links, and the identity data self-billed e-Invoices and Peppol routing depend on	purchasing, financial-accounting, e-invoice
Employee Maintenance	The employee master: default company, branch, department and rank; the link between the employee and a platform login; payment, tax and spending-limit rules; reporting line; org charts; CSV import. Claims and payroll resolve the employee from this record	hr-payroll, claims, e-invoice
Merchant Admin	The merchant view: external businesses that sell or collect payments through your tenant, with their payment-gateway merchant code and key, Peppol IDs, contracts, rate cards and charge rates, and the monthly merchant transaction report	ecommerce, e-invoice

One entity can be both a customer and a supplier — and every document with it lands on one control account. Some ERPs let a receivable record sell and a payable record buy, and nothing else. BigLedger does not draw that line: the sales pickers offer every entity flagged is_customer, the purchase pickers every entity flagged is_supplier, and no document validator checks the direction of a sale or a purchase against the entity’s type. What decides the balance-sheet side is the entity’s AR/AP type (default_arap_type on the Main tab, overridable per company on the Company Linking tab), not the document. When a document posts, the posting engine reads that one type and maps it to the control account — AR_TRADE → trade receivables (DEBTOR), AP_TRADE → trade payables (CREDITOR), the other, merchant and employee variants to their own accounts — and the document type supplies only the sign. So a sales invoice raised on a supplier typed AP_TRADE debits the creditor account: it nets against what you owe that supplier, with no contra document. That is the power of it when you buy from and sell to the same business, and it is the one thing to settle before you choose an entity’s AR/AP type, because the type decides which side of the balance sheet every document with that entity posts to. If an entity is a customer to one of your companies and a supplier to another, set the type per company on Company Linking. (JournalPostingService L85 and L326–L345; EntityHeaderUow.getArAp L416–L424.)

What you sell, and at what price

Applet	What it is for	Also serves
Doc Item Maintenance	The item master every document line points at: code, name, type, UOM, tax codes, pricing schemes and prices, categories, images, branch and company visibility, e-Invoice classification, marketplace listings. No item, no document line	inventory, ecommerce, pos, e-invoice
Inventory Item Maintenance	The stock-keeping record behind every stock-tracked item — the row stock ledgers, balances, serial numbers, bins and costing layers are keyed on: inventory categories, multi-UOM, per-location min / max levels, serial-number import and trace, stock aging. Creating a Basic Item in Doc Item Maintenance creates and links this record for you	inventory
Pricebook	Conditional pricing: a Price Book with Price Sets that say who qualifies, which items, and what happens (discount, sales price, membership points). Master data only — nothing is applied until a consuming applet’s Default Pricebook setting points at it, and the client-side calculator the sales applets use evaluates only part of what the form lets you enter	pos, membership, purchasing

Workflow Design — listed, not promoted

Applet	What it is for	Also serves
Workflow Design Applet	A tenant-wide catalogue of workflow processes — statuses, resolutions, transitions with the roles allowed to make them — that a document applet can attach to a company as a status track. It is not the Document Approval engine: no document lifecycle consults it, and it never blocks FINAL. The Approval Settings that do route a document exist only on Purchase Order, Purchase Requisition and Stock Requisition, and are configured there	financial-accounting, pos, purchasing, inventory — where the settings screens live, not where an approval happens

Registry applet with no reference page yet

Registry applet Why there is no page

Akaun Price Book (AkaunPriceBookApplet) An ACTIVE registry row (created 2025-11-13) whose only source is blg-applet-akaun-platform-akaun-price-book-applet-deprecated — a 2025-11-18 split of a project that was written in April 2020 (eight commits, 2020-04-07 to 2020-04-10) and removed from the platform shell on 2021-04-14 as “old and unused”. It edits the same bl_fi_mst_price_book_* tables through the same shared services as Pricebook, under a b2b route prefix; the bundle path the 2020 shell loaded it from now returns 404. It reads as a superseded build of the Pricebook applet, and no page is written for a superseded build. Q-0335 asks whether the row leaves the catalogue

Applets owned elsewhere that core also serves

Two applets sit in the master-data folder or list core as a supporting module but are owned by E-Commerce: Shipping Pricebook (delivery charges the storefront evaluates at checkout — membership spec §5, A7) and Media Library Applet (tenant file drives). This page links them; their pages and the E-Commerce module page describe them.

Two pages under /applets/master-data/ are not registry applets and are not counted: Group Maintenance and Group Maintenance V2 describe a repository with no ACTIVE registry row (F-0134, F-0268). Roles and who holds them are maintained under Tenant Roles in the Tenant Admin Applet.

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. Permission targets cannot be set until the companies and branches exist, 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. 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 and the document fails at FINAL out of balance. 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 C000123 — 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.

What posts, and what does not

    flowchart LR
  MD["15 master-data applets<br/>write ACTIVE / INACTIVE rows<br/>soft delete · no signum · no journal · no stock"] -.read at FINAL.-> DOCS["Documents in every other module"]
  CT["Cashbook › Cash Transfer<br/>INTERNAL_CASH_TRANSFER"] -->|"FINAL: journal + cashbook lines + PD cheque queue<br/>VOID: all three reversed"| GL["General Ledger"]
  CA["Cashbook › Cash Adjustment<br/>INTERNAL_CASH_ADJUSTMENT"] -->|"FINAL: cashbook transaction lines only<br/>no journal"| CBL["Cashbook balance"]

Master data posts nothing. Organization, Chart of Account, Tax Configuration, Forex, the five entity applets, the three item and pricing applets, Workflow Design, Tenant Admin and T2T Admin have no server document type, no amount or quantity signum, no JournalPostingTypeHandler entry and no open-queue rows. They write rows that documents in other modules read at FINAL. Chart of Account is the nearest thing to an exception: its Opening Balance writes a journal on the primary ledger, its Remove Journal hard-deletes journals, and its fiscal-period locks decide when posting is allowed at all.
One document in this module posts. Cashbook’s Cash Transfer (INTERNAL_CASH_TRANSFER, DRAFT → FINAL → VOID) queues journal posting, cashbook transaction lines and the PD cheque queue at FINAL, and reverses all three at VOID: Dr the To cashbook GL (and charges GL), Cr the From cashbook GL, one journal line per transfer line. Cash Adjustment (INTERNAL_CASH_ADJUSTMENT) writes cashbook transaction lines only; the journal processor returns without posting for that type. The posting proof is on the Cashbook page.
Deletes are soft, and mostly unchecked. Every master-data delete in this module found in code sets status = 'DELETED' and leaves the row. No validator checks whether documents still reference a company, branch or location (Organization) or a forex data source (Forex), so a deleted record disappears from pickers while its documents keep the guid. A GL code is the exception: it cannot be deleted once used in a transaction, even a voided one — set it INACTIVE or merge it. The one hard delete is Chart of Account’s Remove Journal.
Tax rates and forex rates are snapshots. A document line copies the tax code’s rate when it is saved, and a document copies the latest forex rate when the source is picked; changing either here afterwards does not restate anything already saved.

What this module has no engine for

No approval on master-data changes. The generic document approval engine exists only for Purchase Order, Purchase Requisition and Stock Requisition; Workflow Design is a status catalogue that no lifecycle consults. Who may change a credit limit, a GL code or a supplier’s bank account is decided by permissions in Tenant Admin, not by a sign-off.
No save-time credit gate here. Customer Maintenance stores the credit term, credit limit and a credit status (OK / BLACKLISTED); whether a sale is stopped is a property of the document applets. The one server-side credit-control mechanism is a batch job: EntityBlacklistCustomerProcessor calls EntityService.blacklistOverdueCustomers (backend c4a3545d7c, EntityService.java L392) — it runs on a schedule, not when a document is saved.
No tax-to-GL mapping on the tax code. A tax code has no GL field; the account comes from the company’s OUTPUT_TAX / INPUT_TAX Default GL Code links.
No engine applies a price book on its own. The sales applets and POS evaluate the price book named in their Default Pricebook setting in the browser, and the OCR points processor evaluates one on the server; the Pricebook applet only stores it.

Who can see what

The permission model in this module is, with three exceptions, server-side only: each applet’s screens call endpoints guarded by a permission family (API_TNT_DM_*, TNT_API_TAX_CODE_CFG_*, TNT_API_DM_WF_MD_*, T2T_*, the price-book and forex codes), granted through Permission Wizard / Permission Set / Role Permission and targeted at a company, branch or location. Users or roles holding TNT_TENANT_ADMIN / TNT_TENANT_OWNER pass every check. The Tenant Admin Applet itself is gated by rank (OWNER / ADMIN in the master database), with role assignment additionally needing a tenant-database permission.

Client-side SHOW_* permissions — the ones that let a role keep a menu or tab the tenant has hidden — are seeded, at the 2026-09-05 registry check each page records, only for Customer Maintenance (menus and edit tabs), Doc Item Maintenance (Costings tab and cost columns, category grids), Cashbook (eight of the eleven menus it checks) and Inventory Item Maintenance (two Trace Serial No columns). Supplier checks ten codes that are not seeded, so its HIDE_* switches hide for everyone including administrators. Organization, Chart of Account, Tax Configuration, Forex, Entity, Employee, Merchant Admin, Pricebook, Workflow Design and Tenant Admin have no client-side rows and check no codes. Re-checked against the registry on 2026-09-15: the sixteen core applet codes hold 75 ACTIVE rows in bl_applet_client_side_perm_dfn between them — Customer Maintenance 35, Doc Item Maintenance 30, Cashbook 8, Inventory Item Maintenance 2 — and the other twelve (Organization, Chart of Account, Tax Configuration, Forex, Entity, Employee, Supplier, Merchant Admin, Pricebook, Workflow Design, Tenant Admin, T2T Admin) hold none. The definitions are per applet; each applet page is the source for what its codes gate.