The Generic Document

Somebody teaches you how a cash bill is numbered, and without anyone saying so you have also just learned how a purchase invoice, a sales return, a delivery order, a quotation, a receipt voucher and a credit note are numbered. That is not a coincidence and it is not a convention. In BigLedger those are all the same kind of record, and only one attribute says which kind of document you are looking at.

Nothing on any screen tells you this. Every applet presents itself as its own thing, with its own name on the tab. This page is the part underneath: what is shared, what follows from it for you, and the one place the sharing gets genuinely confusing — the ten different numbers a single document can be carrying at once.

Fifteen to twenty minutes, and most people come back to the numbering section rather than read it straight through. There is nothing to set up.

One table, many kinds of document

Every financial document in BigLedger is one generic document: a header with its lines. What makes one a cash bill and another a purchase invoice is the document type stamped on the header — Sales Cash Bill, Purchase Invoice, and so on. The developers themselves describe that stamp as recording “the classname” of the document, which is exactly the right way to think about it: one shape, many kinds.

You can see how deliberate this was. The generic document replaced twelve separate registers in the predecessor system — a supplier invoice register, a customer invoice register, a credit memo register, a payment voucher register, a receipt register, a consignment register, a delivery order register, a job sheet register, a sales order register, a goods received register, a purchase return register. Twelve became one. Today the product recognises close to a hundred document types — and its own internal lists of them do not all agree, which is a good reason not to trust any published list of document types, ours included, over what your own tenant actually contains.

What that buys you is the thing worth taking away. A knock-off between a sales order and an invoice, a contra between an invoice and a credit note, a report that cuts sales and purchases together, an approval route that works on any document — none of those needs to know what kind of document it is holding. Neither do you. When you learn that finalising is what assigns the company and branch numbers, you have learned it for all of them at once.

It is also the busiest record in the product, because every financial document a business raises lands in it. That matters the moment you build a report: a report over generic documents with no document-type filter is a report over every document you have ever raised, of every kind.

This is not the same as an external generic document. External documents are a separate family, for a document that originated outside your tenant and is being matched against yours — a supplier’s own invoice, a warehouse operator’s goods receipt. Those never post a journal, never move stock and have no posting status. If a page or a screen says “external”, check which family it means.

Your document can be carrying ten different numbers

Here is the part that surprises people. A single document header has five numbers BigLedger assigns and five numbers reserved for somebody else’s system, all of them free-form text up to 255 characters, all of them allowed to be empty. They are two different ideas that happen to look alike:

The BigLedger numbers are what BigLedger called this document. The client numbers are what somebody else called it.

The five BigLedger assigns

These are running numbers, drawn from the platform’s single set of counters. Every one of them is a read-only field on the form — you never type them and you cannot change them.

Number	What it counts	Label you see	When it appears	What else keys off it
the tenant number	one sequence per document type, for the whole tenant	Doc No (Tenant)	the moment the document is created, draft or not	the number the listing search box matches on by default, and what the rest of the product means by “the document number”
the company number	the same, per company	Doc No (Company)	only when the document is finalised	reports and e-invoice number templates; a listing column whose visibility is set per applet
the branch number	the same, per branch	Doc No (Branch)	only when the document is finalised	reports and e-invoice number templates; a listing column whose visibility is set per applet
the location number	the same, per company and location	no label; never shown	only when the document is finalised	nothing; searchable and filterable like the rest, but no behaviour reads the value
the device number	the same, per point-of-sale device	Document No (Device) on the POS General cash bill listing only	at finalise, and only if the document carries a device	nothing reads it; the cash bill listing’s `HIDE_SERVER_DOC_4` hides the column
a fifth number	not established	no label; never shown	never, as far as we can find	nothing writes it and nothing reads it — treat it as reserved

Doc No (Tenant) is the one to reach for. It exists from the first save, it is the default column the listing search box matches on, and it is what the rest of the product means when it says “the document number”. Whether a listing shows the company and branch numbers is decided per applet. Where an applet applies them, each column has a setting that hides it and a permission that puts it back, which is why two colleagues can be looking at the same listing and see different columns; the Sales Invoice listing names the same settings and ignores them, and shows all three columns. See Document Numbering for how, for why the sequence starts in the millions, and for why no prefix, year or padding is stored. (A short code such as PI in front of a number is added when the document is rendered, not held in the number.)

