How to build a vendor master sync

What matters here

• Verify every bank detail change out of band, by calling a number you already held. This is the highest-value control in the whole workflow.
• Detect duplicates at onboarding, not in a cleanup project. A duplicate supplier is how the same invoice gets paid twice.
• Key on the legal entity, not the trading name. One company can trade under four names and still be one payee.
• Screen against sanctions and match tax registration before the first payment, not before the first order.
• Report vendors with no spend in a year. A dormant vendor with live bank details is an attack surface.

Who this is for

You run finance systems or procurement operations. Suppliers are created ad hoc, the master has duplicates nobody has time to merge, and bank details are updated by email.

How it works in practice

What happens between needing a new supplier and being able to pay them safely.

1. 1

   Onboarding is one route with the fields payment needs

   Legal name, registration number, tax id, address and remittance details.

2. 2

   Duplicates are checked before anything is created

   On registration number, tax id and normalised name, because cleanup afterwards never happens.

3. 3

   Identity and compliance are checked before first payment

   Registry match, tax validation and sanctions screening.

4. 4

   Bank details are verified out of band, always

   A call to a number already on file, never a number supplied in the request.

5. 5

   One record propagates to every system

   Procurement, ERP and payments read the same vendor rather than each holding their own.

6. 6

   Changes to payment details are treated as events

   Re-verified, recorded, and notified, never applied as a routine field update.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   First, find every place a vendor exists

   There are usually more masters than anybody admits.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are NetSuite and Coupa, or
   whatever we run in those seats.
   
   I need the vendor record in each: which fields exist, which are mandatory,
   where bank details live and who can change them, and how each system
   identifies a vendor.
   
   Then tell me how many vendors exist in each and how much they overlap.
   There are usually more masters than anybody admits, and each extra one is
   another place bank details can be wrong.

2. 2

   Onboard once, and check for duplicates first

   Because the cleanup project never happens.

   Headless skills build-workflow

   Copy

   Use build-workflow. One onboarding route, asking for what payment
   actually needs: legal entity name, company registration number, tax
   registration, registered address, remittance address, contact, and
   payment terms.
   
   Before creating anything, check for duplicates:
   
     Exact on company registration number, which is definitive
     Exact on tax registration
     Normalised legal name plus country, with legal suffixes stripped
     Bank account number, which catches a supplier onboarded twice under
     different names
   
   Above a confidence threshold, block and show the existing vendor. Between
   thresholds, route to a person.
   
   Key the master on the legal entity. One company trading under four names
   is one payee, and treating each name as a vendor is how the same invoice
   gets paid twice.

3. 3

   Verify identity and compliance before the first payment

   Before payment, not before the first order.

   Copy

   Before a vendor can be paid, not merely created:
   
     Validate the registration number against the company registry where an
     API exists
     Validate the tax registration format and check it where possible
     Screen the entity and its known officers against sanctions lists
     Check whether the vendor is already an employee, by matching bank
     details and addresses against payroll, which catches a specific and
     recurring fraud
   
   Record every check with its result and date. A vendor that passed
   screening two years ago has not been screened, and re-screening on a
   schedule is the difference between a control and a formality.

4. 4

   Treat a bank detail change as an event, never a field update

   This is the highest-value control in the workflow.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then handle bank detail changes as their own process:
   
     Never apply a change from an email or an attachment
     Verify by calling a number already held on the vendor record, never a
     number supplied in the request
     Require a second approver
     Notify the previous contact on file that details were changed
     Hold all payments to that vendor for a short period after any change
     Record who requested, who verified, who approved, and how
   
   A request to change payment details is the most common invoice fraud
   there is, and it usually arrives as a plausible email from a real
   supplier domain during a busy week.
   
   Every one of those steps exists because a company somewhere skipped it.

5. 5

   Propagate one record, and prune the dormant ones

   A dormant vendor with live bank details is an attack surface.

   Headless skills tray-patterns

   Copy

   Propagate the vendor to every system that orders or pays, with the master
   id carried on each, so a reconciliation compares records instead of 
   names.
   
   Reconcile nightly: vendors in one system and not another, bank details
   that differ between systems, and any vendor created directly in a
   downstream system bypassing onboarding. That last one should be zero and
   rarely is.
   
   Then report: duplicates prevented at onboarding, bank changes and how
   each was verified, vendors with no spend in twelve months, and vendors
   that failed re-screening.
   
   Deactivate the dormant ones. A vendor nobody pays, with live bank details
   and no owner watching it, is an attack surface rather than a record.

6. 6

   Validate, then hand the controls to finance

   Because verification thresholds are a finance policy.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production.
   
   Then open the same workflow in Tray Build so finance systems can adjust
   the duplicate thresholds, the verification requirements and the
   re-screening cadence in the visual canvas.

What it connects to

One vendor record has to reach everywhere that orders or pays.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides