Quote to cash for a small business: one chain from deal to payment, with nothing retyped

Quote to cash is the chain of documents between an interested customer and money in your bank account: a deal and its quote, a sales order, a delivery note for goods or a service act for work done, an invoice, and a recorded payment. Large companies have whole departments for it. Small businesses usually run it across a CRM, a spreadsheet, a word processor and an accounting tool, with someone retyping the customer’s name and the amounts at every step.

The retyping is where revenue leaks. Not dramatically, but steadily: a won deal that never became an order, a partial delivery that was invoiced in full, a payment recorded against the wrong invoice. The fix is structural. Each document should be created from the one before it, carrying over exactly what is still outstanding, so that nothing is entered twice and every gap is visible.

The chain, step by step

Notice that the leaks sit in the handovers, not in the documents. Each document on its own is usually correct. What goes wrong is the move from one to the next, because a person has to remember to make it and then copy the data across.

Step 1: the deal and the quote

The deal is the CRM’s record of the commercial conversation: the customer, the products or services, the amount, the stage. The quote is what you send. The most common failure here is the quote living in a separate document that drifts from the deal. The customer accepts version three, the deal still says version one, and the order is built from the deal.

Two habits prevent this. Generate quotes from a document template that pulls the company, contact and amounts from the deal, so the numbers come from one place. And treat the accepted quote as the trigger for the next step, not as the end of the sales process. If your stages are vague about what “won” means, pipeline stages with exit criteria covers how to define them.

Step 2: the sales order

Many small businesses skip the sales order, jumping from a won deal straight to an invoice. That works for a single invoice for a single service. It breaks the moment you sell goods, ship in parts or invoice in instalments, because nothing records the commitment itself.

The sales order is that record. It lists the priced lines, it is what the warehouse fulfils, and for goods it is what reserves stock so that another order cannot take it. Above all, it is the parent document: every shipment, service act and invoice is created from it, and the order keeps count of what is done.

Step 3: delivery, in parts if needed

Goods leave on a delivery note; services are confirmed with a service act (some markets call it a certificate of completion or acceptance). An order with both gets both. The point of a separate document is honesty about what actually happened: an order for five units that shipped three is three-fifths delivered, and the next delivery note should offer the remaining two, not five.

When a delivery is posted by mistake, reverse it rather than deleting it. A reversal puts the goods back in stock and leaves both entries visible, which matters if an invoice or a customer conversation already references the original.

Step 4: the invoice

An invoice answers four questions in one row: who billed whom, how much, and whether it is paid. The quality of an invoicing process shows in what people are not allowed to do. Staff should not set an invoice to “paid” by hand; it becomes paid because payments were recorded against it. Staff should not edit the amount on a sent invoice; they issue a correction. The paid figure should be the sum of recorded payments, not a field someone fills in.

This sounds bureaucratic until the first month-end where “paid” and the bank statement disagree. When status is a consequence of events, the disagreement can be traced. When status is a field, it cannot.

Step 5: the payment

A payment record needs the date, the amount, the method, the invoice and the bank or cash account the money went to. Mistakes are corrected with a refund entry that restores the amount due, followed by a correct payment. Editing a payment in place erases the evidence of what happened, and in a business with more than one person touching the books, that evidence is what resolves arguments.

How Nextora runs the chain

Nextora keeps the deal in the CRM and the documents in the ERP, joined by links rather than copies. A sales order carries a deal field; when it is set, the order links to the deal and the deal links back, and nothing is duplicated. An invoice can be raised straight from a deal: the company, contact, currency and amount are already known, the dialog shows a prefilled-from-deal banner, and the link is visible from both sides.

The chain runs order → shipment (for goods) or service act (for services) → invoice → payment. Each next document is made with Create based on and arrives prefilled with what is left. A ribbon at the top of the order reads Order → Shipped → Services done → Invoiced → Paid with partial states such as “shipped 3 of 5” or “invoiced 900 of 1,800”, and the order list shows the same as a Progress column. At the bottom of every order, act and invoice sits the document chain, so anyone can see the order and everything based on it.

Invoice status moves by itself: it changes when the invoice is sent and when a payment is recorded, and the Paid column is the sum of payments. In the register, only the payment due date and the note can be edited inline. Payments are recorded on the invoice page; a wrong payment is fixed with Record full refund, which brings the amount due back and adds an opposite record to the payments log. Only roles with the posting permission can post and reverse documents, and reversals create opposite entries rather than deleting anything.

For paperwork, Print on an order prepares a delivery note for its goods and a certificate of services rendered for its services, as a PDF in the name of the issuing organisation, with its details, bank and signer and the total in words. Document templates handle quotes and contracts: variables in double curly braces are filled from the deal, contact or company, with conditions and loops for sections that should appear only when a field is filled.

Three numbers to review every week

You do not need a finance team to keep quote to cash healthy. You need three lists, reviewed on the same day each week:

1. Won deals with no sales order or invoice. Each one is revenue you agreed and have not started collecting.
2. Delivered work not yet invoiced. Orders with shipments or service acts but invoiced below 100%.
3. Invoices past their due date. Sorted by amount, with an owner for each chase.

A simple measure ties them together: days sales outstanding, the average number of days between invoicing and payment. You can approximate it as receivables at the end of a period divided by revenue for that period, multiplied by the number of days in it. A rising figure means you are financing your customers. A falling one usually means the three lists above are being worked.

A worked example makes the number concrete. Suppose a business invoiced 90,000 over the last quarter of 90 days and has 30,000 still unpaid at the end of it. Its days sales outstanding is 30,000 divided by 90,000, multiplied by 90, which is 30 days. If its standard payment terms are 14 days, customers are paying, on average, more than two weeks late. That gap is cash the business has already earned and is lending, interest-free, to its customers. Closing it rarely needs harder collection; it usually needs invoices to go out on the day of delivery, with a due date the customer can see, and a reminder that happens without anyone remembering to send it.

The same arithmetic shows why invoicing late is expensive. Every day between delivery and invoice adds a day to the customer’s payment clock, because payment terms usually run from the invoice date, not from when they received the goods.

The lists themselves are good candidates for automation. A rule that creates a task for the account owner when an invoice passes its due date costs nothing to run and removes the need to remember. Which automation tool fits which job explains the options, and the record model underneath all of this is in the five records a CRM needs.