Open source. Not deployable to production. This page states what the tests prove and what is missing — nothing else.

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).
  • The contract term was never signed. Effective and term dates are post-signature operational metadata a human types with a required reason.
  • There is no scheduler, so nothing renews, expires or fires on a date (L-04). Amendment, cancellation and renewal flows do not exist.
  • The chain runs locally with no authentication or tenancy, so it is a development artifact, not an operating revenue process (L-01).

No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network. 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.

The implemented stretch carries its own bounds too. Every signature provider is an offline fixture: no envelope has ever been sent to a real signer, and the signed document is canonical JSON rather than a PDF (L-05). The contract term was never signed — dates are operational metadata a human enters with a required reason — and there is no scheduler, so a renewal notice period passes without anything firing (L-04). Quote-to-cash, in this framework, honestly means quote-to-contract with the books left open.

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.

    LimitThe term is post-signature operational metadata, not a signed contractual term. Nothing bills, renews, amends or cancels: there is no scheduler, so auto-renew and notice periods are recorded and never fire.

  • 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, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.
  • L-04 No scheduler, no reminders, nothing on a timer. Follow-up Tasks and an Activity timeline are one shared model that a person moves by hand: a due date changes no state. There is no recurring work, no delayed workflow, no queue — so nothing fires on a renewal notice period either.
  • L-05 No email, calendar or marketing integrations. An in-memory notification provider contract exists. No adapter sends anything to anyone.
  • 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