Instalment Sales Workflow

A customer wants the RM 4,200 laptop but wants to pay for it over twelve months. By the end of this guide you will know the two ways BigLedger can record that, which one your business is actually using, and how to set it up so the money reconciles against the bank at the end of the month. Setting up the settlement method takes ten minutes, once. Selling then takes no longer than any other sale.

Read this first: what BigLedger does not have

There is no instalment sales module. No financing application screen, no credit-approval step, no agreement to generate and sign, no schedule of instalments to track, no hire-purchase ledger and no amortisation. If someone has told you BigLedger manages instalment plans end to end, they have described a different product.

What BigLedger has is a settlement method that can be marked as an instalment tender, carry an instalment period, and account for the fee the provider takes — plus the ordinary credit-sales machinery for when a finance company is the one paying you.

That turns out to be enough, because in almost every Malaysian retail case the instalment plan is somebody else’s product. Your part is to sell the goods, get paid, and record the fee correctly.

Meet GadgetSphere

GadgetSphere Sdn Bhd sells an ultraportable laptop at RM 4,200 — RM 4,452 with 6% SST. The customer at GS-KV-01 wants to spread it over twelve months on their credit card’s instalment plan. The card-acquiring bank takes a higher fee on instalment transactions than on ordinary card sales — say 3.5% rather than 1.2% — and settles the net amount to GadgetSphere’s card-acquiring cashbook a few days later.

Which of the two paths are you on?

Ask one question: who owes you the money after the goods leave the shop?

Path A is what a card instalment plan is. Path B is what an in-house or third-party financier arrangement is. They are recorded completely differently and the difference is not cosmetic: on Path A you have no receivable at all, on Path B you have one for the full amount.

If the answer is “the customer pays us monthly, directly” — that is neither. BigLedger has no schedule to manage it. See If the customer pays you directly at the end of this guide.

Path A: the customer pays their bank, and the acquirer pays you

Step A1: Build the settlement method

Master Data > Cashbook > Settlement Method > Create

The outcome: a payment button at the counter that means “12-month instalment on a card”, and a cashbook that will actually reconcile.

Create the settlement method with a code and name your cashiers will read correctly — CARD-INST-12, Card instalment 12 months. Point it at the cashbook the acquirer settles into; GadgetSphere uses a dedicated card-acquiring cashbook, CASH-CC-ACQ, rather than the operating bank account, because the money arrives net and late.

On the Details tab:

• Settlement Type — CREDIT_CARD.
• Installment period — 12. This is the field the product provides for instalment tenders; it is on the Details tab unless your tenant has hidden it.
• Payment provider / gateway, PGW payment ID and type code — fill these only if the transaction is going through an integrated payment gateway rather than a standalone terminal.

On the Charges tab — and this is the step people skip:

• Set the charges the provider takes from you: mode RATIO, rate 3.5%. This is what makes the cashbook line net and reconcilable against what the acquirer actually deposits: at FINAL, BigLedger books the cashbook line at the amount less the charge and posts the charge itself as a separate line to your company’s Settlement Charges default GL code (Chart of Account > Company Default GL Code, code SETTLEMENT_CHARGES). Map that code before the first sale — it is the account your acquirer fees will accumulate in.
• If you pass a surcharge on to the customer, configure it under Surcharge to customer with the item code it bills under. Note that the legality and the card-scheme rules around surcharging are your business’s call, not the system’s.

On the Branch tab, link the branches that may offer it. A settlement method that is not linked to your branch does not appear at your counter — that is the answer to nine out of ten “the button is missing” questions.

Step A2: Sell

POS General > Create Cash Bill, or Sales Invoice (Internal)

The outcome: a completely ordinary sale.

Ring the laptop up as normal, then choose the Card instalment 12 months button instead of the ordinary card button. Enter the full RM 4,452 and whatever the terminal gives you — approval code, last digits, issuer.

Press FINAL. What posts is a normal sale, with the acquirer’s fee split out because you configured it in Step A1:

Dr  Card acquiring cashbook              RM 4,296.18   (RM 4,452 less 3.5%)
Dr  Settlement charges — card acquirer   RM   155.82
    Cr  Sales — laptops, KV01                     RM 4,200.00
    Cr  SST output tax                            RM   252.00

One laptop leaves GS-KV-01 as an inventory transaction; no cost-of-goods-sold line posts with the bill — that is the month-end journal in the Financial Report applet. You have no receivable. The customer owes their card issuer, not you, and there is nothing on your ageing report to chase. That is the whole point of the arrangement.

If the bill goes FINAL but the Trace Document tab shows no journal a minute later, the posting job failed afterwards — a settlement method with no cashbook or GL code (MISSING_CASHBOOK, MISSING_GL_CODE: STL_MTHD CARD-INST-12), or a missing sales default. FINAL is never blocked by those; find and repair them in Financial Report > Error Checking > Trace Document.

Step A3: Reconcile the acquirer’s payout

Finance > Bank Reconciliation

The outcome: the RM 4,452 you recorded and the smaller number the bank actually deposited, matched.

The acquirer deposits net of their fee, in a batch, days later. Because you configured the charge rate on the settlement method, the cashbook line is already RM 4,296.18, not RM 4,452, and the batch deposit will match against the day’s card-acquiring cashbook lines.

If you did not configure the charge, every instalment sale leaves a small unexplained difference in the card cashbook, and by month end there are hundreds of them. Configure it.

