Recording a Customer Payment: Contra and Finalise

Apply a customer's payment to the invoice and finalise the receipt

Steps 5 to 7 of recording a customer payment: deal with the bank charges, apply the receipt to the invoice, and finalise it. It follows Steps 1 to 4, where you started the receipt, chose the customer and recorded what arrived. The running example is a corporate customer’s RM 42,468 transfer against invoice SI-00019, of which the bank kept RM 12, so RM 42,456 landed (Meet GadgetSphere). Before FINAL, every settlement method on the receipt must point at a cashbook with a GL code behind it (Before you start); FINAL still succeeds without one, and the posting fails afterwards.

Step 5: deal with the bank charges.
Step 6: apply it to the invoice, the step that clears the balance.
Step 7: finalise.

Step 5: Deal with the bank charges

Expenses tab

Add an expense line for the RM 12. An expense line is a deduction taken out of the receipt (a bank charge, a transfer fee), and the customer is credited with what was banked plus the deduction: RM 42,456 + RM 12 = RM 42,468, exactly the invoice.

Choose the item for that line with care, because it decides the account. An expense line does not go to an expense account by itself. It is debited along the same chain a sale uses: the GL code of a GL-code item if the line uses one, otherwise the item’s own sales account, otherwise your company’s default sales account. Any tax on the line is debited to your output-tax account. So RM 12 of bank charges keyed on an ordinary item quietly lowers your sales by RM 12. Set up a GL-code item once that points at your bank-charges expense account, use it with no tax code, and open TraceDocument on the first voucher to check the RM 12 landed there. Whether expense lines should post somewhere else by default is an open question with BigLedger; this is what they do today.

When the charge belongs to the payment method, skip the expense line. If the fee is a fixed part of a settlement method (a card acquirer’s rate set up on the method in the Cashbook applet), record the gross on the Settlement tab and no expense line: the journal splits the method’s charge out to your settlement-charges account by itself (Step 7). Use one route or the other for the same fee, never both.

The Revenue tab, next to it, is the opposite case: money that arrived but is not against any invoice. A deposit, a miscellaneous sale, a refund of something. Revenue lines post like sales lines and carry their own tax.

Step 6: Apply it to the invoice — the step that clears the balance

Contra tab

Search the customer’s open invoices, find SI-00019, and set the amount to apply.

This is the step that reduces the invoice’s Outstanding figure. Skip it and the money is still recorded, still in the cashbook, still on the customer’s account — but the invoice stays open and the ageing report stays wrong.

The list shows this customer’s FINAL invoices (and other open items) in this company that still have something outstanding, oldest transaction date first. Which invoice the money settles is your decision, not BigLedger’s: for a receipt keyed on this screen, nothing matches it to an invoice for you, at FINAL or afterwards. Take it from the customer’s remittance advice. A payment that arrives with no remittance is not yours to guess at; finalise it unapplied and pass it to whoever chases the customer, who can ask.

Check the contra’s date if you are keying late. Each contra carries its own date, and that date decides which month-end ageing counts the payment. It is set differently by the two ways into the list. Tick invoices and press ADD, and each row takes the Contra Date column, which is today unless you type one, or the receipt’s own date if your administrator has switched on CONTRA_DATE_SAME_AS_DOC_DATE_TXN in the applet’s Application Settings. Click one invoice to open the Add Contra form instead, and the contra takes the invoice’s own date, which you can change only if EDIT_CONTRA_TXN_DATE is on. Either way, a contra date earlier than the later of the two records’ dates is moved forward to that date when it is saved, so a payment never settles an invoice before both existed. For a receipt dated after the invoice, that makes the Add Contra form’s date the receipt’s date. The case that catches people: you key on 4 April a transfer that arrived on 28 March, tick SI-00019, press ADD and leave the Contra Date at 4 April. The invoice reads paid today, but the March ageing keeps it open with the receipt beside it as unapplied money. Type 28 March in the Contra Date and March shows it paid.

For a partial payment, apply what you have. The invoice’s Outstanding drops by that much and the rest stays open, with the original due date. There is nothing else to configure: a payment plan in BigLedger is simply several receipt vouchers, each contra’d against the same invoice.

For an overpayment or a payment on account, contra what you can and finalise. The remainder stays as an unapplied receipt and can be contra’d against a later invoice.

The total contra cannot exceed the receipt’s own amount unless your company has allowed that.

Step 7: Finalise

Click FINAL. The applet checks that there is at least one settlement line; the backend refuses a date inside an accounting period your company has locked, then locks the document. The cashbook lines and the journal are posted by background jobs a moment later. The contra is not one of them. The moment the finalise call comes back, the applet sends a second request carrying the invoices you ticked, and the backend writes the settlement and rewrites both balances inside that request — so the invoice’s balance is on the screen before the journal exists. That second request can fail on its own (a missing contra permission, an expired session, a closed tab): you get a red toast, Documents contra unsuccessfully, for about a second, nothing retries, and you are left with a FINAL receipt that has its cashbook line and journal and no contra. If you saw that toast, open the receipt’s Contra tab and apply it there.

