Vendor Master Data

A company pays the same supplier many times, so rather than entering every address and bank account for each invoice it stores a supplier record, and that record is vendor master data. A wrong field can affect many orders and payments, so it needs ownership and checks.

SAP's learning material describes business-partner master data in sourcing and procurement and Oracle's documentation shows supplier bank-account setup fields, but these are examples of system design, not a mandate that every company collect identical fields, and a company should keep only what is needed under applicable privacy and tax rules. Identity comes first, so record the supplier's legal name, registration details and address rather than only a trading name.

Similar names can belong to different entities, and a verified identifier helps distinguish them and supports tax documentation, so do not merge records solely because a salesperson says the firms are part of one group. Commercial data can include payment terms, currency, tax treatment and purchasing contacts, which affect when invoices are due and whether orders can be placed, and a master record should not be edited for a new contract without confirming the contract's effective date.

Bank details are highly sensitive because a fraudulent change can redirect every future payment. Require a documented request and independent verification through a contact method already held, not the phone number in the change request, and let a second reviewer approve the new beneficiary before it goes live.

Keep a history of changes showing old and new values, who requested and approved them, and when they took effect, because if a payment is disputed the team needs to know which bank account was active at that time and overwriting a field without an audit trail destroys useful evidence. Duplicate records create problems, as two vendor IDs for one supplier can split spending, bypass negotiated terms or trigger duplicate payments.

Check registration and bank details before creating another record, although sometimes two entities in one corporate group genuinely need separate IDs, so investigate before merging. Supplier onboarding should reflect risk, since a stationery vendor may need fewer checks than a provider with customer-data access or a cross-border payee, and a long form for every small purchase invites workarounds, so define a basic data set and additional fields for sensitive categories.

Inactive vendors should not remain freely payable forever, so review records not used for a defined period and restrict or archive them under policy, and trigger identity and bank-detail checks on reactivation because a fraudster can exploit an old record if no one notices it has changed. Master data and transaction data are different: a supplier's address belongs in the master, while each purchase order and invoice records a particular deal, so a wrong invoice does not always mean the master is wrong.

Diagnose which layer needs correction rather than changing permanent details to make one payment fit. For illustration, 100 supplier records are sampled and eight have unverified bank changes, so the observed exception rate is 8%; that does not mean eight frauds occurred but shows a control gap needing review, including an assessment of payment exposure and whether any affected transfers were sent.

Access permissions matter too, since few staff should be able to edit bank accounts and those staff should not release payments alone, and request, verification and approval roles should be separated where possible, with access reviewed when employees leave or change duties. Review data quality periodically for missing tax numbers, invalid addresses, unused accounts and duplicate identifiers, ask suppliers for updates through a verified channel rather than relying on a single annual email, and keep bank details out of a spreadsheet shared with everyone, because vendor master data is an operating control as well as a database that should stay current without making onboarding needlessly slow.