A bulk TPS check is a file of phone numbers in and a file of verdicts out. At 10,000 numbers it is an afternoon's task on almost any tool. At 100,000 it starts to matter which route you take, and at a million the route decides the price, the time and whether the result is worth anything a month later. This piece compares the three routes, prices each at three volumes using published figures, and sets out what the file you keep should look like if the ICO ever asks for it.
Three routes to a bulk TPS check
Portal upload. You paste or upload a file to a vendor's website and download the verdicts. Selectabase EasyCheck takes pasted lists of up to 50,000 numbers at a time; TPS Checker takes up to 100 numbers per web batch, with 10 free checks a day on a free account. The route is simple to operate and needs no developer, and every clean is a snapshot you have to repeat by hand.
API batch. A script sends the numbers to a screening API in chunks and writes the verdicts back to wherever the list lives. The TPSClear API accepts up to 1,000 numbers per request, so a million numbers is 1,000 requests. Data8 and TPS Unlimited also sell API access. This route fits a data team that owns the list in a warehouse or a bespoke system, and it is the only one of the three that can be scheduled.
CRM-native continuous screening. The list is already in the CRM, and a connected app screens each number as it is added or edited, then re-screens anything older than 27 days. There is no file at all after the initial backfill. TPSClear does this inside HubSpot, with the API and Zapier covering other CRMs; Data8 has add-ins for Dynamics 365 and Salesforce. This route costs more per month than a one-off clean and removes the question of staleness entirely.
What each route costs at 10,000, 100,000 and 1,000,000 numbers
The figures below are the published prices on each vendor's site as of October 2026, as listed on our comparison page and our pricing page, ex VAT. Where a vendor sells a flat monthly rate, the cost is the same at every volume and the time is the constraint instead.
| Route and vendor | 10,000 numbers | 100,000 numbers | 1,000,000 numbers |
|---|---|---|---|
| Portal: Selectabase EasyCheck (50,000 per paste; plans from £49 a month, unlimited £199 a month) | 1 paste, from £49 | 2 pastes, from £49 | 20 pastes, £199 on the unlimited tier |
| Portal: TPS Checker (100 per web batch; packs from £5 for 325 checks) | 100 batches | 1,000 batches | 10,000 batches; the API is the realistic route |
| API: TPSClear prepaid packs (1,000 per request; £9 for 1,000, £49 for 10,000, £179 for 50,000) | £49 | £358 (two 50,000 packs) | £3,580 (twenty 50,000 packs) |
| API: Data8 (£5 per 1,000 per register, £10 for both; £100 minimum) | £100 | £1,000 | £10,000 |
| API: TPS Unlimited (flat £150 a month TPS only, £200 a month with CTPS) | £200 | £200 | £200 |
| CRM-native: TPSClear plans (Standard 25,000 every 28 days at £295 a month; Scale 250,000 at £795, then £15 per 1,000) | Standard, £295 a month | Scale, £795 a month | Scale plus overage, or a Custom plan |
Three notes on reading the table. First, the CRM-native row is a 28-day allowance, not a one-off clean: the Scale plan screens 250,000 numbers every 28 days, backfill and re-checks included, so it is priced against a programme rather than a file. Second, a flat monthly rate with no CTPS (the £150 TPS Unlimited tier) is not a full clean for a B2B list; use the £200 figure. Third, since 1 September 2026 the DMA charges a royalty of 10p per 1,000 records on TPS and CTPS screening, capped at £3,300 per client per year, which licensed list cleaners recharge at cost. That adds £1, £10 and £100 to the three volumes, on top of whichever row you choose. The background is in the TPS royalty fee.
Why a one-off bulk clean goes stale
The register changes every day, in both directions. Numbers are added when people register, and the industry standard set by the DMA, which operates the TPS, is that screening data is no more than 28 days old when you rely on it. A verdict file dated the 1st is therefore the basis for calls until the 28th and no further. The detail is in the 28-day rule explained.
For a bulk clean this has a cost consequence. A million-number list dialled over three months needs three cleans, not one, and the cheapest route at one clean (a flat monthly rate, cancelled after the download) becomes three months of the flat rate. It has an operational consequence too: the records that were added to the list after the clean are the ones most likely to be dialled first, and none of them has a verdict. Any list that is still being added to after the bulk check needs a screen on entry, which is the CRM-native route by another name.
If the list is a single campaign dialled inside 28 days and then discarded, a one-off clean is the right tool. If the list is the sales team's working database, it is the wrong one, and the comparison above should be read as monthly.
File hygiene before you upload
Most failed bulk checks fail on the input file, and the failure is silent: the vendor returns fewer verdicts than you sent, or returns "unknown" for rows it could not parse, and nobody counts. Four things to do before the file leaves your hands.
- Normalise to E.164. Every number in the form +44 followed by the national number without the leading zero, so 07700 900123 becomes +447700900123. Strip spaces, brackets, hyphens and the "ext" fragments that CRMs collect. A number the screening service cannot parse is a number it cannot screen, and a verdict of "invalid" is not a verdict of "clear".
- Remove duplicates after normalising, not before. "020 7946 0000" and "+442079460000" are the same number. Dedupe on the normalised form, and keep a mapping back to every source row so that the verdict reaches all of them.
- Separate non-UK numbers. The TPS and CTPS are UK registers. A +1 or +353 number has no verdict on either, and if you leave them in the file they come back as unknown, which later reads as unscreened. Set them aside with their own flag; Australian numbers have their own register, which TPSClear also screens.
- Count rows in and rows out. Send 100,000, expect 100,000 verdicts. A result file 300 rows short means 300 numbers without a verdict, and those are the ones the complaint will be about. Reconcile before the file goes anywhere near a dialler.
What the result file should contain for an ICO audit
When a complaint reaches the ICO, the question put to you is whether you took reasonable steps before the call. The answer is a record made at the time, and the result file is that record. A column of "Y" and "N" next to a phone number is not enough, because it does not say when, against what, or by whom.
The minimum per row is the normalised number, the TPS verdict, the CTPS verdict, the date and time of the check, the data source or licensed provider, and a reference that ties the row back to the campaign or client it was screened for. Add a check or audit identifier returned by the provider where one is available, because it lets the provider confirm the verdict from its own log. Keep the input file, the result file and the reconciliation count together, and keep them for a stated retention period that covers the time a complaint can arrive. If the CRM-native route is in use, these fields live on the record itself and the export is a report rather than a reconstruction.
One more column earns its place: the dial decision. The verdict says where a number stands against the registers; whether you dialled it, and on what basis (clear, or consented, or suppressed), is a separate fact. Logging both makes the audit a lookup rather than an argument.
Checking a single number
None of the above is needed to check one number. If you want to know whether a specific line is on the TPS or CTPS before a call, the free TPS check checks one number at no charge, and how to check a number against the TPS covers the other routes for individuals and small teams.
What to do next
Decide whether the list is a campaign (clean once, inside 28 days) or a working database (screen on entry, re-screen monthly), then choose the route from the table. For an API batch run, the API documentation sets out the request shape and the 1,000-number limit; for a CRM, the install runs the backfill for you. Voll Studios Ltd, the company behind TPSClear, is licensed by the DMA as a TPS and CTPS list cleaner, and register data is supplied through our licensed data partners.