Core Concepts

“The order still shows a quantity outstanding after I invoiced it all.” “Why is the cost on my document different from what I paid for the item?” Those two questions, and the one about which document actually brings the stock in, come up again and again from the people who buy for a business, and the eight ideas below answer all three. This page is for the AP clerk, buyer or accountant in a multi-branch group who has to explain a purchasing number to somebody else. Read it once, in about fifteen minutes, and the twenty-six applet pages stop being a list of screens.

The situation it was written for. GadgetSphere Sdn Bhd buys centrally for 22 branches. Head office ordered 200 wireless earbuds at RM 128 for GS-KV-01; the branch counted 180 on the receipt (GRN); the AP clerk knocked that GRN off into the supplier’s bill and finalised it. By Monday three people have asked three questions. The branch manager wants to know why the earbuds were not in stock on the day they arrived (§3). The buyer wants to know why the order still offers 200 to invoice (§1). The accountant wants to know why the line’s cost is not RM 128 (§2). Nothing is broken in any of the three. Each is a design choice, and each is explained where it comes up.

1. The chain is held together by knock-off, and knock-off is an open queue

Every purchasing document is a generic document with a header and lines, a DRAFT state where it has done nothing, and a FINAL state where it is locked and whatever it was going to do has happened. What ties one document to the next is knock-off: on the new document’s KO For tab you pick a finalised source, and its open lines — supplier, items, quantities, prices — are copied forward and linked.

Behind the tab is the open queue. When a document goes FINAL, a processor reads the company’s Knock Off Configuration and, for every downstream document type enabled there, writes one queue row per line with the line’s open quantity. A downstream document that knocks a line off reduces that open quantity; when it reaches zero the source stops appearing in anyone’s picker.

    flowchart LR
  PR["Purchase Requisition<br/>FINAL"] -->|"queue row per line"| Q1[("open queue")]
  Q1 -->|"KO For"| PO["Purchase Order<br/>FINAL"]
  PO -->|"queue row per line"| Q2[("open queue")]
  Q2 -->|"KO For"| GRN["Purchase GRN<br/>FINAL"]
  Q2 -->|"KO For"| PI
  GRN -->|"queue row per line"| Q3[("open queue")]
  Q3 -->|"KO For"| PI["Purchase Invoice<br/>FINAL"]
  PO -. "CLOSE empties the queue" .-> Q2
  

Four consequences:

• Partial deliveries need no special handling. Receive 180 of 200 and the remaining 20 sit in the queue for the next receipt.
• The queue only exists where the configuration says so. A company with no Purchase Requisition → Purchase Order row finalises requisitions that no order can find. This is the first thing to check when a picker is empty.
• CLOSE and VOID are different. CLOSE on an order sets every open quantity to zero and deletes the queue rows — the supplier is not sending the rest. VOID cancels the document. Neither is undone.
• VOID reopens. Voiding an invoice marks its knock-off links deleted, so the receipt’s lines become open again. The reverse is refused: a receipt that an invoice has already knocked off cannot be voided. The server’s message names the invoice by type and number, but the GRN screen shows only that the document has been knocked off with another document, so read the receipt’s Doc Link tab to find the invoice. Void the invoice first, then the receipt — the Doc Link tab shows you the order before you start.

One open balance for each kind of document that may follow

The queue keeps a balance per order line per downstream document type, one for each pair the Knock Off Configuration enables. If your company enables both Purchase Order → Purchase GRN and Purchase Order → Purchase Invoice, the earbud line gets two balances of 200. The GRN that knocks 180 off brings the receipt balance to 20 and leaves the invoice balance at 200. The invoice that then knocks the GRN off draws down the GRN’s balance, not the order’s. So the order goes on offering 200 on the invoice’s KO For tab after the goods are received and billed — which is the buyer’s question in the situation above, and the commonest reason behind “the order still shows a quantity outstanding”.

Enable only the pairs you actually chain. A company that receives on GRNs needs Purchase Order → Purchase GRN and Purchase GRN → Purchase Invoice; add Purchase Order → Purchase Invoice only if some orders are billed with nothing to receive, and then the AP clerk must pick the receipt, not the order, on every invoice that had one. The full mechanics, including how a save recomputes the balance, are on the Purchase Order page.

The same rows feed Stock Availability. Its GRN quantity is the receipts’ open balance toward the purchase invoice, so it exists only while the company has a Purchase GRN → Purchase Invoice row enabled. Its Details screen adds an order’s balances toward the GRN, the GRN Stock In and the invoice together, so the order above counts twice there until one pair is switched off.

