The aging still shows an invoice that's already paid

“The aging still shows an invoice I have already paid” — almost always the invoice is right and the report is simply out of date: the aging is last month’s photograph, taken at 01:00 on the 1st, and your payment landed after it was taken.

You received the payment. The invoice itself shows a zero balance. And the aging report still lists it as outstanding. The invoice is not unpaid, and no transaction is missing.

The fast path (the full check):

Open the invoice and read its own balance. It is rewritten in the same instant a settlement is created or voided, so if it says zero, the document is right. If it still shows the full amount, the report is right too: no payment is applied to this invoice now, so read I knocked it off and the outstanding balance hasn’t changed instead.
Look at which month you asked the report for. The current month is worked out live; any earlier month reads a row stored at the start of the following month.
For money you are chasing this week, run the “as of today” Outstanding Document, Aging or Statement of Account. They read each document’s live balance and are never stale.
Before you ask for a past month to be rebuilt, read the knock-off’s Contra Date on the receipt. A knock-off dated after the month-end counts after it, and a rebuild would change nothing. Do not re-date a knock-off in place. For one knock-off in a month nobody has reported yet, delete it and key it again with the receipt’s date, provided the applet lets that date be chosen and your login may delete a knock-off.

The 30-second check

1. Open the document itself and read its own balance. Every invoice, bill and credit note carries a running balance: what it was raised for, what has been settled against it, and the remainder. That balance is rewritten in the same instant you create or void a settlement — before the screen comes back. If the document says zero, the document is right.

If it still shows the full amount, this page is not your answer. The receipt has no contra against the invoice now (none was made, or one was deleted since): it carries a minus balance and an empty Contra tab, and the invoice stays open in every month, the current one included. A rebuild changes nothing there. Ask whoever took the payment whether it was a deliberate payment on account, then apply it on the receipt’s Contra tab, checking its Contra Date first: a contra dated before last month-end rebuilds the stored months it reaches (Before you re-apply a missing contra, check its date; the other causes are on I knocked it off and the outstanding balance hasn’t changed).

2. Look at which month you asked the report for. This is the dividing line, and it is not labelled anywhere on the screen:

Ask an aging report for the current month and it works the figure out live, from the documents.
Ask it for any earlier month and it reads a stored row that was written at the start of the following month.

The same screen switches engines under you without saying so.

3. Run the same question as an “as of today” report. Outstanding Document, Aging and Statement of Account all read each document’s own live balance. They are never stale. If the invoice has gone from those and is still sitting in the historical view, you have your answer and you can stop looking.

4. On the receipt, read the knock-off’s Contra Date. A stored month counts a knock-off from its own date, which is not always the receipt’s date. If the knock-off is dated after the month-end you asked for, that month is telling you the truth about that date: the invoice still open, and the receipt beside it as money received but not yet applied. Add the two and the customer’s total for the month is right. Only the listing surprises you.

What actually happened

A scheduled job runs at 01:00 on the first of each month. It takes every document that still has a balance, and writes one row per document stamped with the last day of the month that just ended. That row is what the historical aging reports read.

Three ordinary things change a month after it has been written:

A knock-off keyed or deleted on the receipt voucher’s Contra tab. Both documents’ rows are worked out again for every month-end from each document’s own month to last month, counting the knock-off only in months that end on or after its Contra Date.
Finalising a document dated in a month already photographed, on tenants that subscribe to the back-dated aging step: that document’s row is added, corrected or removed for each month-end from its date to last month.
Voiding a document. Its rows leave every month, past and present.

Two details explain what these reports show:

A document already settled when the job runs gets no row at all for that month. The job only photographs documents with a balance left on them.
A row, once written, is never corrected by the monthly job. It will not overwrite what is already there for that document and that month-end.