The device number and the fifth number are a different matter, and we are not going to invent a purpose for them. The device number is genuinely written, at finalise, for a document that carries a point-of-sale device — so if your tills are set up as devices, it fills up in volume without anyone asking for it. The one place it is shown is the POS General cash bill listing, as Document No (Device), which HIDE_SERVER_DOC_4 hides; no other listing we read has a column for it. The fifth number is written by nothing in the product. Treat it as reserved. If you find data in it, something outside the standard document services put it there.

One more honesty note: two paths in the product disagree about what Doc No (Branch) means. The path every applet uses writes the branch number there. An older path, still used when a document is created header-only, writes the company-and-location number instead. It is recorded as an open question rather than smoothed over, because a report that groups on Doc No (Branch) is grouping on two different things depending on how the document was born.

The five your own system fills in

These are not running numbers and BigLedger does not generate them. They are yours. The developers' own description of the first of them is the clearest statement of intent in the whole design:

“the tenant number from the client, in case of peer-to-peer data sync” — the developers' description of Client Doc 1

In other words: Client Doc 1 is the other system’s Doc No (Tenant). When a document arrives from somewhere else it keeps the number it already had, in the client fields, and gets a BigLedger number of its own in the BigLedger fields. Two identities on one record, neither overwriting the other.

The family is wider than five numbers: a client document type (the other system’s document type), the other system’s own record identity, a client source — a free-text mark of which system it came from — and, easy to miss, five matching dates and five matching statuses, one pair per client number. If your integration needs to record not only the other system’s number but when it was raised there and what state it is in, the fields already exist.

Client Doc 2 through Client Doc 5 carry no description at all, and nothing in the product reserves them for anything. Whatever a caller sends in them is stored as sent and given back unchanged, and all five are searchable — exactly, partially, or as a set. Which means the honest answer to “what is Client Doc 4 for?” is: whatever the person who built your integration decided.

Two things about them are worth knowing before you claim one for yourself.

One of them may already hold something in your tenant, and not the one you would guess. The platform writes none of the five itself, so anything in them was put there by an integration, an import or a connector — and those do not start at Client Doc 1 and work along in order. Before you claim Client Doc 4 for a warehouse reference, switch the column on in a listing and see what is in it already. Nothing will stop you writing over someone else’s meaning, and nothing will warn you.

A workflow can give one of them a fixed meaning, and that meaning is local to the workflow, not to the field. The clearest live example is AP automation’s supplier-document matching, which reads a purchase order’s number out of Client Doc 1, the referenced purchase order out of Client Doc 2 and the supplier’s delivery-order number out of Client Doc 3 — see AP Automation. A goods received note keyed without Client Doc 3 can never match there. Marketplace connectors do the same thing more quietly: they write the marketplace’s own order number into Client Doc 1 on every order they bring in.

And one exception to “BigLedger never writes these”. For e-invoicing, if Client Doc 1 is empty and your company has a client-document format configured, the platform composes one itself — branch description, document-type code, the year and month of the transaction date, and the branch running number, joined with hyphens — and writes it back onto the document. That is the only case we found of the platform filling a client field. Where the document-type code comes from, what happens when a piece is missing, and how the reference reaches LHDN are on the My E-Invoice Admin page.

Client Doc 1 also exists on the document line, not only the header, where it is the key an imported line is matched back by. You will meet it on the file-import checking screens as Line Client Doc 1. The BigLedger numbers have no line-level equivalent at all: a document has one set of BigLedger numbers, but its lines can each carry their own foreign reference.

Which number the bank, the auditor or the tax authority actually sees

Not the same one, and that surprises people who assume the document number is a fact about the document rather than a setting.

A bank or an auditor sees Doc No (Tenant). That is not a convention we are recommending, it is what the product does: the bank reconciliation report identifies each document by its short code plus the tenant number, and the e-invoice PDF’s default filename is built from it. If somebody reconciling your account asks for “the document number”, this is the one.

