Prepaid Subscription Reporting
What changed
Two updates were made to how Chord reports on prepaid subscription orders in April 2026:
- Subscription classification — Prepaid subscription parent orders (the upfront payment order) are now correctly counted as part of a subscription. Previously, they were excluded.
- Revenue recognition — Revenue is now recorded on the prepayment order — the order where the customer actually paid. Previously, revenue was spread across each installment shipment order instead.
These are corrections to how data was being modeled. Your total subscription revenue hasn't changed — only when and where it appears in reports.
Background: How prepaid subscriptions work
When a customer purchases a prepaid subscription plan, Chord creates two types of orders:
- The prepayment (parent) order — the single upfront transaction where the customer pays in full (e.g., $440 for a 20-week plan).
- Installment orders — the individual shipment orders generated automatically as the plan progresses (e.g., 20 weekly orders at $0 each, since payment was already collected).
Previously, the prepayment parent order was excluded from subscription reporting and booked $0 in revenue. Instead, each installment order claimed its share (e.g., $22 each). That meant revenue appeared on the wrong orders and was spread across shipment dates rather than the purchase date.
What you'll see in your reports
Subscription order counts will increase
Any report that counts subscription orders will now include prepayment parent orders, which were previously excluded. The increase reflects the number of prepaid subscription purchases in your reporting window — not new sales.
Revenue will shift to the prepayment date
Gross and net revenue that was previously spread across installment orders will now appear on the prepayment parent order.
Example — $440 plan, 20 weekly installments:
Order | Revenue (Before) | Revenue (After) |
|---|---|---|
Prepayment order (Jan 1) | $0 | $440 |
Installment #1 (Jan 8) | $22 | $0 |
Installment #2 (Jan 15) | $22 | $0 |
… (×20 total) | | |
Total across the plan | $440 | $440 |
The total is the same. The difference is timing and placement.
Reports spanning partial plan windows may look different
If a reporting window includes the prepayment order but not all its installments (or vice versa), revenue will appear to shift in or out compared to previous snapshots. This is expected — it reflects the corrected timing, not a revenue discrepancy.
What to do
Most brands don't need to take any action. Your overall revenue figures are correct. The change affects how revenue is distributed across individual orders and dates.
If you or your team use custom reports or data exports that filter or aggregate prepaid subscription data, review the following:
- Subscription counts — Expect higher counts in dashboards filtered by subscription orders. This is accurate.
- Monthly revenue by subscription orders — Expect larger values on prepayment dates and $0 on installment shipment dates, rather than an even spread.
- Subscription customer metrics — First-subscription dates, subscriber counts, and cohort data may appear earlier than in prior snapshots, since prepayment orders are now included.
For analysts: Field-level details
All changes are on the ChordOMS transactional orders table:
Field | What changed |
|---|---|
order_is_part_of_subscription | Now true for prepayment parent orders. Previously excluded them. |
gross_revenue | Full plan value now on the prepayment parent. Installment redemption orders are $0. |
net_revenue | Same as above — full value on prepayment parent, $0 on installments. |
order_is_pre_paid_purchase | No change. |
order_is_pre_paid_redemption | No change. |
pre_paid_purchase_total | No change. Tracks cash received on the prepayment order. |
pre_paid_redemption_total | No change. Tracks value drawn down per installment. |
subscription_pre_paid_subscription_id | No change. |
If your reports sum gross_revenue or net_revenue across installment orders to measure prepaid revenue, update them to read from the prepayment parent order instead.
If you need shipment-timed revenue allocation (e.g., to model deferred revenue), use pre_paid_redemption_total on installment orders. This field is unaffected by the change.