Vendor Management

Your controller found four active vendors in the AP system with no address, no tax ID, and no contract on file. All four had been paid in the past 90 days. Three turned out to be legitimate vendors added during a rush period. One couldn't be explained. Vendor master data is where AP fraud starts and where auditors look first. In an AP context, vendor management is the set of processes that govern how vendors are added to, maintained in, and removed from the vendor master file, the database that decides who can receive payments from the organization. It covers onboarding new vendors with proper validation, keeping banking and tax data accurate, finding and resolving duplicate vendor records, and controlling who can change the vendor master. It is separate from supplier relationship management in procurement, which deals with performance, negotiation, and sourcing. In AP, vendor management is a control function, and the vendor master file is the gatekeeper for payment authorization. If someone can create a fraudulent vendor record, a payment can be made to it. If someone can change a legitimate vendor's bank account without controls, payments can be diverted. Most AP fraud, internal and external, exploits weak vendor master controls, not weaknesses in payment processing or approval workflows.

What vendor management covers in an AP context

The vendor master file holds the data that authorizes and directs payments: the vendor's legal name, tax identification number, address, payment method, and bank account details. A change to any of these fields by the wrong person, or without adequate controls, creates payment risk. The most common fraud vector is vendor impersonation. An outsider calls or emails the AP team posing as a legitimate vendor and asks for a bank account change. Without proper verification, the AP team updates the banking details, and the next legitimate payment to that vendor goes to the fraudster's account. Business email compromise (BEC) attacks aimed at getting AP teams to change vendor banking details have caused billions in losses globally. The controls that prevent this are well understood: verify bank account changes by calling back a number already on file, not one the requestor supplies; require dual approval for bank account changes; and log every vendor master change with the identity of whoever made it. The gap is in implementation and adherence. Vendor master data also drives 1099 filing. At year-end, the IRS requires 1099-NEC or 1099-MISC filings for payments to US vendors above certain thresholds, and each filing needs an accurate tax ID (TIN) for the vendor. Missing or incorrect TINs create backup withholding obligations and filing complications. TIN data is established at vendor onboarding, when W-9 forms are collected and validated.

Where it gets complicated

Vendor onboarding should be a controlled process. Someone requests a new vendor, the requestor's identity and business need are verified, the vendor provides the required documents (W-9, bank details, contact information, and certificates of insurance where needed), and the AP or procurement team validates them before activating the record. TIN validation against the IRS TIN matching database confirms the name and tax ID match IRS records before the vendor is paid. That catches both errors (vendors who give the wrong TIN) and fraud (vendors using misappropriated TINs). Duplicate vendor detection is an ongoing data quality job. Vendors entered under slightly different names or abbreviations, or by different employees at different times, create duplicate records. Duplicates can lead to double payment, with two invoices processed against two records for the same vendor, and to audit complications. Most AP systems flag potential duplicates when a record is created; your controls should also include periodic review of existing records. Bank account changes need their own approval workflow, separate from invoice approval. Because a bank account change redirects where money goes, it is the highest-risk change to the vendor master. Good practice requires a callback to the vendor at an independently verified number (not the one in the change request), dual approval by two AP staff members, and a 24 to 48 hour hold on payments to that vendor after the change, so fraudulent requests are caught before the next payment run.

How platforms handle it

AP and procurement platforms demo vendor onboarding by filling in and submitting a new vendor form. That is the easy path. The controls worth testing are around changes and exceptions. When an AP staff member submits a bank account change, does the system require a second approver, and is there a hold period before the new account goes live? When someone enters a vendor name that closely matches an existing one, does the system flag a possible duplicate, and how does it show that flag? Can an AP staff member who adds vendors also process and approve payments to them, or does the system enforce segregation of duties? When a vendor record is deactivated, can invoices still be processed against it, or does deactivation block payment? Run these tests on any AP automation software you shortlist. Segregation of duties, meaning the person who can add vendors can't also pay them, is the foundational control that many smaller AP teams break out of necessity because they don't have enough staff to split the work. When that separation can't be maintained, compensating controls are required: management review of new vendor additions, periodic audits of vendor master changes, and monitoring reports that flag payments to recently added or recently modified vendors.

Questions to ask

• Are adding new vendors and processing payments to them handled by different staff members, and is that segregation enforced by system permissions?
• Does our vendor onboarding process include W-9 collection and IRS TIN validation before the vendor is activated and paid?
• Is there a separate approval workflow for bank account changes, distinct from invoice approval, with dual authorization and a hold period before the change takes effect?
• Are all vendor master changes logged with who made the change, the timestamp, and the previous value, and is that log reviewed periodically?
• Do we run periodic duplicate vendor reports to detect and resolve records that represent the same vendor entered under different names?
• Are deactivated vendors fully blocked from receiving new invoices and payments, or does deactivation only affect new vendor setup?

Common mistakes

Having no approval workflow for bank account changes is the single highest-risk control gap in vendor management, because bank account changes are how payment diversion fraud works. Without a verified process for updating bank details, including callback verification and dual approval, exposure to social engineering is built into the process. Organizations that have suffered vendor impersonation fraud almost always lacked a bank account change workflow with independent callback verification at the time of the incident. Letting AP staff both add vendors and pay them violates segregation of duties and shows up as a finding in almost every AP audit. The risk is internal fraud: one staff member can create a fictitious vendor, process invoices against it, and approve the payment with no one else involved. In small teams where separation isn't practical, compensating controls are mandatory. Management review of new vendor additions, a monthly reconciliation of payments to recently added vendors, and periodic internal audit testing of the vendor master partly make up for the separation that staffing can't provide.

The record, not the role

Search results treat this as a job title, with questions about what a vendor manager earns. In finance operations, vendor management is a control process. The highest-risk moment is a change to a supplier's bank details, because that is the entry point for payment redirection fraud, so verification out of band and a separation between the person who requests the change and the person who approves it are the standard mitigations.

Comparing AP automation

AP tools separate on what happens to the exceptions: the invoices that do not match a PO, arrive without one, or need a second approver. Once vendor management is settled as a requirement, read the Accounts Payable Automation Software category guide for how the market splits, then weigh the Stampli profile against the Tipalti profile on that requirement rather than on the feature list. Our Tipalti pricing breakdown records what the vendor publishes and what is quote-based. The BILL against Stampli comparison sets two of them side by side on the same criteria. Before you book demos, put your own numbers through the AP automation savings calculator so the business case is written down before a vendor writes it for you.

Vendor Management questions

Related terms

ACH Payment, AP Aging Report, and Approval Workflow come up in the same workflow as vendor management, and the rest of the AP automation cluster is indexed in the finance operations glossary.