Finance Index
How do I handle the vendor master through M&A, migrations, and system cutovers?
Reference guide to vendor master M&A migration, including vendor records, onboarding requirements, compliance checks, fraud controls, and payment readiness.
Vendor-master events - ERP migrations, mergers, system cutovers - are when vendor data is most at risk and fraudsters are most active. The disciplines that matter: cleanse before you migrate (don't carry junk into the new system), reconcile overlapping vendors after a merger, keep 1099 totals complete across both systems mid-year, and *tighten* controls during the chaos rather than relaxing them, because integration confusion is exactly what payment-redirection fraud exploits.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Handle the vendor master through | Vendor-master events - ERP migrations, mergers, system cutovers - are when vendor data is most at risk and fraudsters are most active. | Keeps vendor records and payment decisions reliable. |
| Vendor impact | Migrate active vendors (commonly those with activity in the last 18 months) and archive the rest with their history retained - don't carry a decade of dormant and duplicate records into a clean new system. | Keeps vendor records and payment decisions reliable. |
| Vendor cleanup | Cleanse before migrating: dedupe, fix missing TINs and banking, standardize names. | Keeps vendor records and payment decisions reliable. |
| Post-merger we have two | TIN-match to find the overlap, pick a survivor per vendor (usually the go-forward system's record with the richest valid data), reconcile conflicting terms and tax setups to a deliberate choice, merge in waves starting with active vendors, and keep a cross-reference of. | Keeps vendor records and payment decisions reliable. |
| Keep 1099 totals complete across | Decide which system files, export reportable-payment history from the legacy system before access lapses, and combine payments per TIN across both systems for the full year. | Reduces payment errors, timing issues, and reconciliation cleanup. |
Should we migrate all vendors or only active ones?
Migrate active vendors (commonly those with activity in the last 18 months) and archive the rest with their history retained - don't carry a decade of dormant and duplicate records into a clean new system. A migration is the rare chance to leave the junk behind; cleanse first, migrate the live file, and keep the archive accessible for 1099s and audit history.
How do I migrate the vendor master to a new ERP - what to cleanse, map, and leave behind?
Cleanse before migrating: dedupe, fix missing TINs and banking, standardize names. Map fields carefully (legal name, TIN, addresses, terms, banking, 1099 status) and validate the mapping on a sample. Leave behind dormant and duplicate records (archived, not deleted). Migrating dirty data just relocates the problem - the migration is your cleanup opportunity.
Post-merger we have two vendor masters with overlapping vendors on different terms and tax setups - consolidation playbook?
TIN-match to find the overlap, pick a survivor per vendor (usually the go-forward system's record with the richest valid data), reconcile conflicting terms and tax setups to a deliberate choice, merge in waves starting with active vendors, and keep a cross-reference of old-to-new IDs. Combine 1099 totals per TIN for the transition year.
How do I keep 1099 totals complete across both systems during a mid-year cutover?
Decide which system files, export reportable-payment history from the legacy system before access lapses, and combine payments per TIN across both systems for the full year. Reconcile the merged totals against both systems' disbursement records. The killer mistake is assuming the new system "has" the pre-cutover history - confirm it does, or export it.
The acquired entity's vendor file has no w-9s and questionable data - re-onboard everyone or grandfather them?
Risk-based: re-onboard (or at least re-verify W-9 and banking) for active and high-spend vendors, and especially before paying any of them; archive the inactive tail rather than re-onboarding it. Don't blanket-grandfather questionable data into your payments - but don't try to re-onboard a thousand dormant vendors either. Verify what you'll actually pay.
How do I notify vendors of an entity name change or new payment process after an acquisition without triggering confusion and fraud risk?
Communicate clearly and through trusted channels, explain what's changing and what isn't, and - critically - never ask vendors to change *their* banking as part of it, and warn them you won't ask. Acquisitions are prime time for fraudsters to impersonate "the new entity" requesting banking changes; tell vendors how to verify any such request is really from you.
What vendor controls should be tightened, not loosened, during integration chaos?
The change and creation controls: banking-change verification, new-vendor approval, and reactivation diligence. Fraudsters specifically target companies mid-merger because controls slip and "it's part of the integration" explains away anomalies. The instinct to relax controls for speed during a migration is exactly backward - tighten them while the noise is high.
Stampli perspective
Because Stampli keeps the ERP as the vendor source of truth and surrounds each record with its full interaction history, a migration or merger preserves the operational context - documents, communications, payment history - that usually gets lost in a raw data move. Required-document and approval-gated change controls also give a place to *tighten* vendor governance during integration rather than loosen it: new and reactivated vendors still route through review even when everything else is in flux.