That matters for one failure. If a settlement method has no cashbook behind it, or its cashbook has no GL code, FINAL still succeeds: the receipt locks, and it is the posting job that fails with MISSING_CASHBOOK: STL_MTHD [code] or MISSING_GL_CODE: STL_MTHD [code]. You end up with a FINAL receipt, no cashbook line for bank reconciliation to match, and no journal — and the only places it shows are the receipt’s TraceDocument tab (an empty Cashbook Txn or Journal Txn grid; the receipt voucher has no Posting tab) and Financial Report > Error Checking > Trace Document. The fix is a configuration job in the Cashbook applet, not something you can do on this screen; once the method is mapped, Resolve on Trace Document re-runs the posting.

On success, three things happen — two of them a moment after FINAL, by background jobs, and one inside the second request:

A cashbook line per settlement line, in the cashbook behind that settlement method. These are the lines bank reconciliation will match against your statement.
The journal. The cashbook’s GL account is debited with what was banked, the settlement charge goes to your company’s settlement-charges account, an expense line is debited as Step 5 describes, and the customer’s receivable account is credited with the total of those. (One exception: if your company’s settlement-charges default GL code has no sub-ledger, the charge line is left out and the receivable account is credited with the banked amount only, so the ledger keeps the charge as owed even after the contra clears the invoice. Ask your finance administrator to check that default once.) Notice that the receivable account is credited here, by the receipt, whether or not a contra follows: the contra moves the invoice’s balance and the ageing, never the ledger.
The contra is applied by the second request, so the invoice’s Outstanding and the customer’s ageing both drop. The invoice’s Doc Open Amount does not move, now or later: it is the invoice’s own total.

The TraceDocument tab shows you the journal and cashbook rows it created. Open it once, on your first receipt, so you know what it looks like when it is right.

What success looks like for this part

The receipt is FINAL, its TraceDocument tab shows a journal and a cashbook row for RM 42,456.00 in the cashbook your bank statement corresponds to, and on SI-00019’s ARAP tab Outstanding reads RM 0.00 (or the expected remainder for a partial payment) while Doc Open Amount still reads RM 42,468.00. Then run the whole task’s success check.

Common mistakes in this part

What goes wrong	What you see	The fix
Finalising without a contra	The customer’s balance is right in total, but the invoice still shows outstanding and the ageing is wrong	Contra the receipt against the invoice; an unapplied receipt can be applied later
The contra request failed after FINAL	Exactly the same as the row above — plus the red toast from Step 7, shown for about a second, that you may have missed. The receipt is FINAL with its cashbook line and journal; its Contra tab is empty	Apply the contra from the receipt’s Contra tab (or the Debtor Report). Nothing retries it for you — why
Counting a bank charge twice: the gross on the Settlement tab and the charge on the Expenses tab	The customer is credited RM 12 more than the invoice, and the cashbook line is RM 12 more than the bank statement	Settlement tab: what landed in the bank. Expenses tab: what the bank kept
A bank charge keyed on an ordinary item	Sales are RM 12 lower than your invoices say; the TraceDocument journal shows the charge debited to sales	Use a GL-code item that points at your bank-charges account, with no tax code
Raising a receipt against a draft invoice	The invoice does not appear in the contra search	Finalise the invoice first
Keying a late payment, ticking the invoice and leaving the Contra Date at today	The invoice reads paid, but last month’s stored ageing still shows it open with the receipt beside it as unapplied money	Set the Contra Date to the date the money arrived; to fix an old one, delete the contra and apply it again with the right date
Saving a draft receipt with a contra and not finalising it	The invoice reads paid; the receipt has no journal or cashbook line, and the customer’s available credit has risen by the invoice amount	Finalise the receipt the same day, or delete the contra before you leave it in draft
Keying the receipt in the wrong company or for the wrong customer	The invoice is not in the Contra tab’s list; the receipt sits unapplied on the Outstanding Document Report	Void the receipt and key it again in the company and for the customer of the invoice
A settlement method with no cashbook behind it	The receipt is FINAL but its TraceDocument tab shows the Cashbook Txn or Journal Txn grid empty (`MISSING_CASHBOOK` / `MISSING_GL_CODE` in the job — the receipt voucher has no Posting tab, so an empty grid is the only symptom on the document itself), and bank reconciliation has nothing to match	Map the method to a cashbook with a GL code in the Cashbook applet, then Resolve it from Financial Report > Error Checking > Trace Document

The mistakes that belong to the rest of the task are on the front page, and If you got it wrong says how to change a receipt after FINAL.

Next: What each figure is, and what the receipt touches elsewhere.