I knocked off the payment and the outstanding balance hasn't changed

“I knocked off the payment and the outstanding balance hasn’t changed” — before you go looking for the payment, check which of three figures you are watching: the AR and AP screens show Doc Open, Contra and Balance side by side, and Doc Open never moves when you knock something off.

You received the money and applied it against the invoice. The settlement is listed. And the number you were watching has not moved. That is where the afternoon goes, unless you read the three columns first.

The fast path (the full check):

1. Open the Outstanding Document Report and read the row’s ARAP Doc Open, ARAP Contra and ARAP Balance. Doc Open never moves when you knock something off; Contra is the one that does.
2. Contra has moved: your knock-off worked. Contra is still zero: open the document’s Contra tab. No contra rows there means nothing was applied to this document. Before you apply it again, open the receipt’s own Contra tab, ask whoever took the payment whether it was a deliberate payment on account, and check the contra’s date before saving.
3. The Contra tab lists more than the Contra column shows: the rows were written and the stored figure was not refreshed. The next settlement on the document corrects it; if none is coming, report it. Compare the tab with the column; adding the three columns up will not catch it, because they are written together and always balance.

The 30-second check

Open the Outstanding Document Report and read the row’s three columns across:

Now do the arithmetic. Doc Open + Contra should equal Balance, exactly.

• It adds up, and Contra has moved. Your knock-off worked. You were reading Doc Open, which is a property of the document and is a constant for the life of it. Nothing is wrong.
• It adds up, and Contra is still zero. The settlement did not reach this document. Open the document’s Contra tab and look — if there are no contra rows, nothing was applied here, and the commonest reason is the second request that never got through.
• It adds up, Contra has moved, and the Contra tab lists more than the Contra column shows. This is the real one, and it is rare. The rows were written and the stored figure was not refreshed. Skip to When it is a support matter.

One thing the arithmetic will not catch, and it is worth knowing why: Doc Open + Contra = Balance holds even on a stale document, because the two figures that move are always written together. The stale signature is the Contra tab disagreeing with the Contra column, never the three columns disagreeing with each other. So do not spend time adding the three columns up — they are written together in one update and they will balance. Open the tab and count the rows against the column: that is the comparison that catches it.

The same update also stamps the invoice’s Updated By and Updated Date with whoever applied the knock-off. So an invoice nobody edited can show a change today by the person who took the payment — that is the settlement landing, not somebody altering the invoice.

How you know the fix held

Whether you applied a missing contra yourself or support corrected a header, three things should now be true, and the Outstanding Document Report shows all three in under a minute. Take a GadgetSphere (GS) corporate customer with one invoice of RM 3,180.00 and one receipt of RM 3,180.00 that never got its contra: before the fix the report lists the invoice at a Balance of RM 3,180.00 and the receipt at −RM 3,180.00.

1. The pair is on both documents. The receipt’s Contra tab names the invoice and the invoice’s Contra tab names the receipt, for the same amount with opposite signs.
2. Each Contra column equals its own tab’s total — the comparison above, now agreeing.
3. The customer’s total did not move. Add the customer’s Balance column up before and after: RM 0.00 both times (RM 3,180.00 − RM 3,180.00 before; both rows at zero after, and gone altogether when the report is filtered to outstanding documents only). A contra moves the invoice’s Balance down and the receipt’s up by the same amount, so in ringgit it never changes what the customer owes in total. If the total moved, something else happened in between — a document was finalised, voided or edited.

What each number actually is

Doc Open is the document’s own face, and it is set once

When a document is created, BigLedger walks its lines and sorts them into two kinds:

• the lines that charge — the goods, the services, the tax;
• the lines that collect on the spot — the settlement methods, the cash and card taken at the counter as part of the same document.

Doc Open is those two added together. A cash bill that charged RM 2,400 and took RM 2,400 in card at the till opens at zero and is finished the moment it is raised. An invoice that charged RM 2,400 on credit and collected nothing opens at RM 2,400.

A sales return refunded on the spot is the same shape with the signs reversed: the goods lines carry a minus, the refund line on its Payment tab a plus, and Doc Open is zero. One return shape is worth recognising on sight — a return whose Doc Open is exactly twice its value, with Final refusing ARAP balance must be 0 although the refund is plainly there. That is not a contra problem. The return reached BigLedger through the API or an integration with its refund line typed as a sales return rather than a payment, so on creation the refund took the goods’ sign and added to the balance instead of cancelling it. Open the return and save it once: the save re-types the line and the balance drops to zero. The repair runs on update, never on create, which is why the screen’s own returns never show it and imported ones can.

