Skip to content
The order still shows a quantity outstanding after I invoiced it all

The order still shows a quantity outstanding after I invoiced it all

“The order still shows a quantity outstanding after I invoiced it all” — and the stock it is holding back is being refused to other customers. Usually nothing is broken: an order’s outstanding quantity is a stored balance, one per downstream document type, written by a background job and not worked out live, and there are three ordinary reasons it reads high.

GadgetSphere’s GS-KV-01 branch takes an order for 5 ultraportable laptops from a corporate customer and invoices all 5 over two invoices. A week later the invoice’s KO For tab still offers the order with 2 to come, and the counter is told “item not found even though got stock” while 8 sit on the shelf.

The knock-on matters more than the report. Available stock reads this number. Available is stock on hand, minus the un-invoiced balance of open sales orders, minus reservations, at each location. An order line whose stored balance never came down is quietly refusing goods that are on your shelf.

The fast path. Four checks, each with the fix that matches it (the full check, what to do). On a purchase order the mechanism is the same and the reports differ: start at On a purchase order.

  1. Read the balance from the document type you are knocking off with. The invoice and the delivery note each keep their own, so a delivery note still offering the full quantity after you invoiced it is correct. Read that offer; do not also knock the line off with it.

  2. If you finalised the order seconds ago, wait and refresh: the balance is written by a background job that starts after Finalise.

  3. Open SO Line with SI KO in the Sales Order applet. A negative Qty Closed means the stored balance is higher than the invoices justify. If Qty Received is lower than what you invoiced and Qty Closed is 0, some invoiced quantity has no knock-off link: an invoice keyed fresh, or a knock-off removed since (an invoice keyed fresh).

    If Qty Received equals what you invoiced and nothing more will be invoiced on that line, press Close on the line, not on the order: the order’s own CLOSE ends every balance on it, delivery ones included. Closing is a decision for whoever owns the order, needs a login allowed to delete open-queue entries, and if either check is uncertain the line goes to support instead.

  4. If a FINAL order is missing from KO For altogether, check first for an enabled Knock Off Configuration row for that pair on the company. If there is none, add it in Organisation, then re-queue the orders already finalised in Data Fix, Generic Documents › Missing Open Queue: adding the row creates nothing for them.

The 30-second check

1. Which document are you looking at it from? BigLedger keeps one balance per order line per downstream document type. The sales invoice reads its own row. The delivery note reads a different one. So the delivery note will still offer you the full 40 after the invoice has already taken 22, and that is correct — the goods have not gone out yet. It is an offer to read, not one to take on a line the invoices are already knocking off: the fourth shape below is what happens when both do.

If the “outstanding” you are worried about is on a different document type from the one you knocked off, you are done. Nothing is wrong.

2. Has it been seconds rather than minutes? Writing that row is a background job that starts after the Finalise you pressed, not part of it. A balance missing in the seconds after FINAL is usually a balance that has not arrived. Wait, refresh, look again.

3. Read the line on SO Line with SI KO (Sales Order applet). It puts the two ways of counting side by side. Qty Received is the invoiced quantity, added up from the knock-off links as you look. Qty Outstanding is the stored balance. Qty Closed is what is left when you take both away from Qty Ordered — so if Qty Closed is negative, the stored balance is higher than the invoices justify, and if it is positive on a line nobody closed, the balance is lower than they justify. GadgetSphere’s line reads Ordered 5, Received 5, Outstanding 2, Closed −2. Read it alongside Stock Availability for the order’s location, which is where the 2 are being held back.

4. Is the order on the list at all? A FINAL order missing from KO For, and from SO Line with SI KO, has no row — the first cause below.

The three ordinary causes

No row was ever created. The background job writes nothing unless your company holds an enabled Knock Off Configuration row for that source-to-target pair. Without it the order finalises normally, the invoice simply cannot find it, and availability ignores it. Nothing creates that row when you create the company, and nothing warns you at FINAL that it is missing — so this is the first thing to check, not the last: the pair must exist before the order is finalised. A row marked Pre-order only queues only the lines whose item is flagged pre-order; every other line on the same order gets no balance.

The row is for the other document type. As above — the invoice and the delivery note each keep their own.

And one that is not the row’s fault: the invoice was keyed fresh, not knocked off the order. On the invoice screens, the balance comes down when an invoice is created from the order, through KO For. An invoice raised from scratch for the same customer and items posts its stock and journal normally, and the order never hears of it.

KO For still offers the full quantity, Available stays low by it, and SO Line with SI KO reads Received below what you actually invoiced (0 if nothing was knocked off) with Qty Closed 0. A knock-off is made while an invoice is being raised: the knock-off the invoice screens use refuses an invoice that is already FINAL. So once you have matched the fresh invoice to the line by its number and quantity, Close the line (Closing a line is a decision).

Closing ends the line’s remaining balance; it does not link the invoice to the order, so voiding that invoice later gives nothing back to the order. Keep the invoice number with your record of why the line was closed.

