Proration and Mid-Cycle Plan Changes: Getting the Invoice Right | HL Hunt

Proration and Mid-Cycle Plan Changes: Getting the Invoice Right | HL Hunt
Payments & AI

Proration and Mid-Cycle Plan Changes: Getting the Invoice Right

A customer on a $49 plan upgrades to $99 on day 11 of a 30-day cycle. They owe $31.67 today. Charging the full $99 is a $67.33 overcharge and it is the most common proration error there is. At 144 plan changes a month, an 8% error rate produces 138 wrong invoices a year and enough disputes to move a merchant toward a network monitoring threshold.

By the HL Hunt Research Desk · 15 min read · Updated September 2026

The arithmetic of a mid-cycle upgrade

A customer on a $49 monthly plan upgrades to $99 on day 11 of a 30-day cycle. They have 19 days of the cycle left. There is one correct answer and several common wrong ones.

ComponentCalculationAmount
Unused portion of the old plan$49 / 30 × 19$31.03 credit
Remaining portion of the new plan$99 / 30 × 19$62.70 charge
Net charged today$62.70 − $31.03$31.67
Next full cycleNew plan, full period$99.00

The common wrong answer is to charge $99 today on the reasoning that the customer is now on the $99 plan. That is an overcharge of $67.33, and it is an overcharge the customer can see, because they paid $49 ten days ago and are being asked for the full price of a month they have already partly paid for.

$67.33
The overcharge produced by billing a full $99 on a mid-cycle upgrade instead of the $31.67 that is actually owed. It is more than twice the correct amount, and it is the single most common proration error.

The second wrong answer is to charge nothing today and start the $99 next cycle. That gives away 19 days of the upgrade, which on this plan is $31.67 of revenue per upgrade event. It is a defensible commercial choice if it is made deliberately. It is usually not made deliberately. Per our recurring billing analysis, both errors come from treating the plan change as an event on the subscription rather than an adjustment to a period that is already partly consumed.

Why the downgrade is harder

Run the same change in reverse. A customer on $99 drops to $49 on day 11. The arithmetic is symmetric: $62.70 credit for the unused new portion, $31.03 charge for the remaining old portion, net $31.67 owed to the customer.

And that is where the design question sits, because there are three reasonable things to do with $31.67 and they are not equivalent.

TreatmentEffect
Refund it to the cardCleanest for the customer. Costs the interchange on the original charge, which is not refunded
Hold it as account creditNo fee cost. Per our subscription analysis, becomes a problem if the customer later cancels with a balance
Keep the service at the old tier until the period endsNo money moves at all. Usually the least disputed option

The third option is the one most mature billing systems default to, and the reason is the refund fee. Per our refund analysis, interchange on the original transaction is generally not returned when you refund, so a $62.70 refund costs the merchant roughly the interchange on $99 and returns nothing. Deferring the downgrade to the period boundary avoids the fee and avoids the proration entirely.

Account credit that outlives the account

Holding a downgrade credit is operationally easy and creates a liability with no expiry. A customer who cancels three months later with $31.67 of unused credit has a claim, and in many jurisdictions unclaimed customer balances become subject to unclaimed property rules. Per our dormant balance analysis, the amounts are individually small and collectively material, and a billing system that issues credits without a policy for cancellation with a credit balance is accruing an obligation nobody is tracking.

The volume that makes this a payments problem

One wrong invoice is a support ticket. The reason proration is a systems problem rather than a support problem is the rate at which it happens.

  • 2,400 active subscribers
  • 6% change plans in a given month, which is 144 proration events
  • At an 8% error rate, that is 11.5 wrong invoices a month, or 138 a year
  • If 25% of errors become disputes, that is 2.9 disputes a month

Against 2,400 monthly transactions, 2.9 disputes is 0.12%, which is enough to matter. Per our dispute ratio analysis, card network monitoring thresholds sit in this range, and a merchant whose underlying dispute rate is already near the threshold can be pushed over it entirely by proration errors on plan changes, which is a billing-logic defect producing a payments-compliance consequence.

Proration errors look like billing bugs and arrive as disputes

At 144 plan changes a month, an 8% error rate produces 138 wrong invoices a year and 0.12% of extra dispute volume. HL Hunt AI Payment Processing handles proration, plan changes and mid-cycle adjustments as part of the billing flow, so the calculation does not depend on whoever wrote it last.

See How HL Hunt AI Payment Processing Works

The cases that break naive proration

Dividing by 30 works until it does not. These are the cases where a simple day-count calculation produces a wrong number.

CaseWhat goes wrong
Months of different lengthsA February cycle has 28 days, so a fixed /30 divisor misprices every change in it
Annual plansA mid-year upgrade on an annual term prorates over 365 days, and the amounts are large enough to be noticed
Multiple changes in one cycleEach must prorate from the last change, not from the cycle start
A plan with included usagePer our usage billing analysis, allowances do not prorate the same way as fees
Discounts and couponsA 20% coupon must apply to the prorated amount, not the list price
TaxTax is recalculated on the net, and a credit line can change the taxable base
A change during a failed paymentPer our failed payment analysis, prorating against an unpaid invoice compounds the error

The third row is the one that produces the worst invoices. A customer who upgrades on day 8 and upgrades again on day 20 must have the second change prorated against the price they are actually on, not the price they started the month on. Systems that recompute from the cycle start double-credit the first change, and the resulting invoice is not explicable to the customer or to the person handling the ticket.

