Where margin drift shows up after an ERP migration

Executive Summary

An ERP migration resets every piece of configuration that used to catch a bad invoice: three-way match tolerances, rate cards loaded as master data, approval thresholds, and vendor master records. None of that configuration migrates itself correctly by default, and a project team focused on go-live rarely has time to test it against every contract clause.

The mechanism is straightforward. Old rate tables get re-keyed by hand or bulk-loaded from a flat file, tolerance percentages get reset to vendor defaults instead of contract terms, and vendor records get merged or duplicated during data cleanup. Each of those is a place where an invoice that used to fail a match now passes.

What changes it is treating the first two to three post-migration invoice cycles as a control test, not a completed project. Reconcile a sample of paid invoices against the source contracts, not against the new system's own output, before trusting the new configuration.

1. What should you check after an ERP migration?

Check four things in order: rate cards loaded as master data against the actual contract, three-way match tolerance settings against the old system's settings, vendor master records for duplicates or merges, and approval routing against the current authorization matrix. Each is a place where correct old-system behavior can silently reset to a wrong default during migration.

Rate cards are the first place to look because they are re-entered, not migrated as logic. A project team loads a price file into the new ERP; nobody re-checks it against the signed contract line by line.

Tolerance settings are the second. Many ERPs ship a default tolerance, often a flat percentage or dollar amount, and a rebuild can quietly replace a contract-specific tolerance with that default.

Vendor master records get touched during almost every migration for deduplication. A merge that consolidates two vendor codes can also merge two different contract terms into one record, so only one survives.

Approval routing is last because it fails more visibly. A missing approval step gets noticed faster than a stale rate, but it is worth confirming the new routing reflects the current authorization matrix and not the last one built for the old system.

2. Why does a rate card break during a system cutover?

A rate card breaks in migration because it exists in the ERP as static master data, not as a link to the underlying contract. Someone re-keys or bulk-loads the numbers, and small errors, stale versions, or unit mismatches carry forward as if they were correct, because the new system has no way to know the source document changed.

The rate card in an ERP is a table of numbers: a price per unit, a tier threshold, a surcharge percentage. It has no memory of the contract clause it came from.

During migration, that table is usually rebuilt from an export of the old system, not from the contract itself. If the old system's rate card was already stale, the new one inherits the same error and now carries a fresh timestamp that makes it look current.

Unit mismatches are a second common cause. A rate entered per pallet in the old system can be re-keyed per case in the new one if the data load does not carry the unit of measure with it, and the invoice will still look ordinary against the wrong number.

3. Which contract clauses are easiest to lose in a migration?

Volume tier triggers, rebate accrual schedules, and surcharge expiration dates are the clauses most likely to be lost, because none of them live as a single field in an ERP. They are conditions spread across a contract PDF that someone has to translate into system logic by hand, and that translation step is where they get dropped.

A volume tier trigger changes the unit price once a cumulative quantity is reached. It requires the new system to track spend against that vendor across the full period the contract defines, not just the current invoice.

A rebate accrual schedule works the other direction: money owed back to the buyer based on total purchases. If the accrual logic is not rebuilt with the same period and threshold, the rebate stops accruing and nobody notices until the credit fails to arrive.

A surcharge expiration date, common in fuel and freight contracts, is a condition rather than a static rate. A surcharge configured once and never revisited will keep applying after the condition that justified it has ended.

4. How should you test the new system before trusting it?

Pull a sample of invoices paid in the first full cycle after cutover and reconcile each one against the original contract document, not against what the new ERP calculated. Testing the system against its own output only confirms it is internally consistent. It does not confirm the configuration matches the contract.

Start with the highest-dollar vendors and the categories most governed by tiered or conditional pricing: freight, contract labor, and maintenance agreements typically carry the most conditional clauses.

For each sampled invoice, trace the rate back to the contract PDF, not to the rate table in the new system. If the invoice matches the system and the system does not match the contract, the match will pass and the error will still be there.

