A/R aging
ar_agingWho owes you money and how overdue it is — accounts-receivable aging across ALL customers, bucketed by age. For the unpaid invoices of ONE named customer, use open_invoices. WHAT A ROW IS: the RECEIVABLE each document created on the accounts-receivable control account, less what has been received against it by asOf — never the document's gross total. UNMATCHED PAYMENTS: a customer payment not yet (fully) applied to invoices — a bank receipt posted to a customer, or money recorded on Sales → Official receipts → Receive payment (into a bank or Cash) beyond what the invoices took, or a payment applied only in part (its row is what is left) — is already inside that customer's bucket figures and total as a NEGATIVE amount (money you hold for them), aged from the date it arrived, and is listed under the row's unmatchedPayments (bankTransactionId, date, amount, bucket, kind). kind says what it is: payment (money in, not yet applied — negative; suggest applying it to invoices rather than treating the invoice balance as unpaid: the owner does it in Banking → Match, which can apply part of it, or on Sales → Official receipts → Receive payment, which lists the customer's credit — a payment received in Cash only there), refund (money paid out to the customer, not yet matched — positive), or booked_outside (the bank line was matched to invoices for MORE than it booked to accounts receivable — e.g. posted to an income account first — so the invoices read settled while the control account still holds that amount; positive; the fix is on the bank line). A payment that IS matched, but to an invoice dated after asOf — a deposit the customer paid before the invoice was raised — is listed here too, kind payment, with paysLater ([{reference, date, amount}]) naming the invoice(s) and the date it pays them: it sits on the customer's account until that date and applies then, so do not suggest matching it. unmatchedPaymentsTotal is their sum, less the paysLater part (that part is paysLaterTotal), and documentTotals the buckets of the documents alone — quote documentTotals for what is OVERDUE, totals for the balance. So a row's total is what the customer owes NET, a row can be negative (they have paid ahead), and a customer can appear with no invoice at all. With them, this report equals the control-account balance to the cent, except for entries that belong to no document or bank line: a manual journal posted straight to the control account, the period-end unrealized FX revaluation (on its own date only — it reverses the next day), and a bank line whose allocations were saved but which is not posted yet. If an owner asks why the two disagree, look for those before doubting either figure. The document universe itself differs on purpose wherever the gross was never collectable: a cash or gateway-paid sale posts no receivable at all and is absent; a marketplace order reads the NET PAYOUT the channel owes (gross less the platform fee it withheld, whether that fee was known at import or only booked later from the settlement); a credit note nets its customer down; and an invoice reversed by a channel return reads nil. So a figure here can legitimately be LOWER than the same invoice's total in search_documents or on its PDF — say which you are quoting rather than treating one as an error. Movement booked after asOf is excluded, so a back-dated aging shows what was owed on that date.
Tool call template
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "ar_aging"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| asOf | No |