Why the balance is stored, not worked out

Every picker, the Purchase Order Queue and Stock Availability read the balance as a stored row instead of adding up the links each time, so a branch looking up one item reads a handful of rows however many years of orders sit behind them. The row is written by a job after FINAL and rewritten when a knock-off is saved. The price is the cases where it misleads: a pair you did not mean to enable, or a pair enabled after an order was finalised, which creates nothing for that order. The buyer’s weekly read of the Purchase Order Queue catches both.

2. Two numbers on each document type decide everything

A quantity signum (does stock move, and which way) and an amount signum (does money move, and which way). Zero means nothing happens. They are fixed in the backend per server document type; they are not settings, not per tenant, and the applet’s own copy is overwritten by the server on every save.

The same documents as a chain, with the journal each one writes:

    flowchart LR
  subgraph NONE["Quantity 0 · Amount 0 — record only"]
    PR["Purchase Requisition"] --> PQ["Purchase Quotation"]
    PQ --> PO["Purchase Order"]
    BPO["Blanket Purchase Order"] --> PO
    PO --> GRN["Purchase GRN"]
    PO -.- PONOTE["A header Group Discount on an order<br/>posts Dr Purchase / Cr Creditor<br/>for the discount — a known issue"]
    GIN["Purchase GIN"]
    CPO["Consignment Purchase Order"]
  end
  GRN -->|knock-off| PI
  PO -->|knock-off| PI
  PO -->|knock-off| GRNSI
  subgraph MOVES["Moves stock and posts"]
    PI["Purchase Invoice<br/>qty +1 · amt −1<br/>Dr Purchase, Dr Input Tax / Cr Creditor"]
    GRNSI["Purchase GRN Stock In<br/>qty +1 · amt −1<br/>Dr Inventory Not Invoiced, Dr Input Tax<br/>/ Cr Creditor Not Invoiced"]
    RET["Purchase Return<br/>qty −1 · amt +1<br/>Dr Creditor / Cr Purchase Return"]
    RFN["Purchase Refund Note<br/>qty −1 · amt +1"]
    CGRN["Consignment GRN<br/>qty +1 · amt −1<br/>Dr Consignment Stock / Cr Consignment Liability"]
    CGIN["Consignment GIN<br/>qty −1 · amt +1"]
  end
  GRNSI -->|knock-off| PINSI
  subgraph MONEY["Posts, moves no stock"]
    PINSI["Purchase Invoice No Stock In<br/>qty 0 · amt −1<br/>Dr Purchase, Dr Input Tax / Cr Creditor; and, only when<br/>a knock-off link targets it (any source type),<br/>Dr Creditor Not Invoiced / Cr Inventory Not Invoiced<br/>for the total including tax"]
    PDN["Purchase Debit Note<br/>qty 0 · amt +1<br/>Dr Creditor / Cr Purchase"]
    PCN["Purchase Credit Note<br/>qty 0 · amt −1<br/>Dr Purchase / Cr Creditor"]
    CRET["Consignment Return<br/>qty 0 · amt +1"]
    CBILL["Consignment Billing<br/>qty 0 · amt −1"]
    PV["Payment Voucher<br/>Dr Creditor / Cr Bank"]
  end
  

A line only reaches stock if its item resolves to an inventory item. A service item, or an alias that points at no inventory item, on a +1 document is silently skipped by the stock processor — no error, no ledger line. A basic item with no link is linked for you the first time it posts, and moves stock.

Where the cost on the line comes from

The cost the accountant sees on the earbud invoice line is not the RM 128 that was paid. It is the item’s moving average after this delivery: the stock’s running value plus this line’s amount, divided by the new quantity. If the branch already held earbuds bought cheaper, the average lands a little under RM 128, and that is the figure the stock is valued at until the next delivery moves it.

It arrives late, on purpose. FINAL queues the work and returns; the stock job then adds the line to the item’s balance, the costing job works out the new average, and that average is written back onto the invoice line afterwards. An invoice whose cost is still empty a moment after FINAL has not finished, rather than gone wrong. The RM 128 is kept separately as the item’s last purchase cost, per company and per location — and only a standard Purchase Invoice writes it. Three consequences follow from the signum table above:

