What is quote-to-cash, and where does this one stop?

Quote-to-cash, defined

People ask this as: what is quote to cash, q2c process meaning

Quote-to-cash (Q2C) is the commercial process that runs from configuring and pricing a quote, through discount approval, signature and order, to contract activation, fulfilment, invoicing and payment. It is broader than CPQ, which is only its front segment. Accordo implements the quote-to-contract stretch as one evidence chain — server-priced immutable quotes, human-gated discounts, verified signature events, exactly one immutable Order, activation into contract, subscription and pending obligations — and the cash segment does not exist: there is no invoice, payment, dunning or revenue recognition anywhere in the framework.

Where this stops

Read this before the rest of the page. Every line below is a thing this does not do.

  • The cash segment does not exist. No invoice, payment, dunning, tax, usage rating, proration or revenue recognition, and MRR, ARR and TCV are not derived (L-10).
  • Every signature provider is an offline fixture. No envelope has ever reached a real signer, and the signed document is canonical JSON, not a PDF (L-05).
  • Terms frozen into the signed quote document retain signed-order provenance; legacy orders without signed terms can use explicitly labelled post-signature operational metadata. Operational dates are never promoted to signed terms.
  • Governed renewal and amendment execution creates a successor agreement from its own signed Order, with immutable lineage and a derived line delta. Historical contracts and subscriptions are not edited. There is no automatic renewal, cancellation execution, billing or customer notification. Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included (L-04).
  • The chain runs locally with no authentication, so it is a development artifact, not an operating revenue process (L-01).

No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim. Every claim and every limitation is on one page.

The definition, segment by segment

Quote-to-cash names the whole revenue-side process: configure and price a quote (the CPQ segment), obtain the approvals the discount requires, get the agreement signed, turn the signed agreement into an order, activate the order into a contract and its obligations, fulfil them, and collect the money — invoice, payment, revenue recognition. Its point as a term is continuity: each artifact should descend from the previous one, so the invoice can be traced to the price the policy actually approved.

CPQ is often sold as if it were the whole of this; it is the first segment. The middle segments are agreement and activation, and the last is billing. Any system claiming the term owes its reader a statement of which segments it actually implements — which is what the rest of this page is.

The stretch Accordo implements, as one evidence chain

Quotes price on the server from a catalog and freeze into immutable versions, and a discount beyond policy stops for a named human — an agent actor asking to decide is refused (C-08, C-21). An approved quote version becomes one signature envelope, ever, whose provider events are verified before any state changes, and whose completion produces exactly one immutable Order in a single transaction (C-09). A signed Order then activates, through a versioned policy and one human decision, into a Commercial Contract, an immutable contract version, a Subscription with its lines, and explicitly pending delivery and service obligations (C-10). Every step leaves audit and step-level trace (C-16).

The chain is evidence-first on purpose: the Order copies its terms from the approved quote version rather than reading a live catalog back, and the contract carries the identifiers of the order, quote version, opportunity and company it descended from. What was sold, at what price, approved by whom, remains answerable at every segment boundary.

Where the cash is, and is not

The cash segment does not exist. There is no invoice, no payment, no dunning, no tax, no usage rating, no proration and no revenue recognition anywhere in the repository, and MRR, ARR and TCV are deliberately not derived from contract data (L-10). A Subscription here is a commercial activation record — what was sold as a recurring right — and nothing meters or bills it.

Signature business providers are offline fixtures and canonical signed documents are JSON, not PDF (L-05). Terms frozen into the signed quote document retain signed-order provenance; legacy orders without signed terms can use explicitly labelled post-signature operational metadata. Operational dates are never promoted to signed terms. Governed renewal and amendment execution creates a successor agreement from its own signed Order, with immutable lineage and a derived line delta. Historical contracts and subscriptions are not edited. There is no automatic renewal, cancellation execution, billing or customer notification.

The evidence this page rests on

Claims and limitations are printed from site/claims.json word for word. Job statuses come from docs/benchmarks/jobs.json; a job with no page of its own is listed with its status rather than linked.

Claims

  • C-08 Quotes price on the server from a catalog — one-time and recurring, flat, per-unit, volume and graduated tiers — and freeze into an immutable version when a discount goes for approval.

    LimitCatalog sync runs against a fixture provider; no real external catalog (Stripe, Zuora, ERP) is connected. Money is integer cents with no FX — currencies are never summed.

  • C-09 A signature envelope produces verified events and a hashed signed artifact, and exactly one immutable Order is built from the approved quote version.

    LimitA fixture signature provider with a test-only webhook key. No DocuSign, Adobe Sign or Dropbox Sign adapter exists, and the artifact hash is provider-reported rather than independently recomputed.

  • C-10 A signed Order activates into a Commercial Contract, an immutable contract version, a Subscription and explicitly pending delivery and service obligations — every component classified, never guessed.

    LimitTerms frozen into the signed quote document retain signed-order provenance; legacy orders without signed terms can use explicitly labelled post-signature operational metadata. Operational dates are never promoted to signed terms. Governed renewal and amendment execution creates a successor agreement from its own signed Order, with immutable lineage and a derived line delta. Historical contracts and subscriptions are not edited. There is no automatic renewal, cancellation execution, billing or customer notification.

  • C-16 Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it.

    LimitAudit records what the process did under an asserted actor. It is not a tamper-evident or externally attestable log, and it is not a compliance control.

  • C-21 The same refusal holds where the money is: an agent actor asking to approve a discounted quote is refused with a 403, and only a human user actor can decide.

    LimitThe assertion lives inside a composite end-to-end test rather than a test named for it, so the citation is a file and a line rather than a test name. Extracting it into a named test is tracked in docs/strategy/GO_TO_MARKET.md; until then, cite the line.

Limitations

  • L-01 No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.
  • L-04 Timers exist; a service that runs them for you does not. Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included.
  • L-05 No email, calendar or marketing integrations. An in-memory notification provider contract exists. MK1 marketing records supplied funnel observations and human-reviewed proposals only; it has no sending, publishing or spending path.
  • L-10 Nothing bills. No invoice, payment, tax, usage rating, proration or revenue recognition exists, and MRR, ARR and TCV are not derived from contract data.

Jobs it covers

Documented in

Proved by