A D-U-N-S number is a nine-digit business identifier from Dun & Bradstreet, and both app stores want one before they will let a company publish. It is free. Getting it is usually the single slowest step in setting up a developer account — and most of the delay people experience is avoidable, caused by one of four things that neither store explains up front.
This page is about those four things. If you want the request steps themselves, they are already covered in creating an Apple Developer account and creating a Google Play developer account.
Plenty of companies are already in Dun & Bradstreet's database without anyone internally knowing. If yours is, the number exists today and you can skip the wait entirely.
Apple's enrolment flow has a look-up built in, and its documentation is explicit: "Before enrolling, look up your organization to see if you have a D‑U‑N‑S Number. If your company is not listed, you'll have the option to submit your information to Dun & Bradstreet for a free D‑U‑N‑S Number."
That is the cheapest path available — it checks and, if needed, files the free request in one place. Dun & Bradstreet also has its own free look-up tool if you would rather start there.
Do this before anything else. We have seen companies wait weeks for a number they already had.
This is the mistake we see most often, and it is a costly one because you only discover it at the end.
A D-U-N-S number identifies one legal entity. So if your organisation runs both a charity or association and a trading company — extremely common for federations, pageants and event organisers — those are two separate numbers. Requesting one for the charity and then trying to enrol the company with it will not work.
Apple is unambiguous about the name, too: "make sure to use the legal entity name of your organization, as Apple does not accept DBAs, fictitious businesses, trade names, or branches for enrollment as a company/organization."
So before you request anything, settle one question: which legal entity will own the developer account and sign the agreements? That entity's registered name is what goes on the request — not the brand you trade under, not the event name, not the parent organisation.
If you are not sure whether you even need the organisation route, that decision is covered in individual or organization developer account?
There is a second, more expensive reason to get the entity right, and it catches organisations that thought they were being efficient.
Apple waives the $99 Developer Program fee for nonprofits, accredited educational institutions and government entities. It is a real saving. But the waiver comes with a condition that is easy to skim past: waived organisations must not sign the Paid Applications Agreement and must not sell digital goods or services through any of their apps. In Apple's words, waivers "are not available" to groups distributing paid apps or apps with in-app purchases — and an organisation that has taken a waiver will be charged the regular fee if it later enables them.
So enrolling under the charity or association, then accepting the free membership, quietly trades away your ability to charge for anything: no paid app, no in-app purchases, no subscriptions, no digital goods. For a pageant or federation that later wants paid voting, premium content or ticketing, that is a problem discovered at the worst possible moment.
The rule of thumb: if the app will ever take money, enrol the entity that trades — and pay the $99. If it will only ever be free, the charity entity and the waiver are a genuine saving.
Worth separating one thing that often gets confused with this: charitable donations do not run through in-app purchase at all. Apple's guidelines say that unless you are an approved nonprofit, collecting funds in-app for charities is not permitted — such apps must be free and collect outside the app. Approved nonprofits may fundraise inside their own apps using Apple Pay, and donations are not commissioned. So "we want to accept donations" and "we want in-app purchases" are two different requests with two different answers.
We could not find an equivalent documented restriction on the Google Play side, so treat this as an Apple-specific consequence rather than something both stores impose.
Two minutes here saves a fortnight later. Have these three straight first:
If those three do not match between your business register, your D-U-N-S record and your store enrolment, the store will reject it — and the error message rarely tells you which of the three is the odd one out.
The number costs nothing. Dun & Bradstreet issues it free, and Apple's look-up will file a free request for you. Anyone telling you otherwise is selling something else.
What is actually on the market:
We are not naming individual firms, because the pattern matters more than the brands and the brands change. The test is simple: if a service is charging you for the number itself rather than for speed, you are paying for nothing. Check Apple's look-up first and you will usually find you never needed either.
This one causes real damage, because the natural reaction is to assume the number is wrong and request another. It is not wrong. Apple simply has not received it yet.
From Apple's own documentation: "Once you receive your D‑U‑N‑S Number, please allow up to 2 business days for Apple to receive your information from D&B. After this period, you may enroll as a company/organization in the Apple Developer Program."
Google Play has no equivalent waiting period — in our experience helping customers publish, Play accepts a fresh D-U-N-S number immediately while Apple needs those couple of days to catch up. So seeing it work on one store and fail on the other is expected behaviour, not a broken number.
What to do: wait two business days and try Apple again. Do not request a second D-U-N-S number — you will end up with duplicate records in D&B's database, and that is a genuinely annoying problem to unpick later.
It happens, usually for one of two reasons: someone requested a second number when Apple could not yet see the first, or the company exists in D&B twice under slightly different names after a rebrand or a move.
Duplicates are a nuisance rather than a disaster, but they do need sorting, because the stores will only accept the record that matches your legal entity name — and you may not be able to tell which of the two that is from the outside.
The fix is with Dun & Bradstreet, not with Apple or Google: contact D&B, tell them you believe there are duplicate records for the same legal entity, and ask them to consolidate. Then allow the usual couple of business days for the corrected data to reach Apple before you retry.
The way to avoid it entirely: when Apple says it cannot find your number, wait rather than request another one. Almost every duplicate we have seen started as an act of reasonable impatience.
Both figures circulate and both are correct, because they measure different stages.
Which one you get is largely a matter of geography, and neither store can speed it up — the queue belongs to Dun & Bradstreet. So the practical advice is to start the D-U-N-S request before anything else in your launch plan, and treat it as the long pole rather than a formality.
A mismatched address, an old company name or a slightly different legal name will all cause enrolment to fail. The fix is with D&B rather than with the store: contact Dun & Bradstreet to update your profile.
Then allow for the same lag on the way back. Apple notes that "it takes up to two business days for D&B to provide updated information to Apple" — so if you correct a record and immediately retry, a failure does not mean the correction did not work.
Worth stating plainly, because people often assume otherwise: it is the same identifier for both stores. Google states that to create a developer account for an organization you must have a D-U-N-S number; Apple requires the same for company enrolment. You obtain it once and use it in both places.
Personal and individual accounts need no D-U-N-S number at all on either store — which is sometimes the faster route to a first launch, with a conversion to an organisation account later. The trade-offs are in individual or organization developer account?, and the full cost picture for publishing is in what it actually costs to publish an app.
The D-U-N-S queue is the one part of setting up a developer account that nobody can shortcut. It does not have to block everything else, though — the app itself, the store listing, the screenshots and the description can all be finished while the number is in the post.
With Choicely you can build and preview the whole app in the browser during the wait, then publish to both stores under your own developer accounts once the number lands. If you would rather hand the publishing over, that is our app publishing service.