> For the complete documentation index, see [llms.txt](https://docs.chord.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.chord.co/chord-oms/chord-oms-overview/subscriptions/prepaid-subscription-reporting.md).

# Prepaid Subscription Reporting

## Prepaid Subscription Reporting

## What changed

Two updates were made to how Chord reports on prepaid subscription orders in April 2026:

1. **Subscription classification** — Prepaid subscription parent orders (the upfront payment order) are now correctly counted as part of a subscription. Previously, they were excluded.
2. **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.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.chord.co/chord-oms/chord-oms-overview/subscriptions/prepaid-subscription-reporting.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.