Repeat the sample for a second invoice cycle before declaring the migration clean. A rate table can be correct in month one and drift again in month two if the underlying master data record was only partially fixed.

5. When is a post-migration audit worth doing versus waiting?

An audit is worth doing in the first two to three billing cycles after cutover, while the configuration is still new enough that errors are concentrated and traceable to the migration itself. Waiting lets errors compound across renewals and rate changes, at which point separating migration error from ordinary drift becomes much harder.

Right after cutover, most configuration errors trace to a single, identifiable cause: a bad data load, a default tolerance, a merged vendor record. That makes each one fast to find and fix.

Once a few billing cycles pass, contracts renew, rates change, and new surcharges get added on top of whatever the migration got wrong. At that point an incorrect rate and a legitimately updated rate can look identical on the invoice.

The practical window is the first two to three cycles. After that, a full audit of the vendor category is a bigger undertaking. It is still worth doing, just under different conditions and with a wider scope.

6. Does the ERP vendor's implementation team catch these errors?

An ERP implementation team is scoped to confirm the system runs and the data loaded without error, not to verify every rate against every contract clause. That verification step sits outside a standard implementation statement of work and falls to the buyer's own AP or procurement team, which usually has neither the time nor the contract inventory to do it during go-live.

An implementation team's acceptance testing checks that transactions post, reports run, and integrations connect. That is a systems test, not a contract test.

Confirming that a rate card matches a signed contract requires someone to hold the contract and the system output side by side, line by line. That work is rarely in scope because it is not a system defect if the number is wrong; the system did exactly what it was configured to do.

This is why the check has to be a deliberate, separate step, owned by finance or procurement, run after go-live rather than assumed as part of it.

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

7. Frequently Asked Questions (People Also Ask)

How long after go-live should we wait before running this check?

Do not wait. Start reviewing the first full billing cycle after cutover, while errors are still traceable to specific migration steps like a data load or a tolerance reset. The longer you wait, the more a migration error blends with ordinary contract renewals and rate changes.

Which vendor categories should we sample first?

Start with categories governed by conditional pricing: freight and 3PL, contract labor, and maintenance or calibration agreements. These carry volume tiers, surcharge conditions, and rebate schedules that are easiest to lose in a data migration, compared with a flat unit-price vendor.

Can our AP automation software catch this instead of a manual check?

AP automation checks the invoice against the PO and the receipt inside the current system. It does not verify that the rate table or tolerance setting loaded into that system still matches the original contract. That verification has to happen against the contract document itself, separately.

What is the difference between a migration error and normal margin drift?

A migration error traces to a specific configuration change: a re-keyed rate, a reset tolerance, a merged vendor record. Ordinary margin drift accumulates over time as contracts renew and invoices are not re-checked. Both produce the same symptom on the invoice, so the contract has to be the reference point either way.

Should we test one invoice per vendor or a full cycle?

A full cycle. One invoice can pass by coincidence if it happens to fall under a tolerance threshold or before a tier is triggered. A full billing cycle exposes tier triggers, recurring surcharges, and rebate accrual behavior that a single invoice will not show.

Who should own this check inside the company?

Finance or procurement, not the ERP implementation team. The implementation team's scope ends at confirming the system runs correctly with the data it was given. Confirming that data matches the contract is a separate step that has to be assigned explicitly or it will not happen.

Does this apply to a partial migration, like moving only AP to a new module?

Yes. The same rate cards, tolerance settings, and vendor master records move or get rebuilt whenever AP itself changes systems, even if other modules stay put. The scope of what to check is the same regardless of how much of the broader ERP moved.

What should we do if we find an error during this check?

Correct the configuration first, then determine whether any invoices were already paid against the wrong rate or tolerance. Recovering an overpayment and fixing the underlying setting are two separate tasks, and fixing the setting alone still leaves the prior overpayment uncollected.