DAF Trucks verkoopt abonnementen voor connected-fleet features: een service activeren op één truck of op een hele vloot, met correcte facturatie. GrandVision verkoopt terugkerende plannen voor brillen en lenzen via meer dan 7.200 winkels in 40 landen. Voor beide projecten bouwden we een commerce- en self-service-laag vóór Zuora. Een koffiemerk dat elke vier weken een zak verstuurt, heeft die complexiteit daarentegen niet nodig.
Het verschil tussen die situaties is de echte beslissing. Toch gebruikt iedereen hetzelfde woord: subscriptions.
Eén woord, twee problemen
Terugkerende fulfilment is een commerceprobleem: dezelfde winkelmand op een schema uitvoeren. Elke vier weken verzenden, een opgeslagen betaalmethode belasten, overslaan of pauzeren. De eenheid is een order.
Terugkerende monetization is een financieel probleem: een contract dat in de tijd verandert. Tussentijdse upgrades met proration, usage-based charges, geconsolideerde facturen voor een vloot, payment retries, dunning, belastingen per billingperiode en revenue recognition. De eenheid is een subscription state machine; orders zijn maar één output.
Veel projecten die zeggen “we hebben subscriptions nodig” kiezen tooling voor het eerste probleem terwijl ze stilletjes het tweede nodig hebben.
Wat commercetools native doet
Recurring Orders in commercetools is bedoeld voor het eerste probleem: een cart krijgt een recurrence policy en het platform maakt elke cyclus een normale order. Die normaliteit is de kracht: iedere order doorloopt dezelfde pricing-, promotion-, inventory- en integratiestromen als een eenmalige order. Voor vaste cadans, fysieke producten en eenvoudige lifecycle-events kan dit samen met je PSP voldoende zijn.
Let op een naamgevingsvalkuil in de documentatie: de functie die historisch Subscriptions heette, is eventing voor platformberichten naar queues. Het is niet de klantgerichte subscription capability. Dat is Recurring Orders. Laat één woord niet de hele scope bepalen.
Waar het native model stopt
Bij DAF wordt de grens duidelijk:
- Een fleet manager activeert op de 17e van de maand een feature voor 40 trucks; de prijs moet prorateren.
- Features worden continu toegevoegd en verwijderd; finance wil één geconsolideerde factuur per klantentiteit.
- Mislukte betalingen moeten een retry- en dunning-sequence volgen.
- Contracten lopen jaren en amendments moeten auditbaar zijn.
- Pricing bevat commitments en usage, niet alleen een vaste cyclusprijs.
Dit is geen ordergeneratie. Dit is contract lifecycle accounting. Zelf een billing engine boven op carts bouwen betekent proration, kalenderuitzonderingen, partial credits, tax per periode en revenue recognition opnieuw implementeren. Daar bestaan gespecialiseerde platforms voor.
Commerce vooraan, billing erachter
De productiearchitectuur voor DAF Trucks en GrandVision verdeelt verantwoordelijkheden helder:
- Commerce voor catalogus en aankoop. De storefront of portal presenteert de plannen. commercetools of een custom laag bezit browse-and-buy; de mapping naar rate plans blijft bewust éénrichting.
- Zuora voor het contract. Checkout maakt de subscription. Amendments, proration, invoices, retries en revenue recognition blijven daarna bij de billing engine.
- Self-service als eigen oppervlak. De portals laten klanten plannen, features en facturen beheren zonder voor elke wijziging een engineering ticket te openen.
- Events houden de randen eerlijk. Billing state stroomt naar entitlements, accounting en audit trails via de integratielaag, niet via een web van point-to-point calls.
Het patroon is breder dan Zuora. De grens is het belangrijkst: commerce bepaalt wat je verkoopt en hoe het wordt gekocht; billing bepaalt wat de klant verschuldigd is en waarom.
Zo kies je
Blijf bij Recurring Orders plus PSP als al deze punten gelden:
- Vaste-cadence replenishment van fysieke goederen
- Geen proration, usage of commitments
- Annuleren en overslaan zijn de enige relevante lifecycle-events
- Finance kan met orderrecords werken
Voeg een billing engine toe als één van deze punten speelt:
- Tussentijdse wijzigingen moeten prorateren
- Klanten hebben geconsolideerde of entity-level invoices nodig
- Dunning en recovery beïnvloeden omzet
- Revenue recognition of audit verder gaat dan orderhistorie
- Subscriptions rechten, features of service levels activeren
Een praktische smell test: schrijf de drie lastigste supporttickets op. Gaan ze over pakketten, dan is commerce waarschijnlijk voldoende. Gaan ze over facturen, dan zit de systeemgrens waarschijnlijk verkeerd.
Twee fouten die we vaak zien
Een dubbele catalogus als master. Het product bestaat zowel in commerce als billing en beide teams wijzigen hun eigen kopie. Kies één bron voor commerciële voorwaarden, genereer de andere kant en alarmeer op drift.
Billing edge cases als post-launch polish behandelen. Een mislukte upgrade, een wijziging op de 31e of een gedeeltelijke refund op een geconsolideerde factuur zijn geen uitzonderingen. Test ze vóór go-live; geldstromen zijn duur om achteraf te repareren.
Deze scheiding — commerce vooraan, billing erachter, events ertussen — hoort bij onze subscription economy dienstverlening. Bespreek je product- en financevereisten met ons als je Recurring Orders met een billing engine vergelijkt.
