Modules Documentation

“I saved it and nothing happened.” “The document is Final but it is not in the general ledger.” “An applet I read about is not on my launchpad. Why?” All three come from two things the screen does not show: a module is a way of reading the product, not something you install, and Finalise starts work that finishes after the screen has come back. This page says both once, then sends you to the module that matches your situation. A figure you do not trust starts at Where did this figure come from? instead.

Start here — by the situation you are in

Core Module

Companies, branches, customers, items and tax codes every other module reads

Financial Accounting

The ledger, bank reconciliation and the month-end close

Sales

Selling to businesses on account, quotation to invoice

Point of Sale

You run a counter: the cash bill, the drawer and the end-of-shift balance

E-Commerce

Orders arrive from a marketplace or your own online store

Membership & Loyalty

You give customers points, tiers or vouchers

Purchasing

You buy from suppliers, receive the goods and pay the bill

Inventory & Warehouse

A stock figure looks wrong, or stock has to move between branches

Manufacturing

You build one item out of others and need to know what it cost

E-Invoice & PEPPOL

An invoice has to reach LHDN, or LHDN refused one

Claims Management

Staff spend their own money on the business and claim it back

HR & Payroll

Employee records, and approved claims handed to payroll

Digital CRM

Enquiries, leads, engagements and events before a sale

“Two reports should agree and do not” starts at Numbers that don’t tally. To walk one task end to end, use the Guides.

A module is a way of reading the product; an applet is what you install

The Applet Store installs applets onto one login at a time — singly, or every applet in a catalogue an administrator opened to you. Nothing installs a module, so “an applet is not on my launchpad” is a question for the Applet Store and your Tenant Admin. One applet can serve several modules and is described once: the Tax Configuration applet is linked from six module hubs. Which module an applet belongs to is our editorial judgement — BigLedger’s own data holds no module-to-applet relationship (the link table is empty as of 14 October 2026) — so where your launchpad and a module page disagree, the launchpad is the truth about what you have.

Save keeps a draft; Finalise starts the posting

Save writes the document and posts nothing. Finalise is a request of its own: it sets the document FINAL, queues one job and returns, and that job fans out to the follow-on jobs your tenant subscribes to — stock, journal, cashbook, points, e-invoice — with the cost written back onto the line afterwards. FINAL on screen means the request was accepted, not that every follow-on has run. A foreign-currency document takes a longer route, and for an integration saving and finalising are two REST API calls. How work actually runs traces one end to end.

Two status columns, and both can say DRAFT

Every document carries a status, which is the record’s own lifecycle (ACTIVE, INACTIVE, DELETED, TEMP and others), and a posting status, which says whether it has been finalised (DRAFT, FINAL, VOID and others). DRAFT is a value in both lists, and a document can be ACTIVE and DRAFT at once. When a filter, a report or a support reply says “draft”, ask which column it means before you act on it.

Some controls live on the screen, on purpose

A setting that hides a button or greys out a choice — hiding the FINAL button on Stock Adjustment, for instance — is enforced by the applet, not the API, deliberately, so the API stays general. It binds that screen and nothing else: an import, a marketplace sync or an integration is not held to it. That part of the job stays with you: for each screen setting you rely on as a control, list what else creates those documents, and put the rule there too, or look through the listing periodically for documents that broke it.

What each module’s pages answer

Most modules carry the same six pages beneath the hub — core concepts, configuration, use cases, best practices, reports and related applets; Core and Financial Accounting are arranged by topic instead.

When it goes wrong — what you see, and what to do

What you see	Usually	What to do
“I saved it and nothing happened.”	It is still a draft. Save leaves the posting status where it was.	Finalise it. If there is no FINAL button, a screen setting may hide it from your login — ask whoever set up the applet.
“The document is Final but it is not in the general ledger.”	The journal job ran after Finalise and failed — for instance on a company default GL code that is not mapped — or the company has no journal subscriber.	Open Trace Document in the Financial Report applet: it names the failed check and offers Resolve, and Posting journal present means the journal ran. More checks: How work actually runs.

Where the modules meet, and what to read next

What must exist first. The Core module’s records — companies, branches, GL codes, tax codes, items, customers and suppliers — are what a sales, purchase or till document is checked against and posted with at Finalise. A company default GL code left unmapped shows up as a missing journal, or one posted to the wrong account, in every module that posts through it, and Finalise still succeeds.
For integrators. The REST API is how other systems and AI agents work with BigLedger; integration notes by module say what each module needs.