• A GRN Stock In, a consignment GRN and a purchase return all move the average; only the standard invoice moves the last purchase cost. On the Stock In pair the Last Purchase Price column goes stale while the average stays current.
• A Purchase Debit Note or Credit Note has a quantity signum of 0, so it creates no stock line and the average never sees it. Had the supplier billed RM 132 and the invoice been finalised, the RM 4 recovered on a debit note would lower what you owe and leave the earbuds costed at RM 132.
• A line with a quantity and no amount drags the average down while the last purchase cost, which ignores a zero price, stays put — two figures parting company is the symptom to look for.

When the average itself is wrong, the correction is a Reset MA, at company level. Costing Internals explains the arithmetic in full.

3. The receiving pair, and where the accrual lives

This is the fact that trips nearly everyone coming from another system: in the standard flow the invoice moves the stock, not the receipt.

The GR/IR (Goods Received / Invoice Received) accrual belongs to the second pair only. GRN Stock In posts Dr Inventory Not Invoiced / Cr Creditor Not Invoiced; the No Stock In invoice that knocks it off posts the ordinary purchase journal and then reverses that pair. Two details worth knowing:

• The reversal leg fires whenever the invoice carries any knock-off link — the source type is not checked. An invoice built from a plain GRN or a PO in the No Stock In applet will still post the reversal, against an accrual that was never made.
• The GRN Stock In accrues the net amount as inventory and tax separately as input tax; the invoice reverses the total including tax. If tax is captured on both documents the two accrual accounts do not clear by exactly the tax amount. Capture tax on one of the pair.

On the standard pair there is no accrual at all. Between delivery and bill the goods are on the floor and absent from the stock ledger; you can see them as GRN quantity in Stock Availability, and that is the whole of your visibility.

Who watches the goods between delivery and bill

Neither pair tells anybody that a receipt has gone unbilled for too long; that is a month-end job.

• On the standard pair, the accountant reads Stock Availability’s GRN quantity for the month’s top items on the last working day. Each unit there is on the shelf and absent from the ledger, so the accountant decides whether the auditors need a manual accrual for it, and asks the buyer about every receipt older than the supplier’s billing cycle.
• On the Stock In pair, the accountant reads the GRN Stock Ins not yet invoiced in the Creditor Report’s Outstanding Document Report. They know the accrual is clean when every receipt on that list is one the buyer expects a bill for. A credit left on Inventory Not Invoiced once the bills are in is the sign to look for: a No Stock In invoice knocked off something other than a GRN Stock In, or tax on the pair, because the receipt accrued the net and the invoice reverses the total including tax.

The branch manager’s question in the situation above has the same answer: on the standard pair the earbuds counted on Thursday reach the stock ledger when the AP clerk finalises the bill, so a branch that wants goods sellable the day they land is a reason to choose the Stock In pair — for the whole company, not for one delivery.

4. Matching is a person, not an engine

There is no three-way matching in BigLedger. No tolerance setting, no variance report, no automatic flag, and nothing that blocks a supplier invoice because its price or quantity differs from the order. What exists is knock-off: the invoice shows the order’s or the receipt’s real lines, and the person keying it compares them with the supplier’s paper. If the supplier billed RM 132 where the order said RM 128, the line can be changed and the invoice finalises anyway.

Controls over that live in permissions — who may edit a price, who may finalise an invoice — not in a rule. The Purchase Invoice applet does carry a Knock Off Settings screen with switches named for GRN and PO knock-off; its menu entry is not available and nothing reads the values — the switches appear nowhere in the backend at all, and in the applet only on the five unlinked screens that write them. The KO For tab offers both sources whatever they are set to.

Who compares, when, and how they know it was done

• The AP clerk, on the invoice, before FINAL. Knock-off has put the order’s or the receipt’s quantities and prices on the screen; the supplier’s paper is beside it. Before FINAL a difference costs a keystroke. After FINAL it costs a debit or credit note, and the item’s average keeps the price the stock came in at (§2).
• The buyer, afterwards. The Purchase Report by document lists every line’s unit price with its linked order number. Read monthly, it shows a supplier drifting above the agreed price before anyone notices it in the margin.
• The finance manager, once. The finalise permission on Purchase Invoice is what stands in for a matching rule: give it to the people who check the supplier’s paper, and to nobody who keys orders. The knock-off chain records who did each step; it does not stop one person ordering, receiving and booking the bill, so separating those three is a decision about people (Configuration §10).

The check that it was done is the same for all three: every finalised invoice line traces through Doc Link to a receipt or an order, and any price that differs from the order has a reason the buyer can give.

