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

# AR and collections

> Aging, dunning, payment application, credit memos, and write-offs — turning receivables into cash without burning customers.

# AR and collections

Revenue you have billed is not money until it is collected and **applied**. This is the workflow for
the gap: seeing who owes what, chasing it in a way that scales, and recording the endings — paid,
credited, or written off — so the ledger tells the truth.

## Read the aging first

```bash theme={null}
curl "https://api.stateset.com/api/v1/ar/aging" -H "Authorization: Bearer $STATESET_API_KEY"
curl "https://api.stateset.com/api/v1/ar/aging/customers" -H "Authorization: Bearer $STATESET_API_KEY"
curl "https://api.stateset.com/api/v1/ar/aging/customers/{customer_id}" -H "Authorization: Bearer $STATESET_API_KEY"
```

Aging buckets receivables by how overdue they are. The top view is health; the per-customer views
are the work queue. Before chasing anyone, check for **unapplied payments** — a customer who shows
delinquent but has cash sitting unapplied is your bookkeeping problem, not their payment problem
([order to cash, step 4](/guides/commerce/order-to-cash#4--apply-it)).

## Dunning

```bash theme={null}
curl "https://api.stateset.com/api/v1/ar/dunning/due" -H "Authorization: Bearer $STATESET_API_KEY"

curl -X POST https://api.stateset.com/api/v1/ar/invoices/{invoice_id}/dunning \
  -H "Authorization: Bearer $STATESET_API_KEY"
```

`dunning/due` is the list of invoices whose next reminder is due — the engine tracks the escalation
sequence per invoice, so running dunning daily sends each customer the *right next* notice, not a
blast. Every send lands in the collection-activity log automatically.

For the human touches — the phone call, the negotiated plan — record them the same way:

```bash theme={null}
curl -X POST https://api.stateset.com/api/v1/ar/collection-activities \
  -H "Authorization: Bearer $STATESET_API_KEY" \
  -H 'content-type: application/json' \
  -d '{ "customer_id": "cus_1042", "type": "call", "notes": "Promised payment by Aug 5" }'
```

<Tip>
  The activity log is what makes collections handoff-safe: the next person (or agent) sees every
  notice, call, and promise in one place. An agent doing collections should **read the log before
  contacting anyone** — re-dunning a customer who promised payment yesterday is how you lose them.
</Tip>

## The endings

Every open invoice ends one of three ways. Use the right one:

### Paid — apply it

```bash theme={null}
curl -X POST https://api.stateset.com/api/v1/ar/payment-applications \
  -H "Authorization: Bearer $STATESET_API_KEY" \
  -H 'content-type: application/json' \
  -d '{ "payment_id": "pmt_5k1", "invoice_id": "inv_3f8", "amount": "256.00" }'
```

### Adjusted — credit memo

You agreed the customer owes less: a concession, a billing error found late, returned goods.

```bash theme={null}
curl -X POST https://api.stateset.com/api/v1/ar/credit-memos \
  -H "Authorization: Bearer $STATESET_API_KEY" \
  -H 'content-type: application/json' \
  -d '{ "customer_id": "cus_1042", "amount": "40.00", "reason": "damaged item concession" }'

curl -X POST https://api.stateset.com/api/v1/ar/credit-memos/{id}/apply \
  -H "Authorization: Bearer $STATESET_API_KEY" \
  -H 'content-type: application/json' \
  -d '{ "invoice_id": "inv_3f8" }'
```

### Uncollectable — write off

```bash theme={null}
curl -X POST https://api.stateset.com/api/v1/ar/write-offs \
  -H "Authorization: Bearer $STATESET_API_KEY" \
  -H 'content-type: application/json' \
  -d '{ "invoice_id": "inv_3f8", "reason": "customer insolvent" }'
```

<Warning>
  The three endings are **not interchangeable**, because they say different things about the money: an
  application says it arrived, a credit memo says it was never truly owed, a write-off says it was owed
  and lost. Using a credit memo to hide a collection failure understates bad debt and flatters revenue
  — your auditor will find it, and so will the [income statement](/guides/commerce/period-close).

  A write-off is also **reversible** (`POST /api/v1/ar/write-offs/{id}/reverse`) — the customer who
  pays after all is a reversal plus an application, with both on the record.
</Warning>

## The statement

```bash theme={null}
curl "https://api.stateset.com/api/v1/ar/customers/{customer_id}/statement" \
  -H "Authorization: Bearer $STATESET_API_KEY"
```

One document with every invoice, payment, credit, and balance — the thing to send when a customer
says "we don't recognise this charge", and the fastest way to end a dispute that is really just two
different ledgers.

## Related

* [Order to cash](/guides/commerce/order-to-cash) — how invoices get here
* [Period close](/guides/commerce/period-close) — reconciling AR to the ledger
* [Procure to pay](/guides/commerce/procure-to-pay) — the mirror image, from the paying side