> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/guides/feature-guides/billing-setup/guide-setting-a-subscription-start-date.md).

# 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](/guides/feature-guides/billing-setup/guide-creating-a-trial-bundle-that-auto-converts-to-paid.md)). 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.peakcommerce.com/guides/feature-guides/billing-setup/guide-setting-a-subscription-start-date.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.