LHDN sees something else entirely, and this catches people out. The identifier on the tax document is a separate running number of its own, held on the e-invoice record rather than on your document, and it is what becomes the invoice ID in the file sent to the regulator. Your tenant number reaches LHDN in three other places: as the fallback invoice ID when that running number is absent (document type and number joined, e.g. INTERNAL_SALES_INVOICE-1000583), as the ID on every invoice line, and on the additional-document reference. You can also compose the running number from a template, and the template accepts Doc No (Tenant), Doc No (Company), Doc No (Branch), the document reference and all five client numbers — but not the device number, the fifth number or the location number, which can never reach the regulator by any route. Details on My E-Invoice Admin.

On paper, the number is whatever the printable format prints. The format chooses the number and the heading, and it can print a branch code beside the number, so a branch’s bill can read KV01 / 1000017 while the tenant number stays the audit trail underneath. This is where a prefix lives, if you want one — see Printable Formats. Even Client Doc 4 and Client Doc 5 have print tokens of their own, so a foreign reference can be printed as the customer-facing number.

To a shopper looking up their own receipt on a storefront, the field shown as the invoice number is a widget parameter that accepts Doc No (Tenant), any client number, the document reference or the e-invoice running number, and defaults to Doc No (Tenant).

The E-Invoice Number is none of the above. It is assigned by LHDN’s system, not by BigLedger, and it is the only identifier on the document that the tax authority itself issued.

If all of that feels like the platform declining to name one canonical number — it is, and it knows. The e-invoice search screen binds a single input, named server or client doc no, against all ten numbers at once, because whichever one you have in your hand is the right one to search with.

The practical consequence: before you tell a bank, an auditor or a customer “quote your document number”, find out which number your printable format is actually printing. If the answer is Doc No (Branch), that number repeats across branches and is meaningless without the branch beside it.

Why there are two numbering systems at all

Because a document does not have to be born in BigLedger. It can arrive from a system still running alongside yours during a migration, from a marketplace, from a webstore, from a mall’s own point of sale, or from a historical import done at go-live. Documents like those were never keyed by anyone in your office, and they turn up already numbered — the platform stamps the source they came from into the client source mark so you can tell them apart afterwards.

Those documents already had numbers. Your staff quote those numbers on the phone; your customers have them printed on receipts; your old reports are indexed by them. Throwing them away to adopt a BigLedger number is not a data-modelling decision, it is a business disruption. Keeping only the old number instead would break everything on our side that assumes a running sequence.

So the platform declines to choose. The document gets both, in two families of numbers that never collide, and an imported document is otherwise an entirely first-class document: same record, same journal engine, same e-invoice queue, same posting status as one a clerk typed. That is what makes a partial migration possible at all — you can hand BigLedger one obligation, keep the rest where it is for a year, and still have both sets of books agree on which document is which.

What else is the same on every document type

Five more behaviours you learn once. Each has its own page; this is the map, not the territory.

A sign decides whether a document adds or subtracts. Every document type carries an amount sign (on the header and line) and a quantity sign (on the line), +1 or -1, and they are what make one document type increase a balance where another decreases it. The developers state it plainly: a customer invoice is +1, a receipt -1, a supplier invoice -1, a payment voucher +1, a credit note -1, a debit note +1; on quantity, a goods received note and a sales return are +1 because they bring stock in, an invoice and a purchase return -1 because they take it out. This is why the sign of an amount on screen is not always the sign in the ledger, and why a document type cannot be “reversed” simply by typing a negative.

Posting status is what finalising changes, and finalising is not saving. A document sits at draft until it is finalised, and FINAL is the event, not the save button. Finalise is a separate action that starts a background run, which fans out into the journal, inventory, the cashbook, membership points and the e-invoice queue. Your screen comes back before any of that has finished — deliberately, so that a till is never made to wait for a tax submission. It is also why the company and branch numbers appear a moment after you finalise rather than the instant you click. Where that chain leaves stored figures behind is unpacked in Which figures BigLedger stores, and which it works out fresh.

Branch and profit centre sit on the header and on every line, independently. Both exist in both places, which means one document can carry lines belonging to different branches. The developers describe the header’s branch as “the billing branch”; the line’s as “the billing branch, to account for sales for reporting purpose” — two different jobs. The store (location) is a third, separate dimension: “stocks are deducted from this location”. Branch is not location and neither is profit centre, and a chart of accounts that encodes branch into the GL code is fighting a dimension that already exists.

