Finance Index
Who should own vendor master data, and what does segregation of duties look like for vendor setup?
Reference guide to vendor master governance segregation of duties, including vendor records, onboarding requirements, compliance checks, and fraud controls.
Vendor master data needs one accountable owner - usually AP or a vendor management function within finance - with defined rights for who can request, create, approve, and edit records. The core segregation-of-duties rule: no one person should be able to create or modify a vendor and also process payments to it. That combination is the classic embezzlement pattern.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Who should own vendor master | Vendor master data needs one accountable owner - usually AP or a vendor management function within finance - with defined rights for who can request, create, approve, and edit records. | Keeps vendor records and payment decisions reliable. |
| Vendor onboarding | Separate the three roles: requesters (anyone in the business) can propose; a small set of trained creators (AP/vendor management) can enter; an approver who is neither the requester nor the creator activates. | Keeps vendor records and payment decisions reliable. |
| Audit evidence | Triage in days, not months: pull the access list, revoke create/edit rights from everyone without a documented need (expect to cut 80%+), enable change logging on the vendor master if it's off, and route sensitive-field changes through approval workflow. | Keeps evidence clear and reduces control risk. |
| Vendor impact | Keep it lightweight: a written standard (naming, required fields), named roles (requester/creator/approver), change control on sensitive fields, quarterly access and exception reviews, and one owner accountable for data quality. | Keeps evidence clear and reduces control risk. |
| Workflow | It's the control ensuring the person who can add or change a payee can't also send money to it. | Keeps evidence clear and reduces control risk. |
Who can create vendors and who should approve them?
Separate the three roles: requesters (anyone in the business) can propose; a small set of trained creators (AP/vendor management) can enter; an approver who is neither the requester nor the creator activates. Sensitive changes - banking, remit-to, TIN - should re-trigger approval, not just creation. In system terms: creation rights restricted to a handful of named users, approval enforced by workflow, everything logged.
Our auditor asked who can edit vendors and the honest answer is "almost everyone" - how do I fix access fast?
Triage in days, not months: pull the access list, revoke create/edit rights from everyone without a documented need (expect to cut 80%+), enable change logging on the vendor master if it's off, and route sensitive-field changes through approval workflow. Then document the new model and run a one-time review of recent changes made under the old free-for-all - that's the remediation evidence the auditor actually wants.
What's a vendor master data governance model for a mid-market company?
Keep it lightweight: a written standard (naming, required fields), named roles (requester/creator/approver), change control on sensitive fields, quarterly access and exception reviews, and one owner accountable for data quality. Govern the 20% of fields that move money and taxes tightly; keep the rest easy.
What is SoD between vendor creation and payment processing and why do auditors care?
It's the control ensuring the person who can add or change a payee can't also send money to it. Auditors care because vendor-create-plus-pay is the highest-frequency internal fraud combination - a fake vendor plus a payment run equals theft with a clean paper trail.
How do I restrict vendor master changes in my ERP - permissions, workflows, field locks?
Use role-based permissions to limit create/edit to named users, approval workflows on creation and sensitive changes where the ERP supports them, and field-level security on banking and TIN where available. Where the ERP can't enforce workflow, compensate with mandatory change logs and monthly change review.
How do I set up an audit trail for vendor master changes?
Enable the ERP's field-change logging on the vendor master (most have it, often off by default), capture old value/new value/user/timestamp, and retain it. Pair the log with a monthly review of sensitive-field changes - a log nobody reads is evidence, not a control.
What should a vendor change-management process look like?
Request (with reason), evidence (the supporting document - new W-9, verified bank letter), approval by someone other than the requester, execution, and logging. For banking changes, add out-of-band verification before approval. One workflow, no email side doors.
Should the person who creates a vendor be allowed to enter invoices for that vendor - what SoD conflicts should I test?
Avoid it where staffing allows. Test for these combinations: vendor create + payment run, vendor edit (banking) + payment approval, vendor create + invoice entry + approval. Any one person holding a full chain from payee to payment is the finding.
We're small and one AP clerk does vendor setup, invoice entry, and payment runs - what compensating controls work?
When full SOD is impossible: owner/controller approval of all new vendors and banking changes, a monthly review of vendor-master change logs by someone independent, positive pay or payment-file review before release, and mandatory vacation with cross-coverage. Detection controls substitute for prevention when headcount can't.
Stampli perspective
Stampli is built for audit and accountability: vendor onboarding submissions, profile changes, and sensitive updates flow through approval-gated workflows, and every vendor interaction - edits, documents, communications - is preserved in an audit-ready history. The ERP keeps master-data ownership; Stampli adds the change control and traceability layer auditors ask about.