A subscriber's service is working on the network but no subscription exists in billing. How did that happen, and what do you do about it?

The shapes this takes

There are only a few ways to arrive here, and naming them is most of the diagnosis.

The ordinary one is an activation that converged on the network and then failed further along its own task list. The access port was assigned, the credentials were written to the authentication store, the policy profile was pushed — and the step that creates the subscription in charging and billing timed out, errored, or was never reached because the orchestrator lost the order. The customer is online. Everything downstream of that missing subscription, including the invoice, behaves as though they do not exist.

The second is an acknowledgement lost in the other direction. The subscription creation succeeded and the response was never received, so the workflow retried, failed its retry budget, and rolled back what it thought it had done. Compensation removed a subscription that was in fact the only correct thing in the picture.

The third is human. A fault was resolved by configuring the element directly, a migration script ran outside the fulfilment path, or a bulk load populated the network from a spreadsheet. Nothing wrote back into the systems of record, because the person doing it was solving a different problem.

The fourth is a cease order that only half executed. The subscription was closed and the network configuration was not, so the service the customer thinks they cancelled is still carrying their traffic.

Why nobody noticed

The asymmetry here is the part worth saying out loud. Provisioned-and-unbilled is silent in every direction: no exception is raised, no monitor fires, and the one party who could report it has no reason to. Billed-and-unprovisioned announces itself within a day, because the customer rings up about a service they are paying for and cannot use.

That is why the two failures need completely different detection. The loud one is handled by the complaint path. The quiet one exists only if you go looking for it, which means a scheduled population reconciliation that compares the set of subscribers with configuration on the network against the set with an open subscription, in both directions, and treats every non-empty difference as a finding with an owner rather than as a report somebody reads.

flowchart TD
    R[Population reconciliation<br/>network set against subscription set] --> C{Classify the difference}
    C -->|order exists, stalled| D[Resume the order<br/>from stored intent]
    C -->|order completed, step lost| E[Re-drive the missing<br/>task idempotently]
    C -->|no order was ever placed| F[Investigate<br/>then deprovision]
    D --> G[Unbilled period<br/>referred to commercial policy]
    E --> G

The branch on the right is the one people leave out. A subscriber configured on the network with no order behind them is not a data gap to be filled in, and the next section is about why.

Repair from intent, not from whichever side looks convincing

The repair has to start from the order, because the order is the only artefact that records what was supposed to happen. If a stalled order exists, resume it: the tasks are idempotent, so replaying the ones that already succeeded is a no-op and the missing one runs. If the order completed and closed, raise a corrective task that re-drives the specific missing step with the same identity the original used, so a duplicate does not appear if the first attempt did in fact land.

What you must not do is write the missing subscription directly into billing. It gets the customer billed, which feels like the goal, and it leaves the order record still saying the activation failed, the inventory still unaware of the assignment, and no trace that a defect occurred. Six months later someone runs a cease against that order and reclaims resources from a live customer, because the record they are working from was never corrected.

The case where no order exists at all is the one that has to stay manual, and the reasoning generalises. A reconciliation job that creates subscriptions from observed network configuration will, given a mistaken bulk load, a lab configuration on a production element, or a deliberately provisioned service nobody paid for, convert each of those into a billed contract with a real customer's name on it. Billing someone for something they never ordered is a worse outcome than the leakage you were trying to close, and it is the sort of outcome a regulator reads about. Configuration with no commercial record behind it gets investigated and then removed, never adopted.

The unbilled period is a commercial question with a technical input

Once the subscription exists, someone has to decide what happens to the months already delivered. The technical part of that is narrow and you should offer it: you can state precisely when the service began carrying traffic, from usage records and from the element's own configuration history, so the size of the gap is a fact rather than an estimate.

The decision itself is not yours. Backdating the billing start date and issuing arrears produces a first invoice several times the expected amount for a customer who did nothing wrong, which in many jurisdictions runs into limits on retrospective charging and in all of them runs into a dispute. Starting the charge forward and writing off the gap is clean and costs real money. Most operators land on a policy — bill forward from a stated date, cap any arrears at a defined number of cycles, notify before the invoice rather than with it — and the point is that it is a policy, applied consistently, not a judgement made per ticket by whoever picked up the fallout. An engineer who quietly backdates the start date to the true activation date has made a pricing decision on the company's behalf.

What the interviewer is listening for after the fix

Every one of these tickets is evidence about a class, and the response that earns credit is asking how many others are in the same state right now. One divergence found by chance implies a rate; a rate implies either a defect in a particular task, a partner that acknowledges without completing, or a manual process that routinely bypasses the workflow. Fixing the single subscriber and closing the ticket leaves the generator running.

The structural remedy is that the systems of record must be reachable only through the fulfilment path, and where they are not — because an engineer genuinely needs to configure an element at three in the morning — the out-of-band action has to produce an event the workflow can consume, so the record catches up rather than diverging permanently.