It is recalculated whenever the document itself changes, and at no other time. No part of the settlement machinery ever writes to it. So if you are watching Doc Open for a payment to land, you will watch for ever, and correctly.

That distinction has a practical edge worth knowing, because “knock off” is used in the business for both of them:

Two different mechanisms, one everyday word. Most “the balance did not change” questions are this sentence.

There is a third thing the business calls a knock-off, and it has nothing to do with money: the quantity an invoice takes off a sales order, kept in its own stored row and read by the KO For tab and by available stock. It has its own page — the order still shows a quantity outstanding — and its own background job; nothing on this page moves it, and nothing there moves a balance.

Contra is a mirrored pair, not an entry

A settlement between two documents is stored as two rows, linked as a pair: one filed against the invoice, one against the receipt, with the amount negated on the second so each document sees the movement from its own side. That is why both documents’ balances move from one action, and why you will find the same settlement listed on the Contra tab of each.

The document’s Contra figure is then re-summed from those rows — every active contra it takes part in, added up again from scratch. It is not nudged up and down. That matters for the one failure mode on this page: because it is a re-sum, a single missed refresh does not corrupt anything permanently. The next settlement against the same document recomputes the whole figure and puts it right — and so does any save the document itself still accepts, because the AR/AP figures are re-derived from the lines and the contra rows on every save.

Who writes the pair, and when. Not the Finalise job chain. When you tick invoices on a receipt voucher’s Contra tab and press Save or FINAL, the applet waits for that call to come back and then sends a second request carrying the rows you ticked; the backend writes each pair and refreshes both documents’ figures inside that second request, and the screen shows the new balance when it returns. The cashbook line and the journal, by contrast, are posted by background jobs a moment later. Two things follow. The contra is on the screen before the journal is. And a contra keyed on a draft voucher and saved is live at once — the invoice reads as paid by a receipt that has not been finalised yet, which is worth knowing before you leave a draft sitting overnight.

One more thing that request does quietly: a contra dated earlier than either document is moved to the later document’s date before it is written. Key a March settlement against an invoice dated in April and the contra is an April contra, whatever the date box said — which is the right answer for the aging, and a surprise the first time you look for it in March.

The one settlement that does post to the ledger

Everything above is true of a settlement between two documents in your own currency, and there the general ledger is never touched by the knock-off: the receipt’s own journal already credited the customer when it was finalised.

A foreign-currency invoice is the exception, and it is the only one. When the same second request writes a contra and either document is in a currency other than your company’s, the backend also posts a journal for the realised exchange difference, inside that same request, before the response comes back. The arithmetic is the settled amount valued twice — once at the invoice’s own stored rate, once at the settling document’s — and the difference is the entry: a gain is credited to your company’s Forex Gain account and debited to the customer’s control account, a loss the other way. If the two rates are identical the difference is zero and no journal is written at all.

Three things about that journal are worth knowing before you go looking for it. It carries the document’s transaction date, not the settlement’s, so it lands in the invoice’s month. It is recognisable only by the contra it belongs to — there is no button on any screen that produced it. And if your company has no Forex Gain or Forex Loss default account set up, the order of events matters: the pair is saved and both balances are rewritten first, and only then is the journal built — a line whose account is missing is dropped, and the request fails with no journal created (or total debits and credits not balanced, when one of the two lines found its account). The screen shows the red Documents contra unsuccessfully toast, yet the contra is on the Contra tab and the invoice reads as paid; what is missing is the exchange-difference journal. Ledger And Journal’s Error Checking › Missing Journal Forex Gain Loss tab lists receipts and payment vouchers left in that state. Set the two default accounts up before the first foreign settlement, and do not key the contra again after that toast without opening the Contra tab first.

There is no period-end revaluation to go with it. BigLedger recognises exchange differences when a document is settled and at no other time; nothing sweeps open foreign balances at a month end and nothing posts an unrealised gain or loss.

Balance is simply the two added together

Balance = Doc Open + Contra. There is nothing else in it — but the two halves have different owners. Doc Open belongs to the document and changes only when the document itself is edited. Contra belongs to the settlement: applying or voiding a contra re-sums the contra rows and rewrites Contra and Balance together, and never touches Doc Open. So when a Balance looks wrong, first ask which half moved. A wrong Doc Open is a document problem (a line missing, a sign wrong, a refund typed as a return); a wrong Contra is a knock-off problem, and the rest of this guide is about those.

