Setting a Subscription's Start Date (Backdating)

Overview

By default, the subscription a journey creates starts today — the day the order is placed. Sometimes you need a different start date: migrating an existing customer whose contract began weeks ago, correcting a mis-dated signup, or generating backdated (aged) subscriptions for testing so you can exercise renewals, dunning, and reporting. This guide shows how to control — and backdate — the start date of the subscription a journey's checkout step creates, using the create-order step's field mappings.

This is an advanced configuration technique; it assumes you're comfortable editing a journey step's commerce actions.

How a subscription's start date is set

When a journey step places an order (the create order commerce action), the subscription's start is governed by three trigger dates on the order:

• Contract Effective — when the contract begins,

• Service Activation — when service starts,

• Customer Acceptance — when the customer accepts.

If you don't map these, the journey sets all three to today, so the subscription starts the day the order runs. To move the start date, you set the trigger dates yourself.

An "order date" alone won't move the start. The trigger dates drive the subscription's start — mapping only an order date does nothing to it. You must map the trigger dates.

Backdate with a dynamic date

Open the create-order step (Content → Journeys → Edit → Steps → expand the step → Commerce actions) and add field mappings. Use the Dynamic source with the today() value and a negative offset to compute a date relative to now — for example today(-60) resolves to 60 days ago (formatted YYYY-MM-DD) every time the journey runs, so you never hard-code a fixed date.

Map the three trigger names (as Literal values) and the backdated date (as Dynamic today(-60)) to the order's trigger-date fields:

Source	Value	Destination field
Literal	ContractEffective	subscriptions[0].orderActions[0].triggerDates[0].name
Dynamic	today(-60)	subscriptions[0].orderActions[0].triggerDates[0].triggerDate
Literal	ServiceActivation	subscriptions[0].orderActions[0].triggerDates[1].name
Dynamic	today(-60)	subscriptions[0].orderActions[0].triggerDates[1].triggerDate
Literal	CustomerAcceptance	subscriptions[0].orderActions[0].triggerDates[2].name
Dynamic	today(-60)	subscriptions[0].orderActions[0].triggerDates[2].triggerDate

Because you're now supplying the trigger dates yourself, the journey no longer fills them with today — your backdated dates are used. (Change -60 to any number of days; use a Literal YYYY-MM-DD value instead of today(-60) if you want a fixed calendar date rather than a rolling one.)

If the subscription is Termed, backdate the term start too

For a Termed subscription (a fixed contract length), the term's start defaults to today unless you set it — which would fight your backdated trigger dates. Add one more mapping so the term begins on the same backdated date:

Source	Value	Destination field
Dynamic	today(-60)	subscriptions[0].orderActions[0].createSubscription.terms.initialTerm.startDate

Evergreen subscriptions (no fixed end date) don't need this — skip it.

Turn off activation-offset timing on this step

PeakCommerce also has activation-offset timing, used to defer a start into the future — for example a trial that converts later (see Creating a Trial Bundle that Auto-Converts to Paid). That feature is designed to push dates forward, and when it's enabled on a step it overrides your field-mapped trigger dates back to today. So the two are opposites:

• Backdating (this guide) — leave activation offsets off on the create-order step and use the field mappings above.

• Deferring forward — use activation offsets (not field-mapped dates).

Don't combine them on the same step.

Tips

• Trigger dates drive the start. If a change doesn't move the start date, you probably mapped an order date rather than the trigger dates.

• today(-N) is relative. It recomputes to "N days ago" on every run, so it stays correct over time instead of drifting to a stale fixed date.

• Great for testing. Backdated subscriptions in a test tenant let you exercise renewals, dunning, invoicing, and reporting without waiting for real time to pass.

FAQ

Why didn't changing the order date move the subscription's start?

The start is driven by the trigger dates (Contract Effective / Service Activation / Customer Acceptance), not an order date. Map the trigger dates as shown above.

Can I set a fixed date instead of a rolling one?

Yes — use the Literal source with a YYYY-MM-DD value on the same trigger-date destinations instead of Dynamic today(-N).

It's not backdating — the dates keep coming out as today. Why?

Activation-offset timing is almost certainly enabled on that step; it overrides mapped dates to today and pushes forward. Turn it off on the create-order step and use the field mappings above.

Does this work for Evergreen and Termed subscriptions?

Both. Termed subscriptions need the extra initial term start mapping so the term doesn't default to today; Evergreen subscriptions don't.