Vendor invoice checks to run after an acquisition

Executive Summary

An acquisition closes on the balance sheet and the org chart long before it closes on vendor terms. The acquired company's contracts, rate cards, and rebate agreements do not automatically update to reflect the buyer's negotiated terms, and the buyer's AP team often has no visibility into what the acquired entity actually signed. The mechanism is simple: invoices keep paying against whatever contract was live at close, correct or not, until someone reconciles the two vendor files line by line.

The fix is not a full audit of every invoice from day one. It is a sequenced check: find the vendors that exist in both entities under different names, find the contracts that expired or changed hands during diligence, and find the rate cards nobody has re-pointed to the surviving entity's terms. Each of those is a discrete, checkable task with a clear owner.

What changes the outcome is timing. Run these checks in the first 100 days, while the acquired entity's AP records are still intact and before the two systems are merged into one chart of accounts. Wait until after systems consolidation and the audit trail that would prove overbilling is gone.

1. What should you check first after an acquisition closes?

Start with vendor identity, not invoice accuracy. Match both entities' vendor master files by tax ID and remit-to address, not by vendor name, because the same freight carrier or staffing agency often sits in each system under a different name and a different negotiated rate. Until that match is done, every other check runs against an incomplete list of who you actually pay, and duplicate vendors keep two rate cards active for one relationship.

A vendor master reconciliation is a data task before it is an audit task. Export both vendor files, match on tax ID first, remit-to address second, and vendor name last, because names drift across two AP systems even when the underlying entity has not changed.

Flag every pair that matches on tax ID but carries different payment terms, different rates, or different contract references. Each of those pairs is a candidate for two invoices being paid at two different rates for the same service, from the same vendor, in the same month.

This step also surfaces vendors the acquired company used that the buyer has an existing, better-priced contract with. Those are consolidation opportunities, not audit findings, and they belong on a separate list for procurement rather than AP.

Do this before touching invoice-level detail. An invoice check run against an unreconciled vendor file misses every case where the same vendor exists twice, which is exactly where a legacy rate keeps billing after the deal has closed.

2. Which contracts actually survive the transaction?

Not every vendor contract at the acquired entity transfers to the buyer, and not every contract that transfers keeps its original terms. Change-of-control clauses, assignment restrictions, and automatic renewal language decide this, and none of it is visible from the invoice. The invoice keeps arriving either way, so the only way to know which rate is actually enforceable is to read the contract, not the billing history.

Pull every service contract above a threshold you set and check three things: whether it has a change-of-control clause that triggers on the acquisition, whether it requires the counterparty's consent to assign, and whether it auto-renewed on terms nobody at either company re-negotiated.

A contract that legally terminated at close but keeps generating invoices at the old rate is not a vendor error. It is a control gap: nobody told AP the agreement ended, so AP kept paying against a document that no longer governs the relationship.

Conversely, a contract that survived intact but has since had its volume tier, rebate threshold, or NTE cap invalidated by the combined entity's new spend level is a different problem. The contract is valid; the number it was priced against no longer describes the business.

Both cases require the same fix: someone reads the contract language against the transaction structure, not just the payment history. Post-acquisition vendor contract consolidation covers how to sequence the work once this review is done.

3. How do you find duplicate payments hiding across two AP systems?

Duplicate payment risk spikes during integration because the same invoice can be entered once in the legacy AP system and again after data migration into the buyer's system, especially for vendors paid manually during the transition. Match on invoice number, vendor tax ID, amount, and date within a window, not on vendor name alone, since the vendor may be recorded under two different names across the two systems during the changeover.

The highest-risk window is the migration itself: invoices received in the last weeks before cutover, entered into the legacy system, then re-entered into the buyer's system because the transition team could not confirm they had been paid.

Run the match on invoice number plus tax ID plus amount, allowing for a date window of several weeks either side of cutover. A name-only match misses pairs where the acquired entity's short vendor name does not match the buyer's full legal name for the same tax ID.

Manual payments made outside either system during the transition, wires or checks cut to keep a vendor current while systems were down, are the least likely to be captured by either AP ledger and the most likely to duplicate later. Ask the transition team for that list explicitly rather than assuming it is in either system.

This check has a hard deadline. Once both AP ledgers are merged into one chart of accounts, the transaction-level detail that lets you trace a duplicate back to its origin system is much harder to reconstruct.

4. What should you do about rate cards and rebate terms that were never updated?

A rate card or rebate agreement negotiated for the acquired entity's pre-deal volume does not update itself when that entity's spend gets folded into the buyer's. Freight tiers, MRO volume discounts, and rebate thresholds are all written against a spend level that changed the day the deal closed, and nobody at the vendor is going to flag that the combined entity now qualifies for a better tier.

These two problems, rate card carryover and rebate threshold reset, both stem from the same root cause: a pricing agreement written against a spend figure that changed the day the deal closed, with no mechanism on either side that automatically re-prices it.

A vendor rarely raises this proactively, because a stale tier or an understated rebate favors them. The obligation to check sits with the buyer's AP or procurement team, and it should sit on the same list as the contract survival review rather than as a separate later project.

A. Rate card carryover

Every freight, MRO, and contract labor rate card tied to the acquired entity should be checked against the combined entity's post-close volume. A tier that made sense for the acquired company alone often understates what the buyer now qualifies for once the two spend bases are combined, and the vendor has no obligation to renegotiate proactively.