Path B: a finance company buys the goods

Step B1: Make the financier a customer

Master Data > Customer Maintenance > Create

The outcome: an entity you can invoice.

Under this arrangement the finance company is your buyer. Set them up as a customer with their real credit terms, their tax registration for e-Invoice, and an AR type that tells you at a glance that this is financed business rather than ordinary trade — GadgetSphere posts them to a separate receivable account.

The end customer is still worth recording — on the invoice’s delivery details, and in the remarks — because they are who the goods went to and who will ring you about the warranty.

Step B2: Invoice the financier

Finance > Sales Invoice (Internal) > Sales Invoice > Create

Bill the finance company for the full RM 4,452, with the end customer’s name and the agreement reference in the header reference and remarks. FINAL takes the stock out and opens the receivable against the financier:

Dr  Debtor — financed sales              RM 4,452.00
    Cr  Sales — laptops, KV01                     RM 4,200.00
    Cr  SST output tax                            RM   252.00

If the financier deducts a commission, raise a Sales Credit Note (Internal) for it against that invoice rather than reducing the invoice — you want the gross sale and the commission visible separately, and the end customer’s paperwork shows the gross price.

Step B3: Collect from the financier

Finance > Receipt Voucher (Internal) > Internal RCT Voucher > Create

When the financier pays, raise a receipt voucher, add the settlement line, and contra it against the invoice. Financiers usually pay in batches covering many sales, so one voucher will often contra several invoices — that is exactly what the Contra tab is for.

Until the contra exists, the invoice sits on your ageing as unpaid, which is correct: on Path B you genuinely are carrying credit risk on the finance company, and it belongs on the Debtor Report with everything else.

If the customer pays you directly, month by month

This is the arrangement BigLedger has the least for. There is no instalment schedule object, no automatic monthly posting, and no balance that counts itself down.

Two workable approaches, both manual:

• Invoice the full amount and let it sit on the ageing, taking receipt vouchers as each payment arrives and contra-ing each one against the invoice. The open amount reduces as they pay. Honest, simple, and your ageing report will show a twelve-month-old invoice that is not actually overdue — which will annoy whoever runs collections unless you agree a convention for marking it.
• Invoice each instalment as it falls due. Recurring Sales Invoice Applet generates sales invoices on a schedule, so a twelve-month plan can be twelve dated invoices. Cleaner on the ageing. The catch is that the goods left on day one, so the first invoice has to carry the stock and the other eleven must not — which means eleven invoices of a non-stock item, and a tax treatment you should put to your accountant before you start.

Neither is a finance product. If instalment selling is a material part of your business, the sound answer is a financier or a card plan — Path A or Path B — rather than carrying the credit yourself on a system that is not built to track it.

What success looks like

On Path A, after the first instalment sale:

1. The customer’s account shows nothing outstanding. They owe their bank, not you.
2. The card-acquiring cashbook has a line for the sale, net of the fee you configured.
3. Stock Balance at GS-KV-01 is one laptop lower.
4. When the acquirer’s batch lands, it matches in Bank Reconciliation without a manual adjustment.

On Path B, after the first financed sale:

1. The invoice is on the financier’s account, not the end customer’s.
2. The Debtor Report shows the exposure under your financed-sales receivable, separate from ordinary trade.
3. The end customer’s name is on the invoice somewhere you can search for it.

Common mistakes

Expecting an instalment schedule to exist. It does not. If you need one, it lives in a spreadsheet or in the financier’s system, not here.

Using the ordinary card settlement method for an instalment sale. The fee rate is different and the money arrives on a different timetable. Everything nets out wrong in the card cashbook and nobody can tell which sales caused it.

Not configuring the provider’s charge on the Charges tab. The cashbook says RM 4,452 and the bank deposits RM 4,296.18. Multiply by a month of sales and you have a reconciliation that nobody will ever finish.

Configuring the charge but not the SETTLEMENT_CHARGES default GL code. BigLedger still nets the cashbook line, but the fee line is silently dropped from the journal because it has no account — so the journal is out of balance by the fee, the posting job fails after FINAL with TOTAL_DEBITS_AND_TOTAL_CREDITS_NOT_BALANCES, and nothing in the message names the cause. Map the code once, under the company’s default GL codes, and re-post from Trace Document.

Forgetting to link the settlement method to the branch. No button at the counter, and a cashier improvising with the ordinary card method under pressure.

Invoicing the end customer on Path B. You have then billed someone who is never going to pay you, while the financier who is going to pay has no invoice. Bill whoever owes you the money.

Reducing the invoice to account for the financier’s commission. The end customer’s paperwork says RM 4,452 and your invoice says less. Raise a credit note for the commission and keep the gross sale visible.

Promising the customer a plan before checking your settlement methods. If CARD-INST-12 is not set up and linked to the branch, you cannot take that payment today, and the customer is standing at the counter.

Related documentation

• Cashbook — settlement methods, the Installment period field, the Charges tab, and how a method reaches a branch
• POS General — the counter, and every settlement error by name
• Sales Invoice (Internal), Receipt Voucher (Internal), Sales Credit Note (Internal)
• Recurring Sales Invoice Applet — scheduled invoice generation
• Bank Reconciliation and the bank reconciliation guide
• Credit Sales Workflow — the machinery Path B runs on
• Cash Sales Workflow — the counter transaction Path A is a variant of