> 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/product/customer-success-portal/discounts-and-the-recurring-total.md). # Discounts and the Recurring Total Every subscription card shows a **Recurring total** at the bottom — the amount the customer pays each period once every discount is applied. Most of the time it needs no explanation. The moment it does is almost always the same moment: a subscription carries **two or more discounts**, someone adds the percentages together in their head, and the number on screen doesn't match. It isn't meant to. This article explains what the total represents, where its numbers come from, and walks through the cases that surprise people. ## Where these numbers come from PeakCommerce does not calculate discounts. It **reads the amounts the billing system says it will charge** and displays them. That distinction matters more than it sounds. Billing systems apply discounts according to their own rules — the order discounts were added, whether they stack, whether one discount applies on top of another's result, whether a charge is prorated this period. Those rules live in the billing system's configuration, and they can be changed there without anyone touching PeakCommerce. If we reproduced that logic here, our figure and the invoice would drift apart the first time a setting changed, and the customer would be told one number and billed another. So the rule is simple: **the invoice is the source of truth, and the card shows what the invoice will say.** One consequence is worth knowing up front: if you change a discount in the billing system, the card reflects it as soon as the change is committed — not on some refresh cycle of ours. ## It's a rate, not the next invoice The Recurring total is a **steady-state figure** — what this subscription costs in a full billing period. It is deliberately *not* the amount of the next invoice. Those two differ whenever a period is partial. A customer who signs up on the 26th of a month, on an account that bills on calendar months, gets a short first invoice covering 26th–31st only. The card still shows the full monthly rate, because that is what the subscription costs — a rate of "$1.67" would be true of six days and misleading about everything after them. To see what the customer will actually be invoiced next, use **Billing & Invoices**. *** ## Worked examples Every example below uses the same starting point: an **Essentials** plan at **$14.00 / month**. ### One discount A single **30%** discount. ``` Essentials $14.00 30% discount -$4.20 Recurring total $9.80 ``` Nothing surprising. 30% of $14.00 is $4.20. ### Two discounts — the one that catches people out Now add a second discount of **15%** alongside the 30%. The instinct is 30 + 15 = 45%, so $14.00 − 45% = **$7.70**. The card shows **$8.33**. ``` Essentials $14.00 30% discount -$4.20 ← 30% of 14.00 15% discount -$1.47 ← 15% of 9.80, not of 14.00 Recurring total $8.33 ``` The second discount is applied to what remains **after** the first, not to the original price. The effective combined discount is 40.5%, not 45%. This is a normal, deliberate billing-system behaviour, not an error — and it is the single most common reason a Recurring total doesn't match a mental calculation. Whether discounts combine this way or apply independently depends on how each discount is configured in the billing system, which is exactly why PeakCommerce reads the result rather than guessing at it. > **If a customer questions the figure**, the honest and correct answer is that the discounts apply in sequence. The invoice will show the same three lines. ### A discount that expires Discounts often run for a fixed number of periods. If the 30% discount above is set to last three billing periods, the total changes on its own when it lapses: ``` While both are active $8.33 / month After the 30% discount ends $11.90 / month ← 15% of 14.00 ``` Nothing needs to be done for this to happen, and no one gets a notification. If a customer calls about a total that "went up without warning," an expiring discount is the first thing to check — the subscription card shows each discount as its own line, so an expired one simply won't be there any more. ### A 100% discount used as a free trial Some teams grant a free period by applying a **100% discount** rather than setting prices to zero. Both approaches are valid, and they read differently on the card: ``` Essentials $14.00 100% discount -$14.00 Recurring total $0.00 ``` The plan and its price stay visible, which is usually what you want — the customer can see what they're getting and what it will cost when the discount ends. A subscription priced at zero instead would show $0.00 with no indication of the eventual price. ### A "negative discount" is a surcharge Some billing systems have no direct way to express a percentage-based *add-on*, so the convention is a discount with a **negative** percentage. A −20% "discount" is really a 20% markup. PeakCommerce renders these as what they are — a cost, not a saving: ``` Essentials $14.00 Premium support (20% of plan) +$2.80 Recurring total $16.80 ``` If you see a positive amount on a line that looks like a discount, this is why. It is adding to the bill, not reducing it. ### Metered and usage charges Usage charges are excluded from the Recurring total and called out separately beneath it ("Plus metered usage charges, billed in arrears"). They belong to what was consumed, not to what the subscription costs, and including them would make the headline figure move every time usage did. Usage charges still appear as their own rows on the card, with their rate and any included allowance, so nothing is hidden — it just isn't folded into a number that is meant to be stable. ### More than one billing cadence A subscription with both monthly and annual charges shows **two** Recurring totals, one per cadence. They are not blended into a single figure, because there is no honest way to express "$14 a month and $500 a year" as one number without inventing a conversion. *** ## When a total looks wrong Work through these in order: 1. **Count the discounts.** Two or more, and they almost certainly apply in sequence — see the worked example above. This resolves most questions. 2. **Check whether a discount has an end date.** An expiring discount changes the total with no other signal. 3. **Check whether the period is partial.** A mid-cycle signup, plan change, or cancellation produces a short invoice that will not match the monthly rate. Compare against **Billing & Invoices**, not the card. 4. **Look for a negative percentage.** A line that adds instead of subtracting is a markup, not a discount. 5. **Compare against the billing system directly.** The card shows what the billing system reports. If the two genuinely disagree, that is worth escalating — include the subscription number and what each side shows. ## Related * [Working with an Account](/product/customer-success-portal/working-with-an-account.md) — the account detail page these cards live on * [The Account Timeline](/product/customer-success-portal/account-timeline.md) — the history of changes to a subscription --- # 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/product/customer-success-portal/discounts-and-the-recurring-total.md?ask=&goal= ``` `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.