The requirement that decides how fast a CPaaS reseller can deliver numbers to its customers isn’t provisioning speed. It’s whether the right documents for the right number type in the right country arrive complete the first time.
DID regulatory requirements are the documents and details a country’s regulator, or the number provider on its behalf, requires before a phone number can be assigned to an end user. They typically cover who the end user is, where they’re located, and sometimes what the number will be used for. They vary by country and by number type within a country, and for resellers, they’re the most common reason provisioning stalls.
This post treats the problem the way an enterprise architect would: as a data-governance and workflow question. The goal is a process where no order sits waiting on paperwork nobody knew was needed.
Why this is a reseller problem first
A reseller sits between the end user who holds the number and the carrier that assigns it. That position makes documentation the reseller’s problem in practice, even when the obligation belongs to someone else.
The end user doesn’t know the rules and doesn’t want to learn them. The carrier won’t activate numbers without the documents. The reseller is the only party with a relationship on both sides, so it becomes the collector, the validator and the one fielding the customer’s “why isn’t my number live yet?”
That’s also why ad hoc handling fails. A reseller that collects documents by email, one order at a time, will eventually lose a document, submit an expired one, or send the same end user’s passport to three different places. Each failure costs days. At scale, it costs customers.
The document categories you’ll see
Requirements differ in detail, but most countries draw from the same short list of categories. Designing around categories rather than countries keeps the intake process manageable.
End-user identity. For a business, usually the registered company name and a registration or tax identifier. For an individual, a government-issued ID. The name must match across every other document.
Address. Proof of the end user’s address, such as a utility bill, bank statement or registration extract, often required to be recent. Some number types require the address to be in the country.
Local presence. A stricter form of the address rule. Some geographic numbers require an address within the specific area the number belongs to. Germany’s geographic numbers are a well-known example; our guide to opening a local support line without an entity explains how national numbers work around it.
Business registration. A certificate of incorporation or equivalent extract, sometimes translated or recent.
Use declaration. A statement of how the number will be used. Some countries or number types restrict usage, for example to exclude certain outbound calling.
Authorized signatory. Confirmation that the person submitting the request is entitled to act for the business.
Not every country asks for every category. Some ask for none beyond basic details. But if your intake process can capture all six in a structured way, you can meet almost any requirement without redesigning the flow.
Build a country and number-type matrix
The core artifact is a matrix: rows for each country and number type you sell, columns for each document category, and a cell value saying whether it’s required, conditional, or not needed.
A simplified structure looks like this:
| Country / number type | Identity | Address | Local presence | Registration | Use declaration | Notes |
|---|---|---|---|---|---|---|
| Country A, geographic | Required | Required | Required | Conditional | No | Address must be in area code |
| Country A, national | Required | Required | No | Conditional | No | Common workaround for no local office |
| Country B, geographic | Required | No | No | No | No | Basic details only |
| Country C, mobile | Required | Required | Required | Required | Required | Restricted use |
The real matrix comes from your carrier. Ask for it in writing, per number type, and ask how often it’s updated. Store it as data your ordering system can read, not as a PDF someone consults.
Once the matrix is data, three things become possible. Your order form can show end users only the fields their chosen number requires. Your sales team can see before quoting whether a customer can even qualify for a number type. And your ops team can tell, the moment a rule changes, which pending and existing orders are affected.
An intake workflow that doesn’t stall
The workflow that works is structured, validated early and reusable. Each step closes a specific failure.
1. Collect at order time, not after
Ask for documents when the customer orders, driven by the matrix. The worst pattern is accepting an order, submitting it, and learning from a rejection what was missing. Every round trip adds days.
2. Validate before submission
Check what you can mechanically: file type and legibility, document dates against recency requirements, name consistency across documents, and address location against local-presence rules. A surprising share of rejections come from fixable issues: a cropped scan, a name abbreviated differently on two documents, a bill older than the window allows.
3. Store once, reference many times
An end user who orders five numbers in one country shouldn’t upload their registration certificate five times. Store documents against the end-user record, with expiry dates, and reference them from each order. When a document expires, flag every number that depends on it.
4. Track status per order
Record where each order is: awaiting documents, validating, submitted, approved, rejected with reason, active. Show the customer the same status. “Your German number is waiting on proof of a Berlin address” is a far better message than silence.
5. Re-verify on a schedule
Some requirements continue after activation. Addresses change, companies are restructured, documents expire. Build periodic re-verification into the process for the countries that require it, so a regulator’s audit or a carrier’s request doesn’t catch you with stale records.
Data governance: you’re holding sensitive documents
Collecting identity and address documents for your customers’ customers makes you a custodian of sensitive personal and business data. Treat it as a governance matter from day one.
Decide who can access documents and log that access. Encrypt them at rest. Set retention periods that match what the requirements need, and delete documents when they’re no longer required. Keep documents separated per end user and per tenant, so one customer’s records can never surface in another’s order. If you run a multi-tenant platform, our guide to multi-tenant DID inventory for ISVs covers how that separation extends to the numbers themselves.
Your legal team should decide the specifics for the jurisdictions you operate in. The architectural point is that a documents store with no ownership, no access controls and no retention policy will become a problem regardless of which regulator notices first.
The most common rejection reasons
Knowing why submissions fail tells you what to validate. The usual culprits:
- Name mismatch. “ACME Ltd” on the registration, “Acme Limited” on the bill, “ACME UK” on the order.
- Stale documents. A proof of address older than the accepted window.
- Wrong address location. A national address submitted for a number that needs one in the specific area.
- Illegible or partial scans. Cropped edges, glare, missing pages.
- Unsupported document type. A document the regulator doesn’t accept as proof, even if it looks official.
- Missing translation. Where the country requires documents in a specific language.
Each of these can be caught before submission. If your rejection rate is high, the fix is almost always in validation, not in the carrier relationship. For problems that appear after a number is active, such as calls not arriving, see our guide to resolving common DID setup issues.
Set customer expectations honestly
Resellers lose trust by promising activation dates before documents are approved. Quote timelines from the point of approved documents, not from the order. Where the matrix shows a strict requirement, say so on the order page. Customers accept a requirement they were warned about; they resent one that surfaces a week in.
If a customer is moving existing numbers to you rather than ordering new ones, the documentation question overlaps with the porting process, which has its own paperwork; see our guide to porting numbers with LOA and FOC.
When the rules change
Requirements aren’t static. Regulators revise number rules, and carriers update what they accept. Assign an owner for the requirements matrix, ask your carrier how it announces changes, and when a rule changes, run the affected-orders query the matrix makes possible. Pending orders may need new documents before submission; active numbers may need re-verification by a deadline. Treat a rule change like a schema migration: identify what’s affected, plan the update, and tell customers before the deadline, not after.
Choosing a carrier for regulated numbers
The carrier’s side of this process matters as much as yours. Ask any number provider for its requirements matrix per number type, how it notifies you of changes, what its review turnaround looks like, and how rejections are communicated. Clear answers to those questions will save you more time than any API feature.
Coverage matters too, because every additional provider means another matrix, another intake format and another status feed. IDT Express provides DID numbers in 140+ countries, so a reseller can run one intake process against one provider across most of its markets. Our guide to what a DID number is covers the fundamentals for anyone newer to the product.
Frequently asked questions
What documents are needed to get a DID number?
It depends on the country and number type. Common requirements include proof of the end user’s identity, proof of address, sometimes a local address in the number’s area, business registration, and occasionally a declaration of how the number will be used.
Why do some countries require a local address for phone numbers?
Some regulators require a local address, particularly for geographic numbers, to keep numbers tied to real users in the area they represent and to discourage misuse. National or non-geographic numbers in the same country often have lighter requirements.
Who is responsible for DID regulatory documents, the reseller or the end user?
The documents usually describe the end user, but in practice the reseller collects, validates and submits them to the carrier. Resellers should manage the process formally, including data protection and retention, because they sit between both parties.
How can resellers reduce DID number rejections?
Collect documents at order time using a per-country requirements matrix, and validate them before submission for legibility, recency, name consistency and address location. Most rejections come from issues that validation can catch.
Do DID numbers need to be re-verified after activation?
In some countries, yes. Requirements can continue after activation, so resellers should track document expiry dates and re-verify end-user details on a schedule where the rules require it.
Check DID coverage by country
Planning numbers across several markets? See DID coverage and pricing for the countries you sell into.
