How effective dating works
Learn how effective dating is applied during PRPC creation and editing, ensuring automatic versioning of price changes.
To preserve pricing integrity and prevent unintended price overrides, Zuora restricts past-dated Effective Date updates for existing Dynamic Pricing rate card rows when the charge is already linked to a subscription. If a subscription is linked to the charge, you cannot update the Effective Date of an existing row to a date earlier than the current time.
If the charge is not linked to a subscription, you can still update the Effective Date of an existing row to a past date.
If you try to update an existing row to a past Effective Date for a subscribed charge, Zuora rejects the request and displays the following error message: Effective Date cannot be updated to a past date. This validation is enforced consistently in both the UI and API.
Existing rows with historical Effective Dates remain valid for pricing evaluation. However, for subscribed charges, you cannot resubmit or update an existing row using any EffectiveDate that is already in the past, even for price-only updates on a historical row. To update pricing on a subscribed charge, use the current date or a future Effective Date so Zuora creates a new effective-dated version through the existing merge logic.
Effective dating is implemented in one of two ways:
During PRPC creation (OOB Behaviour)
During PRPC editing (UI or API)
During PRPC creation (OOB Behaviour)
When defining attributes for a rate card during PRPC creation, Zuora automatically creates a reserved attribute:
{
"name": "EffectiveDate",
"type": "Datetime"
}
You can use the EffectiveDate field to specify when the pricing should take effect while building the rate card, instead of waiting until after the rate card is saved. If you do not specify an Effective Date, Zuora applies the default EffectiveDate behavior when the rate card is saved.
The EffectiveDate field is system-seeded automatically with the current UTC datetime when a charge is first created.
All subsequent price updates are automatically effective-dated. This means that every price change creates a new version valid from that timestamp onward.
While Editing a PRPC
All subsequent price updates are automatically effective-dated. Each price change creates a new version that becomes valid from the applicable timestamp onward.
When editing a Product Rate Plan Charge (PRPC) via the API or UI:
UI - The system automatically uses the current UTC timestamp as the EffectiveDate. This creates a new version of the price behind the scenes, and no manual input is required.
API - You have two options:
You can schedule a future price version by explicitly providing an
EffectiveDate, which must be a future datetime.You can omit the
EffectiveDateto have the system automatically use the current UTC timestamp.
Note:Setting a past EffectiveDate is not supported in UI and not recommended in API, as it overwrites all future-dated prices.
Retire rate card rows with Ineligible
Pricing Admins can now retire rate card rows without deleting them. To retire a row, set its price to Ineligible. The row remains stored for historical reference, but it is excluded from pricing evaluation. This provides a non-destructive way to phase out pricing configurations while preserving full audit history. Previously, rate card rows remained permanently active, which made it difficult to stop a row from participating in price determination without losing the historical record.
When a row is marked as Ineligible, Zuora applies the same versioning behavior used for other price updates. The existing row is end-dated with its original price preserved, and a new row is created with a price of Ineligible and an effective date based on the current timestamp or a specified future date. Future-dated retirements are also supported.
Ineligible rows do not participate in price determination. Historical and future evaluations remain deterministic because prior prices, date ranges, and attribute combinations are preserved for audit and reporting.
Restrictions on past Effective Dates
To preserve pricing integrity and prevent unintended price overrides, Zuora restricts past-dated EffectiveDate updates for existing Dynamic Pricing rate card rows when the charge is linked to a subscription.
If the charge is linked to a subscription, you cannot update the EffectiveDate of an existing row to a date earlier than the current UTC timestamp. If the charge is not linked to a subscription, you can update the EffectiveDate of an existing row to a past date.
If you try to update an existing row to a past EffectiveDate for a subscribed charge, Zuora rejects the request and displays the error message, Effective Date cannot be updated to a past date.
This validation is enforced in both the UI and API.
Existing rows with historical EffectiveDate values remain valid for pricing evaluation. However, for subscribed charges, you cannot resubmit or update an existing row with an EffectiveDate that is already in the past, including price-only updates to a historical row. To update pricing for a subscribed charge, use the current UTC timestamp or a future EffectiveDate so that Zuora creates a new effective-dated version.
Show rate card dates and times in the tenant timezone
When you view rate card date and time fields in the Dynamic Pricing UI, Zuora displays those values in your tenant's configured timezone. This applies consistently across the rate card UI so that effective dates and other time-based values are shown in the same timezone context as the rest of your tenant configuration.
If your tenant timezone is UTC, the displayed values remain in UTC.
This change affects only how values are displayed in the UI. The existing backend timezone implementation, API behavior, and persisted data remain unchanged.