> ## 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.

# Order to cash

> The full revenue path — order, invoice, payment, application, ledger — as one connected workflow over the Commerce API.

# Order to cash

The revenue path runs through five resources: an **order** is placed, an **invoice** bills it, a
**payment** settles it, a **payment application** connects the two, and the **general ledger**
records all of it. Each step is one or two calls; the value of this guide is the order they go in
and what breaks when you skip one.

All paths are under `https://api.stateset.com/api/v1`. Send an `Idempotency-Key` on every POST.

## 1 — Take the order

```bash theme={null}
curl -X POST https://api.stateset.com/api/v1/orders \
  -H "Authorization: Bearer $STATESET_API_KEY" \
  -H "Idempotency-Key: src_88213" \
  -H 'content-type: application/json' \
  -d '{ "customer_id": "cus_1042", "line_items": [{ "sku": "SHOE-RED-10", "quantity": 2 }] }'
```

An order is a commercial fact, not a financial one — nothing has hit the ledger yet.
Fulfillment proceeds independently ([fulfillment workflow](/guides/commerce/fulfillment)); this
guide follows the money.

## 2 — Invoice it

```bash theme={null}
curl -X POST https://api.stateset.com/api/v1/invoices \
  -H "Authorization: Bearer $STATESET_API_KEY" \
  -H 'content-type: application/json' \
  -d '{ "order_id": "ord_9x2", "customer_id": "cus_1042", "invoice_type": "standard" }'

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

Creating an invoice is a draft; **sending** it is the event that starts the clock. Invoice
[status](/stateset-commerce-api-reference/invoices/get) runs
`draft → sent → viewed → paid`, with `overdue` when the terms lapse — and `overdue` is computed from
the *send*, which is why an unsent invoice can never be chased.

## 3 — Record the payment

```bash theme={null}
curl -X POST https://api.stateset.com/api/v1/payments \
  -H "Authorization: Bearer $STATESET_API_KEY" \
  -H "Idempotency-Key: pay_ord_9x2_1" \
  -H 'content-type: application/json' \
  -d '{ "customer_id": "cus_1042", "amount": "256.00", "method": "card" }'

curl -X POST https://api.stateset.com/api/v1/payments/{id}/complete \
  -H "Authorization: Bearer $STATESET_API_KEY"
```

## 4 — Apply it

This is the step naive integrations skip. A completed payment and a sent invoice are **not
connected** until you apply one to the other:

```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" }'
```

<Warning>
  Skip application and every downstream AR view is wrong: the invoice stays open, [AR
  aging](/guides/commerce/ar-collections) shows the customer as delinquent, and
  [dunning](/guides/commerce/ar-collections#dunning) will chase someone who already paid. Cash in the
  bank and cash *applied* are different states, and only application closes an invoice.

  Applied wrongly? `POST /api/v1/ar/payment-applications/{id}/unapply` reverses it — do that rather
  than compensating with a credit memo.
</Warning>

## 5 — Check the ledger

Every step above posted journal entries automatically. Verify rather than assume:

```bash theme={null}
curl "https://api.stateset.com/api/v1/gl/journal-entries?source=invoice&reference=inv_3f8" \
  -H "Authorization: Bearer $STATESET_API_KEY"
```

You should see revenue recognized on the invoice and cash against AR on the application. If you post
manual entries on top of these, you are double-counting — the engine is doing the accounting; your
job is to read it.

## Partial payments and short-pays

Apply the amount actually received. The invoice stays open for the balance, and the remainder shows
in [aging](/guides/commerce/ar-collections) at its true age. A deliberate short-pay you agree to
forgive is a **credit memo** (`POST /api/v1/ar/credit-memos`, then `/{id}/apply`) — not an edit to
the invoice, which would erase the history of what was billed.

## When it goes backwards

| Situation             | Do                                  | Not                    |
| --------------------- | ----------------------------------- | ---------------------- |
| Customer refund       | `POST /api/v1/payments/{id}/refund` | A negative payment     |
| Billing error, unsent | Edit the draft invoice              | —                      |
| Billing error, sent   | Credit memo, apply it               | Editing a sent invoice |
| Uncollectable         | `POST /api/v1/ar/write-offs`        | Deleting the invoice   |

Write-offs are reversible (`/{id}/reverse`) — a customer who pays after all is a reversal plus an
application, and the audit trail shows both.

## Related

* [AR and collections](/guides/commerce/ar-collections) — what happens when step 3 doesn't come
* [Period close](/guides/commerce/period-close) — locking the months these entries land in
* [Commerce API reference](/api-reference/commerce/overview)