Approved parties: vendors, carriers, and labs the network qualifies

What the Approved parties row is

Some HQ programs are not about what franchisees do, they are about who franchisees are allowed to deal with. A vendor-approval program is a preferred-vendor panel: which restoration-supply vendors, equipment rental houses, or subcontractors the network has vetted and cleared. A carrier program is the reverse relationship, a preferred-contractor arrangement with an insurance carrier. A TPA program tracks enrollment with a third-party administrator. All three are built on the same primitive underneath: a roster of external parties the network qualifies, not a roster of franchisees.

The Approved parties row is where that roster lives. Each party sits as a tile: its qualification status, when it was last audited and how it scored, when its next audit is due, and, for a vendor party, the rate HQ negotiated with it. This is the one place on the platform where you both see the network's procurement panel and act on it, adding a party, scheduling its next audit, or setting the price the network is supposed to be paying it.

Verinode does not decide which vendors, carriers, or labs your network works with, and it does not qualify a party on your behalf. It reads the roster, the audit history, and the rate you have entered, and lays it out so the qualification decision, and the negotiation, stays yours.

Where to find it

1. 1Open Programs from the HQ sidebar at hq.verinode.ai/programs.
2. 2Click into any vendor approval, carrier, or TPA program tile from the Active, Drafts, or Sunset row. You land on hq.verinode.ai/programs/[id].
3. 3The Approved parties row sits directly below the hero panel, the first row of tiles on the page.

The row only appears on a program whose enrollment model is approved-party list, the setup vendor-approval, carrier, and TPA programs normally use. A cert mandate, training, brand standard, or safety program tracks franchisees instead and shows a Franchisee enrollments row in this exact spot. A marketing co-op program does not use this detail page at all, it opens onto its own reimbursement ledger. For the full logic behind which rows appear on which program type, see Inside a program: the detail view and its rows.

What the hero above it is already telling you

Before you scroll into the row itself, the hero panel at the top of the page has already summarized it: the headline number is the count of qualified parties (not the total party count, only the ones that have cleared to qualified), the pill next to it carries the program's own lifecycle status (Active, Draft, Sunset, or Archived), and one of the three secondary figures repeats the qualified-party count with a sub-line reading how many are on probation. The other two secondary figures, Open violations and Audits last 90d, roll up across every party on this program. None of that is specific to this row, it is context that sits above it every time you open the page.

Reading a party tile

Each approved party renders as one tile in the row, in this shape:

• Label (top-left): the qualification status, one of Pending, Qualified, Probation, Suspended, or Removed.
• Headline: the party's display name, exactly as it was entered when added.
• Sub-line: the party kind, Vendor, Carrier, TPA, Certification body, Lab, or Broker, plus the last audit score out of 100 when one is on file and no negotiated rate is showing in the meta line below (see the note on rate priority below).
• Meta line (bottom): whichever of these applies, in order of priority:

1. For a vendor party with a negotiated rate on file: Negotiated $X/mo, plus a tolerance percent (± Y%) when one is set. 2. Otherwise, the next audit due date, if scheduled. 3. Otherwise, the last audit date, phrased relative to today ("3 months ago"). 4. Otherwise, the date the party was first qualified. 5. If none of those exist, the meta line is blank.

The tile's accent color tracks the qualification status: Deere Green for Qualified, Hard Hat Yellow for Pending and Probation alike, Ember Red for Suspended, and a neutral border tone for Removed.

The row shows up to 20 parties, ordered alphabetically by name. If a program's approved list ever grows past that, the newest additions past the cap are not visible in this row (there is no pagination on it today), though every party still counts toward the hero's totals.

Qualification status: what each state means

• Pending. Listed on the program but not yet cleared. This is the default status for a newly added party, before its first audit.
• Qualified. Audited and cleared to full standing. Setting a party to Qualified stamps qualified_since to today, the date shown in the meta line once no audit or rate data is available yet.
• Probation. Listed with provisional access, a status that flags the party for a closer look on its next audit rather than removing it outright.
• Suspended. Access withdrawn pending resolution.
• Removed. No longer part of the network's approved roster.

Today, only the first three, Pending, Qualified, and Probation, are selectable from the Add approved party form (below). Suspended and Removed exist as data states a party can carry, but this row does not yet expose an in-app control that moves a party into either of them, that would come from a program's follow-on decertification logic (an audit or KPI-threshold breach automatically demoting a party) once that enforcement layer ships. If you see a party in one of those two states today, it was set there outside this UI.

Audit dates and scores on the party record

Every approved party carries four audit-related fields that the tile's meta line draws from: qualified since, last audit date, last audit score (out of 100), and next audit due. None of these are typed directly onto the party. They fill in as audits against that party are conducted, through the same Schedule audit flow that produces the page's Recent audits row further down.

When you schedule an audit against an approved party, you are creating a draft audit record scoped to that one party, its type (Annual, Quarterly, Spot, Triggered, or Self-attest), its scheduled date, and any initial findings you want on record before the audit happens. As the audit is conducted and completed with a score and status, that record both shows up in the Recent audits row and rolls forward into this party's own last-audit fields.