Every “as of today” report — Outstanding Document, Aging, Statement of Account — reads this figure straight off the document, live. It is not a snapshot and it does not go stale with age.

(The historical aging reports are a different matter entirely, and that is the next page along.)

Where else these figures are read, and what a missing contra disturbs

Three other parts of BigLedger read Balance or the contra rows behind it, and a missing contra reaches each of them differently — which is worth knowing before you decide how urgent the repair is.

• The credit check at FINAL. Where you have switched on the optional credit-limit check on sales orders and invoices, it depends on the sum of Balance across every finalised document the customer has in that company (Deciding on credit). A receipt that lost its contra still carries its own minus balance, so the customer’s available credit comes out the same with or without the contra; only the per-invoice view is wrong.
  • The case that does disturb it runs the other way: a contra keyed on a draft receipt lowers the invoice’s Balance at once, while the draft receipt, not being final, is left out of the sum — so until the receipt is finalised or the contra removed, the customer has credit for money nobody has confirmed.
• Collection Invoice with Aging, the Debtor Report’s record of how long customers took to pay, is built from the contra rows themselves rather than from balances. A receipt with no contra is absent from it, and so is its invoice unless something else was knocked off against it — so a salesperson’s collections read low by exactly the missing knock-offs, for as long as they stay missing.
• The month-end aging history. Every contra keyed on a Contra tab rebuilds the stored month-end aging of the documents it touches, from the document’s own month up to last month, counting the contra only in months ending on or after its date. So the date on the contra, not the day you keyed it, decides which months show the invoice as paid — see Before you re-apply a missing contra, check its date.

Four ordinary reasons Contra reads lower than you expected

The second request never got through. Because the contra travels in its own request after the finalise, it can fail on its own: the login lacks the contra permission, the session had expired, the network dropped, the tab was closed the moment FINAL came back. The applet shows a red toast — Documents contra unsuccessfully — for about a second, and does not retry. What you are left with is a receipt that is FINAL, has its cashbook line and its journal, and has no contra: the customer’s total on the Statement of Account is right, the invoice is still open, and the receipt sits on the statement as an unapplied credit. Open the receipt’s Contra tab: if it is empty, apply the contra there (or from the Debtor Report’s Contra tab). A finalised receipt carrying a balance and no contra is also the perfectly normal shape of a deliberate payment on account, and a failed second request leaves exactly the same shape — which is why the receipt’s own Contra tab is the check, and a list of unapplied receipts is not.

The amount rounded to nothing. Settlement amounts are rounded to two decimal places before anything is written, and a row that rounds to exactly zero is dropped silently. A one-sen residual you tried to clear this way simply is not there.

You settled a different document. The invoice and the receipt each have their own Contra tab. If you cannot find the pair on the invoice, look at the receipt — it will name the document it was actually applied to.

Somebody unwound it. Voiding the receipt deletes the contras and recomputes both documents' balances, so an invoice goes back to outstanding. Voiding the invoice does the same from the other side — every contra on either side of it goes, and the receipt that paid it becomes an unapplied credit again. That is the void working — see What a void undoes. A login holding the delete contra permission can also remove one settlement from the voucher’s Contra tab without voiding anything: the pair is deleted, both documents are re-summed, and if the contra was back-dated the aging months it touched are rebuilt. It does not announce itself anywhere except the Contra tab.

Before you re-apply a missing contra, check its date

Re-applying the contra puts every “as of today” report right at once. The month-end history is a different matter, because it counts a contra only from its date. On the receipt voucher’s Contra tab, with the applet’s settings as they come, the Contra Date box is locked and the contra is dated the day you save it. Apply in May a RM 3,180.00 receipt that arrived on 20 March, and the March and April month-end aging keep showing the invoice open and the receipt as unapplied credit — on those dates, as far as BigLedger knows, the two had not met. The customer’s Statement of Account ages it the same way, by the contra’s date.

Two receipt-voucher settings change that (Receipt Voucher (Internal), Contra date): one dates every new contra on the receipt’s own date, the other unlocks the box so any date can be keyed. Which a group should run is a policy choice, and each option has a cost:

