> ## Documentation Index > Fetch the complete documentation index at: https://docs.garmentflow.ai/llms.txt > Use this file to discover all available pages before exploring further. # Aging buckets > The five age bands GarmentFlow uses to classify every open receivable and payable, the date the rule is read from, and the per-currency sub-total rule that keeps balances in their own money. Every open balance on the [Receivables](/modules/receivables) and [Payables](/modules/payables) boards is placed into an **aging bucket** — a band that says how long the balance has been outstanding. This page is the canonical definition of those buckets: the bands, the date the rule reads from, and the rule that keeps the sub-totals per currency rather than blended. ## What an aging bucket is An aging bucket is a single label, attached to a document, that says how far past its due date the document currently sits. A document moves through the bands as time passes — a freshly raised invoice sits in the first band on the day it is issued, and ages into a later band as days pass without being settled. The bands are the same for receivables and for payables. They are read off the same rule. They are the bands shown on the [Statement of Account](/modules/statement-of-account) and on the workspace's aging reports. ## The five bands A document is placed into one of five bands by counting how many days have passed since its **due date**. A document whose due date is today, or in the future, sits in the first band; a document a year past its due date sits in the last. | Band | What it covers | | --------------- | ------------------------------------------------------------------- | | **0–30 days** | Documents that are not yet due, or up to 30 days past the due date. | | **31–60 days** | 31 to 60 days past the due date. | | **61–90 days** | 61 to 90 days past the due date. | | **91–180 days** | 91 to 180 days past the due date. | | **180+ days** | More than 180 days past the due date. | A document with no due date — for example a vendor invoice recorded without one — is treated as not yet overdue and counted in the first band; it stays there until a due date is set on it. ## What "due date" means here The aging rule reads the `Due Date` on the document itself — the date the document is expected to be settled by. It is not the date the document was raised, not the date of the underlying order, and not the date of any related shipment. For customer invoices, the due date is the date the customer is contracted to pay by, set from the order's payment terms when the invoice is issued. For vendor invoices, the due date is the date the workspace is contracted to pay the vendor by, set from the vendor's terms or the purchase order. A document moves from one band to the next as days pass; the date is re-read each time the board is opened, not frozen at any earlier moment. ## Per-currency sub-totals A workspace that invoices and pays in more than one currency carries a real question every time it reads an aging: *how much is owed (or owing) in each currency.* GarmentFlow answers it by keeping the sub-totals per currency rather than blending them. Every aging band, on both the receivables and the payables side, carries a breakdown of its outstanding amount by currency. A band that holds a USD invoice, a EUR invoice, and a TWD invoice reports three sub-totals — one per currency — not a single figure converted into the workspace's reporting currency. The rule applies the same way to the grand totals above the detail tables on the [Receivables](/modules/receivables) and [Payables](/modules/payables) boards: each currency's total is reported in that currency. ### Why it works this way Foreign-exchange rates move. A USD receivable booked at 31.00 TWD/USD and a USD receivable booked at 32.50 TWD/USD are still two USD-denominated debts — they are owed in USD and will be received in USD. Blending them into a single TWD figure at any one rate would tell the team a number that is neither owed nor receivable: it would be a snapshot of the workspace's exposure at a point in time, not the working balance for collections. Keeping the sub-totals per currency means: * **The team can read a balance the way it will be settled.** A USD invoice is owed in USD, and the per-currency total shows USD. * **A rate change does not silently rewrite a balance.** A blended TWD figure would jump every time a FX rate changed; a per-currency figure does not. * **Foreign-exchange gains and losses live where they belong.** The difference between the booking rate and the payment rate of a foreign invoice is recorded on the foreign-exchange side of the [finance ledger](/concepts/finance-ledger), as its own entry. It is not folded back into the counterparty's outstanding balance. A workspace-reporting-currency grand total is still available on the boards for the rare case where a single figure is needed — it is computed at the rate each document was booked at, not at today's rate. ## Where the bands are shown The bands surface on every Finance view that ages money: * **The [Receivables board](/modules/receivables)** — five summary cards across the top, and a `Bucket` column on each row in the detail table. * **The [Payables board](/modules/payables)** — five summary cards across the top of the factory-grouped detail. * **The [Statement of Account](/modules/statement-of-account)** — the customer-facing statement carries the `Due Date` on every charge row, so the customer reads the same aging the team does. * **The aging reports** under the Finance module's **Reports (報表 / 报表)** tab — the same bands, broken out by customer or vendor. The bands and the per-currency rule are shared across all of these. A row that sits in the **91–180 days** band on the Receivables board sits in the same band on the statement the customer sees, and on the aging report finance runs at month-end. ## Related pages * [Receivables](/modules/receivables) * [Payables](/modules/payables) * [Statement of Account](/modules/statement-of-account) * [The finance ledger](/concepts/finance-ledger) * [Finance module](/modules/finance)