Put those together and the symptom explains itself. GadgetSphere Distribution Sdn Bhd invoices a corporate customer RM 12,480.00 on 18 March for a batch of ultraportable laptops. The customer pays by bank transfer on 28 March. You key the receipt on 4 April, date it 28 March — ordinary and correct — and knock it off against the invoice on the receipt’s Contra tab. At 01:00 on 1 April the invoice was still open, so the March row says RM 12,480.00 outstanding. The knock-off then works March out again for both documents, counting it from its Contra Date, and that date depends on how you picked the invoice. Ticked and added from the Contra list, with the Receipt Voucher applet’s settings as they come, its Contra Date is 4 April, the day you saved it, unless you typed 28 March in the Contra Date column. So March keeps the invoice open at RM 12,480.00 and adds the receipt beside it at minus RM 12,480.00. Meanwhile the document, and every “as of today” report, correctly shows it settled. Clicked to open the Add Contra form instead, the knock-off starts from the invoice’s own date, 18 March, unless your administrator has switched on EDIT_CONTRA_TXN_DATE; on saving, a date earlier than the later of the two documents is moved forward to it, so the knock-off is dated 28 March and March shows the invoice paid.

Neither screen is wrong. They were asked different questions.

Why a month-end is stored rather than worked out each time

Look at what the arrangement gives you. A month-end position you have already sent to someone does not move because a payment arrived later: the monthly job never overwrites a month. The only things that reach back into a month are corrections that name a date inside it — a back-dated knock-off, a back-dated document, a void. And “what is owed today” is already answered live, by the “as of today” reports. The stored month answers the other question: what did the ledger say was owed on that date.

In the case above the month is not even wrong in total. The receipt’s own journal is dated 28 March, so the ledger counts the payment in March either way; and the stored March month, carrying the invoice and the receipt at opposite amounts, comes to zero for that customer. The total is right. Only the listing is not.

What to do about it

What you are doing	What to read
Chasing money this week	The “as of today” reports — Outstanding Document, Aging, Statement of Account. Live, never stale.
Reporting a position at a past month-end	The historical aging, which is the photograph — and only useful if a photograph was actually taken that month.

If a past month genuinely has to be right — because it is going to an auditor, or because it is the basis of a provision — the stored month has to be rebuilt, and that is not a button in the reporting applets. It is a request.

Which corrections reach a past month, and which leave it as it was

Before you ask for a rebuild, know which kind of correction you made. The document’s own balance always follows; the stored months follow only some of them.

What you did	The stored months
Knocked it off on the receipt voucher’s Contra tab	Worked out again for both documents, counting the knock-off from its Contra Date
Deleted a knock-off on the Contra tab	Worked out again the same way, for both documents
Changed a knock-off’s Contra Date after saving it (the box opens only when the applet is set to allow it)	Left as they were — and only the receipt’s half of the knock-off takes the new date; the invoice’s half keeps the old one
Voided the receipt	The receipt leaves every month; the invoice it paid keeps whatever its stored months said
Let something else make the knock-off — a receipt file import, an integration, an online payment, a marketplace settlement	Left as they were

The first two are the ones you can steer. The rest leave the months as they were until somebody works them out again: either a rebuild of the month, or — where a knock-off still exists — deleting it on the receipt’s Contra tab and keying it again, which is the first two rows in turn.

Do not re-date a knock-off in place. Changing the Contra Date moves only the receipt’s half, so the receipt and the invoice now disagree about when they met, and the next time either document’s months are worked out — a later knock-off, or a rebuild somebody asks for — the customer’s total for the months in between is out by the amount. If the date has to change, delete the knock-off and key it again with the right date.

If the knock-off is dated after the month-end

Here a rebuild would change nothing: it counts the knock-off by its date, exactly as the Contra tab did. Whether the month should show the invoice as settled is a policy question for your group, and the choice of how knock-offs are dated — on the receipt’s date, on the day they are keyed, or on a date somebody picks — is set out with its costs in Before you re-apply a missing contra, check its date. For one knock-off in a month nobody has reported yet, deleting it and keying it again with the receipt’s date puts both documents right — provided the applet lets that date be chosen and your login may delete a knock-off.

What you see, and what to do

