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 bank receipt posted to a customer but not yet matched to an invoice 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 matched — negative; suggest matching it to invoices rather than treating the invoice balance as unpaid), 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). unmatchedPaymentsTotal is their sum 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.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| asOf | No |