Following a sales order deposit from collection to refund and close

Part of creating a sales order: one deposit, followed from the day it is taken to the day the order is closed. It assumes the order exists and that your company has chosen which tab takes deposits, at Step 5; Receipt Voucher is the default the guide recommends. If the deposit was taken on the Settlement tab, refund or re-receipt the money before you void the order: the void reverses the cashbook line and journal the deposit posted, while the money stays in your bank (Void or close).

Following a deposit from collection to close

A second GadgetSphere order, this time with a deposit, followed to the end. A corporate customer orders 10 flagship smartphones at RM 4,000 each, RM 40,000 in all (tax is left out to keep the arithmetic plain). They pay a RM 20,000 deposit by bank transfer. Four phones are delivered and invoiced, RM 16,000. The customer then cancels the other six. You owe them RM 4,000 back.

Four jobs, and none of them is done for you:

1. Record the deposit, and check it reached the bank

Take the RM 20,000 on the route your company chose at Step 5. Then look at the order’s ARAP tab. Outstanding should read −20,000.00: a credit of RM 20,000 held for this customer against this order. Until the order is finalised, that credit is on the order and nowhere else.

Then check the money reached the books. It is a person’s check, and the moment is the day the deposit is taken. Open the order’s Trace Document tab if you used the Settlement tab, or the receipt’s if you used the Receipt Voucher tab. The Cashbook Txn tab should show one line for RM 20,000, and the Journal Txn tab a debit to the bank and a credit to the customer (trade debtors).

On the Settlement tab this depends on how your tenant is set up. Finalising the order queues one primary job, and that job starts the cashbook and journal postings only where your tenant subscribes to them for this kind of document. A subscription is a link in BigLedger’s platform registry, switched on per tenant — not a setting on the order, and not a clock in the Scheduler, which lists clocks and not subscriptions (the difference is explained in How work actually runs).

The two halves differ. The journal comes by itself only through its subscription. The cashbook line has a second way in: where the cashbook watchdog clock runs on your tenant, about every 15 minutes it adds cashbook lines to any order or other document whose settlement lines have none at all, subscription or not, a limited number per run. Nothing on the order tells you what will happen; its Trace Document tab shows what did, so look an hour later. A Cashbook Txn line with an empty Journal Txn tab means the cashbook has the money and your accounts do not: neither the bank’s GL account nor the customer’s account has moved. Both tabs empty means the deposit is not in your books: your bank will show RM 20,000 that nothing in BigLedger explains. In either case, ask BigLedger whether the cashbook and journal subscriptions are switched on for sales orders, and until they are, take the next deposits on the Receipt Voucher tab. Do not key this one again as a receipt: it is already on the order, and it would count twice. This rests on reading the source, not on a test. Before your company relies on the Settlement tab, take one small deposit on a test order and look at its Trace Document tab.

2. Use the deposit against the invoice

When the four phones ship, raise the invoice from the order (the invoice’s KO For tab, Sales Order). Because the order holds a credit, BigLedger asks Transfer Available Credit? and shows the order’s credit balance: RM 20,000.

• Yes moves the whole balance, RM 20,000, from the order onto the invoice, not just the RM 16,000 the invoice is for. The invoice’s Outstanding reads −4,000.00: the customer’s leftover credit now sits on the invoice, and the order’s balance goes to zero.
• No moves nothing. The invoice shows RM 16,000 owed and the order still holds −20,000. Somebody must then apply RM 16,000 by hand, from the invoice’s Contra tab.

An invoice made on the server from the whole order (the Convert action, or a delivery job) moves the whole balance without asking.

Knock-off moves quantities; contra moves money. Pulling the order into the invoice (knock-off) tells BigLedger which units have been billed. The deposit reaches the invoice only through the contra that the Yes answer creates. A contra writes no journal of its own, except on a foreign-currency document. It changes which document the customer owes on, not what the customer owes in total.

Deciding Yes or No is the invoicing clerk’s call, made on the dialog. Answer Yes when the deposit should be used up first. Afterwards, check the invoice’s ARAP tab: it should read the invoice total less the deposit. The whole-balance move comes from reading the source, not from a test. Before your team relies on it, invoice part of one small test order that holds a deposit, answer Yes, and read both documents’ ARAP tabs. Whether BigLedger means the whole balance to move, rather than the invoice’s share, is an open question to the product team.

3. Refund what is left, and match the refund back

Nothing in BigLedger raises a refund. The leftover credit waits, on the invoice after a Yes or on the order after a No, until somebody acts. That somebody is accounts, and the moment is when the customer confirms the cancellation.

1. Raise a payment voucher to the customer for RM 4,000 (Payment Voucher (Internal) → Internal Payment Voucher → Create). Pay it from the cashbook the money actually leaves.
2. On its Contra tab, pick the document holding the credit. The picker offers the customer’s documents with a credit balance. After a Yes, that is the invoice, not the order.
3. Finalise. The voucher posts a debit to the customer and a credit to the bank. The invoice’s Outstanding goes to 0.00.

Separate the two people where you can. The person who agrees the refund with the customer should not be the one who raises and finalises the payment voucher. That separation is yours to set up; the order does not enforce it. The finalise permission on the payment voucher is where it lives.

4. Close what will never ship

The six cancelled phones are still open on the order. Close them from SO Line with SI KO, one row at a time, or with Close on the finalised order, which closes every line. Closing stops the lines appearing in the invoice’s KO For picker. It does nothing to money. A deposit still sitting on the order after a close stays there until you apply or refund it.

Once a month, somebody should read the credits. The Debtor Report’s outstanding list includes finalised orders that still hold a deposit, and invoices carrying a leftover credit, each as a credit line. BigLedger will not chase a credit you owe. Reading that list and asking “is this order still going to ship, or do we owe this money back?” is accounts’ job, and the month-end review is the moment to do it.

Void or close — decide before you click

VOID refuses on any live link, whether to an invoice, a delivery order or a draft invoice. So “void only when nothing is invoiced” is the practice, and the system enforces something broader. Close, on the other hand, is offered for any open line, including one nothing has been delivered against. “Close only after part has shipped” is a practice for your team to keep, not a rule BigLedger enforces.

What success looks like for this part

How you know the whole thing is finished: the customer’s balance in the Debtor Report is zero for this order and its invoice, SO Line with SI KO shows 4 invoiced and 6 closed, and the bank shows RM 20,000 in and RM 4,000 out.

Common mistakes in this part

The rest of the order’s mistakes are on the front page and with Steps 6 to 8.

Related documentation

• Creating a Sales Order — the whole task, and Step 5’s two deposit routes.
• Payment Voucher (Internal) applet — the refund.
• Sales Order (Internal) applet — the Settlement and Receipt Voucher tabs.