CRM that ends in the ledger

The chain, document by document

Lead-to-cash is not a metaphor. It is a sequence of documents, each with a defined effect on the general ledger, and most of them have none at all. Confusion about which is which is where the money leaks.

A lead is a record of interest. An opportunity is a forecast object with an expected value and a probability attached by a person. Neither touches the ledger, and neither should. A quotation is an offer: it commits price, scope and validity, and it may reserve nothing. A sales order is the acceptance of that offer by the customer. It is a commitment on both sides and often the trigger for procurement, scheduling or production, but it is still not an accounting entry. No revenue, no receivable.

The delivery or service completion is the event that usually matters most, because it is where control of the goods or the service passes. The invoice is the point of recognition: it debits accounts receivable, credits revenue, and raises the output tax liability. The receipt clears the receivable against cash or bank; it recognises no revenue, only settles a debt that already exists. A credit note reverses part or all of the invoice and, where tax was charged, reverses that too.

This is the practical form of the position that orders are not bills. Only ledger-posted documents get paid, get chased, and appear in ageing. If a system lets someone apply a payment against a sales order, or reports order value beside recognised revenue in the same column, it has broken the chain before month end starts.

• Lead and opportunity: pipeline records, no ledger effect.
• Quotation: a priced offer with a validity period, no ledger effect.
• Sales order: a mutual commitment, no ledger effect, but it drives stock, purchasing and scheduling.
• Delivery note or service sign-off: evidence of transfer of control, may move inventory and cost of sales.
• Invoice: debit receivable, credit revenue, raise output tax. Recognition happens here.
• Receipt: debit cash or bank, credit receivable. Settlement, not revenue.
• Credit note: reverses invoice value and tax, and restores or writes off the underlying obligation.

What separation actually costs

When the CRM is one system and the ledger is another, nothing dramatic happens on day one. The damage is in small reconciliations that people quietly do by hand and then stop doing.

Customer master data gets re-keyed, so the same buyer exists twice with two spellings and two payment terms. A quote is negotiated down in the CRM and the invoice is raised from the old price list, so either the customer disputes it or someone issues a credit note to fix it. A discount approved by a sales manager exists only in a CRM field the invoicing screen never reads. Commission is calculated on booked order value rather than invoiced and collected value, which means the company pays commission on revenue it has not recognised and sometimes will not collect. Sales reports a number for the quarter, finance reports another, and the meeting is spent explaining the gap instead of acting on it.

Each of these has the same root: a value entered once in one system and re-entered, by hand or by import, into another. The mechanism to remove is the re-entry, not the discrepancy.

One customer record, and why receivables care first

A duplicate customer is usually described as a sales hygiene problem. It is an accounts receivable problem first. Credit exposure is calculated per record, so two records mean the credit limit is effectively doubled without anyone approving it. Ageing splits across both, so neither looks bad enough to chase. Payments arrive as one remittance covering invoices held under two accounts, and the allocation has to be done manually.

The customer record has to carry the fields that both functions depend on, held once and read by both: legal name and trading name, tax registration number, credit limit, payment terms, assigned price list, currency, billing and delivery addresses, and the collection contact who is not always the buying contact. In Saudi Arabia and the wider Gulf the tax registration number is not a nicety; it is a required field on a compliant tax invoice, and an invoice raised against the wrong or blank number is a compliance problem, not a formatting one.

Credit control, before the promise is made

The ledger already knows what the customer owes and how late it is. The ageing exists the moment the invoices post. The question is whether the salesperson can see it at the moment it changes their behaviour, which is before the terms are offered, not after finance refuses them.

The pattern to avoid is familiar: a customer with several invoices past due receives an offer of extended terms, the deal is closed on that basis, and finance is then put in the position of either withdrawing the terms and damaging the relationship or accepting exposure nobody approved. Neither outcome is a finance decision at that point; it is a consequence of the salesperson not being shown the balance.

The mechanics are simple when the systems are one. Current balance, overdue balance by bucket, credit limit and remaining headroom are displayed on the account and on the quotation screen. Orders above the limit require an approval, which is recorded against the order rather than agreed in a corridor. Skyline Nexus works this way because the CRM and the receivables ledger read the same customer account, so the exposure shown to sales is the balance finance is looking at, not a copy of it.

Recognition timing lives in the CRM data

Under IFRS 15, revenue is recognised when a performance obligation is satisfied, which is when control of the promised good or service transfers to the customer. That may be at a point in time, such as delivery, or over time, such as a maintenance contract or a staged construction project. The standard also requires the transaction price to be allocated across separate performance obligations in a contract.

The information that decides all of this sits in the commercial documents. What was promised, whether the contract bundles distinct deliverables, when each was delivered or accepted, what was discounted and against what. If the CRM holds that contract and delivery data and the accounting system never sees it, someone rebuilds it in a spreadsheet at period end and the audit trail ends at that spreadsheet. When the order lines carry the obligations and the delivery records carry the dates, the deferral and release schedule is derived from documents rather than reconstructed from memory.

Pipeline is a forecast, revenue is a fact

Weighted pipeline is a probability-adjusted estimate of what might close. Recognised revenue is what the ledger says was earned in a period, and it can be audited. They answer different questions and they should never appear as one figure.

A connected system does not merge them; it lets you trace between them. From a pipeline number you can reach the opportunities behind it, then the orders they became, then the invoices those orders produced, then the cash received. That path is what makes the forecast improvable: you can measure how much order value historically converted to invoiced revenue, and in what elapsed time, and adjust the forecast method rather than argue about it.

What has to be shared, and what month end feels like

Sharing does not mean copying everything. It means a defined set of records that exist once and are read by both functions, and a defined set of events that move a document to the next stage without re-entry.

The month-end payoff is narrow and concrete. Ageing is complete because every invoice came from an order in the same system. The revenue figure sales quotes and the revenue figure in the trial balance are the same figure, because there is only one. Deferred revenue is supported by delivery records rather than a schedule someone maintains. Commission accrues on invoiced or collected value, calculated from ledger data. Credit notes are matched to the invoices they reverse, so disputes are visible as a number rather than as a feeling that collections are slow. Skyline Nexus keeps CRM, sales, inventory and accounting in one database for this reason: the invoice is generated from the order it belongs to, and the receipt is applied to the invoice it settles.

• Customer master: identity, tax registration number, credit limit, terms, price list, currency, addresses.
• Product and service master with the price lists and tax treatments the invoice will actually use.
• Approved discounts and their approver, stored on the document, not in a note.
• Order lines that carry through to invoice lines without retyping.
• Delivery and acceptance dates, since they decide recognition timing.
• Live receivable balance and ageing, readable from the CRM screens.
• Invoice, receipt and credit note references linked back to the originating opportunity.