Skip to content
Firmspace
Back to blog

From Quote to Paid Invoice: How the Document Chain Works in the CRM

A quote, an order, an invoice and a payment are four views of one and the same deal. In many small companies they live in four different places: a document in a folder, a line in a spreadsheet, a PDF sent by e-mail, a note in the accounting program. Every handover between them is a chance to mistype an amount, forget a position or lose the thread of who owes what.

The chain begins on the deals board, not in a text editor. The card already holds the customer, the contact person, the responsible colleague and the expected amount. Every document that follows is created from that card, so the customer name and the deal reference are never re-typed.

The quote is prepared as a draft and then sent to the customer. The moment of sending is recorded as an event, and the status changes with it. This matters more than it sounds: only a quote that has actually been sent can later be marked as accepted or declined, so a draft cannot silently turn into a commitment.

The customer does not have to call back to say yes. A public link can be issued for the quote, and through it the customer accepts it himself. The link opens exactly one document and nothing else, the token is long and random, it can be revoked at any moment, and its lifetime is limited by default to ninety days. If the customer only wants part of what was offered, he ticks the positions he agrees with, and only those stay in the quote.

Only an accepted quote can become an order, and only once. The order inherits the customer, the contact person, the deal, the currency and every line item from the quote. Nothing is copied by hand, so the amounts in the order are the amounts the customer agreed to.

An order moves through a fixed set of statuses: draft, confirmed, fulfilled, invoiced, paid, closed, cancelled. Not every status may follow every other one — the system follows an explicit transition table, so an order that was already issued cannot quietly slide back to draft. The status change and the warehouse movements happen in a single transaction: issuing goods writes them off, cancelling returns exactly what left, and the movement journal is the source of truth, so a repeated issue does not write anything off twice.

An invoice can be created from an order only when the order has no invoice yet and does have line items. The invoice takes the customer, the contact, the deal and the contract from the order, applies the firm's tax settings, and counts the payment deadline from the agreed payment term — fourteen days by default. The order itself moves to the status invoiced.

Payment closes the loop. An invoice can be marked as paid in full or in part, and the date on which the money arrived decides which month it appears in on the charts — not the date someone got around to writing it down. Bank transactions can be matched to invoices, so the reconciliation does not have to be redone by hand at the end of the month.

A contract follows its own short path: draft, then active once it is signed, then completed. Only a draft can be signed, and the signature is recorded with its date and reported as an event, so the rest of the company learns about it without anyone sending a message around.

Each of these moments is an event the CRM can react to: a quote was sent, a quote was accepted, an order was created, an order changed status, an invoice was sent, paid or became overdue, a contract was signed, a bank transaction was matched. An automation rule can respond immediately or after a delay of an hour, a day or three days, and its action may be a notification, a task, a note, a stage change, an e-mail, a webhook call or a step performed by the assistant.

The step performed by the assistant deserves a word of caution, because it works differently from the chat. It runs without a person nearby, so it cannot ask for confirmation. It may first look things up with read tools, but then it performs at most one write action per run — not a chain of them. It acts with the rights of the firm's owner and consumes the same daily AI quota as the chat. If the instruction is unclear or it is not confident, it performs no action at all and explains why in one sentence. That is the intended behaviour: in a process that runs unattended, doing nothing is often the better outcome.

Every step leaves a trace. Document events are written into the activity history of the deal, the contact and the company, and each entry is keyed so that the same event is not recorded twice. Weeks later it is still possible to reconstruct when the quote went out, when it was accepted, when the goods were issued and when the money arrived — without asking anyone.

The value of the chain is not that documents look tidy. It is that the same record travels from the first quote to the final payment, so an amount cannot drift on the way, the warehouse and the paperwork cannot disagree, and the system itself notices the step that is overdue instead of waiting for someone to remember it.

Let us automate your next process together.

Describe a recurring workflow to us. Together we will check whether and how it can be automated sensibly.