Costing is written back onto the line after the fact. When the chain has run, the moving-average, weighted-average, FIFO and LIFO costs of each line are computed from the inventory ledger and written back onto the document line — all four, side by side, so a report can read the basis a company uses without recomputing anything. It also means the cost on a line you finalised last quarter is a stored figure that a later backdated purchase can rewrite. That is the single commonest cause of “last quarter’s margin changed by itself”, and it has its own page: the margin report and the profit and loss don’t agree.

Posting status is not the only status, and the other one means what each applet says it means. Every document has one more status slot, free text, that posts nothing and moves nothing, and each applet uses it for its own purpose:

On a sales order it holds the Sales Order Status — a list you write yourself under the Sales Order applet’s Settings → Sales Order Status, each entry a code, a name, a sort order and an icon. GadgetSphere Online might keep Awaiting stock, Packed, Handed to courier and Collected. The list is one list for the whole tenant: the same settings screen sits in Seller Admin and in the Shopee sales order applet, and an entry added in one appears in all three.
On an outbound delivery order the applet fills the same slot itself, as a print status — Printed after a print, Amended after an edit — and bulk printing skips an order already marked Printed.
The five client statuses above are a third thing again, stored separately.

So “status” on two different document types is not one field with one meaning, and a report that filters on it has to know which applet wrote it.

Three things follow for a Sales Order Status. Changing it changes nothing else — no posting, no stock, no hold on fulfilment. Each pick in the drop-down is recorded as an event on the order at once, naming the new status — before you save, so the history can name a status the order was never saved with. The order keeps the code, not a link to the list: renaming an entry’s name is safe, but changing its code or deleting it leaves every order that carries the old code showing a code no list explains, and nothing stops two entries sharing a code. And your customers may see it, and change it: on a CP Commerce storefront the customer’s order page can show the list’s icons in sort order, and its Order received button sets the order to a code typed into that page’s settings — so the code there and the code in your list have to stay the same, or the button writes a status your list no longer has. Filtering the sales order listing by status is what turns the list into a working queue: everything at Awaiting stock, in one view.

BigLedger also has a scheduled job that e-mails a list of documents of a given type, at given statuses, that nobody has edited for a set number of hours — sales orders still at Awaiting stock after 48 hours. It measures the last edit of any kind, not the last status change. Ask BigLedger to set it up for you.

What goes wrong with document numbers

“The document number is blank on a finalised document”

The tenant number is assigned immediately after the document is created, and if that fails — a database hiccup, a counter that could not be topped up — the error is logged and swallowed and the document saves anyway. Nothing retries it. The tell is a pending-number marker left attached to the document that should have been removed when the number arrived; support can see it. It is repaired by a BigLedger system administrator ranked Admin or Owner — not a Member-rank system administrator, and nobody in your own tenant, however senior — with a tool that fills in the numbers on the documents you name to it — a tenant number on any of them missing one, drafts included, and the company and branch numbers on the finalised ones. It is not a sweep, so send support the list. The scheduled job named for back-filling numbers does nothing. You cannot fix this from a screen, and re-saving the document will not trigger it.

“The company or branch number is blank on half my rows”

Expected, not broken. Only Doc No (Tenant) exists on a draft. The company, branch, location and device numbers are stamped at FINAL. If the blank rows are all drafts, there is nothing to fix; if a FINAL row is blank, it is the case above.

“Two documents have the same number”

First, check which number and which document type you are looking at, because most apparent duplicates are not duplicates. Each BigLedger number is its own sequence per document type: a sales invoice numbered 1000583 and a purchase invoice numbered 1000583 are unrelated and both correct. Doc No (Company) repeats across companies, Doc No (Branch) across branches, the device number across devices. Two branches each having a document numbered 41 is the feature working.

Second — and this is the part no screen tells you — the platform enforces none of this. There is no uniqueness rule on any of the ten numbers, at any scope. Uniqueness within a document type is a convention the running-number generator keeps, not a rule the platform can enforce. It holds as long as the generator is the only thing writing the number — and when it is not, the duplicates land silently and in bulk. Group your own documents by type and tenant number before you build anything that assumes the pair is unique.