B. Rebate threshold reset

Rebate agreements calculated on a trailing twelve months of the acquired entity's standalone spend can understate or misstate what is owed once that spend is reported under the buyer's entity structure. Confirm with each vendor how the rebate calculation treats the combined entity going forward, and get it in writing rather than assuming the prior formula still applies.

5. Can existing AP automation catch these gaps on its own?

AP automation and three-way matching check an invoice against a purchase order and a receipt. Neither one reads a change-of-control clause, reconciles two vendor master files against each other, or notices that a rebate threshold was calculated on the wrong entity's spend base. Those checks require someone to read the contract and the transaction structure together, which is a one-time review, not a system configuration.

Three-way matching confirms an invoice matches what was ordered and received. It says nothing about whether the contract behind the purchase order is still the one that legally applies after a change of control, because that information does not live in the ERP.

The acquired entity's AP automation, if it has any, was configured against its own standalone vendor terms. Nobody has gone back and re-pointed those rules to the terms that actually survive the transaction, so the system keeps enforcing rules that may no longer be the correct ones.

This is why the checks in this guide are manual and contract-led rather than system-led. They close once, at integration, and the output becomes the reference the ongoing AP process should be configured against afterward. Indirect spend spans categories that AP automation was never configured to price against, which is the broader argument for where this fits against a continuous system.

6. How should a new CFO sequence this against everything else in the first 100 days?

Vendor invoice checks compete for attention with month-end close, reporting integration, and the board update in a new CFO's first 100 days. Sequence them early anyway: vendor master reconciliation and contract survival checks are cheap and fast now, and become expensive later once the acquired entity's records are absorbed into the combined chart of accounts and the original audit trail is gone.

None of these four checks require the acquired entity's systems to be merged first. They work better before that merge, while the original records are still intact and attributable to a single source system.

A new CFO's broader first 100 days plan has to hold reporting, close, and team integration alongside this. Treat the vendor checks as a fixed-scope project with its own owner rather than something the AP team absorbs into its existing workload, since it competes with month-end close for the same people's time.

For the wider pattern this sits inside, start with the margin drift guide.

1. Vendor master match: Run this in the first two weeks, while both vendor files still exist as separate, queryable exports.
2. Contract survival review: Complete before any vendor renegotiation conversation, so the buyer knows which contracts are actually still in force.
3. Duplicate payment sweep: Run once immediately post-cutover and again 60 days later, since manual transition payments surface with a lag.
4. Rate and rebate reset: Sequence after the vendor match, since you need the combined spend figure by vendor before a tier conversation makes sense.

For the wider pattern this sits inside, start with the margin drift guide.

7. Frequently Asked Questions (People Also Ask)

Who should own the post-acquisition vendor invoice review?

Assign a single owner, typically the controller or a designated integration lead, rather than splitting it across the existing AP team's regular workload. The review has a start and an end date and a defined output: a reconciled vendor list and a contract survival log. Treating it as a side task inside normal AP operations is how it stalls past the point where the original records are still recoverable.

Do we need outside help to run these checks, or can internal AP handle it?

Internal AP can run the vendor master match and duplicate payment sweep with existing tools. Contract survival review benefits from someone who reads contracts for a living, since change-of-control and assignment clauses are legal language, not billing data. Many teams split the work this way rather than outsourcing all of it.

What happens if we skip these checks and just let the systems merge first?

Once the two AP ledgers are combined into one chart of accounts, the transaction-level detail that ties an invoice back to its original source system becomes much harder to reconstruct. A duplicate payment or a stale rate is still there, but the audit trail that would prove it and let you recover it is largely gone.

How far back should the duplicate payment sweep look?

Focus first on the weeks immediately before and after cutover, since that is when invoices are most likely to be entered into both the legacy and the buyer's system. Extend the window if the acquired entity had a slow or manual migration process, since delayed data entry widens the risk period.

Does this apply the same way to an asset purchase as to a stock purchase?

The mechanics differ. In an asset purchase, contracts generally do not transfer automatically and each one needs an explicit assignment or new agreement. In a stock purchase, the acquired entity's contracts typically continue unless a change-of-control clause says otherwise. Either way, the check is the same: read the contract before trusting the invoice.

What counts as a 'threshold' for which contracts get the survival review?

There is no fixed figure to apply here; set the threshold against your own indirect spend data, for example by reviewing every service contract above a dollar amount that covers most of your addressable spend by count of vendors reviewed, and add any contract flagged during diligence regardless of size.

Can the acquired entity's AP team just keep running as-is until the review is done?

Yes, and that is the point: leave the acquired entity's AP process untouched until the vendor match and contract survival review are complete. Changing their process before you know which contracts and rates are actually valid risks locking in the wrong terms before anyone has checked them.

What is the difference between this review and a normal AP recovery audit?

A standard recovery audit looks for overbilling and missed credits within one stable vendor file and one set of contracts. This review exists because the acquisition itself, not routine billing error, created two vendor files and two contract sets that need to be reconciled before a normal audit process even applies.

Should we tell vendors we are running this review?

Not upfront. Complete the internal vendor match and contract survival review first, so you know which specific gaps to raise. Then approach each flagged vendor individually about rate carryover or rebate treatment, rather than sending a broad notice that invites every vendor to renegotiate before you know your position.