> ## Documentation Index
> Fetch the complete documentation index at: https://developers.getbreezyapp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Revenue, collections, and AR

> Keep issued invoice activity, received cash, and current receivables distinct.

| Measure           | Basis                                                     | Date                                      |
| ----------------- | --------------------------------------------------------- | ----------------------------------------- |
| Invoice activity  | Calculated invoice values; defaults to OPEN and PAID      | Invoice issue date                        |
| Collections       | Payments currently PAID minus refunds currently SUCCEEDED | Each payment/refund occurrence date       |
| Receivables aging | Current signed balance of OPEN invoices                   | Current company-local date                |
| Job profitability | Recorded costing subtotal minus saved costs               | [Costing report date](/job-profitability) |

## Start with a summary

```http theme={"theme":{"light":"github-light","dark":"github-dark"}}
GET /v1/reports/invoice-activity?start_date=2026-08-01&end_date=2026-10-01&bucket=month
GET /v1/reports/collections?start_date=2026-09-01&end_date=2026-10-01&bucket=month
GET /v1/reports/receivables-aging
```

Use [Dates, money, and identities](/conventions) for time buckets, grouping, and total calculations. All summaries are pageable.

## Worked example

| Example measure           | Expected amount                                                                                                                 |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Invoice 1001              | \$1,000 subtotal − \$100 discount + \$90 tax = \$990 total.                                                                     |
| Its current open balance  | \$990 − \$500 paid applications − \$100 processing applications = \$390.                                                        |
| Payment P-1001            | \$800 received once: \$500 applied to invoice 1001, \$300 to invoice 1002.                                                      |
| September collections     | \$800 received − \$50 successful refund = \$750. The \$100 processing payment and \$20 pending refund do not enter collections. |
| Invoice activity          | August: one invoice, \$990 total. September: two invoices, \$500 total and \$250 average.                                       |
| Current AR on September 8 | \$590: \$390 in 1–30 days overdue plus invoice 1003's \$200 due September 30 in current. Invoice 1002 is paid and excluded.     |

These dates and amounts describe the fictional example dataset. Live receivables aging always uses the current company-local date.

## Invoice amount basis

Invoice totals use the existing invoice pricing, discount, and tax-rounding rules. Lines expose both recorded unit prices and their rounded subtotal after any pricing multiplier. Discounts retain their configured flat amount or rate; the combined applied discount is in `amounts`. The discounted subtotal is floored at zero. Paid invoice applications use the latest payment status PAID; processing uses PENDING or PROCESSING. `open_balance_cents` is the signed remainder for OPEN invoices and zero for other statuses. Refunds do not automatically increase this balance, and this API does not invent invoice-level refund allocation.

A payment with no recorded status has `status: null`; its invoice applications also have `payment_status: null`. These records remain readable and contribute neither paid nor processing invoice amounts nor received collections.

## Collections and refunds

Received collections count only payments currently PAID. Refunded collections count only refunds currently SUCCEEDED. A later refund reduces the period of the refund, not the earlier payment period. Occurrence date supports backdating and is not bank settlement. Refund grouping by collector uses the original payment's collector. Collections do not support business-unit, job-type, or technician-participation grouping, because refunds have no recorded split across invoices.

Count each payment once, even if it is allocated across several invoices. Read `/payments` for the complete allocation set and `/refunds` for refunds on their own dates. Invoice payment applications explain invoice balances; they are not additional payments.

## Current receivables

AR groups OPEN invoices by account, retaining positive, zero, and negative balances. Buckets are current, 1–30, 31–60, 61–90, and 91+ days past due. Due today and future due dates fall in current. A legacy OPEN record without a due date is represented as current with null `days_past_due`; new OPEN invoices require a due date, and the worked example uses September 30. For dated invoices, days past due is the signed company-local calendar-day difference. Non-open invoices have null aging. The summary's `report.aging_date` is the current local date; there is no historical `as_of` parameter. Its detail is `/invoices?status=OPEN` with identical account/business filters. Processing applications are separately visible.

For refreshing open invoices without losing ones that became paid, follow [Build a reporting store](/reporting-store).