# Number porting failure: a worked case | SourceX

Canonical: https://refer.sourcex.si/guides/number-porting-failure-resolution-exception-examples
Last updated: 2026-10-18

The records that explain a failed port are the ones that keep the "before" beside the "after": the port order as first submitted, the rejection with its reason code, the evidence used to diagnose it, the approval to resubmit, and the accepted corrected submission with its activation result. An order that simply reads "complete" says nothing about the failure. The case below follows one business port through a common exception and names the record each step leaves.

This case belongs to the [number porting failure resolution guide](/guides/workflow-number-porting-failure-resolution), which covers what to inventory before a provisioning migration. Here the job is to show one exception from end to end, then turn it into a way of spotting similar cases at a client.

## The case in one table (Illustrative)

Illustrative and invented for this page: a fictional 260-person business communications provider ports 38 numbers for a multi-site clinic group. It is not a real case, customer or port.

| Element | In this case |
|---|---|
| Port | 38 numbers, two clinic sites, one account with the old provider |
| Exception | Old provider rejects the order: service address does not match its records |
| Root cause | Clinic moved from Suite 120 to Suite 400; old provider updated billing but not service address |
| Who diagnosed | Provisioning analyst, using the old provider's customer service record (CSR) |
| Who authorized | Provisioning lead, approving resubmission with the CSR address |
| Checked result | Numbers active on day 8, test calls passed at both sites |

The FCC treats a port as "simple" only when it involves a single-line account with no unbundled network elements, no complex switch translations and no reseller; simple ports must be processed within one business day. A 38-number multi-site account is not simple, so it carries more fields to validate and more room for exactly this kind of mismatch.

## Day by day: from rejection to activation

Each step gives the decision, who made it and the record it left.

1. **Day 1, submitted.** The order platform records the purchase order number, the 38 numbers, the clinic's account number with the old provider, and the service address copied from the clinic's latest invoice: Suite 400. *Record:* original port order, version 1.
2. **Day 2, rejected.** The old provider returns the order with a reason code meaning the address does not match its records. *Record:* rejection with reason code in the order platform, and a copy in the provisioning team's shared mailbox.
3. **Day 2, ticket opened.** The service desk logs the rejection against the clinic's account and calls the office manager, who explains the move and suspects the old provider changed only the billing address. *Record:* ticket with call notes.
4. **Day 3, diagnosed.** The analyst requests the CSR, which still lists Suite 120, attaches the CSR reference to the ticket and notes that only the service address field differs. *Record:* CSR reference and analyst note.
5. **Day 3, authorized.** The provisioning lead approves resubmitting with the address exactly as it appears on the CSR, recording why: the customer's authorization covers the numbers, and the order must match the losing provider's record to validate. *Record:* approval comment on the ticket or supplement.
6. **Day 4, resubmitted.** A supplement to the original order goes in with the CSR address. The old provider accepts and returns a firm order commitment date. *Record:* supplement, version 2, and the commitment date.
7. **Day 8, checked.** The numbers activate, test calls succeed at both sites, the ticket closes, and the account notes are updated so the clinic's next port uses the CSR address from the start. *Record:* activation timestamp, test-call note, closure code.

## Before and after: the fields that changed

The evidence value sits in the difference between version 1 and version 2, and in the note that explains it.

| Field | Version 1 (day 1) | Version 2 (day 4) | Evidence for the change |
|---|---|---|---|
| Service address | Suite 400, from invoice | Suite 120, from CSR | CSR reference on the ticket |
| Telephone numbers | 38 | 38 | Unchanged |
| Old-provider account number | As on invoice | As on invoice | Unchanged |
| Status | Rejected, address mismatch | Accepted, commitment date returned | Rejection code; acceptance |
| Approver | Analyst submitted | Provisioning lead approved | Approval comment |

If the platform overwrote version 1 when the supplement went in, the first row of this table disappears and the case reads as an ordinary port. The [cross-system map for porting records](/guides/number-porting-failure-resolution-records-across-systems) shows which keys keep the versions and the ticket joined.

## Why days 2 and 3 carry the evidence

Days 2 to 3 hold a business problem, the reasoning applied to it, the person with authority to act and the basis for acting. Day 8 supplies the checked outcome that makes the reasoning verifiable. Together they form the pattern that makes any exception record explain itself, the same shape described for [logistics exceptions and their resolutions](/guides/how-to-identify-logistics-exceptions-and-their-documented-resolutions) and [warranty claims](/data-types/warranty-claims-data).

The FCC's consumer guidance also says an old provider cannot refuse to port a number because the customer owes a balance or termination fee. So a rejection on file has to rest on something other than an unpaid balance, often a mismatch in the order data, which is what makes the diagnosis step informative rather than political.

## Recognizing similar port failures at a client

A telecom systems consultant can spot this pattern without opening an order. Ask the provisioning director:

- "Roughly how many business ports a year are rejected at least once?"
- "Are rejections logged as service desk tickets, or handled only in the shared mailbox?"
- "When a supplement goes in, does the platform keep the earlier version?"
- "Do analysts record the CSR reference and the reason for resubmitting?"
- "Is the activation result tied back to the ticket before it closes?"

Mostly yes answers suggest the company holds cases like this one. Port orders carry customer account details, and carriers have a duty under Section 222 of the Communications Act to protect customer proprietary network information, so record only metadata: years, rough counts, systems, owners. Who can authorize a discussion is covered on [who can license number porting failure records](/questions/who-can-license-number-porting-failure-resolution-records). The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Whether copies of another provider's CSR can be licensed stays unknown until SourceX's rights review. Neighboring record types are on the [telecommunications page](/industries/telecommunications).

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If a provider's rejected ports still carry their original versions, tickets and approval notes, [register as a partner](/register), check the provider against [who qualifies](/who-qualifies), and read the [program terms](/terms) before you introduce the provisioning director.

## Sources

- https://www.fcc.gov/consumers/guides/porting-keeping-your-phone-number-when-you-change-providers
- https://docs.fcc.gov/public/attachments/FCC-10-85A1.pdf
- https://www.fcc.gov/enforcement/areas/privacy
- https://refer.sourcex.si/terms