Slowest Payers: which TPAs make your network wait for payment

Slowest Payers is the payment-risk row on the TPAs page: a ranked list of the third-party administrators taking the longest to pay across your whole network, average days-to-pay, worst first. The p…

8 min read·Updated July 14, 2026
On this page

What this row is

Slowest Payers is the payment-risk row on the TPAs page: a ranked list of the third-party administrators taking the longest to pay across your whole network, average days-to-pay, worst first. The page header above it gives you one weighted number for the network's entire TPA book (see The network TPA summary). This row breaks that single number apart and names which specific TPAs are actually driving it.

A TPA is the company a carrier hires to process and pay a claim on its behalf, so a TPA relationship carries its own payment cycle, separate from the carrier that ultimately owns the claim. Verinode does not chase a TPA for payment or negotiate its terms on your behalf. It reads the jobs and payment history your franchisees have already recorded, rolls them up by TPA across the network, and surfaces the ones whose payment cycle is running long. Leadership decides what to do with that: a direct conversation with a specific TPA, a network-wide policy on which TPAs to keep accepting work through, or nothing at all if the numbers look fine.

Where to find it

Open Accounts from the HQ sidebar (Revenue band), at hq.verinode.ai/tpas. The page opens on a three-pill strip, Carriers · TPAs · Commercial; TPAs is the second pill, and clicking it is a real navigation to /tpas rather than an in-page swap, so a bookmark or shared link always lands directly on this page. Slowest Payers is the first row of tiles below the header, above Broadest Network Footprint, Heaviest Pushback, and All TPAs further down the same page.

How a TPA gets on this list

A TPA qualifies for this row on two conditions:

  1. It has at least one recorded days-to-pay value. A TPA with jobs on file but no days_to_pay recorded on any completed job never appears here, no matter how much business it administers for the network. It still shows up in the header's total-TPA count and in the All TPAs row further down the page, just without a days-to-pay figure attached.
  2. It clears the network's privacy floor. A TPA served by only one franchisee is withheld from every TPA-level row on this page, including this one, so that a single TPA's figures can never be traced back to one franchisee by elimination. See the privacy section below.

Among the TPAs that clear both, Verinode ranks by network-wide average days-to-pay, slowest first, and shows up to six. This is not a list of every slow TPA, it is the worst six, meant to be scanned in one glance rather than sorted or paged.

What each tile shows

Every tile in this row carries four pieces of information:

  • Days figure (for example "52 days"): the TPA's own network-wide average days-to-pay, weighted across every franchisee that bills it.
  • Headline: the TPA's name.
  • Sub-line: how many franchisees serve this TPA, for example "3 franchisees serving" (or "1 franchisee serving" when only one, in networks where that's allowed to show at all, see below).
  • Meta line: the TPA's total billed over the trailing 36 months, for example "$210k billed 36mo," when that figure exists. If billing data isn't available for the TPA, the meta line is omitted entirely rather than showing a placeholder.

Tiles in this row render as large, double-width "action" tiles with a solid accent rail down the left edge, a deliberate "this needs a look" treatment that's visually louder than the plain browsing tiles in the rows below it (Broadest Network Footprint, All TPAs). It's the same signature Verinode uses across IQ and HQ whenever a tile is flagging a risk rather than a routine ranking.

The accent logic: three different reads of the same number

Days-to-pay shows up in three places on this page, and each one uses a different accent scheme because each is answering a different question.

This row (Slowest Payers): a single 60-day cut.

  • Over 60 days average: the tile's accent renders in Analyse (Ember Red). This is a genuinely slow TPA, one whose payment cycle is dragging past two months on average.
  • 60 days or under: the tile's accent renders in Maintain (Hard Hat Yellow). Because this row only ever shows the network's six slowest TPAs to begin with, even the "yellow" tiles here are already among the worst in your book, they simply haven't crossed the 60-day line.

There is no green tier inside this row. A TPA paying quickly enough to read green never ranks slow enough to make this list in the first place.

The page header above it: a three-tier read, 30 and 60 days. The header's Avg days-to-pay figure (and the pill beside the page's headline count) uses a finer, three-way scale on the network-wide weighted average: 30 days or under reads Expand (green), 31 to 60 days reads Maintain (yellow), and over 60 days reads Analyse (red). That's the network's overall pulse; this row exists specifically to name which TPAs are pulling that pulse into the yellow or red zone. See The network TPA summary for the full header read.

