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 removes the cashbook line the deposit posted (and reverses its journal, where one 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 (on the Settlement tab, today, only for some payment methods: see below). 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. On the receipt, 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).

A payment on the Settlement tab may not reach the ledger

A payment keyed on a sales order’s Settlement tab posts to the general ledger at the order for cash, card, bank transfer, voucher and points. For cheque, e-wallet, FPX e-mandate, payment gateway, open credit and Others it never reaches the ledger: a known defect BigLedger is tracking, since every payment is meant to post at the order, Dr bank and Cr customer. What you get, by payment method:

Behind the scene: for the first group the screen writes the payment as a receipt line with a negative sign, which the cashbook, the order’s balance and the journal all count. For the second it leaves the line’s document type blank, so BigLedger gives the line the order’s own type, and every sales-order line is stamped with an amount sign of zero, the mark of a line that moves no money. The cashbook amount and the order’s credit are both the amount times that sign, so both come out at zero, and the journal job leaves the line out, finds nothing to post and records Total Debits: 0, Total Credits: 0 in a log you do not see.

What it does to your accounts, for a RM 20,000 deposit:

• First group, where the journal is missing. The cashbook shows RM 20,000 (less any settlement charge) and the ledger’s bank account does not. The order’s credit later moves onto the invoice by a contra, which posts no journal, so the customer’s balance on the Debtor Report ends RM 20,000 below the ledger’s receivable account.
• Second group. Nothing in your accounts holds the money: the bank shows RM 20,000 that only a line on the order explains, the invoice is later raised for its full amount, and the customer appears to owe what they have paid.

When the cashbook line arrives. Finalising the order queues one primary job, and that job starts the cashbook and journal postings only where your tenant subscribes to them. 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 (see How work actually runs). The cashbook line has a second way in: where the cashbook watchdog clock runs, about every 15 minutes it adds cashbook lines to any document whose settlement lines have none, subscription or not, a limited number per run. It adds no journal, so look at Trace Document an hour after finalising.

How you can tell. Open the order’s Trace Document tab. A Cashbook Txn line for the amount is the first group: beside a Journal Txn debit to the bank and credit to the customer it posted; beside an empty Journal Txn grid the journal is missing (below). A line for RM 0.00 is the second group. With no Cashbook Txn line at all, the ARAP tab decides: a credit there means the first group with no cashbook posting yet, so ask BigLedger whether the cashbook and journal jobs run for sales orders; no credit means the second. Orders keyed before the screen changed or brought in through an integration can differ, and so can a line whose payment method was changed, so Trace Document is the test, not the date or the method.

A missing first-group journal usually has one of two causes. If neither fits, BigLedger support can read the job record.

• The posting failed. The journal job refused the order, typically for a settlement method or cashbook with no GL code or a company with no default GL codes; it also refuses every foreign-currency order. The reason goes to a log you do not see: ask BigLedger support for it, fix the cause, then give support the order numbers to post. Key no receipt or journal for them meanwhile.
• The order is older than your tenant’s journals, for example from before journal posting was switched on for your tenant. Such orders were finalised without a journal, and some got their cashbook line much later from a bulk catch-up run that writes cashbook lines only. A clue: the order is dated before the oldest invoice or order of the same company that has a journal on its Trace Document. If none has one, the journal job is not running for your tenant. BigLedger support can confirm either. Decide with your accountant before anything posts such an order: the deposit may already be in your opening balances.

What to do meanwhile.

1. Take new deposits on the Receipt Voucher tab. Then check that the receipt’s own Trace Document, in the Receipt Voucher (Internal) applet, shows both the cashbook line and the journal; either can still fail on a missing cashbook or GL code.
2. For deposits already on the Settlement tab, list the orders with an empty Journal Txn grid and give the list to your accountant and to BigLedger support before correcting anything. If a repair or a support repost later posts those orders, a receipt or manual journal you add meanwhile counts the money twice.
3. Never key a deposit again as a receipt when the order’s cashbook line already carries the amount, and ask support before keying one whose line is RM 0.00 or missing: a later repair could post the order’s own line too.

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.