On a vendor approval program, audits are meant to be scored against the network's own weighted criteria, the Audit rubric row that sits further down the page (only vendor-approval programs carry a rubric). That rubric is not wired to automatically move a party's qualification status yet, tying a rubric score to an automatic status change is a follow-on step. Today, the rubric exists so every audit is scored consistently; moving a party from Pending to Qualified, or flagging Probation, is still a decision you make from what the rubric-scored audit tells you.

Adding a party

1. 1If you are a group admin, an Approved party tile sits at the end of the row: "+ Add the first party" when the list is empty, "+ Add party" once it isn't. Click it.
2. 2Party name. Required. The name as it should read on the tile and anywhere else the party shows up (for example, "ACME Restoration Supply").
3. 3Party kind. A dropdown of six options: Vendor, Carrier, TPA, Certification body, Lab, Broker. The default selection follows the program you opened this from: Carrier for a carrier program, TPA for a TPA program, Certification body for a cert mandate or training program, Lab for a safety program, Vendor for everything else.
4. 4Qualification status. Three radio options, each with a plain description right on the form: Pending ("Listed but not yet cleared on the rubric. Default for new parties."), Qualified ("Audited and cleared. Stamps qualified_since to today."), or Probation ("Listed with provisional access, revisit on next audit.").
5. 5Qualified until (optional). A date field. Leave blank if the party's standing has no expiry.
6. 6Notes (optional). Free text, counsel notes, audit history, or the reasoning behind the starting status, whatever the next admin who opens this party should know.
7. 7Click Add party. The party appears in the row immediately (no page reload needed) and the hero's qualified/probation counts update to match if you set a starting status other than Pending.

This action is admin-only. A non-admin viewer sees the same row of parties but no Add tile.

Negotiated vendor rates as procurement leverage

This is the part of the Approved parties row that turns from a status list into a procurement tool, and it only applies to parties whose kind is Vendor.

When HQ negotiates a rate with a vendor, that rate is captured here, on the vendor's own approved-party record, not somewhere separate. Click the vendor's tile as an admin, and a modal titled Negotiated rate, followed by the vendor's name, opens with two fields:

• Monthly rate (USD). The flat monthly amount HQ agreed with this vendor.
• Tolerance % (0-100). How much the network's actual spend can run above that rate before Verinode calls it drift, rather than ordinary regional variance. Leave it blank on a first save and Verinode applies a default of 10%. Set it to 0 for strict enforcement; a higher number widens the acceptable band.

Save it, and two things happen at once. First, the vendor's own tile in this row updates: its meta line now reads "Negotiated $X/mo" (with the tolerance appended when one is set), taking priority over whatever audit-date meta it was showing before. Second, and this is the leverage part, that rate becomes the number the rest of the platform measures the network against. On the Vendors page, the Rate Drift row compares the network's median per-franchisee spend on this vendor against the rate you just entered, and once the network is paying more than the rate plus its tolerance, the vendor surfaces there as a renegotiation candidate. See Rate drift: the right vendor at the wrong price and Renegotiation candidates for how that comparison reads once it fires, and Vendor detail: negotiated rate vs. network median for the same math shown against one vendor's own numbers.

A vendor can sit on more than one active approved-list program at once, each with its own negotiated rate. When that happens, Verinode holds the network to the strictest of them, the lowest negotiated monthly amount across every active program that vendor sits on. That is deliberate: it measures the network against the best deal HQ has on file, not an average of several deals, so a weaker rate negotiated on a second, smaller program cannot quietly loosen the standard the network is actually held to.

To remove a rate entirely, reopen the same modal and click Clear rate (it only appears once a rate is already on file). Clearing wipes both the rate and the tolerance, the vendor's tile falls back to showing its audit-date meta instead.

Who can do what here

Any HQ user with access to Programs sees the full Approved parties row, every party, every status, every audit date, and every negotiated rate that has been set. The authoring actions, adding a party and setting or clearing a vendor's negotiated rate, are restricted to group admins. A non-admin viewer sees identical data with the "+ Add party" tile and the click-to-edit affordance on vendor tiles simply absent.

Empty states

If the program has no approved parties yet and you are not an admin, the row is replaced by a single line of text instead of an empty tile row:

"No parties qualified yet. Approved vendors / carriers / labs appear here once the program owner walks them through the audit rubric and grants qualified status."

If you are an admin and the list is empty, you see the "+ Add the first party" tile instead, so the row is never a dead end for the person who can actually populate it.

Related help articles

• Inside a program: the detail view and its rows, the full page this row lives on, including the hero, the Franchisee enrollments row it swaps places with, the Audit rubric and KPI threshold matrix rows, and how the Recent audits and Open violations rows read.
• Programs: how HQ codifies what the network adopts, the program model overview, including the eight program types and enrollment models.
• The Programs catalog: hero, Active, Drafts, and Sunset rows, the page you click into a program from.
• Vendor detail: programs and per-franchisee participation, how this same qualification tier and negotiated rate roll up onto a vendor's own detail page.
• Vendor detail: negotiated rate vs. network median, the per-vendor drill-in of the drift comparison the negotiated rate feeds.
• Rate drift: the right vendor at the wrong price, the network-wide row that surfaces vendors drifting past their negotiated rate.
• Renegotiation candidates, where drifting vendors surface as a prioritized action list.
• The privacy boundary between HQ and franchisee data, how the small-cohort floor protects franchisee-level spend figures on the Vendors page.
• Network health, how open violations and audit activity across all programs feed the network-wide health rollup.