• Date every contra on the receipt’s date. The history is right for the ordinary late knock-off without anyone choosing a date; a receipt applied to an invoice raised after it is moved forward to the invoice’s date by the rule above. Nobody can pick a date deliberately.
• Unlock the box. You can repair the history exactly, and so can anyone else with the applet: a settlement can be dated into a month you have already reported, which rebuilds that month’s history.
• Leave it as it comes. Nothing to configure; every late knock-off leaves the months in between showing the invoice open and the receipt unapplied — the customer’s total right, the ageing wrong.

Whichever you run, the person who re-applies a missing contra is the one who checks the date on the row before saving it.

What you see, and what to do

When it is a support matter

The signature is the Contra tab disagreeing with the Contra column. Add up the rows on the tab; if they come to more than the column shows, the rows were written and the header was not refreshed. (Doc Open plus Contra will still equal Balance — the two are written together, so a missed refresh leaves them consistent with each other and wrong together.) Report it in those words, with the two totals and the document number.

Here is why it happens, so you can recognise the shape rather than guess at it.

When a settlement is created, the contra rows are written and then each affected document’s balance is recomputed inside the same call — there is no queue and no delay, which is why a knock-off normally shows on the screen the instant you save it. But the two ways of creating one behave differently when that recomputation fails:

• Settling several documents in one go saves the pairs first, in a step of their own, and then refreshes each document. If a refresh fails, you get an error — but the pairs are already saved, and every document whose refresh succeeded shows the settlement. So an error here does not mean nothing happened: the document whose refresh failed carries exactly the stale signature above. The server checks a new pair for its documents and a non-empty amount, not against the balance left or a pair already saved, so keying it again can put a second settlement on top of the first. Open the Contra tab before you retry.
• Settling a single document logs the failure and carries on. The contra rows are committed and the header keeps the balance it had. Nothing on your screen says so, and nothing sweeps it up afterwards — there is no watchdog that re-selects documents whose balance disagrees with their contra rows.

Voiding a settlement behaves the same way as the single path.

Which path you are on is decided by the screen, not by how many invoices you ticked: every Contra tab in the voucher and report applets sends the settle-several path, even for one invoice. The settle-single path is behind no button — it is what the receipt file import, the JSON document import, the payment-gateway callback and a background job call. So a settlement that a person keyed is never silent — when the refresh fails, the screen says so, even though the pair may already be saved; the half-write that nobody is told about belongs to integrations and imports.

There is a queue table for exactly this recomputation, with a registered processor and a sweeper that polls it — and nothing has ever written a row to it. Every live tenant has the table and every one of them has it empty. So the recomputation is inline in the request or it does not happen; there is no “async recalculation stuck” to wait for, however natural that reading of the symptom is.

Because the figure is a re-sum rather than a running total, the damage does not compound, and the next settlement against the same document will correct it by itself. If the document is finished and no further settlement is coming, it needs a correction — the customer’s own word for it is a data fix — and that is a request, not a button.

What this page cannot tell you

• Whether your tenant has a stale row right now. Nothing in the product lists documents whose balance and contras disagree. The arithmetic above is the only check available from a screen, and it works one document at a time. So the sweep for the commoner case — a receipt that never got its contra — is a person’s job: whoever keys receipts, at each month end before the month-end aging is taken on the 1st, reads the minus balances on the Outstanding Document Report — the receipts and credit notes not yet applied — and opens each one’s Contra tab. You are done when every receipt left with a balance is one a customer asked you to hold on account.
• How to unwind part of a settlement from a screen. Reducing a contra without removing it exists as an API operation, gated on an administrator permission, with no screen behind it. From a screen the choice is to leave it, remove it whole (the voucher’s Contra tab, with the delete-contra permission), or void the voucher.
• Why the historical aging still shows the document. That is a different stored figure with a different refresh rule — the aging still shows an invoice that’s already paid. A back-dated settlement does trigger a rebuild of the months it affects, but only on the settle-several-at-once path.
• Whether the underlying amount is right. All this tells you is which of the three numbers you are reading and whether they agree with each other.

Related documentation

• Debtor Report applet and Creditor Report applet — where the three columns appear, which reports read them live, and the Contra tab that creates and lists settlements.
• Debtor and Creditor Report applet — the same figures, read-only, with the historical reports beside them.
• Recording a customer payment — the receipt voucher end to end: settlement method, cashbook and knock-off.
• What a void undoes — what happens to these figures when a settlement or a document is cancelled.
• Which figures BigLedger stores, and which it works out fresh — the same trade-off in the other five places it appears.