# Vendor invoice checks after an ERP migration > Guide on which vendor invoice checks to run after an ERP migration, covering rate cards, tax setup, PO matching, and vendor master data risks during cutover. Source: https://valuexpa.com/insights/vendor-invoice-checks-to-run-after-an-erp-migration Publisher: ValueXPA (https://valuexpa.com) Updated: 2026-09-06 --- Margin drift is the gap between what a vendor contract says and what the invoice actually charges. An ERP migration is one of the few events guaranteed to widen that gap in a single quarter, because the systems doing the checking change while the contracts they check against do not. Rate tables get rebuilt by hand. Approval workflows get rebuilt from a template that was never yours. Vendor master records get merged, deduplicated, or dropped. None of that shows up as an error message. It shows up three months later as a line item nobody can explain. ## Executive Summary A migration moves the enforcement layer, not the contract. Every rate card, surcharge schedule, tax rule and approval threshold that lived correctly in the old ERP has to be re-entered, re-mapped or re-imported into the new one, and each of those steps is a place a number can change without anyone deciding it should. The invoice keeps looking normal. The contract underneath it has quietly stopped matching. The mechanism is migration-specific, not generic AP risk: data conversion scripts round or truncate fields, vendor records get merged and lose their negotiated terms, three-way match tolerances reset to system defaults, and tax jurisdiction mapping breaks on multi-entity structures. None of these is a fraud. All of them are drift, and all of them are invisible in a normal invoice approval workflow because the invoice, the PO and the receipt all agree with each other. They just agree with the wrong number. What changes it is a fixed window of checks run against the source system before the old ERP is decommissioned, not against the new one in isolation. You need the pre-migration contract terms in hand, not just the post-migration output, or there is nothing to compare the new numbers against. ## 1. What should you check after an ERP migration? **Check five things before the old system is decommissioned: vendor master data integrity, rate card and price list accuracy, tax and jurisdiction mapping, three-way match tolerance settings, and open purchase order carryover. Each one is a place the conversion process can silently substitute a default, a rounded figure, or a blank field for a negotiated contract term, and each failure looks identical to a normal invoice until someone checks it against the original contract.** The checklist matters more than the order. Vendor master data comes first only because everything else depends on it: if a vendor record was merged, split, or re-keyed during conversion, every rate and term attached to it moved with it, correctly or not. Rate cards and price lists are the second most common failure because they are usually re-entered rather than migrated as structured data. A price list stored as a scanned PDF in the old system does not import. Someone retypes it, and a single misread column header turns a volume discount into a flat rate. Tax and jurisdiction mapping breaks specifically on multi-entity structures, where the old system had entity-specific tax logic that the new chart of accounts does not reproduce by default. Three-way match tolerances reset to whatever the new system ships with, which is rarely what your AP team configured over years of exceptions. Open purchase orders spanning the cutover date need a manual carryover check, because a PO closed and reopened in the new system can silently lose its original pricing terms. ## 2. Why does vendor master data break during a migration? **Vendor master records break during migration because deduplication logic merges vendors that were legitimately separate for billing purposes, such as a carrier's regional divisions with different rate agreements, or drops fields the conversion script does not recognize, such as a rebate tier stored in a custom field. The result is a vendor record that looks complete but is missing the exact term an invoice needs to be checked against.** A deduplication pass is standard in any ERP conversion project. It is designed to collapse duplicate entries and clean up the vendor list before go-live. The problem is that a single corporate vendor can legitimately have multiple billing entities, regional divisions, or subsidiary accounts, each carrying its own negotiated rate. When the dedup script merges those records because they share a tax ID or an address, it has to pick one set of terms to keep and discard the rest. Whichever contract term was not selected disappears from the new system entirely, with no error and no flag. Custom fields carry the same risk in the other direction. A rebate tier, a minimum volume commitment, or an NTE cap that lived in a custom field in the old ERP has to be explicitly mapped to a field in the new one. If the conversion script does not recognize the field type, it is silently dropped rather than migrated, and the vendor record in the new system looks complete because nothing indicates a field is missing. ## 3. How do rate cards and price lists get corrupted in conversion? **Rate cards and price lists get corrupted through three specific mechanisms: manual re-entry from an unstructured source such as a PDF or scanned document, unit mismatches where the old system stored a rate per pallet and the new system imports it as per case, and effective-date errors where a superseded rate is imported instead of the current one because the source file had multiple versions in a single folder.** Most contract pricing does not live in the ERP as clean structured data. It lives as a PDF rate schedule, a rebate agreement in a shared drive, or an amendment email that someone manually keyed into the old system years ago. None of that migrates automatically. A migration project typically re-keys pricing data from whatever source document the project team can locate, and the accuracy of that re-entry depends entirely on which version of the document they found. A vendor that amended its rate card eighteen months ago but never sent the update to your AP team has two versions in circulation, and the older one is exactly as likely to get keyed in as the current one. Unit mismatches are a narrower but common failure: a freight rate quoted per hundredweight in the source contract can be imported as a flat per-unit charge if the field mapping does not carry the unit of measure along with the number. The dollar figure looks plausible on its own and only fails when checked against the original contract line. ## 4. What happens to three-way match tolerances after migration? **Three-way match tolerance settings, the dollar or percentage thresholds that determine whether an invoice needs manual review against its purchase order and receipt, typically reset to the new system's default configuration rather than carrying over the values your AP team tuned over time. A tolerance that was tightened to catch small recurring overcharges can revert to a wide default that lets the same overcharge pass automatically.** Three-way matching checks the invoice against the purchase order and the receipt. It confirms the quantity and price billed match what was ordered and received, within a configured tolerance band. That tolerance is not a contract term. It is a system setting, and system settings are exactly what an ERP migration replaces with new defaults unless someone explicitly exports and reimports them. An AP team that spent years narrowing its match tolerance to catch a specific vendor's habit of rounding up on freight surcharges loses that narrowing the moment the new system goes live with its factory default, typically a wider band designed to minimize exception volume for a generic implementation. The invoice that would have kicked out for review in the old system now passes automatically in the new one. Nothing about the vendor's billing changed. The control that used to catch it did. ## 5. Which open purchase orders need a manual check at cutover? **Any purchase order open across the cutover date needs a manual check, because closing and reopening a PO in the new system during conversion can strip the line-level pricing terms that were attached to the original order, replacing them with whatever the vendor master record shows as of the migration date rather than the price actually agreed when the PO was issued.** A purchase order is a snapshot of pricing at the moment it was issued. If a vendor's rate changed between PO issuance and invoice receipt, the PO price is what should govern, not the current rate card. That is the entire point of a PO in the first place. Migration conversion scripts do not always preserve that snapshot. Depending on how open orders are handled, a PO carried across cutover can be recreated in the new system using current vendor master pricing rather than the pricing that was locked in when the order was placed. The invoice then matches the PO exactly, because both were repriced to the same current rate, and the mismatch that should have been caught never surfaces. The check here is narrow and specific: pull every PO open on the cutover date, and confirm its line-level price in the new system against the original PO document, not against the current vendor rate card. ## 6. How long should the reconciliation window stay open? **Keep the source ERP's data accessible and the reconciliation window open for at least one full invoice cycle covering every vendor category, which for most industrial manufacturers means one full month-end close plus any vendors billed on longer cycles such as quarterly rebate settlements or annual maintenance contracts, so every recurring charge type has been tested at least once against its original contract.** A migration that goes live cleanly on day one can still be wrong for vendors billed on cycles longer than a month. A quarterly rebate settlement, an annual calibration contract, or a semi-annual maintenance true-up will not generate an invoice inside the first thirty days, which means the new system's handling of that vendor's terms has not actually been tested yet at go-live. Closing access to the old ERP before every billing cycle has run at least once removes the only reference point available for catching a conversion error on that vendor. Once the source system is decommissioned, the original contract terms as they existed in the old system are gone unless they were separately archived. The practical rule is to hold read access to the source system open until every distinct billing frequency in the vendor base has produced at least one invoice in the new system, and to check that invoice specifically against the archived contract term, not just against the new system's own output. ## 7. What should you do if you find drift after go-live? **Treat a post-migration finding as a data conversion defect, not a vendor billing dispute: document the original contract term, the value that appears in the new system, and the point in the conversion process where they diverged, then correct the master data before requesting any credit, because the same broken mapping is likely repeating across every invoice from that vendor until it is fixed at the source.** A single overcharge found after migration is rarely isolated. If a rate card was mistyped or a field was dropped during conversion, every invoice from that vendor processed since go-live carries the same error, not just the one that happened to get noticed. The fix has to happen in two places. First, correct the master data or the tolerance setting in the new system so the error stops recurring on the next invoice. Second, go back through every invoice processed since cutover for that vendor and recheck it against the original contract term, because AP has been paying against the wrong number the entire time and a credit memo for one invoice does not recover the rest. This is where a fixed-scope diagnostic differs from routine AP review: it checks the full population of post-migration invoices against pre-migration contract terms in one pass, across every vendor category, rather than waiting for individual invoices to surface complaints one at a time. For the wider pattern this sits inside, start with the [margin drift](/guides/cfo-agenda-mid-market-manufacturing) guide. See also [the six categories drift hides in](/guides/indirect-spend-audit-categories) and [margin drift vs. legitimate price increases: how to tell them apart](/guides/margin-drift-vs-legitimate-price-increases-how-to-tell-them). ## 8. Frequently Asked Questions (People Also Ask) ### How soon after go-live should we run these checks? Start within the first month-end close after cutover, while the source ERP is still accessible and staff who ran the conversion still remember the mapping decisions they made. Waiting until the old system is decommissioned removes your only reference point for what the contract terms looked like before migration. ### Can our new ERP's own validation reports catch this? No. Validation reports built into the new system check for data completeness and format, not accuracy against the original contract. A rate card entry that is complete, correctly formatted, and wrong will pass every validation check the new system runs, because the system has no way to know what the number should have been. ### Do we need to check every vendor or just the largest ones? Check every vendor category represented in your indirect spend, not just the largest dollar vendors. Conversion errors are tied to how a vendor's data was structured in the old system, not to spend volume, so a small vendor with a complex rebate structure carries the same conversion risk as a large one with simple flat pricing. ### What if the migration happened over a year ago? The checks still apply, though the source system may no longer be accessible. Work from archived contracts and rate schedules instead, and expect the reconciliation to take longer since you are rebuilding what the original terms should have been rather than comparing two live systems side by side. ### Is this the same as a standard post-implementation audit? No. A standard post-implementation audit typically checks that the new system functions correctly and that data migrated without technical errors. It does not check whether the migrated contract terms match the original agreements, which is a commercial question a technical audit is not scoped to answer. ### Which ERPs carry the highest risk during this kind of migration? Risk is tied to how much of a company's vendor pricing lived in unstructured documents versus structured system fields before migration, not to any particular ERP brand. A company moving off a heavily customized legacy system with data spread across spreadsheets carries more conversion risk than one moving between two modern systems with similar data models. ### Should this delay our go-live date? No. These are checks to run in parallel with and shortly after go-live, not gating criteria for it. Delaying a migration to complete a full contract reconciliation first is rarely practical; running the reconciliation against the source data during the transition window achieves the same result without holding up the project. ### What documentation do we need before the old system is turned off? Export or archive the full vendor master file, all rate cards and price lists, three-way match tolerance settings, and any open purchase orders as they stood immediately before cutover. These four records are what a post-migration reconciliation checks the new system against, and none of them can be reconstructed after decommissioning. ### Is contract complexity quietly draining your operating margin? A small systematic drift between your negotiated contracts and your actual vendor billing compounds quietly across a year of invoices. Stop guessing at your exposure and run a targeted audit. **[Take the Free Screener → https://valuexpa.com/margin-drift-screener](https://valuexpa.com/margin-drift-screener)** ## Executive Summary A migration moves the enforcement layer, not the contract. Every rate card, surcharge schedule, tax rule and approval threshold that lived correctly in the old ERP has to be re-entered, re-mapped or re-imported into the new one, and each of those steps is a place a number can change without anyone deciding it should. The invoice keeps looking normal. The contract underneath it has quietly stopped matching. The mechanism is migration-specific, not generic AP risk: data conversion scripts round or truncate fields, vendor records get merged and lose their negotiated terms, three-way match tolerances reset to system defaults, and tax jurisdiction mapping breaks on multi-entity structures. None of these is a fraud. All of them are drift, and all of them are invisible in a normal invoice approval workflow because the invoice, the PO and the receipt all agree with each other. They just agree with the wrong number. What changes it is a fixed window of checks run against the source system before the old ERP is decommissioned, not against the new one in isolation. You need the pre-migration contract terms in hand, not just the post-migration output, or there is nothing to compare the new numbers against. ## 1. What should you check after an ERP migration? Check five things before the old system is decommissioned: vendor master data integrity, rate card and price list accuracy, tax and jurisdiction mapping, three-way match tolerance settings, and open purchase order carryover. Each one is a place the conversion process can silently substitute a default, a rounded figure, or a blank field for a negotiated contract term, and each failure looks identical to a normal invoice until someone checks it against the original contract. The checklist matters more than the order. Vendor master data comes first only because everything else depends on it: if a vendor record was merged, split, or re-keyed during conversion, every rate and term attached to it moved with it, correctly or not. Rate cards and price lists are the second most common failure because they are usually re-entered rather than migrated as structured data. A price list stored as a scanned PDF in the old system does not import. Someone retypes it, and a single misread column header turns a volume discount into a flat rate. Tax and jurisdiction mapping breaks specifically on multi-entity structures, where the old system had entity-specific tax logic that the new chart of accounts does not reproduce by default. Three-way match tolerances reset to whatever the new system ships with, which is rarely what your AP team configured over years of exceptions. Open purchase orders spanning the cutover date need a manual carryover check, because a PO closed and reopened in the new system can silently lose its original pricing terms. ## 2. Why does vendor master data break during a migration? Vendor master records break during migration because deduplication logic merges vendors that were legitimately separate for billing purposes, such as a carrier's regional divisions with different rate agreements, or drops fields the conversion script does not recognize, such as a rebate tier stored in a custom field. The result is a vendor record that looks complete but is missing the exact term an invoice needs to be checked against. A deduplication pass is standard in any ERP conversion project. It is designed to collapse duplicate entries and clean up the vendor list before go-live. The problem is that a single corporate vendor can legitimately have multiple billing entities, regional divisions, or subsidiary accounts, each carrying its own negotiated rate. When the dedup script merges those records because they share a tax ID or an address, it has to pick one set of terms to keep and discard the rest. Whichever contract term was not selected disappears from the new system entirely, with no error and no flag. Custom fields carry the same risk in the other direction. A rebate tier, a minimum volume commitment, or an NTE cap that lived in a custom field in the old ERP has to be explicitly mapped to a field in the new one. If the conversion script does not recognize the field type, it is silently dropped rather than migrated, and the vendor record in the new system looks complete because nothing indicates a field is missing. ## 3. How do rate cards and price lists get corrupted in conversion? Rate cards and price lists get corrupted through three specific mechanisms: manual re-entry from an unstructured source such as a PDF or scanned document, unit mismatches where the old system stored a rate per pallet and the new system imports it as per case, and effective-date errors where a superseded rate is imported instead of the current one because the source file had multiple versions in a single folder. Most contract pricing does not live in the ERP as clean structured data. It lives as a PDF rate schedule, a rebate agreement in a shared drive, or an amendment email that someone manually keyed into the old system years ago. None of that migrates automatically. A migration project typically re-keys pricing data from whatever source document the project team can locate, and the accuracy of that re-entry depends entirely on which version of the document they found. A vendor that amended its rate card eighteen months ago but never sent the update to your AP team has two versions in circulation, and the older one is exactly as likely to get keyed in as the current one. Unit mismatches are a narrower but common failure: a freight rate quoted per hundredweight in the source contract can be imported as a flat per-unit charge if the field mapping does not carry the unit of measure along with the number. The dollar figure looks plausible on its own and only fails when checked against the original contract line. ## 4. What happens to three-way match tolerances after migration? Three-way match tolerance settings, the dollar or percentage thresholds that determine whether an invoice needs manual review against its purchase order and receipt, typically reset to the new system's default configuration rather than carrying over the values your AP team tuned over time. A tolerance that was tightened to catch small recurring overcharges can revert to a wide default that lets the same overcharge pass automatically. Three-way matching checks the invoice against the purchase order and the receipt. It confirms the quantity and price billed match what was ordered and received, within a configured tolerance band. That tolerance is not a contract term. It is a system setting, and system settings are exactly what an ERP migration replaces with new defaults unless someone explicitly exports and reimports them. An AP team that spent years narrowing its match tolerance to catch a specific vendor's habit of rounding up on freight surcharges loses that narrowing the moment the new system goes live with its factory default, typically a wider band designed to minimize exception volume for a generic implementation. The invoice that would have kicked out for review in the old system now passes automatically in the new one. Nothing about the vendor's billing changed. The control that used to catch it did. ## 5. Which open purchase orders need a manual check at cutover? Any purchase order open across the cutover date needs a manual check, because closing and reopening a PO in the new system during conversion can strip the line-level pricing terms that were attached to the original order, replacing them with whatever the vendor master record shows as of the migration date rather than the price actually agreed when the PO was issued. A purchase order is a snapshot of pricing at the moment it was issued. If a vendor's rate changed between PO issuance and invoice receipt, the PO price is what should govern, not the current rate card. That is the entire point of a PO in the first place. Migration conversion scripts do not always preserve that snapshot. Depending on how open orders are handled, a PO carried across cutover can be recreated in the new system using current vendor master pricing rather than the pricing that was locked in when the order was placed. The invoice then matches the PO exactly, because both were repriced to the same current rate, and the mismatch that should have been caught never surfaces. The check here is narrow and specific: pull every PO open on the cutover date, and confirm its line-level price in the new system against the original PO document, not against the current vendor rate card. ## 6. How long should the reconciliation window stay open? Keep the source ERP's data accessible and the reconciliation window open for at least one full invoice cycle covering every vendor category, which for most industrial manufacturers means one full month-end close plus any vendors billed on longer cycles such as quarterly rebate settlements or annual maintenance contracts, so every recurring charge type has been tested at least once against its original contract. A migration that goes live cleanly on day one can still be wrong for vendors billed on cycles longer than a month. A quarterly rebate settlement, an annual calibration contract, or a semi-annual maintenance true-up will not generate an invoice inside the first thirty days, which means the new system's handling of that vendor's terms has not actually been tested yet at go-live. Closing access to the old ERP before every billing cycle has run at least once removes the only reference point available for catching a conversion error on that vendor. Once the source system is decommissioned, the original contract terms as they existed in the old system are gone unless they were separately archived. The practical rule is to hold read access to the source system open until every distinct billing frequency in the vendor base has produced at least one invoice in the new system, and to check that invoice specifically against the archived contract term, not just against the new system's own output. ## 7. What should you do if you find drift after go-live? Treat a post-migration finding as a data conversion defect, not a vendor billing dispute: document the original contract term, the value that appears in the new system, and the point in the conversion process where they diverged, then correct the master data before requesting any credit, because the same broken mapping is likely repeating across every invoice from that vendor until it is fixed at the source. A single overcharge found after migration is rarely isolated. If a rate card was mistyped or a field was dropped during conversion, every invoice from that vendor processed since go-live carries the same error, not just the one that happened to get noticed. The fix has to happen in two places. First, correct the master data or the tolerance setting in the new system so the error stops recurring on the next invoice. Second, go back through every invoice processed since cutover for that vendor and recheck it against the original contract term, because AP has been paying against the wrong number the entire time and a credit memo for one invoice does not recover the rest. This is where a fixed-scope diagnostic differs from routine AP review: it checks the full population of post-migration invoices against pre-migration contract terms in one pass, across every vendor category, rather than waiting for individual invoices to surface complaints one at a time. For the wider pattern this sits inside, start with the [margin drift](/guides/cfo-agenda-mid-market-manufacturing) guide. See also [the six categories drift hides in](/guides/indirect-spend-audit-categories) and [margin drift vs. legitimate price increases: how to tell them apart](/guides/margin-drift-vs-legitimate-price-increases-how-to-tell-them). ## Common questions ### How soon after go-live should we run these checks? Start within the first month-end close after cutover, while the source ERP is still accessible and staff who ran the conversion still remember the mapping decisions they made. Waiting until the old system is decommissioned removes your only reference point for what the contract terms looked like before migration. ### Can our new ERP's own validation reports catch this? No. Validation reports built into the new system check for data completeness and format, not accuracy against the original contract. A rate card entry that is complete, correctly formatted, and wrong will pass every validation check the new system runs, because the system has no way to know what the number should have been. ### Do we need to check every vendor or just the largest ones? Check every vendor category represented in your indirect spend, not just the largest dollar vendors. Conversion errors are tied to how a vendor's data was structured in the old system, not to spend volume, so a small vendor with a complex rebate structure carries the same conversion risk as a large one with simple flat pricing. ### What if the migration happened over a year ago? The checks still apply, though the source system may no longer be accessible. Work from archived contracts and rate schedules instead, and expect the reconciliation to take longer since you are rebuilding what the original terms should have been rather than comparing two live systems side by side. ### Is this the same as a standard post-implementation audit? No. A standard post-implementation audit typically checks that the new system functions correctly and that data migrated without technical errors. It does not check whether the migrated contract terms match the original agreements, which is a commercial question a technical audit is not scoped to answer. --- ValueXPA runs a fixed-scope Margin Drift Diagnostic that validates every service vendor invoice against contract terms, for $100M+ US industrial manufacturers and distributors. Two to four weeks. The client retains 100% of recoveries. https://valuexpa.com/contact-us