A TPA's own detail view: a three-tier read, 45 and 60 days. Tapping a tile in this row opens that TPA's detail view (a modal overlay on the same page, with a full-page version at hq.verinode.ai/tpas/[id] as a fallback if you land on a direct link). The detail view repeats the same days-to-pay figure with its own three-tier scale, one step finer than the header's: over 60 days reads red (Analyse), over 45 up to 60 reads yellow (Maintain), and 45 or under reads green (Expand). A single TPA's own number can be genuinely healthy in a way this row, by design, never shows, since only the worst six TPAs make this list at all.

Note

Three scales, three questions. The header's 30/60 split answers "is the network's overall TPA payment cycle healthy." This row's single 60-day cut answers "which TPAs are slow enough to name." The detail view's 45/60 split answers "is this one TPA, looked at on its own, actually a problem, or just a little slow." A tile reading yellow in this row can still read green once you tap through, because the row is only ever showing you the worst of the worst to begin with.

The privacy boundary

Same guard as the rest of the Accounts page: a TPA served by only one franchisee is withheld from this row (and every other TPA-level row) in networks made up of independently owned locations, because showing that TPA's days-to-pay by itself would tell HQ, by elimination, which franchisee it belongs to. This does not apply to networks configured as a single legal entity operating multiple locations, where every TPA row is visible regardless of how many locations serve it.

When TPAs are withheld this way, the header's summary line carries a trailing note ("N hidden as single-franchisee") so leadership knows the visible rows are a filtered set, not the network's complete slow-payer list. Qualitatively: the fewer franchisees sharing a given TPA, the more likely that TPA sits below the visibility floor and simply won't appear here yet, regardless of how slow it actually pays.

What it needs to populate

This row needs one specific thing recorded that a lot of the rest of the TPAs page doesn't: days_to_pay on completed, TPA-administered jobs. A franchisee can bill a TPA, get paid, and close the job out without ever recording how many days that took, in which case the job counts toward billed and collected totals elsewhere on the page but contributes nothing to this row or to the header's network-average days-to-pay figure.

Empty state

If no TPA in the network has a recorded days-to-pay value at all, the row reads:

"Payment-cycle data appears once franchisees record days_to_pay on TPA-administered jobs."

This is not a broken page. It means every franchisee in the network has either not billed a TPA-administered job yet, or has billed and been paid without recording how long it took. As franchisees start closing that field out on completed jobs, TPAs begin appearing here in the order their average days-to-pay data accumulates.

How to use it

  1. 1Scan this row before any network-wide TPA or carrier conversation. It's the fastest read on which specific counterparties are actually dragging the network's cash cycle, rather than the header's single blended average.
  2. 2Tap a red tile first. Anything over 60 days average, across enough franchisees to clear the privacy floor, is a genuine collections drag worth a direct conversation with that TPA or a policy question about continuing to accept work routed through it.
  3. 3Tap through to the TPA's detail view before drawing conclusions. The three-tier read there (green under 45, yellow 45 to 60, red over 60) tells you whether a "yellow" tile in this row is borderline-fine or actually close to the red line.
  4. 4Cross-check against Billed 36mo on the same tile. A slow TPA that represents a small slice of network billing is a different priority than one that's both slow and heavily used.
  5. 5If the row looks thin or empty, that's a data-completeness gap, not a compliment. Push franchisees to record days_to_pay on TPA-administered jobs so the network's actual payment risk becomes visible.

Tip

Pair this row with the header's own Avg days-to-pay figure (see The network TPA summary). The header tells you whether the network's overall TPA payment cycle is healthy, watchable, or a drag; this row tells you which specific TPA is responsible when it isn't healthy.

Heads up

A TPA missing from this row is not necessarily paying well. It may simply have no days_to_pay recorded yet, or it may sit below the network's privacy floor for visible TPA rows. Treat an empty or short list as a prompt to check data completeness before treating it as good news.

Data sources

Data sources

  1. 1.Franchisee-recorded jobs, billing, and `days_to_pay` on TPA-administered jobs. Your network's franchisees.
  2. 2.Nightly network aggregation, rolled up by canonical TPA. Verinode HQ.
Was this helpful?