# Vendor Master

> The authoritative record of every supplier and subcontractor a contractor pays — the file that controls who can be paid, at what terms, and whether the payment is compliant and legitimate.

- Source: https://briq.ai/acu/object/vendor-master
- Department: Workforce, Equipment & Supply Chain (https://briq.ai/acu/department/workforce)
- Catalog code: WRK 207 · Level: Practitioner · Track: Finance · 11 min read
- Also known as: Vendor file, Supplier master, Vendor database, Payee master, AP master

## Definition

The vendor master is the authoritative, controlled record of every supplier, subcontractor, and payee a contractor does business with — legal name, tax identification, remittance details, payment terms, insurance and compliance status, and banking information. It exists to ensure that money leaves the company only to legitimate, correctly identified, compliant payees, on the right terms, and that every payment can be reported and reconciled. It is not a contact list or a CRM: those track relationships and opportunities, while the vendor master governs the ability to pay and the integrity of that payment. Because it is the gatekeeper of cash disbursement, the vendor master is one of the highest-control records a contractor maintains, and a weak one is a direct fraud and compliance exposure.

## Why it matters

The vendor master is the primary control against payment fraud, and payment fraud overwhelmingly enters through it. Fictitious vendors, altered remittance and banking details, and duplicate vendor records set up to route a second payment are the classic schemes, and every one of them is a vendor-master manipulation. Controls over who can create and change a vendor record, and verification of banking changes, are what stand between a contractor and a wire sent to a criminal.

It governs tax and regulatory reporting that carries real penalties. The vendor master holds the tax identification and classification captured on the vendor's W-9, which drives year-end information reporting and backup-withholding obligations. A missing or mismatched taxpayer identification produces filing penalties and, worse, an obligation to have withheld that the contractor did not meet, turning a data-quality gap into a liability.

It enforces the compliance a contractor cannot afford to pay around. Subcontractors and suppliers must carry current insurance, and on many jobs valid lien waivers and, on public work, bonds and certified payroll are conditions of payment. When these compliance statuses live in the vendor master and gate payment, an expired certificate of insurance or a missing lien waiver stops the payment automatically; when they live in someone's memory, a payment goes out to an uninsured sub and the exposure lands on the general contractor.

Vendor-master data quality quietly determines the accuracy of spend analysis and the efficiency of accounts payable. Duplicate and inconsistent vendor records fragment spend so the contractor cannot see how much it actually buys from a supplier, undermining negotiation and rebate capture, and they cause the three-way match and payment automation to fail because invoices cannot be reliably tied to one clean payee. A clean master is the foundation the whole payables process stands on.

## Lifecycle

1. **Request and onboarding** — A new vendor is requested, typically because a purchase or subcontract is imminent, and onboarding collects the W-9, insurance, banking, and terms. Onboarding driven by an urgent invoice rather than ahead of need is where controls get skipped under pressure.
2. **Verification and validation** — The vendor's legal name and taxpayer identification are validated, insurance is confirmed current, and banking details are verified through an independent channel. Skipping independent banking verification is the single gap most exploited by payment-diversion fraud.
3. **Approval and activation** — The record is approved by someone independent of the requester and activated for payment. Segregation between who requests, who approves, and who pays is the core internal control, and collapsing those roles is how fictitious vendors get created.
4. **Maintenance and change control** — Over time, addresses, terms, insurance, and banking change, and each change must go through controlled, verified update. An unlogged or unverified change — especially to banking — is the highest-risk event in the vendor master's life.
5. **Compliance monitoring** — Insurance expiration, lien-waiver status, W-9 currency, and any watchlist or debarment checks are monitored continuously. Compliance that is verified once at onboarding and never rechecked lapses silently and gates nothing.
6. **Transaction gating** — The master gates purchasing and payment: no PO or payment to an inactive, non-compliant, or unverified vendor. This is where the master's controls either operate or are bypassed by manual workarounds.
7. **Deduplication and cleansing** — The master is periodically cleansed of duplicates, inactive records, and inconsistencies. Duplicates accumulate constantly through slightly different name entries, and each one fragments spend and creates a duplicate-payment path.
8. **Deactivation and archive** — Vendors no longer used are deactivated rather than deleted, preserving history for reporting and audit while closing the payment path. A dormant-but-active vendor is a standing fraud risk that deactivation removes.

## Anatomy

- **Vendor legal name and DBA** — The exact legal entity name and any doing-business-as. Payments and tax reporting must use the legal name, and a wrong name breaks both the payment and the information return.
- **Taxpayer identification and W-9** — The TIN and the W-9 that supports it, including entity type. Drives information reporting and backup withholding; a mismatch triggers penalties and a withholding obligation.
- **Remittance address and payment method** — Where and how the vendor is paid — check address, ACH, or wire. The field most targeted by fraud, because changing it redirects the money.
- **Banking details** — Bank account and routing for electronic payment. The highest-risk field in the record; any change must be independently verified against a known contact, not the requester's email.
- **Payment terms** — Net terms, discounts, and retainage where applicable. Governs cash timing and whether early-payment discounts are captured or lost.
- **Insurance / certificate of insurance status** — Current general liability, workers' compensation, and other required coverage with expiration dates. Gates payment to subs and suppliers who must be insured.
- **Lien waiver / compliance flags** — Whether required lien waivers, bonds, and certified payroll are current. On many jobs these are conditions of payment enforced through the master.
- **Vendor classification** — Supplier, subcontractor, 1099 individual, employee-vendor. Determines reporting treatment, approval path, and which compliance requirements apply.
- **Approval and change audit trail** — Who created, approved, and changed the record and when. The evidentiary backbone for fraud investigation and audit; a record without it cannot be trusted.
- **Status** — Active, on-hold, or inactive. The switch that opens or closes the payment path, and the reason a held vendor's payment stops automatically.
- **Diversity / certification status** — MBE, WBE, DBE, small-business, or similar certifications where tracked. Supports participation goals and reporting on jobs with such requirements.
- **Linked records** — Purchase orders, subcontracts, invoices, and payment history tied to the vendor. The links that make spend analysis, the three-way match, and duplicate detection possible.

## Failure modes

- **Fictitious or fraudulent vendor** — A vendor with no real existence is created, often by someone who can both set up and approve payees, and invoices are pushed through to it. Without segregation of duties between requesting, approving, and paying, the scheme runs until an audit or a whistleblower catches it, and by then the money is gone.
- **Unverified banking change** — A request arrives — often a convincing email impersonating a real vendor — to change remittance banking, and the change is made without independent verification against a known contact. The next payment wires to the fraudster's account, and these losses are frequently large and rarely recovered.
- **Duplicate vendor records** — The same vendor is set up multiple times under slightly different names or spellings. Spend fragments so the contractor cannot see its true purchase volume, negotiation and rebate leverage is lost, and the same invoice can be paid twice through two different records.
- **Stale taxpayer identification** — A vendor's TIN is missing, wrong, or never validated, and it surfaces at year-end information reporting. The filing is penalized, and the contractor may owe backup withholding it never took, converting a data gap into a real liability.
- **Lapsed insurance still paid** — A subcontractor's certificate of insurance expires but the vendor record still shows active and compliant, so payments continue to an uninsured sub. If that sub then causes a loss, the exposure flows up to the general contractor, who paid as though the coverage were in place.
- **Dormant active vendors** — Vendors long out of use remain active in the master rather than being deactivated. Each is a standing open payment path that fraud can exploit or through which a stale, duplicate, or erroneous invoice can slip, with no legitimate transaction volume to make the anomaly obvious.
- **Change control bypassed under pressure** — An urgent invoice forces a rushed vendor setup or change with the normal verification skipped to make a deadline. The workaround becomes habit, the controls that exist on paper are routinely bypassed in practice, and the master's integrity erodes one exception at a time.

## Metrics

- **Duplicate vendor rate** — Share of vendor records that are duplicates of an existing payee. Measures master hygiene and directly correlates with duplicate-payment risk and fragmented spend.
- **Compliance currency rate** — Share of active vendors with current insurance, W-9, and required waivers. The health measure of whether the master is actually gating payment on compliance.
- **Banking-change verification rate** — Share of banking changes verified through an independent channel before taking effect. The single most important anti-fraud control metric.
- **TIN match rate** — Share of vendor TINs validated against the taxing authority. Prevents information-reporting penalties and backup-withholding liability.
- **Dormant active vendors** — Count of active vendors with no recent transactions. Each is standing fraud exposure; the metric drives periodic deactivation.
- **Segregation-of-duties exceptions** — Instances where the same person requested, approved, and paid a vendor. The core internal-control breach the master exists to prevent.
- **Onboarding cycle time** — Time to fully onboard and verify a new vendor. Long cycle times drive the deadline-pressure workarounds that bypass controls.

## The AI shift

- **Conversational** — An AP or controls manager asks which active vendors have expired insurance or an unvalidated TIN, which records look like duplicates of each other, and which vendors changed banking in the last quarter without a logged verification — and gets specific records with the audit trail cited, instead of scanning the master by hand.
- **Generative** — From an uploaded W-9, certificate of insurance, and banking form, a model drafts a clean, structured vendor record with legal name, TIN, entity type, remittance, and coverage dates extracted and normalized, and flags anything that conflicts with an existing record. The manager reviews a drafted, deduplicated record rather than keying it, which is where name inconsistencies and duplicates usually originate.
- **Orchestrated** — The vendor master stops being a passive table. New records are checked against the existing master for duplicates before creation; compliance dates are monitored and payment is gated when insurance or waivers lapse; banking changes are routed through an independent verification workflow before they take effect; and the master feeds the three-way match and spend analysis so payments and reporting draw from one clean, controlled source.
- **Autonomous** — The maintenance loop runs inside strict guardrails: duplicate and dormant records flagged, compliance expirations monitored and payment holds applied when coverage lapses, TIN validation queued, and every banking-change request held pending independent verification — as an exception queue. Humans create and approve vendors, verify banking changes against known contacts, and release holds; the system never activates a vendor, never applies a banking change, and never releases a compliance hold on its own, because these are exactly the actions fraud targets.

## Prompts

### Conversational — Quarterly vendor-master control review.

```text
Review our vendor master for control and compliance risk. Identify: active vendors whose certificate of insurance or required lien waivers are expired; vendors with a missing or unvalidated taxpayer identification; records that appear to be duplicates of another vendor based on name, address, or banking; active vendors with no transactions in the last twelve months; and any banking changes in the last quarter that do not have a logged independent verification. For each finding, give me the vendor, the specific issue, and the exposure it creates, and rank by risk with the fraud and compliance exposures at the top.
```

**Expected output:** A risk-ranked control findings list — lapsed compliance, unvalidated TINs, duplicates, dormant records, and unverified banking changes — each tied to a vendor and its exposure, with fraud and compliance risks prioritized, not a raw vendor dump.

**Follow-ups:**

- For the duplicate candidates, tell me which is the surviving record and what needs to merge.
- Which of the lapsed-insurance vendors have open payments pending right now?
- Draft the list of dormant vendors we should deactivate.

### Generative — Onboarding a new subcontractor cleanly.

```text
I am uploading a new subcontractor's W-9, certificate of insurance, and banking authorization form. Draft a structured vendor-master record: legal name and any DBA, taxpayer identification and entity type from the W-9, remittance and payment method, insurance coverage types and expiration dates from the certificate, payment terms, and vendor classification as a subcontractor. Before you finalize, check the proposed record against our existing vendor master and flag any possible duplicate by name, address, or TIN. List exactly what still needs independent verification before this vendor can be activated for payment, especially the banking details, and note any required coverage that appears missing or already expired.
```

**Expected output:** A drafted, normalized vendor record with a duplicate check against the master and an explicit verification-and-gap checklist — a record to verify and approve, not one activated on the spot.

**Follow-ups:**

- Draft the verification steps and the independent-contact checklist for the banking details.
- Which insurance requirements for our jobs does this certificate not satisfy?
- If this is a duplicate of an existing vendor, what should we do instead of creating a new record?

### Orchestrated — Handling a banking-change request safely.

```text
A request has come in to change the remittance banking for an existing vendor, citing an email from a contact at that company. Do not apply the change. Instead: confirm the vendor's identity and current record, compare the requested new banking details against the record and against any prior change history, and lay out the independent verification steps required before this change can be made — including contacting the vendor through a known, previously verified phone number rather than any contact information in the change request itself. Flag every characteristic of this request that matches known payment-diversion fraud patterns, and tell me what would have to be confirmed, and by whom, before the change is safe to apply.
```

**Expected output:** A refusal to auto-apply the change, a fraud-pattern assessment of the request, and a concrete independent-verification procedure with the human confirmation required — the control operating exactly where fraud attacks.

**Follow-ups:**

- Draft the verification call script and the documentation we should retain.
- Are there open payments to this vendor that should be held until this is resolved?
- What change-control record should we create so this verification is auditable?

### Autonomous — Standing policy for continuous vendor-master maintenance and control.

```text
Maintain our vendor master continuously under these rules. Monitor every active vendor's insurance, lien-waiver, and W-9 currency, and apply a payment hold the moment a required compliance item lapses. Queue every new or changed TIN for validation against the taxing authority. Continuously scan for duplicate records and dormant active vendors, and surface them for cleanup. Route every banking-change request into a hold pending independent verification against a known contact, and treat any request whose contact details come from the request itself as high-risk. Enforce segregation of duties by flagging any vendor where the same person requested, approved, and paid. Never activate a new vendor, never apply a banking change, never release a compliance hold, and never merge or deactivate a record on your own — prepare each with the supporting detail and route it to a human.
```

**Expected output:** A continuously controlled vendor master with compliance-gated payments, held banking changes, duplicate and dormant detection, and SoD enforcement — where the system monitors and prepares but humans perform every activation, banking change, hold release, and merge.

**Follow-ups:**

- Show me this week's compliance holds, banking-change requests held, duplicate candidates, and SoD exceptions.
- Which vendors repeatedly lapse compliance and should be required to fix their process?
- Report how many banking-change requests you held and how many were confirmed fraudulent.

## Maturity ladder

- **Level 0 — Level 0 — Ad hoc payee list** — Vendors are added whenever an invoice needs paying, with little verification and no change control. Duplicates, dormant records, and lapsed compliance accumulate, and payment fraud has an open door.
- **Level 1 — Level 1 — Controlled setup** — New vendors go through onboarding with a W-9 and insurance, and creation is segregated from payment. Compliance and duplicates are checked manually and periodically, not continuously.
- **Level 2 — Level 2 — Gated and monitored** — Compliance currency is monitored and gates payment, banking changes require independent verification, TINs are validated, and the master feeds the three-way match from one clean source.
- **Level 3 — Level 3 — Assisted** — Records are extracted and normalized from onboarding documents with duplicate detection, compliance lapses and unverified banking changes are flagged, and cleanup candidates are surfaced for review.
- **Level 4 — Level 4 — Operated** — The maintenance loop monitors compliance, holds banking changes, and detects duplicates and dormant records unattended, while humans perform every activation, banking change, hold release, and merge.

## FAQ

### Why is the vendor master such a fraud target?

Because it is the record that controls where the money goes, and altering it redirects payment without touching an invoice. The three classic schemes all live here: creating a fictitious vendor to pay, changing a real vendor's banking so payments divert to a fraudster, and setting up a duplicate record to pay the same invoice twice. Each is a manipulation of the master rather than of any single transaction, which is why the strongest anti-fraud controls a contractor has — segregation of duties, independent banking verification, and change auditing — all center on the vendor master.

### Why verify a banking change if the request came from the vendor?

Because the request may not actually be from the vendor. Payment-diversion fraud works by impersonating a real, trusted vendor — often through a convincing email — and requesting that remittance banking be changed. If you act on the contact information in the request itself, you are verifying with the fraudster. The control that works is independent verification: confirming the change by contacting the vendor through a phone number or contact you already had on file before the request arrived. These losses are frequently large and rarely recovered, so the verification step is not bureaucracy; it is the control that prevents the loss.

### Why do duplicate vendor records matter so much?

They cause two concrete problems beyond untidiness. First, they fragment spend: if a supplier exists under three slightly different records, you cannot see how much you actually buy from it, which costs you negotiating leverage and rebate capture. Second, they create a duplicate-payment path, because the same invoice can be entered and paid against two different records without the system recognizing it as a repeat. Keeping the master deduplicated is both a spend-management and a payment-integrity discipline, which is why periodic cleansing and duplicate detection at creation both matter.

## Related objects

- [Vendor Onboarding & W-9](https://briq.ai/acu/object/vendor-onboarding-w9)
- [Certificate of Insurance (COI)](https://briq.ai/acu/object/certificate-of-insurance)
- [Lien Waiver](https://briq.ai/acu/object/lien-waiver)
- [Three-Way Match](https://briq.ai/acu/object/three-way-match)
- [Accounts Payable Invoice](https://briq.ai/acu/object/ap-invoice)
- [Subcontractor Invoice](https://briq.ai/acu/object/subcontractor-invoice)