Skip to content
Guide
Daily Tasks
Purchase Invoice: Finalise and Settle

Purchase invoice: finalise it, check what it posted, and settle it

Steps 5 and 6 of Purchase Invoice Processing: attach the supplier’s invoice, finalise it, confirm what it posted, and settle it. It follows Step 4, where you checked the invoice against the paper.

The running example: 200 earbuds at GS-KV-01, RM 25,600 net plus RM 1,536 SST at 6%, RM 27,136 owed to the supplier on 30-day terms.

Before you click FINAL, check that your company’s default GL codes are linked — PURCHASE, INPUT_TAX, and the creditor account for the supplier’s AR/AP type (Before you start). A missing one does not refuse the document: the invoice finalises with no journal behind it, or with a line left out.

  1. Step 5: attach the invoice and finalise.
  2. Step 6: confirm it posted, then settle it.

Step 5: Attach the invoice and finalise

Finance > Purchase Invoice (Internal) > (your draft) > Attachment, then FINAL

Attach the supplier’s PDF or scan on the Attachment tab. Check the image is readable and that every page is there.

There is no approval step on a purchase invoice. There is no Submit for Approval button and no approval queue, because BigLedger’s approval engine covers only purchase orders, purchase requisitions and stock requisitions. Your control here is who holds the finalise permission. If your policy is that anything with a variance needs a second pair of eyes, build that into who can click FINAL — the system will not route it for you.

Then click FINAL.

What FINAL posts. For our invoice:

Dr  Purchase (or the item's GL code)   RM 25,600
Dr  Input Tax                          RM  1,536
    Cr  Creditor — the supplier                RM 27,136

and 200 units into stock at GS-KV-01, with the serial number records created and the item’s last purchase cost updated to RM 128.

Which GL code the purchase line lands in is decided in this order: a GL code on the line, then a GL code on the document header, then the item’s own company GL link for purchases, then the company’s default PURCHASE. Tax lines always use the company default INPUT_TAX.

Two accounts you might expect to see in this journal are not there. Nothing posts to a purchase-discount account, even when your company has one mapped: a line discount is already taken off the line’s net amount, and a discount on the whole invoice is a line of its own that posts to Purchase, reducing it. So a 5% discount the supplier gave you on the earbuds shows on the invoice line, not as a separate figure in your ledger: purchases are simply posted lower. If you report discounts received, take them from the documents. Exchange differences are not in it either. On a foreign-currency invoice, the forex gain or loss is a separate journal written when a contra settles the invoice against a payment, not when you finalise.

If your company is live on e-Invoice, a finalised invoice with the self-billed flag is picked up by the My E-Invoice Portal automatically. The E-Invoice tab shows its MyInvois processing status and any failures.

Two errors that stop a FINAL:

  • The period is locked — the transaction date falls in a closed month. Change the date, or ask for the period to be reopened.
  • “Generic Document has already been posted to FINAL” — someone beat you to it. Reload the listing.

One failure that does not stop FINAL, and is worse for it. A missing default GL code does not refuse the document. FINAL succeeds, the invoice locks, and BigLedger queues the posting as a background job; it is that job that fails — with MISSING_DEFAULT_GL_CODE: CREDITOR (or CREDITOR_NON_TRADE / EMPLOYEE_OTHER_PAYABLE, whichever the supplier’s type needs). The result is a FINAL invoice with no journal, and nothing on the invoice screen says so except the Posting tab. The same is true of a settlement line on the Payment tab whose method has no cashbook (MISSING_CASHBOOK: STL_MTHD [code]).

And one that does not fail at all. When PURCHASE or INPUT_TAX is the code missing, the unmapped line is left out and the supplier’s line is built from what remains, so the journal balances and posts. A RM 1,060 invoice for RM 1,000 of laptops plus RM 60 SST, with no PURCHASE code, posts debit input tax RM 60, credit trade creditors RM 60: purchases are RM 1,000 short, and once you pay the RM 1,060, trade creditors carries a RM 1,000 debit. With INPUT_TAX missing instead, the RM 60 of tax on the bill is in no GL account. How you would notice: the payable GL account stops agreeing with the creditor ageing — the supplier statement and ageing are built from documents and look right, and the Posting tab and Trace Document show nothing wrong because a journal exists. Only a supplier with no AR/AP type turns this into a failure (TOTAL_DEBITS_AND_TOTAL_CREDITS_NOT_BALANCES). Before go-live, check every purchase, return and tax code has a company default, or every item its own.

To find the failed postings, use Ledger And Journal > Error Checking > Missing Journal: pick the purchase invoice document type and a date range, and it lists the FINAL invoices with no journal behind them. To repair one, open Financial Report > Error Checking > Trace Document, give it the document type and the invoice number — it traces one named document, not a list — and Resolve re-runs the posting. Link the GL code first, then resolve; a resolve before the code is linked fails with the same message.

Step 6: Confirm it posted, then settle it

Finance > Purchase Invoice (Internal) > (the invoice) > Posting, TraceDocument

The Posting tab shows five statuses: Journal, Inventory, Membership Points, Cashbook and Tax. Journal and Inventory both posted means you are done. If Journal shows anything else a minute after FINAL, go back to Step 5 — the document is FINAL but your accounts do not have it yet. TraceDocument shows the actual journal and inventory rows that were created, which is what you show an auditor.

When you come to pay:

  • One invoice — record the settlement on the invoice’s own Payment tab. The methods offered are the ones assigned to your branch in Branch Settings. To offset against a supplier deposit or a credit document, use the Contra tab instead.
  • Several invoices in one payment — use the Payment Voucher (Internal) applet. One payment line per real bank movement, contra-linked to the invoices being settled. Each payment line becomes one cashbook transaction, and those are what you will tick off in bank reconciliation later.

What success looks like for this part

The invoice’s Posting tab shows Journal and Inventory posted, and on the first invoice of a new tenant, or after a chart-of-accounts change, its journal shows each account carrying the amount you expect — purchases RM 25,600, input tax RM 1,536 and the supplier RM 27,136 in the example — because a missing PURCHASE or INPUT_TAX code still posts a journal that balances. When you pay, the payment is on the invoice’s own Payment tab, or on a Payment Voucher contra-linked to the invoice.

Common mistakes in this part

Treating FINAL as proof that it posted. FINAL means the document locked and the posting was queued. On a new tenant, or after a chart-of-accounts change, check the Posting tab on the first invoice of the day: a missing creditor code shows up there as a journal that was not posted, not as an error on FINAL. A missing PURCHASE or INPUT_TAX code does not show there at all — open the first invoice’s journal and check that purchases, input tax and trade creditors each carry the amounts you expect.

The rest are on the page that covers the step they spoil: keying the lines, adjusting them to the supplier’s paper, finalising an unagreed price and expecting a variance report with Steps 3 and 4; the wrong invoice document and the wrong date on the front page.

Related documentation

Last updated on
Purchase Invoice: Knock Off and CheckSales Operations Overview