The B2B commercial operations process, from quote to cash

The B2B commercial operations process is the path a piece of revenue takes from a customer request to money in the bank: capture the request, qualify it, quote it, take the order, fulfil and bill it, then collect and follow up. Most companies run this as five or six stages owned by different teams and different systems, and buy commercial operations software one stage at a time. The work that decides whether the whole thing runs fast or slow is not inside those stages. It is in the handoffs between them.

That is the argument of this post. The stages are mostly fine. Nobody in a functioning company is bad at writing a quote. What goes wrong is the space between the quote and the order, between the order and the invoice, between the invoice and the payment. That space is where context gets dropped, where somebody has to ask a question, and where the days quietly accumulate.

What are the stages of the quote to cash process?

Six, in most B2B companies, whatever they are called internally.

1. Capture. A request arrives. An email, a PDF purchase order, a portal notification, a spreadsheet, a phone call written on a notepad, a form on the website. It lands somewhere that is usually a shared inbox.
2. Qualify. Someone works out which customer this is, whether the products exist, whether the quantities make sense, whether anything is missing, and whether this is a duplicate of the request that came in yesterday.
3. Quote. Prices come from a price list, a contract, a volume break, or a previous deal. Margin gets checked. If the discount is unusual, someone approves it.
4. Order. The agreed quote becomes an order in the ERP or order management system. Details are validated: delivery address, requested date, payment terms, credit position.
5. Fulfil and bill. The order moves. Stock is allocated, a delivery goes out, an invoice is raised, and the invoice has to match what was actually shipped.
6. Collect and follow up. Payment arrives or it does not. Discrepancies get resolved. And the account, if anyone is watching, is due to reorder in about eleven weeks.

Written out like that, it reads like a clean pipeline. In a real company it is closer to six departments with a shared inbox between each pair of them.

Where do the days actually go?

Not into the stages. Into the waiting.

APQC's cross-industry benchmarking puts top performers at 30 days or less to collect payment on a customer invoice, the median at 38 days, and bottom performers at 46 days or longer (reported by CFO.com). That is a 16-day spread between the top quartile and the bottom quartile.

Sixteen days is not explained by how fast anyone types. No team in the bottom quartile is slower at writing invoices than the top quartile by two working weeks. The gap is made of waiting: an invoice that sat for four days because nobody noticed the order had shipped, a query that took a week to reach the person who could answer it, a credit hold that nobody cleared because the person who set it was on holiday.

Those are not process steps. They are gaps between process steps. They do not appear on anyone's process map, which is exactly why they survive.

What does this look like in a real company?

A distributor, about sixty people, several thousand SKUs, orders arriving from around four hundred trade accounts.

Orders come into one shared inbox. Some are PDFs. Some are the body of an email, written differently by each customer. A few are spreadsheets with the customer's own product codes, which do not match the distributor's product codes. Two people open that inbox every morning and retype what they find into the ERP.

They are good at it. They are fast, they know the accounts, and they catch things a system would miss. They also carry the whole operating layer in their heads: that this customer always means the 25kg bag even when they write 25, that this one has a contract price that is not in the standard list, that this one's purchase orders arrive with the delivery address of a site they closed last year.

Then one of them is off sick. Orders still get entered, but slower, and three of them get entered wrong. Two customers call to chase. An invoice goes out with the old delivery address on it and gets disputed, which puts that payment three weeks behind. None of this shows up as a failure of the ordering process. The ordering process worked. The knowledge that made it work was not written down anywhere.

This is the same pattern in wholesale and distribution and in manufacturing, and it is why buying a better quoting tool rarely moves the number anyone cares about.

Why does the work break between the stages and not inside them?

Because every stage is designed, and the space between stages is not.

Each stage has an owner, a system, and a definition of done. Sales owns the quote. Operations owns the order. Finance owns the invoice. Each of those is measured on its own stage, so each of those stages is reasonably efficient.

What sits between them is a different kind of work, and it has no owner:

• Rules that were never written down. Which customers get which price, when a discount needs approval, what counts as too big a credit risk, which products can be substituted.
• Context that has to travel. The reason the customer asked for a split delivery, the promise the sales rep made on the phone, the fact that last month's invoice is still disputed.
• Exceptions. The request that is missing a quantity. The product that is out of stock. The purchase order that arrives for a customer who is on hold.
• Chasing. Somebody has to notice that nothing has happened, and go and find out why.

That is the operating layer. It is real work, it takes real time, and it lives in people's heads and in Slack messages and in the fifth reply of an email thread. When people talk about their systems not talking to each other, this is usually what they mean. Not that the data cannot move. That the context cannot.

What does commercial operations software actually have to do?

If the gaps are the problem, then commercial operations software that only speeds up a stage is solving the wrong half. To be useful across the cycle it has to do six things.

Read the request where it actually arrives. Not in a portal you wish the customer used. In the inbox, in the PDF, in the badly formatted spreadsheet. If capture requires the customer to change how they order, capture will not happen.

Identify what it is looking at. Which account, which products, which of that account's specific terms apply. Product code matching is most of the job here and it is unglamorous.

Apply your rules, not generic ones. Your price lists, your approval thresholds, your credit policy, your substitution logic. A system that imposes a standard process onto a business that has run differently for fifteen years will be worked around within a month.

Carry the context forward. What was agreed at the quote should still be visible at the invoice. If the reason for a split delivery has to be re-explained three times, the handoff is still broken.

Ask when it is not sure. This is the important one. A system that is confident when it should not be produces mistakes faster than a person can. A system that routes the unclear case to a named human, with the reason it is unclear, produces work a person can finish in thirty seconds.

Write back into the systems you already run. The ERP stays the system of record. If the automation lives in its own database and someone has to reconcile the two, you have added a stage rather than removed a gap.

What should stay human?

Judgment.

Not as a hedge. As a design rule. The routine cases are volume: the standard reorder, the request that matches a contract price, the invoice that matches the delivery. Those should run without anyone touching them, and most companies have more of them than they think.

The exceptions are the ones that need someone who understands the relationship. Whether to extend terms to an account that is slipping. Whether to hold a shipment for a customer with an unpaid invoice and a good reason. Whether a margin exception is worth it because of what else that customer buys. Whether to take the order at all.

Automating those is not ambitious, it is careless. The right split is that automation runs the routine and humans own the exceptions, with the exceptions arriving already researched instead of arriving as a surprise.

It is also worth saying what software of this kind does not do. It does not pick, pack or ship anything. It does not replace an ERP. It does not make a commercial decision that a person is accountable for. It generates the quote, the order, the invoice and the chase for a human to approve, and it keeps a record of what it did.

How do you start without a replatforming project?

Pick one gap. Not one stage, one gap.

Find the place where work waits longest before someone touches it. In most B2B companies it is one of three: the shared inbox where orders land, the approval that sits in someone's queue, or the invoice query nobody owns. Measure how long things actually sit there, which is usually the first uncomfortable moment, because the number is worse than anyone's estimate.

Then automate the routine half of that one gap, route the rest to a person, and check the waiting time again in a month. If it did not move, the gap was not where you thought it was, and you have learned that for the price of one experiment rather than one implementation programme.

The takeaway

The quote to cash process is not slow because any one stage is slow. It is slow because the operating layer between the stages runs on memory, goodwill and email. Fix the gaps and the stages you already have will look considerably better than they do today.

That is the part Elentaria works on: reading the request where it arrives, carrying the context across the handoffs, applying your rules, and putting the exceptions in front of the person who should decide.