What you see	What it means	What to do
The invoice is open in last month’s aging and the receipt sits beside it as a minus	The knock-off is dated after last month-end	Nothing, if that date is right; otherwise see the section above
The invoice is open in last month’s aging and the receipt is nowhere in that month	The knock-off arrived by a route that does not work months out again	Delete it on the receipt’s Contra tab and key it again, or ask for a rebuild of that month
Last month shows nothing owed, but the payment has since been voided	A void takes the receipt out of every month and leaves the invoice’s months as they were	Ask for a rebuild of the months between the payment and the void
The invoice is open in this month’s aging too, and the receipt carries a minus balance with an empty Contra tab	No payment is applied to the invoice now; no stored month is involved	Apply it on the receipt’s Contra tab, once you know it was not a payment on account (the four ordinary reasons)
Every month after a certain one is empty	The monthly clock stopped	See the caution below
The aging total and the receivables account differ by the same amount every month	Usually a manual journal posted straight to the receivables account, which has no document for the aging to read	Find the journal — that difference is not a stale month

How you know it worked

Run the historical aging for the month you corrected, for that one customer. If the knock-off is dated inside the month, the invoice and the receipt are both gone from it. If they are both still there with opposite amounts, the knock-off is dated after the month-end — the month is consistent with that date. If the invoice is there alone, the month was not worked out again: that is the support case below.

Before a past month leaves the building

Checking a stored month is still a person’s job, and the moment is before it goes to an auditor, a lender or into a provision for doubtful debts. Whoever signs off receivables for the month agrees the historical aging total for that month-end to the receivables account in the trial balance at the same date. A difference the size of one customer’s payment points to a knock-off whose months were never worked out again; a difference that repeats every month points to a journal with no document behind it. The aging is built from documents and the trial balance from journals, which is exactly why agreeing the two catches what either one alone would miss.

Check the photograph is being taken at all. The monthly aging job runs on a clock, MONTHLY_GENERIC_DOC_HISTORICAL_AGING_PROCESSOR, at 01:00 on the 1st. It has been one of the clocks a new tenant is created with since August 2025, so a tenant created before then has it only if BigLedger re-installed the default clocks or someone added it. Where the clock is missing or inactive, the historical aging simply stops at whatever month it last ran, and every month after that is blank rather than wrong. You can check for yourself: open the Scheduler applet and look for that code in the listing with Status ACTIVE. If it is not there, ask your BigLedger contact to add it.

Do not run it by hand to fill a gap. Whenever the job runs, it stores last month-end using the balances at that moment, and it never replaces a month it has already stored. Run it with Run Now in the middle of the month, or switch its clock on after a missed 1st, and last month-end is stored from today’s balances — including every payment received since — for good. Ask for a rebuild instead.

When it is a support matter

Two signatures, and it is worth reporting them in these words:

A past month still reads wrong after the underlying document was corrected. Some corrections reach the stored months and some do not: a knock-off keyed or deleted on the receipt voucher’s Contra tab works them out again for both documents, while a knock-off whose date was changed in place, a voided payment, or a knock-off made by an import, an integration, an online payment or a marketplace settlement updates the documents and leaves the months as they were.
The document shows a settlement applied and the history shows the same document at its full original amount — that is, the history has the invoice but not the offset against it.

Raise it with the two screen names, the two numbers, the company and the month. Naming the month is what makes a rebuild quick rather than open-ended. Say also whether the knock-off’s date was ever changed: a rebuild counts each half of a knock-off by its own date, so a re-dated knock-off needs its date put right before the month is rebuilt, or the rebuilt month comes out wrong in a new way.

What this page cannot tell you

The row does not say when it was taken. The last day of the month is on the report; the fact that it was written at 01:00 on the following day is not.
Rebuilding a past month’s aging is not self-service. No screen in the reporting applets offers it. Deleting a single knock-off and keying it again works the months out for those two documents only; a month for every customer is a request.
Whether the underlying figure is right is a question for the documents, not for this page. All this tells you is which of the two you are reading.