5. Approval is optional, off by default, and causes FINAL rather than gating it

BigLedger’s document-approval engine covers exactly three document types: Purchase Order, Purchase Requisition and Stock Requisition. It is off until somebody creates an Approval Setting in the applet’s own Settings. And the dependency runs the way people do not expect: the document goes FINAL on the FIRST approval, not the last. The engine runs the move to FINAL on every approving request it processes, so on a two-level rule the level-1 approval finalises the document while the level-2 request is still in someone’s inbox. Level 2 is still e-mailed and the approval record only reads Approved when they act — but the document has already moved, and a second level is therefore a recorded opinion rather than a gate. Nothing in the document lifecycle checks for an approval — an order with a request still pending can be finalised by hand, and it posts exactly the same.

What a setting contains, and what actually does something:

• Approvers are not named on the setting. They are the employees placed under Settings → Branch → Designation, each with an approval level; the submitter’s designation comes from their employee job title.
• Min Approval Amount does not route to a different approver. It decides how many levels a document must clear: every level whose minimum is at or below the document amount is required. Levels at RM 0, RM 10,000 and RM 50,000 make a RM 25,600 order need two approvals.
• Max Approval Amount and Approval Logic are stored and never read. ANY versus ALL is decided by the quorum.
• There is no delegation, no escalation, no reminder and no stand-in approver. A request sits until its approver acts.
• The Purchase Order applet alone has an Approval Monitor rule that can require every order submitted for approval to have been built from a requisition.

No approval exists for GRNs, invoices, payment vouchers, returns, credit or debit notes. Where a spending policy matters, control who holds the finalise permission — that is the only hard stop in the module. The full walkthrough is in Document Approvals.

6. The notes point the way the ledger points, not the way the name suggests

In this platform a Purchase Debit Note posts Dr Creditor / Cr Purchase: it lowers what you owe the supplier — an overcharge, a rebate, a short delivery. A Purchase Credit Note posts on the same side as an invoice: Dr Purchase / Cr Creditor, so it raises what you owe — a further charge the supplier is adding. This is the reverse of how many people name them from the supplier’s point of view, and the applet pages carry the warning in the same words.

Neither note moves stock. When goods go back, the document is a Purchase Return (stock out, supplier debited), and it leaves a positive balance on the supplier’s account that is closed by contra against their invoices or by a settlement when they refund cash.

A ten-second check after keying a note

Read the supplier’s balance in the Creditor Report before and after you finalise. A note for an overcharge, a rebate or a short delivery should bring it down. If it went up instead, you keyed a Credit Note where you wanted a Debit Note, and the supplier now looks owed twice the difference you meant to recover. Agree the correction with your accountant before the payment run, because the AP clerk pays from that balance.

7. Supplier credit terms and limits are records, not rules

The Supplier applet stores credit terms and credit limits, with listings, uploads and per-company variants. In the backend:

• A purchase invoice carries no due date. The applet’s Due Date field is switched off, the date it works out from the terms reaches no field, and nothing on the server computes one; the terms themselves are stored only when Purchaser is filled (Purchase invoice processing, Step 1). The only server reader of a credit term is statement-of-account reporting, and it reads the sales side.
• Nothing reads a supplier’s purchase credit limit. The purchase-side limit reaches no service, report or job; the sales-side limit, by contrast, is joined into the outstanding-document report. The one credit-availability service is advisory, never throws, and is hard-coded to sales orders and sales invoices. The one hard stop — the customer blacklist, a flag a person sets on the customer record — is checked only when one of four sales document types is finalised.
• Because the credit-limit status sits on the shared entity header, a supplier who is also a customer can be blacklisted by their receivables behaviour, and the effect lands on their sales documents only.

If a supplier limit matters to your business it is a policy for the buyer, enforced by nothing in the product. Hand it to people instead: the AP clerk plans each payment run from the Creditor Report aging, working out when each bill falls due from its invoice date and the supplier’s terms, and the finance manager reads each supplier’s exposure there, monthly, rather than on the supplier record. They know it is working when no supplier’s balance has passed the figure they agreed without one of them having said yes to it.

8. Consignment is its own chain, with its own accounts

