Purchasing Module

Purchasing in BigLedger is a chain of documents tied together by knock-off: a requisition is knocked off into an order, the order into a receipt, the receipt into the supplier’s bill, and the bill is settled by a payment. Each link copies the previous document’s open lines forward and reduces what is still outstanding. Nothing in the chain compares the numbers for you, and along one chain a single document moves stock: the supplier’s bill, or the receipt when you use GRN Stock In. This page is for whoever buys, receives or pays suppliers, and it routes you to the page that answers your question.

Start here.

Setting a company up? Read Configuration first: the records in the order to create them, and the receiving-pair decision to make before the first receipt.
Doing a job — ordering, receiving, booking a supplier’s bill, buying on consignment? The Purchasing guides walk each one, step by step: Standard Procurement Workflow · Direct GRN Workflow · Direct Invoice Workflow · Invoice-First Workflow · Consignment Purchasing · Document Approvals.
A number already wrong? Start at Related Applets, because most purchasing problems surface in another module; the symptoms that come from the module’s own design are in Core concepts. A bill that is FINAL with no journal is Finalised, and nothing happened.

The receiving pair is the decision that matters. Either the purchase invoice books the stock and the plain GRN records the receipt but moves nothing, or GRN Stock In books the stock and the invoice that follows is Purchase Invoice No Stock In. Pick one pair per company; mixing them counts goods twice or never, with no error. Core concepts §3 explains both, and §2 has every document’s stock and ledger effect.

The module’s pages

Core concepts

Knock-off and the open queue, the signum, the receiving pair, matching, approval, supplier credit

Configuration

Suppliers, items, GL codes, knock-off rows and the one decision to make before the first receipt

Use cases

Central buying for 22 branches, replenishment, stock before the bill, returns, consignment, the supplier window, buying inside the group

Reports

The reports that exist, which question each answers, and the ones people ask for that do not

Best practices

Operational advice that follows from the mechanics

For developers: API notes

Where the REST API is documented, and what an integration must respect

Applets in this module

Which applets belong here is an editorial judgement: the product’s data has no module-to-applet link. Each applet’s reference page carries its fields, settings, posting proof and failure modes. Purchase Invoice (Internal) and Payment Voucher (Internal) are filed under Financial Accounting and listed here because the person raising them is in a purchasing process.

Job	Applets
Deciding what to buy	Purchase Requisition · Purchase Quotation · Blanket Purchase Order (an agreement orders are drawn down from; it orders nothing) · Purchase Order
Receiving	Purchase GRN (moves nothing, posts nothing) · Purchase GRN Stock In (books stock and the accrual) · Purchase GIN (a dispatch record only)
Billing, paying and adjusting	Purchase Invoice · Purchase Invoice No Stock In · Payment Voucher · Purchase Return · Purchase Debit Note (you owe less) · Purchase Credit Note (you owe more) · Purchase Refund Note
Consignment from a consignor	Consignment Purchase Order · Consignment GRN · Consignment GIN · Consignment Return · Consignment Billing (a purchase document, filed under sales by its name) · Consignor Purchase Billing
Reporting	Purchase Report; what you owe by age is the Creditor Report — see Reports
The supplier’s window	Purchase Order, GRN, Invoice, Credit Note, Return and Blanket Purchase Order Supplier Access, and Supplier Delivery Order. All resolve the user through the Supplier’s Supplier Login tab (Use cases §8). The order view also lets a supplier upload orders and set a status your buyer does not see
Reconciling supplier e-Invoices	AP Automation matches PDF e-Invoices to receipts, not invoices to orders; AP Automation Supplier Access shows the supplier the result. Neither posts

What the module does not do, and what to do instead

No tolerance-based three-way match. Nothing compares order, receipt and bill and blocks the bill when they differ: the AP clerk compares the knocked-off lines with the supplier’s paper before FINAL, noting the reason for each difference (Core concepts §4). Where suppliers e-mail e-Invoices as PDFs, AP Automation checks each one against the receipt that quotes its delivery-order number and lists the differences to work, once BigLedger schedules its jobs and receiving keys that number in each GRN’s Client Doc 3; Peppol e-Invoices are listed, not matched.

Approval does not block FINAL. Purchase orders and purchase requisitions can be routed to approvers by e-mail, and the first approval finalises the document — but an order still pending can be finalised by hand. The control is who holds FINAL, and the requisition has a catch there that Core concepts §5 explains (Document Approvals has the setup).

Supplier terms and limits are records, not rules. A purchase invoice gets no due date from the supplier’s terms, and nothing checks a supplier’s credit limit; the AP clerk plans each payment run from the Creditor Report ageing (Core concepts §7).

Purchasing Module

The module’s pages

Applets in this module

What the module does not do, and what to do instead

Related documentation