Skip to content
QSWEQB
mediumScenarioConceptMidSenior

Take me through a bill cycle, then tell me what the invoice looks like when a customer changes plan mid-cycle and disputes the result.

A cycle closes a period, assembles recurring, usage and one-off charges, applies discounts and tax, then issues an invoice that must never be edited afterwards. A mid-cycle change produces a credit for unused advance rental plus a prorated new charge, which is what customers dispute.

5 min readUpdated 2026-07-26

What the interviewer is scoring

  • Does the candidate know why cycles are staggered across the subscriber base
  • Whether recurring charges are understood to be billed in advance and usage in arrears
  • That an issued invoice is corrected by a new document rather than by being regenerated
  • Whether a dispute is scoped to the disputed amount instead of freezing the whole account
  • Does the candidate propose leakage checks that reconcile counts between stages, not just totals

Answer

What a cycle run does

Subscribers are divided into bill cycle groups, each with its own cut-off date, so that a base of millions is billed as a series of manageable runs spread across the month rather than as one enormous job on the first. That staggering is not only about compute: it spreads the call volume that follows every bill, and it means a defect in one run affects a fraction of the base and can be caught before the next.

When a group's cut-off arrives, the period closes and the run assembles the invoice from three kinds of charge. Recurring charges come from the subscription and are almost always billed in advance, covering the period that is about to start. Usage charges come from rating and are necessarily in arrears, covering the period that has just ended. One-off charges — activation fees, hardware instalments, engineer visits, credits already agreed — come from wherever they were raised. Discounts and bundle allowances are then applied, which is the step most sensitive to ordering, because a percentage discount and a fixed credit produce different results depending on which goes first. Tax is calculated on the resulting lines, the invoice is rendered and issued, and the amount enters the receivables ledger where payment collection and, failing that, dunning take over.

Two properties of that pipeline matter more than the sequence. It closes the period, meaning nothing may be added to a period once it is billed without an explicit restatement path. And it produces a document, not a number.

Proration on a mid-cycle change

Take a monthly cycle running the 1st to the 30th, a customer on a £30 plan who upgrades to a £45 plan with effect from the 11th, and a convention that the old plan is charged through the 10th inclusive.

The arithmetic itself is unremarkable. Ten days of the old plan is 10/30 × £30 = £10, and twenty days of the new one is 20/30 × £45 = £30, for £40 of rental in that month. What surprises customers is the shape of the invoice, because the £30 for the whole month was already charged in advance on the previous bill:

LineAmount
Standard plan, monthly rental in advance, 1–30already billed, £30
Credit, unused standard rental, 11–30−£20
Premium plan, prorated rental, 11–30£30
Net effect of the change£10

Three lines for one change, one of them a credit, and none of them equal to the difference between the two plans. This is the single largest source of billing contacts at any operator that lets customers change plans, and a candidate who can explain the credit line has explained most of the call volume.

Two details decide whether your proration is defensible. The day count convention must be stated and consistent — calendar days in the actual month, or a fixed thirty-day month — because the two disagree in February and the discrepancy will be noticed. And the effective date is a property of the subscription, not of the moment someone clicked a button, so a change requested on the 11th with effect from the 15th prorates from the 15th.

A bill you cannot reconstruct is a bill you cannot defend

That last point generalises into the thing this question is really probing. Proration must be computed from the same effective-dated subscription timeline that rating uses to price usage. When billing keeps its own notion of "the customer's current plan" — a mutable field updated when the change is applied — the invoice and the rated usage are derived from two different histories, and they will disagree for any customer who changed anything mid-period.

The requirement is that every line on every invoice can be regenerated from versioned inputs at any later date: which subscription version was in effect over which interval, which tariff version priced each usage record, which discount rule matched and why. Systems that store only the outcome pass their first audit and fail their first serious dispute, because the answer to "why was I charged this" is "that is what the system produced," and that answer costs the operator the money whether or not the charge was right.

Disputes and adjustments

An issued invoice is an accounting and tax document that the customer already holds a copy of. Correcting it by regenerating it is wrong even when the corrected figure is right, because it destroys the audit trail, breaks the reference the customer is quoting, and puts the ledger out of step with a document that exists in the world.

Corrections are therefore new facts appended to the account: an adjustment or credit note that references the original invoice line, carries a reason code, an amount, an operator identity and an approval where the amount warrants one. Reason codes are worth insisting on, because they are the only way to learn that a particular tariff or a particular retention script is generating most of your goodwill credits.

While a dispute is open, suspend collection on the disputed amount and only on that amount. Freezing the whole balance stops dunning on money nobody contested and turns a £4 argument into an unpaid bill; chasing the whole balance regardless makes the dispute process theatre. Both mistakes are common, and the interviewer is listening for the distinction.

Finding leakage before the auditors do

Revenue leakage is service delivered and not billed, and it hides in the gaps between systems rather than inside any one of them. The technique that works is reconciliation by count and value at every hand-off, run every period and alerted on as a control: records emitted by the network elements against records accepted by mediation, records accepted against records rated, records rated against records invoiced. Any stage where the counts do not reconcile has either lost usage or duplicated it, and knowing which stage narrows a vague suspicion into a defect.

Alongside that, run population reconciliations in both directions, because the two failures are not symmetric. Subscribers active in the network inventory with no billing subscription are unbilled service, which is direct lost revenue. Subscribers billed with nothing provisioned are billing for nothing, which is worse in a different way, because it is a refund liability and a regulatory exposure rather than a shortfall. Add ageing of unbilled usage, since usage sitting rated but uninvoiced past a cycle boundary points at something stuck, and monitoring of discounts applied outside the catalogue's permitted ranges, which is where a well-intentioned retention team quietly gives away a margin nobody has budgeted for.

Likely follow-ups

  • Why is regenerating an invoice with the corrected figure the wrong fix, even though it looks cleaner?
  • Where do you get the day count for proration, and what happens in February?
  • Which reconciliation would catch a subscriber active on the network but absent from billing?
  • How would you decide whether an adjustment needs approval before it is applied?

Related questions

billingprorationinvoicingdisputesrevenue-assurance