Accounts receivable aging groups outstanding invoice balances by days past their payment deadline. Finish with a fixed-date worksheet that reconciles every positive balance, keeps unknown due dates visible and separates customer credits.
Updated: 29 October 2026.
What does an aging worksheet establish?
Accounts receivable is money customers still owe for goods or services supplied. Aging describes how those outstanding amounts are distributed across payment deadlines. It does not establish whether a customer will pay, what legal action is appropriate or how much a business should provide for bad debts. Keep that limited question in the report title.
Choose a fixed reporting date before calculating. Our exercise uses the end of 29 October 2026 and due-date aging, rather than invoice-date aging. All dates use the same local calendar and all amounts use one currency. A payment received the following day must not silently change the balance that existed at this cutoff.
Every identifier and amount below is fictional training material, not an Anar client ledger or a collection result. Arithmetic and saved output were checked programmatically. No bank connection, accounting application or desktop user trial was operated. The customer concentration exercise asks who generates sales; this worksheet asks how long verified invoice balances have been past due.
Confirm outstanding balances before assigning age groups
Prepare one record per uniquely identified invoice, with customer, currency, payment deadline and verified outstanding balance at the cutoff. Age the remaining balance, not the original face amount. Payments and credit adjustments reduce it only when they were effective by the cutoff and genuinely assigned to that invoice.
Fictional invoice I5 originally totals 600. A verified payment of 200 and an approved credit adjustment of 100 were effective by the report date. Its remaining balance is therefore 300. A further payment of 100 dated 30 October does not reduce the 29 October snapshot. A request for a discount is not the same as an approved credit adjustment.
I5 original600 − eligible payment200 − approved credit100 = open300 Later payment100 dated30October: excluded from29October snapshot
This is not another payment-allocation tutorial. Start with balances whose allocation is already verified. If a receipt cannot be connected to an invoice, return to the partial-payment matching exercise rather than guessing. Preserve source versions and the population covered so a reviewer can distinguish a complete register from a selected sample.
Declare non-overlapping day boundaries
Calculate calendar days as report date minus the agreed due date. A bill due on the report date has day difference zero and belongs in Current under this exercise’s policy. A future deadline also belongs in Current. Weekends are not removed: this is a calendar-day classification, not a business-day or contractual penalty calculation.
| Group | Day difference | Boundary |
|---|---|---|
| Current | Zero or negative | Due today or later |
| 1–30 | 1 through30 | Includes30 |
| 31–60 | 31 through60 | Includes60 |
| 61–90 | 61 through90 | Includes90 |
| 91+ | 91 or more | Includes91 |
| Unknown due date | Not calculated | Retain amount separately |
These intervals are a declared reporting policy, not a universal legal standard. Xero describes this style of overdue grouping. Zoho documents date bases and configurable aging periods, with defaults that differ from our thirty-day intervals. Record the actual policy instead of assuming every accounting package produces the same columns.
Test the edges explicitly. Day thirty belongs in the first overdue bucket, while day thirty-one belongs in the next. Repeat that check for sixty versus sixty-one and ninety versus ninety-one. A condition using greater than thirty is different from one using thirty or more. Small wording changes can move an entire invoice balance.
Classify the supplied invoice snapshot
| ID | Due date | Open amount | Days | Group |
|---|---|---|---|---|
| I1 | 2026-10-31 | 100 | -2 | Current |
| I2 | 2026-10-29 | 200 | 0 | Current |
| I3 | 2026-10-28 | 150 | 1 | 1–30 |
| I4 | 2026-09-29 | 250 | 30 | 1–30 |
| I5 | 2026-09-28 | 300 | 31 | 31–60 |
| I6 | 2026-08-30 | 400 | 60 | 31–60 |
| I7 | 2026-08-29 | 500 | 61 | 61–90 |
| I8 | 2026-07-31 | 600 | 90 | 61–90 |
| I9 | 2026-07-30 | 700 | 91 | 91+ |
| I10 | Unknown | 800 | Unknown due date |
I5 contributes its verified remaining 300, not its original 600. The part payment does not restart the due-date clock in this exercise. A formally changed deadline would need its own evidence and version. A customer’s later promise to pay should not quietly overwrite the original deadline used in a historical report.
I10 has a verified positive balance but no due date. Placing it in Current would make the report appear more comfortable without evidence. Placing it in the oldest bucket would invent lateness. Keep the 800 in an explicit unknown-date column and assign someone to find the missing document. Use the team decision log to retain that question, owner and review date.
A fully settled invoice with zero outstanding can remain in a separate reference list. It does not contribute to positive open balances. Keeping its history visible is different from treating a missing payment record as proof that the invoice remains unpaid.
Reconcile the buckets to the complete positive balance
Current is 100 plus 200, or 300. Days one through thirty total 150 plus 250, or 400. The next bucket totals 300 plus 400, or 700. Days sixty-one through ninety total 500 plus 600, or 1,100. The oldest group contains 700. Known-date balances therefore total 3,200; adding the unknown-date 800 gives 4,000.
Known-date groups:300+400+700+1100+700=3200 Known-date3200 +unknown800 =positive open4000 Known overdue:400+700+1100+700=2900
Do not label 2,900 the exact overdue amount for the entire population. I10’s status is unresolved. Under this simple classification, total overdue could range from 2,900 to 3,700 depending on that missing deadline. This is a completeness bound, not a probability distribution or expected-loss estimate.
Suppose a separate verified customer credit has a negative-fifty balance. Keep it outside the positive aging groups. Positive open balances remain 4,000; the separately disclosed credit is negative fifty; the simplified register’s net control is 3,950. Do not automatically apply that credit to the oldest invoice or another customer. The profit margin calculation cannot be derived from these receivable totals.
Which exceptions prevent acceptance?
A repeated I5 must not add another 300. If the identifier and values match, flag a possible duplicate import. If values differ under the same identifier, preserve the conflict and ask the source owner which record is authoritative. Define the unique key first: unrelated customers may legitimately use the same invoice number, so an invoice label alone may not identify the transaction.
Do not combine euro and dollar balances in one money total. Our fictional ledger has one currency; a new currency needs a separate worksheet unless an explicit conversion policy and rate date are supplied. Invalid dates, missing amounts and an undefined reporting cutoff block acceptance. A valid amount with an unknown due date remains visible in its own group instead of disappearing.
Negative balances can represent credits or overpayments. Do not clamp them to zero and conceal them. Nor should you offset another customer’s positive balance without authority. Aging is not an instruction to write off debt, calculate provisions or initiate legal collection. An old invoice is not automatically uncollectible, and a current invoice is not guaranteed future cash. A dispute may also require review without changing its arithmetic age.
Save a handoff with inputs, controls and unresolved items
On Windows, search Start for Notepad and create a blank document. Open Calculator from Start separately to check the money totals. Title it “Fictional aging V1, end of 29 October 2026, one currency, due-date basis”. Copy the ten source rows, I5’s remaining-balance explanation and the interval rules. A text editor records the calculations but does not execute them; independently verify the supplied date differences.
Positive open4000; known-date3200; unknown800 Current300;1–30:400;31–60:700;61–90:1100;91+:700 Known overdue2900; unresolved-date bound2900–3700 Separate credit−50; net control3950; settled reference0 I5:600−200−100=300; later payment100 excluded Next evidence:confirm I10 due date
In Notepad, choose File → Save As, select Documents and save aging-review-V1.txt. Use a different version name if it exists; do not overwrite another file. Close Notepad, open Documents in File Explorer and reopen the saved file. Find all ten source rows, the four-thousand control and the missing-date exception. In a separate test copy, check the thirty/thirty-one and ninety/ninety-one boundaries and the repeated identifier.
Fifteen minutes is a suggested work window for this supplied example, not measured reader performance. Leave the handoff with one concrete evidence request, such as confirming I10’s deadline. When moving to a cash-flow plan, record expected receipt dates separately. An aging category does not tell you when money will arrive or what is currently in the bank.
Frequently asked questions
Is an invoice due today overdue?
Under this exercise’s policy, day zero belongs in Current. The following unpaid day becomes one day overdue.
What does a part payment change?
An eligible, verified allocation reduces the outstanding balance at the cutoff. It does not automatically restart the due date.
Where should a missing due date go?
Keep the verified amount in an explicit unknown-date group. Do not invent Current or overdue status.
Does the oldest bucket mean the debt is lost?
No. It records an overdue interval under the declared policy, not a loss probability or write-off decision.


