Quote-to-Cash in ERP: Quotation to Invoice to Payment

Every ERP system eventually has to answer the same question: how does a quotation become cash in the bank without anyone double-shipping an order or invoicing a customer twice. The answer is not a single feature. It is a pipeline of distinct documents, each with its own lifecycle, chained together by a state machine that refuses to let a record skip a step it has not earned.

This post walks through the quote-to-cash workflow the way I have built it for ERP clients: quotation, sales order, delivery, invoice, and payment, with the guardrails that stop the pipeline from silently drifting out of sync. It assumes a relational database, a backend service layer, and a willingness to model business rules as code rather than as tribal knowledge.

Why quote-to-cash needs a state machine, not just a status column

A naive implementation gives every document a status text field and lets any part of the codebase write to it. That works for a demo and fails in production, because nothing stops a shipping clerk's bug from marking an order paid, or a race condition from invoicing the same delivery twice. The fix is to treat each document type as a finite state machine: a fixed set of states, a fixed set of allowed transitions, and a single code path that is the only thing permitted to move a record from one state to the next.

Quote-to-Cash State Machine

  DRAFT ──► SENT ──► ACCEPTED ──► CONVERTED (Sales Order)
                │                       │
                └──► REJECTED           ▼
                                    CONFIRMED
                                        │
                                        ▼
                                    ALLOCATED ──► PICKED ──► SHIPPED
                                                                │
                                                                ▼
                                                            INVOICED
                                                                │
                                        ┌───────────────────────┤
                                        ▼                       ▼
                                  PARTIALLY_PAID            OVERDUE
                                        │                       │
                                        └──────────┬────────────┘
                                                   ▼
                                                 PAID (terminal)

Notice that the sales order does not become invoiced the moment it is confirmed. It has to pass through allocation, picking, and shipping first, each a checkpoint that a real-world event actually happened. A payment then only ever pushes an invoiced order toward partially paid or paid, never backward. Once you draw the graph, most of the edge cases people usually patch with special-case logic turn into transitions that simply are not defined, so the code rejects them by construction.

The five documents and what each one owns

Quote-to-cash is really five separate aggregates that reference each other by foreign key, not one giant table. Splitting them cleanly is what lets you reprice a quotation without touching a shipped order, or issue a partial invoice without blocking the rest of the sales order. It also means each document can carry its own approval rules, its own numbering sequence, and its own retention policy, which matters once finance and audit teams start asking for document-level history rather than a single flattened order record.

Converting a quotation into a sales order

The conversion step is where most custom ERPs earn their keep, because it is the moment a sales rep's promise turns into something the warehouse and finance teams are obligated to honor. A clean conversion handler does four things in a single transaction, and none of them are optional if you want the books to stay correct.

• Re-validate pricing and stock availability, because a quotation may be days or weeks old by the time the customer accepts it
• Run the credit check against the customer's outstanding balance and credit limit before the order is allowed to reach the confirmed state
• Copy the accepted quotation's line items into new sales order line rows rather than referencing the quotation rows directly, so later edits to either document never bleed into the other
• Record the transition with the acting user, a timestamp, and the source quotation id, so any later dispute has a full audit trail back to what the customer actually agreed to

-- PostgreSQL: sales_order status column with a guarded transition table
CREATE TYPE sales_order_status AS ENUM (
  'draft', 'confirmed', 'allocated', 'picked',
  'shipped', 'invoiced', 'partially_paid', 'overdue', 'paid'
);

CREATE TABLE sales_order (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  quotation_id UUID REFERENCES quotation(id),
  customer_id UUID NOT NULL REFERENCES customer(id),
  status sales_order_status NOT NULL DEFAULT 'draft',
  total_amount NUMERIC(14, 2) NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- Allowed transitions live in application code, not a trigger,
-- so the workflow engine can log who approved each hop.
CREATE TABLE sales_order_transition (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  sales_order_id UUID NOT NULL REFERENCES sales_order(id),
  from_status sales_order_status NOT NULL,
  to_status sales_order_status NOT NULL,
  actor_id UUID NOT NULL REFERENCES employee(id),
  note TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Delivery and the moment invoicing becomes legitimate

A sales order should never be invoiced directly. It should be invoiced because a delivery happened, or because a contract milestone was met. That distinction matters for tax compliance in most jurisdictions, and it matters for your own data integrity: if invoicing reads straight from the sales order, a partial shipment has no way to trigger a partial invoice, and the whole pipeline degrades into invoicing everything up front and hoping fulfillment catches up.

Invoicing and payment matching

Once a delivery closes, the invoice generation job creates an invoice referencing that delivery's line items, its own sequential invoice number, a due date computed from the customer's payment terms, and a status that starts at sent. Payment matching is the part teams underestimate, because in the real world payments rarely arrive as one clean transfer per invoice.

1. A customer pays for three invoices with one bank transfer, so the payment record needs a many-to-many allocation table between payments and invoices, not a single invoice id column
2. A customer underpays by a rounding difference or a bank fee, so the matching logic needs a tolerance threshold before it flags the invoice as a mismatch requiring manual review
3. A customer overpays, so the excess should become a credit balance on the customer record rather than being silently discarded or forced onto the next invoice without a paper trail

Keeping the pipeline observable

The state machine buys you correctness, but you also want visibility into where documents are stuck. A dashboard query that counts sales orders sitting in confirmed for more than a set number of days, or invoices sitting in sent past their due date, turns the pipeline from a black box into something the sales and finance teams can actually manage day to day. Log every transition with an actor and a timestamp from the start, because that transition table becomes the single source of truth for every future dispute about who approved what and when. As the ERP grows, this same transition log is also what lets you add automated alerts, such as flagging a sales order that has been allocated for a week without shipping, without rewriting any of the core workflow logic.