Step 1: describe the observable symptom
Record whether platforms disagree on individual states, part of a batch failed, an export contains fewer rows than the upload, or a job remains pending. Capture time, platforms, failure share and single-record versus batch mode. A few anomalies suggest number-specific or formatting issues; broad failures suggest file structure, mapping or concurrency.
Layer 2: normalize every submitted number
Check country codes, plus signs, whitespace, non-digits, extensions and note fields. Mixed local and international forms can produce different decisions. Create one canonical local list first, submit that exact identifier to every provider and compare normalized identifiers rather than visually similar spreadsheet cells.
Layer 3: distinguish definition differences from state changes
Providers vary in range coverage, refresh rate and whether they measure activity, registration or reachability. Review each definition before comparing. Differences concentrated in new, IoT, virtual or ported ranges often indicate coverage policy; random differences may indicate separate batches or intermediate deduplication.
Layer 4: inspect batch and API mechanics
Verify UTF-8, header expectations, spreadsheet scientific notation, upload limits, queue state and child-task timeouts. For APIs inspect rate, timeout, callback reachability and duplicate task identifiers. A smaller export may reflect deduplication, rejected rows or omitted failures, so reconcile success, failure and reason counters instead of row totals alone.
Choose the right corrective action
Fix preprocessing when input is at fault. For legitimate rule differences, designate a primary provider and use another for sampling rather than demanding identical output. Adjust batch size, retry policy or submission timing for capacity issues. Escalate availability only when one provider repeatedly fails on the same normalized input and definition while controls remain stable, retaining samples, receipts and logs.
