Skip to content

Order to cash

Selling something and collecting for it: the customer and their credit limit, the sales order, getting the goods out, the invoice, and applying the cash that comes back.

Customers & credit control (/customers)

The customer master records who you sell to. Credit limits and payment terms live alongside it in credit control, a thin layer over receivables:

  • A per-customer credit limit, checked when a sales order is confirmed: exposure + order value ≤ limit. Exposure is derived from receivables, never stored separately, so it cannot drift.
  • A dunning run over the receivables ageing emits escalating actions (reminder, first notice, final notice, collections) at 30 / 60 / 90 / 90+ days.
  • Status is OK, on-hold or blocked.

Permissions: erp-customer:read, erp-customer:manage; credit control adds credit:manage, credit:run, credit:override.

Sales orders (/sales)

Place an order, confirm it (credit-checked), deliver it (which issues stock and posts the cost), and invoice it (which posts the revenue).

  • Lifecycle: DRAFT → CONFIRMED → DELIVERED → INVOICED. Once goods have left, the order cannot be cancelled.
  • Delivery and invoicing are separate steps on purpose: cost belongs to the period the goods left, revenue to the period billed.
  • One order drives both cost and revenue, so gross margin is a fact about the order, not something reconstructed later.

What it posts:

Step Debit Credit
Deliver Cost of goods sold Inventory control
Invoice Receivables Revenue, Output tax

A mixed order (goods and services) credits goods and services revenue separately.

Permissions: sales:read, sales:manage, sales:confirm, sales:invoice.

Fulfilment (/fulfilment)

The warehouse side of getting an order out. Reserve stock against an order (a soft allocation), then ship it (issues stock, posts cost) or release the reservation; return goods back into stock; check availability per item.

  • available = on hand − open reservations.
  • Reserving posts nothing: it is a promise. Availability does not change when you ship, because the promise was already reflected.

Shipping calls inventory's issue (Dr cost of goods sold, Cr inventory control); a return records the stock back. The customer credit note for a return (reversing revenue and cost) is not yet modelled.

Permissions: fulfilment:reserve, fulfilment:ship, fulfilment:release, fulfilment:return, fulfilment:read.

Receivables (/receivables)

Record a customer invoice and issue it, the point of no return, which posts it. View ageing (rendered from the backend's own banding, so the screen, the reports and the ledger cannot disagree) and outstanding balances.

What issuing posts:

Debit Credit
Receivables Revenue, Output tax

Permissions: receivables:read, receivables:manage, receivables:issue.

Cash allocation (/ar-receipts)

Record a customer receipt (customer, date, amount, currency, reference) and allocate it across several open invoices.

  • Lifecycle: UNALLOCATED → PARTIALLY_APPLIED → APPLIED.
  • One payment can settle many invoices. Any excess is held as unapplied / on-account cash, a real credit on the account, never forced onto an invoice. Over-application is impossible; cross-customer allocation is refused.

The cash-in posts once, when you record the receipt:

Debit Credit
Bank Receivables control

Allocating that cash across invoices moves money within receivables and posts nothing.

Permissions: receivables:receipt, receivables:read.

Two doors to the same subledger

You can also record a customer receipt from the Cash & bank reconciliation screen, optionally settling a specific invoice. Both surfaces feed the same receivables ledger.