The row outlived what it was counting. Three shapes, all seen in more than one company:

  • The stored figure is above what the links say — the Qty Closed test above. The row is rewritten from the links each time one is saved, so a high figure means a rewrite was missed somewhere; which one, the screens do not show.
  • A line was removed from the order after its row existed. The order looks right, SO Line with SI KO leaves removed lines out, and availability is low by the removed line’s quantity.
  • The order was voided and still holds stock. A void removes the order’s rows in a follow-on job of its own, after the void itself; a voided order whose rows survived keeps lowering Available.

One more shape reads low, not high: the line was knocked off by both an invoice and a delivery note. The two rows are separate, but each save rewrites its own row from every knock-off on the order line, of either kind. So the invoice balance falls by what the delivery notes took as well as by what was invoiced, and the delivery balance falls by both too. Invoice 1 of GadgetSphere’s 5 laptops, knock 1 off the same line on a goods delivery note, then invoice 1 more: the invoice balance reads 2 where the customer is still owed 3. SO Line with SI KO shows Ordered 5, Received 2, Outstanding 2 and a Qty Closed of 1 that nobody closed. Once a rewrite comes to zero or less, the row is deleted, and KO For stops offering a line the customer is still owed.

How the number is kept, and why that matters

When a sales order reaches FINAL, a job processor writes one row per order line per downstream document type, holding the quantity still to come. That row is rewritten synchronously the moment a knock-off link for its document type is saved, from every knock-off link on the order line, whatever document made it — and when it reaches zero it is deleted outright rather than left showing zero. Void the invoice or delete the link and the quantity goes back: the row is re-created if it had been deleted. That give-back needs the company to still have a knock-off pair enabled from sales orders at the moment the link is let go; if the pair was switched off first, the void or the deleted link gives nothing back, with no message, and the order stays short rather than long.

Several reports do it the other way, working the balance out by subtracting the knock-off links from the ordered quantity. That is why an order report and the stock availability figure can disagree while both are doing arithmetic correctly — and why the report can look right while availability is still wrong.

Where the held stock sits, and which pair availability reads

The row holds stock at one location: the line’s delivery location, else the line’s own location, else the order’s, else the branch’s default. So an order keyed at GS-KV-01 for delivery from GS-KV-02 lowers Available at GS-KV-02, and the branch that took the order sees nothing missing.

The main availability figure reads the Sales Order → Sales Invoice rows and nothing else on the sales side. A company that knocks orders off only with delivery orders gets correct delivery balances and orders that never count against Available. And the calculation does not look at the order or the line behind a row — which is why a row left on a removed line or a voided order goes on counting.

What goes wrong elsewhere while the balance is wrong

A stale row breaks nothing in the ledger and two things outside it.

  • The next invoice. KO For proposes the stored balance as the quantity to knock off. On a stale line that is 2 laptops the customer has already been invoiced for — change it, or close the line first.
  • Every promise made from that location. Available is low by the stale quantity until the row goes, so anyone who checks stock before promising it sees less than is on the shelf.
  • Not the ledger. An order line carries no quantity sign, so it moves no stock. The row is a promise, which is why the books are right while availability is wrong.

What to do about it

  1. No row: add the configuration, then re-queue the orders already finalised. Add or enable the pair under Organisation › the company › Knock Off Config. Adding it creates nothing for orders finalised before; re-queue those in the Data Fix applet, Generic Documents › Missing Open Queue, which runs the open-queue step alone and posts nothing — the steps and the cautions are under Recovering documents finalised before the configuration was right. Data Fix is an administrator’s applet; if it is not on your menu, ask BigLedger support.
  2. Wrong document: re-check from the right one. Read the balance from the document type you are actually knocking off with.
  3. Stored figure too high on a line nothing more will be invoiced against: Close it. On SO Line with SI KO, press Close on that line. The row moves to the closed list, KO For stops offering the line, and Available goes back up. Close removes the whole remaining balance and only the invoice one — the delivery balance for the same line stays. It needs a login allowed to delete open-queue entries.
  4. Voided order still holding stock: clear it in Trace Document. In Financial Report › Error Checking › Trace Document, pick the order’s type and number. Missing Reversal Queue reads Error — Queue present for a voided document that still has rows; Resolve deletes them.
  5. Line knocked off both ways: one route per order line from now on. Invoices only, or a delivery note and no invoice knock-off — the rule and the reason are in Partial delivery workflow, Step 3. If the customer wants paperwork for an invoiced drop, raise a delivery order from the invoice instead, which leaves the order’s balances alone. A balance that is already short on a line you still mean to invoice is a support repair: say the line was knocked off both ways.
  6. Anything else is a repair. A row on a removed line, or a stale figure on a line you still mean to invoice, is not something to close away — see below.
Nothing re-drives this on its own. A watchdog written for exactly this case — re-queuing any finalised order whose knock-off never ran — declares a queue code that is not registered as a runnable job, so both dispatch paths drop it silently and it has never run on any tenant. An order balance that never appeared will not heal overnight. Report it, or re-queue it yourself as in step 1.