Two ways a genuine duplicate gets in:

A caller supplies its own number. The generator only fills a document whose tenant number is empty, and nothing validates the field on create — so an integration that sends its own value keeps it, and no counter ever knew about it. If your tenant has duplicate tenant numbers, this is where to look first.
An import runs twice. Nothing enforces uniqueness on Client Doc 1 to Client Doc 5 either, so an integration that re-sends a batch without an idempotency key of its own produces two BigLedger documents carrying the same foreign number, both real, both postable. The duplicate is visible only when somebody searches for that number and gets two hits.

“Our two systems disagree about this document”

Three things can be true at once and they are often confused: the document arrived, the document posted, and the document was submitted. Arriving is not posting — an imported document lands as a draft unless the payload says otherwise, and a draft posts no journal and never reaches the e-invoice queue. Posting is not submitting. When a document is missing from a report, work in that order: is it in BigLedger at all, is its posting status FINAL, and did the run behind the report happen.

“I searched for my own reference and found nothing”

The listing search box matches a fixed set of fields — by default Doc No (Tenant), all five client numbers, the document reference and the E-Invoice Number. If your reference lives somewhere else, for instance in remarks or in a custom field, the search will never find it however exactly you type it. The set of fields searched is configurable per applet.

What we cannot tell you

What the fifth BigLedger number is for. Declared, described, and written by nothing we can find. See above.
Which meaning of Doc No (Branch) is canonical — branch, as every applet path writes it, or company-and-location, as the older header-only-create path does. Recorded as an open question; do not build a report that depends on it without checking your own data first.
What Client Doc 2 to Client Doc 5 mean in your tenant. The platform assigns them no meaning, so whatever they hold was decided by whoever built your integration. The only reliable way to find out is to ask them, or to look.
Whether a populated device number is really a device counter or a slot some integration repurposed. We can see the number filled; we cannot see why.
Whether a particular number is the one printed on the paper your customer is holding. That is a printable-format setting per branch, and this page cannot see your settings.
The full list of document types. The product’s own lists do not agree with each other. The authority is your own tenant’s data, not a list we could keep current.

What success looks like

Open any document listing — a cash bill, a purchase invoice, whichever you use most — and do three things in under a minute.

Turn on the company and branch number columns if they are not already showing. Every FINAL row now has three numbers and every draft has exactly one. That is the assignment rule, visible.
Take the tenant number from the top FINAL row and paste it into the search box. You should get one result. Now paste the branch number instead: you may get several, one per branch. That is the scoping rule, visible — and if the tenant number returns two rows of the same document type, read “Two documents have the same number” above, because that is worth chasing.
Open one document and look for a client document number. If it has one, that document came from somewhere else, and the client source mark tells you where. If none of your documents has one, nobody is feeding you documents, and the whole client family is simply unused in your tenant — which is also a useful thing to know.

Where this sits in the rest of BigLedger

What must exist before any of this works. Nothing you have to set up. Counters create themselves the first time a document type is numbered, and no screen lists or edits them. The one thing worth doing before your first document is choosing a starting number, because it cannot be changed cleanly afterwards — Document Numbering step 3.

What this makes possible. Because every document is the same shape, features are written once against the shape rather than per document type: knock-off between an order and its invoice, contra between an invoice and a credit note, document links, approval routes, custom processors, and the import layer that lets another system feed you documents at all.

Its sibling, and when to use which. The generic document holds your documents. The external document family holds a copy of somebody else’s document that you are matching against yours — it posts nothing and has no posting status. A document you imported is still your document and belongs in the first family; it is marked with a client source, not moved elsewhere.

What breaks if the numbering is wrong. It is cross-module by construction. A blank tenant number breaks the listing search, the e-invoice duplicate check that keys on the tenant number and the document type, any integration matching on document number, and the reconciliation between your two systems — all at once, and none of them says why.

What it pairs with in practice. Printable formats, because the number is only useful once it is printed somewhere a human can read; and the e-invoice configuration, because that is where a document number leaves your tenant and becomes somebody else’s reference.