Stock a consignor places with you and still owns does not run through the standard chain. It has its own six documents, two GL codes of its own, and one naming trap.

    flowchart LR
  CPO["Consignment PO<br/>0 / 0"] -->|"KO For"| CGRN["Consignment GRN<br/>stock +1<br/>Dr Consignment Stock<br/>Cr Consignment Liability"]
  CGRN -->|"goods sell on a<br/>Sales Invoice (stock −1)"| SOLD(["sold"])
  SOLD --> CBILL["Consignment Billing<br/>Dr Purchase / Cr Creditor<br/>+ Dr Consignment Liability<br/>/ Cr Consignment Stock"]
  CGRN -->|"unsold, goes back"| CRET["Consignment Return<br/>Dr Consignment Liability<br/>/ Cr Consignment Stock<br/>stock unchanged"]
  CGRN -->|"issued without a sale"| CGIN["Consignment GIN<br/>stock −1<br/>ordinary purchase / creditor accounts"]
  CBILL --> PV["Payment Voucher"]
  

• The GRN and the Return post to CONSIGNMENT_STOCK and CONSIGNMENT_LIABILITY, and a GL code typed on a line is ignored for these types. The two accounts are found differently. The liability (and any input tax) comes only from the company default GL codes. Each goods line’s stock account is looked for in turn: a GL code on the document header, then the item’s own CONSIGNMENT_STOCK code for this company, then the company default. A missing code does not stop FINAL at either end of the cycle: the journal posting that runs after it fails — MISSING_DEFAULT_GL_CODE: CONSIGNMENT_LIABILITY, or NO_JOURNAL_CREATED when no goods line found a stock account — and the document sits FINAL with no journal.
• One unresolved line is quieter than all of them. When some goods lines find a stock account and one does not, that line is left out, the liability is written for the lines that remain, and the journal balances and posts — short by that line, with no error. Compare a consignment GRN’s journal total with its document total when an item is new to consignment.
• The GIN is not in the consignment list: a posted consignment GIN falls back to the ordinary purchase and creditor accounts. Use it for issues without a sale; use the Return to reverse value.
• Consignment Billing is the consignor’s bill to you. Its applet sits in the sales folder and is named as if it billed a customer; it is a purchase invoice in every respect, and it moves no stock — the GRN already brought the quantity in.
• Consignor Purchase Billing is a period worksheet in its own tables. It has no FINAL, posts no journal, and creates no creditor balance; the amount owed is still recorded by a purchase document.

A consignment GRN keyed at RM 0 — common when the price is not yet agreed — enters the moving-average cost pool at zero and pulls the item’s average down for everything in stock.

Who keeps the consignor honest

The principal’s statement of what sold is their count, not yours. Each month the category buyer compares it with the units the branches actually sold, and settles any difference with the principal before the Consignment Billing is keyed, because the billing is the purchase invoice and the amount it books is the amount you will pay. After the billing, the consignment holding left on the GRNs should equal the units still on the shelves.

Where the numbers on this page come from

Each idea above leaves a figure on some screen, and each figure is either stored when a job runs or worked out when you look. Which one it is decides when it can be wrong.

The same question, answered for every purchasing figure on another module’s screen, is in Related Applets.

When one of these ideas bites

Configuration causes — a missing default GL code, a supplier on a receivable type — surface in another module first, and are in Related Applets.

How you know your company follows them

About ten minutes, once per company, and again whenever someone changes the knock-off or receiving set-up:

1. Knock Off Configuration (Organization → Company). Every pair you chain is enabled, and no pair you do not chain is. You are done when the list matches the flow your buyers actually use — usually Purchase Order → Purchase GRN and Purchase GRN → Purchase Invoice on the standard pair.
2. One receiving pair. Pick last month’s ten largest deliveries. Each is either a plain GRN knocked off into a Purchase Invoice, or a GRN Stock In knocked off into a No Stock In invoice — never one of each. You are done when all ten follow the same pair.
3. One finished invoice. On a recent purchase invoice: Doc Link shows the receipt it came from, the Posting tab shows Journal and Inventory posted, and the line’s Costing Details shows both an average and a Last Purchase Price. You are done when all three are there.
4. The queue tells the truth. In the Purchase Order Queue, no order whose goods have all been received and billed still shows a balance. You are done when every line older than the supplier’s lead time has a reason the buyer can give, or has been closed.

The month-end version of the same check, ledger by ledger, is the Related Applets checklist.

Where to go next

If you are setting up a company, read Configuration next: it creates the records these ideas depend on, in order, and asks for the receiving-pair decision before the first receipt. If you want to see the ideas in a real buying pattern, read Use Cases.