Closing a line is a decision, not a fix

Close is the same button a salesperson uses for an order line the customer cancelled. So it is a judgement about the order, and it belongs to whoever owns the order — usually the branch or sales admin, not the stock controller who noticed Available was wrong. Close the line rather than the order: the order’s own CLOSE button ends every balance on it, delivery ones included, and is for an order that is finished altogether. Before pressing it, check two things on the line: Qty Received equals what you invoiced, and there is nothing more you intend to invoice.

Where an invoice was keyed without knocking off the order, Received leaves it out, so match that invoice to the line by its number and quantity instead. If either check is uncertain, leave the line open and send it to support instead.

How you know it is fixed

  • SO Line with SI KO shows the line with Qty Outstanding 0 and Queue Closed Status Closed, or no longer lists it as open. Qty Closed is no longer negative.
  • The next invoice’s KO For either does not offer the order, or offers exactly what you expect to invoice.
  • Stock Availability at the order’s location shows Available up by the quantity the row was holding — 2 more laptops at GadgetSphere’s branch.
  • For a re-queued order, it appears in KO For as soon as Data Fix reports success. For a voided one, Trace Document’s Missing Reversal Queue now reads Succeed — Queue missing.

On a purchase order

A purchase order keeps its balance the same way: one stored row per order line per downstream document type, one for each receiving document the company enables (Purchase GRN, GRN Stock In) and one for the purchase invoice where that pair is enabled. It is rewritten when a GRN or invoice created from the order through KO For is saved, and given back when a knock-off is removed or a linked GRN is voided (Purchasing core concepts §1). One difference changes the stakes: Available stock does not read a purchase order’s balance, so a stale row holds nothing back. What it costs is a buyer chasing goods that came, and a GRN or invoice screen still offering the order.

The check. In the Purchase Order applet, PO Line with GRN KO shows the receiving balance and PO Line with PI KO the invoice balance, with the same columns as the sales report: Qty Ordered, Qty Received (added up from the links), Qty Outstanding (the stored row) and Qty Closed. Purchase Order Queue lists the orders that still have a Purchase GRN balance but shows no quantity, so read the two reports. A company that enables both Purchase Order → Purchase GRN and Purchase Order → GRN Stock In sees each line twice on the GRN report, once per receiving balance.

The causes, on the purchase side.

  1. A GRN or invoice keyed fresh, not created from the order: the order never hears of it. The GRN report reads Received below what arrived, and Qty Closed 0.
  2. The invoice knocked off the GRN, not the order, at a company that also enables Purchase Order → Purchase Invoice. That invoice balance then stays at the full quantity: the invoice report reads Received 0 and Outstanding equal to Ordered. If the GRN and the invoice both knock off the order, each save counts both against the balance, so it reads low, or the line drops off.
  3. A knock-off removed, or a linked GRN voided: the quantity goes back to the order, even on a line somebody already closed, as long as a pair from the order is still enabled. Voiding a GRN reopens the line.

The fix. For a line nothing more will arrive or be billed against, press Close on it in the report whose balance is wrong. Closing on the GRN report ends the receiving balance only; the invoice balance stays. There is no confirmation, so check first: Qty Received equals what arrived (on the invoice report, what was billed), and nothing more is due from the supplier on that line. Like a sales line, closing is a decision for whoever owns the order. Close needs a login allowed to delete open-queue entries.

A row closed from the GRN report is listed under Closed Queue KO; one closed from the invoice report, or by the order’s own CLOSE, is not. The knock-off requests refuse a GRN or invoice that is already FINAL, so prevention is the route: receive with a GRN from the order, bill the GRN, and switch off Purchase Order → Purchase Invoice unless you invoice orders that have nothing to receive.

How you know it worked. The line reads Qty Outstanding 0 and Queue Closed Status Closed, and its Close button is gone. The next GRN’s KO For stops offering the line, and the order leaves Purchase Order Queue once it has no Purchase GRN balance left.

When it is a support matter

Report it when the outstanding quantity is wrong and the knock-off configuration is in place and the links on the documents are correct, and the line is one you cannot simply close. Two shapes cover nearly all of them:

  • Extra outstanding quantity — the order shows a balance the invoices have already covered, on a line you still mean to invoice, or from a line that was removed.
  • The order is missing from the KO tab entirely, even though it is FINAL and has a balance, and Data Fix’s re-queue did not bring it back.

Give the order number, the company, the line, and the three figures from SO Line with SI KO — ordered, received and outstanding.

What this page cannot tell you

  • Whether the background job ran on your tenant. Which processors are subscribed is a per-tenant setting with no screen that lists it. You find out by finalising a test order and watching it appear in KO For, normally seconds later; if it does not, with the pair enabled, support can tell you what is subscribed.
  • How to set a stored balance to a figure you choose. The repairs above either create a missing balance, remove a voided order’s, or close a line’s whole remaining balance; setting it to, say, 1 of a remaining 2 is a support repair.

Related documentation

Last updated on