Every vendor a company pays has a master record: legal entity name, tax identification number, remittance address, banking details for electronic payment, agreed payment terms, and approved contacts. Every purchase order, invoice, and payment references this record rather than re-entering the same details each time.

Because this data controls where money actually gets sent, it's a favorite target for fraud: a common scheme is a fraudulent request to update a vendor's banking details, redirecting a real, legitimate invoice's payment to an attacker's account. Vendor master changes are typically among the most tightly controlled updates in a finance system.

Frequently Asked Questions

Why is a bank-detail change on a vendor record treated as high-risk?

Because it silently redirects future payments, an attacker who successfully changes a vendor's bank details doesn't need to fake an invoice, they just wait for the next legitimate one to get paid to the wrong account. This is why these changes typically require independent verification, not just approval from whoever requested it.

What causes duplicate vendor records?

The same vendor entered slightly differently by different requesters, a misspelled name, an old address, a different contact, creates a second record for what should be one supplier, which fragments spend visibility and can even cause duplicate payments.

Should an AI agent be allowed to update vendor master data directly?

It can prepare and validate the change, but sensitive fields, especially banking details, should require independent human verification before the update takes effect, given the fraud risk involved. Zamp addresses this by separating an agent's ability to propose a change from the authority to approve it.

How does vendor master data connect to onboarding?

Vendor onboarding is the process that creates this record in the first place, collecting and verifying the tax, banking, and compliance documentation before a new supplier can be paid at all.