Recurring revenue in B2B

A large part of what a B2B company sells is the same thing again, on a rhythm nobody wrote down. This article separates the four mechanisms that turn that rhythm into something the platform can run, and shows where each one breaks.

The revenue you already have

Look at one account for a year. A Zulieferer with two production halls buys from you roughly every three weeks: cutting fluid, gloves, filter cartridges, seals, the V4A fittings for the hydraulic line — around forty articles, the same forty, in quantities that wobble by twenty percent. Between orders somebody at their end walks the shelf, notices the gloves are low, writes a list, and mails it to your Innendienst, who keys it in.

Nothing about that transaction was a sales decision. It was a clerical one, made twice — once by the buyer writing the list, once by your Innendienst typing it. Both sides pay for it, and the only thing either of them gets in return is the risk of getting it wrong: forgetting a line, ordering the discontinued variant, running out of the filter cartridge on a Friday.

That is what recurring order handling is for. It is not a new revenue stream. It is the revenue you already have, arriving without either side re-doing the paperwork — and, as a side effect, becoming forecastable.

The four patterns

"Recurring" covers four different mechanisms. They get confused constantly, and the confusion is expensive because they fail in different ways.

Replenishment is prediction. You know what an account consumed and how fast, and you propose the next order before they run out. Nothing is committed until somebody accepts. Because it is a suggestion, a wrong one is cheap — an ignored email rather than a wrong delivery. See How smart reordering works.

A standing order is a fixed basket on a fixed interval, set up by — or with — the customer, and running until someone stops it. The cart is known in advance, so the run is mechanical. It is the least clever pattern and the most reliable one, and for consumables it is usually the right first step.

A subscription sells access rather than goods: a seat in your customer portal, a monitoring service, a licence, a leased device with a monthly fee. The defining property is that money moves on a cycle whether or not anything ships, which makes it the only one of the four where payment failure is a lifecycle event you have to design for.

A service contract — Wartungsvertrag, calibration, statutory inspection — is an obligation with dates in it. It generates work orders and invoices, not deliveries, and its failure mode is that the appointment did not happen and the customer only finds out at the audit.

Who controls the schedule

This is the question to settle first, because it decides who gets the phone call when a delivery arrives that nobody wanted.

The German Mittelstand default is worth naming: buyers are cautious about giving a supplier a standing mandate, and rightly so. Almost every successful rollout starts customer-controlled, with your team helping set the first one up on a call, and moves toward automation once the account has watched three runs go correctly.

The one arrangement that reliably goes wrong is you owning the schedule for goods the customer's consumption actually drives. Betriebsferien in August, a line shut down for a retooling, a project that ended — none of those reach your calendar, and all of them turn a scheduled run into a pallet of gloves nobody ordered.

Price: fixed at the start, or current at each run

Every recurring mechanism has to answer one question, and the answer belongs in the contract, not in a setting somebody flips later.

The second is the normal choice for goods, and it is what the platform does by default: a scheduled run resolves price the same way a checkout does, from the buyer's contract prices and scale prices at that moment. See How pricing works and Contract prices.

That default has a sharp edge. A time-limited price or a framework agreement that expires between runs changes the price silently — the run does not fail; it books at the list price and the buyer finds out on the invoice. Two habits prevent the argument:

• Send the run notification before the run, with the resolved prices in it, far enough ahead that the buyer can react.
• Put the expiry dates of contract prices for accounts with standing orders on the same review calendar as the standing orders themselves.

Pause, skip, and end

Three different actions, and conflating them is the most common support ticket in this area.

• Skip affects exactly one run. The arrangement stays live and the following run happens as planned. This is what Betriebsferien needs.
• Pause suspends the arrangement indefinitely, with no runs, until it is resumed. Use it for a line that is down for a retooling of unknown length. A pause that nobody ever resumes is churn wearing a disguise — see Recurring revenue health.
• End stops it for good. For a standing order that is immediate. For a subscription or a service contract it is a notice, and the arrangement keeps running until the term expires.

That last distinction is where B2B and B2C part company. A consumer subscription cancels today. A B2B subscription has a Kündigungsfrist — three months to the end of the term is common — and an automatic renewal if nobody gives notice. Both the notice period and the renewal have to be visible to the customer, and the renewal has to warn before it fires. Silent auto-renewal is legally fragile in Germany and commercially poisonous everywhere.

Why this is not a consumer subscription

Four things break if you carry a B2C subscription model into B2B:

Somebody has to approve it. A standing order is a recurring commitment of budget. It may need the same approval path as any other order, and the approval belongs at setup, not at every run — see Approval models.

Every run needs the buyer's own references. A purchase-order number, a cost centre per line, a position text naming the machine. Without them the delivery note cannot be booked at the other end, and your automated order becomes a manual clarification.

Payment is an invoice, not a card. Kauf auf Rechnung with 30 days net is the default, so a "failed payment" is not a declined card at the moment of purchase. It is an invoice that aged past its terms, which is a dunning process — see Payment terms.

The delivery address moves. Hall 3 this quarter, the new site next quarter. Bind a recurring arrangement to an address that can be changed without recreating it.

How this works in the Revenue Cloud

• The saved basket already exists. Order lists and recurring carts are the substrate — a named, shared, positioned list carrying cost_center_id, custom_sku and position_texts per line. A standing order is that list plus a schedule, and it inherits every field, which is why the buyer's references survive each run.
• Standing orders run the list on an interval and produce ordinary orders — same statuses, same approval path, same ERP transmission. See Standing orders.
• Subscriptions carry plans, terms and billing cycles separately from delivery, and have their own failure handling. See Subscriptions.
• Reorder suggestions come from consumption in your own order history and arrive as proposals, on the storefront or as a call reason for a rep. See Configure reorder suggestions.

Next

• How smart reordering works — where the predicted date comes from, and when to distrust it.
• Standing orders — the fastest of the four to get live.