ABM sign-up stalls: D-U-N-S lookups and Apple verification calls while new iPads sit in boxes

Apple Business Manager enrolment routinely takes a week or more because it depends on a Dun & Bradstreet record check and a verification call to a company officer. You cannot compress Apple's process — but you can stop it rejecting you, and you can sequence it so hardware never arrives first.

The problem

You have ordered iPads (or Macs), started the Apple Business Manager (ABM) sign-up so you can use Automated Device Enrolment, and the application is sitting at pending. Apple wants a verified D-U-N-S number for your legal entity and a phone conversation with a named person who can act on behalf of your organisation before it will approve the account — and the hardware is already on the loading dock.

Apple's own guidance sets the timescales. If your Dun & Bradstreet record needs creating or correcting, Apple says to allow up to five business days for D&B to process the change, and around two more business days for Apple's systems to receive the update. Add the wait for the verification call itself and a first-time enrolment can easily consume one to two weeks.

The people who hit this are almost always doing their first Apple deployment: a batch of iPads for field staff, a first fleet of Macs, a move from ad-hoc device setup to proper zero-touch enrolment. As one admin put it on Apple's Support Communities, the wait is "holding up employees from getting to work in the field and makes new iPads useless."

Until the account is approved you cannot link purchases, generate MDM server tokens in ABM, or assign devices for Automated Device Enrolment — so the boxes stay shut.

Why it happens

ABM is a legally binding agreement between Apple and a specific legal entity, so Apple verifies that the entity genuinely exists and that the person accepting the terms has authority to do so. It outsources the entity check to Dun & Bradstreet via the D-U-N-S system, and layers a human verification step on top. Three things make this slow:

• The D&B record is built from official registries, not from what you type. If your D-U-N-S record shows a former name, a trading name rather than the registered legal name, an old address, or different abbreviations from what you entered on the enrolment form, the automated match fails and the application drops into manual review — or is rejected outright. Legal-entity name mismatches are the most common cause of stalled applications.
• The verification contact is a human bottleneck. Apple's programme requirements state the verification contact must be an employee who can act on behalf of the organisation. Apple contacts them by phone and email. A missed call from an unrecognised number, a verification email caught by a spam filter, or a listed contact who turns out to be an external IT contractor rather than an officer each adds a full round-trip of days.
• The D&B-to-Apple pipeline is not real-time. Corrections propagate on D&B's schedule (up to five business days) and then sync to Apple (roughly two more), which is why fixing a record mid-application is so painful.

Apple publishes no expedite path. The only levers you control are the accuracy of the record before you apply, and the availability of the person Apple will call.

The fix

Before you enrol — or right now, if you are stuck

1. Look up your D-U-N-S record first. Use the D-U-N-S lookup tool linked from Apple's D-U-N-S help page and check that the legal entity name and registered address match your official company registration character for character (Companies House, if you are in the UK). Do this before submitting the ABM application, not after a rejection.
2. Fix the record before applying. If the record is wrong or missing, request a correction or a new D-U-N-S number through the D&B route on Apple's page (free for this purpose), and budget the five business days for D&B plus roughly two for Apple's systems that Apple's documentation describes.
3. Apply with the registered legal name, exactly. Not the brand name, not the trading name. Use an email address on your company's own domain (never a personal Gmail/Outlook address) and a website that visibly belongs to the entity.
4. Choose and brief the verification contact. Name a genuine officer or senior employee — someone who can bind the organisation. Tell them explicitly: Apple will ring, possibly from an unrecognised or international number, and will email from an apple.com address. Ask them to check junk folders daily and to answer or return the call promptly. Give Apple a direct number that person actually answers.
5. Build the lead time into procurement. Start the ABM application when the purchase order is raised, not when the pallet arrives — two to three weeks before hardware is due is a sensible buffer given Apple's published timescales.

If the devices are already in boxes

• Progress the MDM side in parallel. The MDM server token has to wait for ABM approval, but your enrolment profiles, configuration policies and app assignments do not. Have everything staged so approval day is deployment day.
• Talk to your reseller now. Note your Apple Customer Number or the reseller's ID and ask whether they can assign the existing order to your ABM account once it is approved, so the devices appear for Automated Device Enrolment without being touched.
• Know the fallback. Devices that cannot be reseller-assigned can be added to ABM afterwards with Apple Configurator; per Apple's guidance they then sit in a provisional period (30 days) during which a user can remove management, so prefer the reseller route where possible.
• Escalate if you are beyond the published windows. Contact D&B through the support route on Apple's D-U-N-S page and raise it with Apple Business Manager support in parallel, with your company registration documents to hand.

How Decolla handles it

Straight answer: no tool can compress Apple's process. The D-U-N-S check and the verification call are Apple's end to end, and Decolla's device automation runs on the Microsoft side — it provisions Windows devices over your organisation's own Microsoft Intune and Windows Autopilot tenant, so it does not touch the Apple enrolment itself.

What Decolla is built to prevent is the sequencing failure this niggle belongs to: hardware arriving before the tenancy is ready. Every Decolla deployment starts with a written, itemised plan that you approve before anything runs, and tenant prerequisites sit at the front of that plan, settled in Week 0 before any device work. For estates that include Apple hardware, the written plan front-loads ABM onboarding as a Week-0 prerequisite with exactly the steps above — the D-U-N-S record checked against the registered legal name, corrections submitted with Apple's published lead times budgeted, the verification contact named and briefed, and the application raised at purchase-order time — so hardware never lands before the tenancy is ready, on either side of the estate.

Decolla is currently pre-launch, with a waitlist open at decolla.app.

Sources

• Apple Developer Help — D-U-N-S Number: lookup, corrections and processing times
• Apple Business Manager User Guide — programme requirements (D-U-N-S and verification contact)
• Apple Support Communities — admin thread on ABM verification delays leaving new iPads unusable