Quote-to-cash is six documents in a line: a quote, an order, a fulfilment, an invoice, a payment, and the ledger entries that record what happened. In most companies at least three of those are produced by a human reading one screen and typing into another.
Every one of those hops has a characteristic failure. They are not random errors. They are specific, repeatable, and they each have a name.
The chain, hop by hop, with the error each hop produces
The useful way to audit a quote-to-cash process is to find each point where information changes hands and ask what a mistake there would look like three weeks later.
| Hop | What gets retyped | The error mode | What it costs |
|---|---|---|---|
| Quote to order | Quantities and line items | Transposed quantity: 12 becomes 21 | You ship or manufacture nine units nobody ordered |
| Quote to order | Unit prices | Stale price: the quote predates a price change | Margin quietly disappears on a document nobody re-reads |
| Order to fulfilment | Item identity | Wrong variant picked against a re-typed description | A return, a re-ship, and two movements to reconcile |
| Fulfilment to invoice | Quantity actually delivered | Invoiced ordered rather than shipped | You bill for a back-ordered line and get a dispute |
| Order to invoice | Tax treatment | Wrong tax code chosen by hand | An understated or overstated liability that surfaces at filing |
| Invoice to payment | The payment reference | Reference retyped at the bank | The payment cannot be matched and sits unallocated |
| Payment to ledger | Amount and account | Posted to the wrong account or period | A reconciliation difference with no obvious source |
Read down the third column and a pattern appears. None of these errors announces itself. Each one produces a document that looks entirely reasonable, and the discovery happens later, in a different department, by somebody who cannot tell which of the six hops produced it.
That is the real cost of re-keying. Not the typing time, which is small. The un-attributable error, which is expensive to find and embarrassing to explain.
Why “be more careful” does not work
The standard response is a checking step: someone verifies the order against the quote. This fails for a structural reason, and it is worth being precise about why.
A checking step is another read-and-compare performed by a person, so it has the same error rate as the step it is checking. It catches the errors that are visible on a screen and misses the ones that are not, which is exactly the set that matters. A transposed quantity looks correct. A stale price looks correct. A wrong tax code looks correct to anyone who is not a tax specialist, and the person doing invoice entry is not one.
The only intervention that removes an error mode rather than reducing its frequency is removing the hop. If the order is generated from the quote rather than typed from it, transposition at that hop is not less likely. It is impossible.
The failure case: the invoice that was right about the wrong quantity
Here is a concrete version, drawn from the shape rather than a customer.
A wholesale order for 60 units of a fast-moving item is quoted in March at the March price. The customer sits on it. In May the price list goes up and the customer accepts the old quote by email, because the quote never expired. A salesperson creates the sales order by typing the lines in, and reads the quantity column one line high: the 60 belongs to line two, and line one gets it.
Warehouse picks what the order says. Stock decrements by what was picked. The invoice is raised from the order, so it agrees with the order perfectly, and every internal check passes because every document downstream of the mistake is consistent with the mistake.
Three things are now true at once. The customer receives the wrong mix and disputes the invoice. The ledger holds revenue and cost at March pricing for goods sold in May, so the margin report for the month is wrong in a way no one will ever trace. And the stock figures are correct, which is the most confusing part, because the system did exactly what it was told.
The dispute takes two weeks and a credit note. The margin error is never found. Both come from one line of typing, and no amount of downstream validation would have caught either, because nothing downstream had access to the quote.
What “derived, not typed” means in practice
A quote-to-cash chain is sound when each document is a derivation of its predecessor and the derivation is enforced by the system rather than by a convention.
In Oneop the account record carries its own sales history: every quote, sales order and invoice against that account, with drill-down to line items. The head office total is the sum of what its subsidiaries actually bought, because it is computed from the documents rather than maintained in a spreadsheet. The CRM can also gate the pipeline on this, since one of the three stage-gate types is a required quote, and a stage move that does not qualify is refused with the list of what is missing rather than recorded with a warning.
Fulfilment is where the strongest guarantee sits, and it is worth stating exactly. In Oneop, shipping a sales order runs as a single transaction: it locks the order row, re-checks that the order is still in a shippable state so the loser of a race aborts rather than shipping twice, writes the shipment, updates the lines, attaches any service lines exactly once, decrements stock, posts cost of goods sold as a balanced journal entry, and raises the invoice. One commit, or none of it.
That ordering is a deliberate choice rather than a convenience. Invoicing is deferred to shipment for inventory orders, so you never invoice goods that have not left the building. Confirming a sales order reserves stock inside the order’s own commit, so if anything later in order creation fails, the hold disappears with it and there is no compensating cleanup job, because there is nothing left to clean up. The reservation arithmetic behind that is the subject of available to promise, and why overselling happens.
The ledger end: posting, tax and the payment match
The last two hops are where errors become expensive rather than annoying, because a posted entry is a statement about the company.
In Oneop’s finance module, cost and revenue land in the same ledger the shipment posted to, not in an export. Three refusals fire before a row is written: an unbalanced entry, a line carrying both a debit and a credit, and an entry where every line is zero. Every account on the entry is then checked to belong to your workspace. A posted entry is never edited; a correction is a linked reversal, joined to the original in both directions, and the same entry cannot be reversed twice. Why that matters more than it sounds is covered in double-entry accounting, explained for founders.
Tax is the hop where derivation beats entry most clearly. Choosing a tax code by hand on an invoice is a re-keying step with a jurisdictional error mode, and the mistake is only visible at filing. Oneop’s determinacy guard blocks an invoice whose tax was never determined from posting, and it is careful about what it is: it tells a genuine zero apart from a tax that was silently dropped, and it never computes or alters an amount. It is also inert until tax localization is turned on for the workspace.
Payment matching is the one hop where full automation is the wrong answer. Oneop suggests rather than merges: a bank line and a ledger line stay two rows joined by a computed score a person confirms. Amounts must be within 0.01 and dates within five days, and the score reflects how close the date is, with a bonus when the reference agrees. A wrong automatic match posts cash against the wrong invoice, and unwinding that is worse than the ten seconds of confirmation it replaced.
Where automation belongs in this chain
Automation earns its place at the joins, not inside the documents. A rule that creates the onboarding project when a deal is won, or raises a task when an invoice passes its due date, removes a hand-off delay without touching a figure.
What automation should not do is retype. An automation that copies a value from one document to another is a re-keying step performed faster, and it inherits every error mode in the table above, including the ones where the source document was already stale. The goal is not to automate the typing. It is to arrange the data so there is nothing to type.
The test for your own process is short. Walk the six stages and mark every point where a human reads one screen and types into another. Each mark is an error mode you currently own. Some will be genuinely hard to remove. Most will turn out to exist because two systems were bought at different times, and the join between them was a person.