The second row is the one that produces the largest single errors. On an annual plan the prorated amounts run into hundreds of dollars, so an error of a few percent is a dollar figure a finance team notices, and per our B2B card analysis on larger accounts it arrives as a purchase-order mismatch rather than a complaint.

Make the invoice explain itself

Most proration disputes are not about the amount. They are about the fact that the amount is unexplained, and the fix is presentation rather than arithmetic.

An invoice that says "$31.67" invites a question. An invoice that says "Unused Starter, 19 days: credit $31.03. Pro, 19 days: $62.70. Net due: $31.67" answers it before it is asked.

This matters at the statement level too. Per our descriptor analysis, a customer who sees an unexpected $31.67 on a card statement from a merchant they believe they pay $49 to has no way to connect it to anything, and per our chargeback analysis an unrecognized amount is the most common origin of a dispute that the merchant would win on the facts and loses on the paperwork.

The case for not prorating at all

A real alternative exists and it is not obviously worse. Charge the full new price at the next cycle, make the upgrade effective immediately, and give the remainder of the current period at the new tier for free. Every number disappears: no credits, no adjustment invoices, no mid-cycle statement entries, no disputes about amounts nobody recognizes. The cost is $31.67 of revenue per upgrade event, which at 144 changes a month is not trivial. The honest comparison is that figure against the support cost, dispute cost and engineering cost of doing proration correctly, and for a small subscriber base the free-upgrade policy frequently wins. It becomes the wrong answer as volume grows and as the price gap between tiers widens.

Getting it right

  1. Pick a proration basis and write it down. Days in the actual cycle, or seconds, or a fixed 30. All three are defensible; switching between them is not.
  2. Prorate from the last change, not the cycle start. This is the single most common logic defect.
  3. Decide what a downgrade does before you have one. Deferring to the period boundary avoids both the refund fee and the proration.
  4. Have a policy for cancellation with a credit balance, because that is where the unclaimed property exposure sits.
  5. Apply discounts to the prorated amount and recompute tax on the net.
  6. Never prorate against an unpaid invoice. Resolve the payment first, per our failed payment analysis.
  7. Show the credit and the charge as separate lines. Per our reconciliation analysis, this is also what makes the entry reconcilable later.
  8. Test the February case and the double-change case. They are the two that production finds for you.

Item one sounds procedural and is the one that prevents the worst class of bug. A system where the upgrade path divides by the actual day count and the downgrade path divides by 30 produces credits and charges that do not net, which means a customer who upgrades and then immediately downgrades does not return to where they started.

What to monitor

MetricWhy
Proration events per monthThe denominator for everything else
Invoices manually corrected after issueThe real error rate, which is rarely the assumed one
Disputes traceable to a plan changePer our dispute handling analysis, this links billing logic to the dispute ratio
Credit balances held, and their ageThe liability that accrues quietly
Refund fees paid on downgrade refundsPer our statement audit analysis, often invisible on the statement
Net proration revenue, upgrades less downgradesTells you whether the policy is costing or earning

The second row is the only honest measure of correctness. A team that believes its proration is right because nobody has complained is measuring customer tolerance rather than accuracy, and the count of invoices someone had to fix by hand is the number that cannot be argued with.

The invoice has to explain itself

Most proration disputes are not about the amount but about an amount with no explanation attached. HL Hunt AI Payment Processing produces itemized credit and charge lines, consistent descriptors and reconcilable records on every mid-cycle adjustment.

Talk to HL Hunt About Payment Processing

Frequently asked questions

How do you calculate proration on a mid-cycle upgrade?

Credit the unused old plan and charge the remaining new plan. On $49 to $99 with 19 days left, that is $31.67 due now.

What should happen to the credit when a customer downgrades mid-cycle?

Most systems defer the downgrade to the period boundary, which avoids both the refund fee and the proration. Refunding costs unreturned interchange.

Why do proration errors turn into card disputes?

Because an unexplained amount on a statement is unrecognizable. At 144 changes a month, errors can add 0.12% to the dispute ratio.

Is it ever better not to prorate at all?

Often yes at low volume. Giving the remainder of the period free costs about $31.67 per upgrade and removes every adjustment invoice and dispute.

Key takeaways

  • A $49 to $99 upgrade with 19 days left owes $31.67: a $31.03 credit against a $62.70 charge.
  • Billing the full $99 is a $67.33 overcharge; billing nothing gives away $31.67 per upgrade.
  • Downgrades are harder because the credit can be refunded, held, or avoided by deferring to the period boundary.
  • Refunding costs interchange that is generally not returned, which is why most systems defer downgrades.
  • At 2,400 subscribers and 6% monthly changes, an 8% error rate gives 138 wrong invoices a year.
  • Those errors can add 0.12% to the dispute ratio, which is a billing defect with a payments-compliance consequence.
  • Prorating from the cycle start rather than the last change is the most common logic defect.
  • At low volume, not prorating at all can be the better policy, at about $31.67 of revenue per upgrade.

This guide is educational and does not constitute financial, accounting, tax, or legal advice. All figures are stylized illustrations using assumed plan prices, cycle lengths, subscriber counts, plan-change rates, error rates, and dispute conversion rates, and do not describe any particular business or billing system. Card network dispute monitoring thresholds, interchange treatment on refunds, sales tax treatment of credits, and unclaimed property rules governing customer credit balances vary by network, processor, and jurisdiction and change over time; consult your processor and a qualified adviser before setting billing policy.