When two providers disagree on the service address: a worked number porting failure case

Short answer

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.

Visual briefFull-size diagram
A vertical case timeline for one 38-number port: submitted on day 1, it branches at the day 2 rejection for an address mismatch into a side track of ticket, CSR check showing Suite 120 and approval to resubmit, then rejoins with the day 4 supplement, firm order commitment and activation on day 8.
Illustrative case for a fictional business communications provider; not a real customer or port.

This case belongs to the number porting failure resolution guide, 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.

ElementIn this case
Port38 numbers, two clinic sites, one account with the old provider
ExceptionOld provider rejects the order: service address does not match its records
Root causeClinic moved from Suite 120 to Suite 400; old provider updated billing but not service address
Who diagnosedProvisioning analyst, using the old provider's customer service record (CSR)
Who authorizedProvisioning lead, approving resubmission with the CSR address
Checked resultNumbers 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.

FieldVersion 1 (day 1)Version 2 (day 4)Evidence for the change
Service addressSuite 400, from invoiceSuite 120, from CSRCSR reference on the ticket
Telephone numbers3838Unchanged
Old-provider account numberAs on invoiceAs on invoiceUnchanged
StatusRejected, address mismatchAccepted, commitment date returnedRejection code; acceptance
ApproverAnalyst submittedProvisioning lead approvedApproval 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 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 and warranty claims.

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. 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.

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, check the provider against who qualifies, and read the program terms before you introduce the provisioning director.

  1. Step 1Share your linkSend your personal link to a company you know.
  2. Step 2Company appliesThe company applies itself at /apply.
  3. Step 3Company signs and is paidThe company signs, delivers its data and is paid by SourceX under its agreement.
  4. Step 4You get your rewardYour 25% of the actual supplier payout. A reward becomes payable after SourceX has paid the referred company under its signed agreement and the payout conditions in the program terms are met, including finance approval and your tax and payment details.

Common questions

Is a rejected port a sign the provider did something wrong?

Usually not. Many business port rejections come from mismatches between what the customer supplied and what the losing provider holds. The value of the record is that it shows how the mismatch was found and fixed.

Why does the address on the order have to match the old provider's record rather than the true address?

Because the losing provider validates the order against its own customer service record. In this case the analyst chose to match the record on file so the port could proceed, and noted why; updating the record is a separate task.

Does the consultant need to see the ticket notes to judge whether cases like this exist?

No. The provisioning director can say whether rejections are logged as tickets, whether supplements keep earlier versions, and roughly how many ports were rejected each year. That is enough for an introduction.

Sources

  1. fcc.gov/consumers/guides/porting-keeping-your-phone-…
  2. docs.fcc.gov/public/attachments/FCC-10-85A1.pdf
  3. fcc.gov/enforcement/areas/privacy
  4. refer.sourcex.si/terms

Free resources

Know a company with valuable proprietary data?

Become a referral partner, get your link and introduce the company’s CEO (in an owner-run company, usually the owner). Referral partners can join from most countries. We can't work with partners in countries or regions under U.S. sanctions or on U.S. restricted-party lists. The companies you introduce should be based in the U.S., Canada and the EU, or in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia with at least 90% of their data in English.

Refer a company →

I own a business

Explore licensing your company's data directly to SourceX for AI training and evaluation. Start a short assessment; no uploads needed.

Start an assessment