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

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); this guide follows the money.

2 — Invoice it

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

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:

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

Skip application and every downstream AR view is wrong: the invoice stays open, AR aging shows the customer as delinquent, and 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.

5 — Check the ledger

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

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

AR and collections — what happens when step 3 doesn’t come
Period close — locking the months these entries land in
Commerce API reference

Onsite Chat Quickstart AR and collections

Overview

Quickstarts

Commerce Workflows

Order Management

Returns & Warranties

Supply Chain

Agent Development

Knowledge & RAG

Response Features

Advanced Features

Integrations

Commerce Network

Self-Hosted

Best Practices

E-commerce Workflows

Order to cash

Order to cash

1 — Take the order

2 — Invoice it

3 — Record the payment

4 — Apply it

5 — Check the ledger

Partial payments and short-pays

When it goes backwards

​Order to cash

​1 — Take the order

​2 — Invoice it

​3 — Record the payment

​4 — Apply it

​5 — Check the ledger

​Partial payments and short-pays

​When it goes backwards

​Related

Order to cash

1 — Take the order

2 — Invoice it

3 — Record the payment

4 — Apply it

5 — Check the ledger

Partial payments and short-pays

When it goes backwards

Related