# What to ask procurement after an ERP migration > A first-90-days question set for procurement and AP: rate cards, tax and freight rules, approval tolerances, and vendor master data after an ERP cutover. Source: https://valuexpa.com/insights/what-to-ask-procurement-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 that can widen that gap overnight, across every vendor at once, without anyone changing a contract. This guide is a question set for the weeks right after go-live. It targets the specific fields migration projects tend to get wrong, not general AP hygiene. ## Executive Summary An ERP migration resets the system that enforces vendor contract terms, and the reset almost never carries every term forward correctly. Rate cards get re-keyed by hand, tax and freight configurations get rebuilt from templates instead of from the actual contract, and approval workflows get recreated with different tolerance thresholds than the old system used. None of this shows up as an error. The new system runs, invoices post, and the mismatch sits quietly in the data until someone reconciles against the source contract. The mechanism is simple: migration projects are scoped and staffed to move data and go live, not to re-audit every vendor term against the contract file. Procurement and AP inherit a system that looks complete because every field has a value, but some of those values are wrong, stale, or defaulted. The fix is not more testing before cutover. It is a structured question set to procurement and AP in [the first 90 days after go-live](/guides/the-first-100-days-for-a-new-mid-market-manufacturing-cfo), aimed specifically at the fields most likely to have moved. This page gives that question set: what to ask about rate cards, tax and freight rules, approval tolerances, and vendor master data, and why each question targets a specific failure mode of migration rather than a generic control gap. ## 1. What should you check after an ERP migration? **Check four things first: whether vendor rate cards were re-entered correctly, whether tax and freight rules carried over or reverted to system defaults, whether approval tolerances match the old system's thresholds, and whether vendor master records point to the current contract version. Each of these is edited by hand during a migration, by someone working from a template or a prior export rather than the signed contract itself, which is exactly where a term quietly changes.** A migration project has a go-live date and a data-conversion team, not a contract-compliance mandate. The team's job is to get vendor records, open purchase orders, and pricing tables into the new system so the business can transact on day one. Verifying that every rate matches the underlying contract is a different task, usually owned by nobody explicitly. That gap is where drift starts. A rate card gets re-keyed from the old ERP's field rather than the contract PDF. A [freight accessorial table](/guides/freight-invoice-audit-in-industrial-distribution) gets rebuilt from the new ERP's default template because the old configuration did not map cleanly. An approval tolerance gets reset to the new system's out-of-the-box value because nobody carried over the old one. None of these show up as a system error. The invoice posts, the PO matches, the [month closes](/guides/month-end-close-for-multi-entity-manufacturers). The question set below walks procurement through the four places this happens most, so the check happens deliberately instead of by accident. ## 2. Did vendor rate cards migrate correctly? **Ask procurement to pull the current rate table for your ten highest-spend vendors directly from the new ERP and compare each line to the signed contract or the most recent amendment, not to the old ERP's export. The old system's export is not a source of truth; it may already have contained a stale rate that the migration then carried forward correctly, faithfully preserving an error that predates the cutover entirely.** Rate cards are usually migrated as a data extract from the legacy system, transformed to fit the new schema, and loaded. Each of those three steps is an opportunity for a rate to shift: a volume tier boundary rounds differently, a currency or unit-of-measure conversion is applied once instead of never, or a rate that was manually overridden in the old system reverts to its base value because the override lived outside the migrated field. The check has to go back to the contract, not just forward from the old system, because the old system's rate may itself have been wrong. Ask procurement for the rate card as it now displays in production, and match it line by line against the signed contract or its latest amendment. Do this for the vendors with the highest annual spend first. A rate error on a low-volume vendor costs little. The same error on a top-ten vendor compounds every invoice cycle until someone catches it. ## 3. Are tax and freight rules configured correctly post-migration? **Ask whether tax jurisdictions, exemption certificates, and freight accessorial tables were migrated from the old system's configuration or rebuilt from the new system's default templates. A rebuild from a template is the higher-risk path: it reproduces a generic rule set instead of your negotiated terms, and a surcharge schedule or exemption that took months to negotiate can disappear without triggering any visible error.** Tax and freight configuration is often the hardest part of a migration to map one-to-one, because the two ERPs rarely model jurisdictions, exemptions, and accessorial charges the same way. When a clean field-to-field mapping is not available, implementation teams frequently fall back on the new system's standard template and plan to customize later. That fallback is reasonable project management. It is also exactly where a negotiated surcharge waiver, a fuel surcharge cap, or a state tax exemption certificate gets dropped, because the template does not know your contract exists. Ask procurement directly which path was taken for your top freight carriers and any vendor with a negotiated tax treatment: migrated configuration, or rebuilt template. Where the answer is template, treat that vendor's next several invoices as needing a manual check against the contract until a full reconciliation confirms the rule is correct. ## 4. Do approval tolerances still match the old system's thresholds? **Ask for the price-variance and quantity-variance tolerance percentages configured in the new three-way match, and compare them to the thresholds the old system used. A wider tolerance band lets more variance through without a hold, which means a rate discrepancy that used to trigger a manual review can now post automatically, and nobody decided that on purpose.** Three-way matching checks the invoice against the purchase order and the receipt within a configured tolerance. If the invoiced price sits within that band, the system posts it without a hold. The tolerance itself is a setting, and settings default during a migration unless someone explicitly carries the old value forward. A new implementation often ships with a wider default tolerance than the business actually wants, because a wider band produces fewer holds during the stabilization period right after go-live. That is a reasonable short-term choice for reducing noise. Left in place permanently, it is a control that quietly stopped doing its job. Ask procurement or IT for the exact tolerance percentages now in production, on both price and quantity, and compare them to what the prior system enforced. If they widened during the migration and nobody decided that deliberately, that is the finding. ## 5. Does the vendor master point to the current contract terms? **Confirm that each vendor master record in the new ERP references the most recent signed contract or amendment, not an earlier version carried over from the legacy system's file. A vendor master field showing a contract number does not confirm the terms behind that number are current, only that a reference exists, and a stale reference is invisible until an invoice tests it.** Vendor master data is the record procurement and AP trust by default because it is the system of record. But a migration typically moves the master record's fields, not the judgment behind them. A contract number field gets populated correctly while the amendment it should point to does not exist as a linked document, or points to a version superseded eight months before the migration even started. This matters most for negotiated terms that live outside the base rate: [rebate tiers](/guides/contract-compliance-in-industrial-distribution), minimum volume commitments, and not-to-exceed caps. These are exactly the terms most likely to be maintained in a spreadsheet or a contract PDF rather than a structured ERP field, which makes them the easiest to lose in a data conversion. Walk the vendor master for your highest-spend contracts against the actual signed document, not against what the old ERP displayed. - **Contract version field:** Check that it names the latest amendment, not the original agreement, for any vendor renegotiated since the original contract was signed. - **Rebate and volume tier setup:** Confirm the tier thresholds and rebate percentages match the current agreement, since these are often maintained separately from the base rate card. - **NTE and cap fields:** Verify any [not-to-exceed ceiling](/guides/ebitda-protection-levers-ranked-by-speed-to-cash) or spend cap carried forward as a hard control, not just a note in a free-text field that no rule enforces. - **Renewal and expiration dates:** Check that contract expiration dates migrated correctly, since an expired contract left active lets a vendor's old rate stand indefinitely. ## 6. Who should own this check, and how long does it take? **Assign one owner, typically the controller or AP lead, to run this question set against your top vendors by spend within the first 90 days after go-live, before the post-migration stabilization period ends and attention moves elsewhere. The check does not need every vendor: prioritizing by spend concentration catches most of the dollar exposure with a fraction of the review effort a full audit would require.** Migrations generate their own project team, their own timeline, and their own sign-off criteria, all of which typically end at go-live or shortly after. Contract-term verification is rarely on that project's closing checklist, because it was never the project's mandate. That leaves it as an orphaned task unless someone claims it explicitly. The controller or AP lead is usually the right owner, because they see the invoices the checks are meant to catch problems in, and because they are the ones who will explain a margin gap to the CFO later if the checks did not happen. Scope the check to the vendors carrying the most spend rather than attempting full coverage immediately. A concentrated review of the top vendors, run inside the first 90 days, catches the terms most likely to matter in dollar terms. Broader coverage can follow once the highest-risk vendors are confirmed clean. For the wider pattern this sits inside, start with the [margin drift](/guides/cfo-agenda-mid-market-manufacturing) guide. ## 7. Frequently Asked Questions (People Also Ask) ### How soon after go-live should we run this check? Within the first 90 days, while the migration team and its documentation are still available to answer questions about what was migrated versus rebuilt. Waiting longer makes it harder to trace a discrepancy back to a specific migration decision, because normal operations will have layered more changes on top of the original cutover. ### Does our ERP vendor's implementation partner already check this? Implementation partners are typically scoped to move data and configure the system to go live, not to verify every migrated rate against the signed contract. Ask directly what validation was performed on pricing and tax configuration specifically, since general data-migration testing does not necessarily include contract-level verification. ### What if we don't have a copy of every vendor contract on file? Start with the vendors you can verify and flag the rest as a separate finding. A missing contract is itself a control gap worth raising, since it means procurement cannot confirm what any system, old or new, should be charging that vendor. ### Should we hold payments while we run this check? No. Holding payments broadly creates its own vendor relationship and cash flow costs. Run the check in parallel with normal payment cycles, and flag specific invoices for manual review only where a vendor's rate card or tolerance setting is confirmed uncertain. ### Is this specific to one ERP platform? No. The failure mode comes from how migration projects are scoped and staffed, not from any single platform's technical limitations. The same rate-card, tax-configuration, tolerance, and vendor-master risks appear across ERP migrations generally. ### How does this relate to a broader margin drift problem? An ERP migration is a trigger event that can introduce or reset drift across many vendors at once. It sits alongside other causes of margin drift, such as ordinary contract changes or vendor billing errors, but concentrates the risk into a short window right after cutover. ### What's the difference between this and a full contract compliance audit? This question set is a targeted, fast check aimed at the specific fields a migration is likely to have disturbed: rates, tax and freight rules, tolerances, and vendor master references. A full contract compliance audit is broader in scope and not limited to a migration event. ### Can our existing AP team run this, or do we need outside help? An AP or controller team with contract access and time can run this for a prioritized list of top vendors. The constraint is usually time and cross-referencing capacity, not expertise, since the task is comparing system output to a document rather than performing specialized analysis. ### 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 An ERP migration resets the system that enforces vendor contract terms, and the reset almost never carries every term forward correctly. Rate cards get re-keyed by hand, tax and freight configurations get rebuilt from templates instead of from the actual contract, and approval workflows get recreated with different tolerance thresholds than the old system used. None of this shows up as an error. The new system runs, invoices post, and the mismatch sits quietly in the data until someone reconciles against the source contract. The mechanism is simple: migration projects are scoped and staffed to move data and go live, not to re-audit every vendor term against the contract file. Procurement and AP inherit a system that looks complete because every field has a value, but some of those values are wrong, stale, or defaulted. The fix is not more testing before cutover. It is a structured question set to procurement and AP in [the first 90 days after go-live](/guides/the-first-100-days-for-a-new-mid-market-manufacturing-cfo), aimed specifically at the fields most likely to have moved. This page gives that question set: what to ask about rate cards, tax and freight rules, approval tolerances, and vendor master data, and why each question targets a specific failure mode of migration rather than a generic control gap. ## 1. What should you check after an ERP migration? Check four things first: whether vendor rate cards were re-entered correctly, whether tax and freight rules carried over or reverted to system defaults, whether approval tolerances match the old system's thresholds, and whether vendor master records point to the current contract version. Each of these is edited by hand during a migration, by someone working from a template or a prior export rather than the signed contract itself, which is exactly where a term quietly changes. A migration project has a go-live date and a data-conversion team, not a contract-compliance mandate. The team's job is to get vendor records, open purchase orders, and pricing tables into the new system so the business can transact on day one. Verifying that every rate matches the underlying contract is a different task, usually owned by nobody explicitly. That gap is where drift starts. A rate card gets re-keyed from the old ERP's field rather than the contract PDF. A [freight accessorial table](/guides/freight-invoice-audit-in-industrial-distribution) gets rebuilt from the new ERP's default template because the old configuration did not map cleanly. An approval tolerance gets reset to the new system's out-of-the-box value because nobody carried over the old one. None of these show up as a system error. The invoice posts, the PO matches, the [month closes](/guides/month-end-close-for-multi-entity-manufacturers). The question set below walks procurement through the four places this happens most, so the check happens deliberately instead of by accident. ## 2. Did vendor rate cards migrate correctly? Ask procurement to pull the current rate table for your ten highest-spend vendors directly from the new ERP and compare each line to the signed contract or the most recent amendment, not to the old ERP's export. The old system's export is not a source of truth; it may already have contained a stale rate that the migration then carried forward correctly, faithfully preserving an error that predates the cutover entirely. Rate cards are usually migrated as a data extract from the legacy system, transformed to fit the new schema, and loaded. Each of those three steps is an opportunity for a rate to shift: a volume tier boundary rounds differently, a currency or unit-of-measure conversion is applied once instead of never, or a rate that was manually overridden in the old system reverts to its base value because the override lived outside the migrated field. The check has to go back to the contract, not just forward from the old system, because the old system's rate may itself have been wrong. Ask procurement for the rate card as it now displays in production, and match it line by line against the signed contract or its latest amendment. Do this for the vendors with the highest annual spend first. A rate error on a low-volume vendor costs little. The same error on a top-ten vendor compounds every invoice cycle until someone catches it. ## 3. Are tax and freight rules configured correctly post-migration? Ask whether tax jurisdictions, exemption certificates, and freight accessorial tables were migrated from the old system's configuration or rebuilt from the new system's default templates. A rebuild from a template is the higher-risk path: it reproduces a generic rule set instead of your negotiated terms, and a surcharge schedule or exemption that took months to negotiate can disappear without triggering any visible error. Tax and freight configuration is often the hardest part of a migration to map one-to-one, because the two ERPs rarely model jurisdictions, exemptions, and accessorial charges the same way. When a clean field-to-field mapping is not available, implementation teams frequently fall back on the new system's standard template and plan to customize later. That fallback is reasonable project management. It is also exactly where a negotiated surcharge waiver, a fuel surcharge cap, or a state tax exemption certificate gets dropped, because the template does not know your contract exists. Ask procurement directly which path was taken for your top freight carriers and any vendor with a negotiated tax treatment: migrated configuration, or rebuilt template. Where the answer is template, treat that vendor's next several invoices as needing a manual check against the contract until a full reconciliation confirms the rule is correct. ## 4. Do approval tolerances still match the old system's thresholds? Ask for the price-variance and quantity-variance tolerance percentages configured in the new three-way match, and compare them to the thresholds the old system used. A wider tolerance band lets more variance through without a hold, which means a rate discrepancy that used to trigger a manual review can now post automatically, and nobody decided that on purpose. Three-way matching checks the invoice against the purchase order and the receipt within a configured tolerance. If the invoiced price sits within that band, the system posts it without a hold. The tolerance itself is a setting, and settings default during a migration unless someone explicitly carries the old value forward. A new implementation often ships with a wider default tolerance than the business actually wants, because a wider band produces fewer holds during the stabilization period right after go-live. That is a reasonable short-term choice for reducing noise. Left in place permanently, it is a control that quietly stopped doing its job. Ask procurement or IT for the exact tolerance percentages now in production, on both price and quantity, and compare them to what the prior system enforced. If they widened during the migration and nobody decided that deliberately, that is the finding. ## 5. Does the vendor master point to the current contract terms? Confirm that each vendor master record in the new ERP references the most recent signed contract or amendment, not an earlier version carried over from the legacy system's file. A vendor master field showing a contract number does not confirm the terms behind that number are current, only that a reference exists, and a stale reference is invisible until an invoice tests it. Vendor master data is the record procurement and AP trust by default because it is the system of record. But a migration typically moves the master record's fields, not the judgment behind them. A contract number field gets populated correctly while the amendment it should point to does not exist as a linked document, or points to a version superseded eight months before the migration even started. This matters most for negotiated terms that live outside the base rate: [rebate tiers](/guides/contract-compliance-in-industrial-distribution), minimum volume commitments, and not-to-exceed caps. These are exactly the terms most likely to be maintained in a spreadsheet or a contract PDF rather than a structured ERP field, which makes them the easiest to lose in a data conversion. Walk the vendor master for your highest-spend contracts against the actual signed document, not against what the old ERP displayed. - Contract version field: Check that it names the latest amendment, not the original agreement, for any vendor renegotiated since the original contract was signed. - Rebate and volume tier setup: Confirm the tier thresholds and rebate percentages match the current agreement, since these are often maintained separately from the base rate card. - NTE and cap fields: Verify any [not-to-exceed ceiling](/guides/ebitda-protection-levers-ranked-by-speed-to-cash) or spend cap carried forward as a hard control, not just a note in a free-text field that no rule enforces. - Renewal and expiration dates: Check that contract expiration dates migrated correctly, since an expired contract left active lets a vendor's old rate stand indefinitely. ## 6. Who should own this check, and how long does it take? Assign one owner, typically the controller or AP lead, to run this question set against your top vendors by spend within the first 90 days after go-live, before the post-migration stabilization period ends and attention moves elsewhere. The check does not need every vendor: prioritizing by spend concentration catches most of the dollar exposure with a fraction of the review effort a full audit would require. Migrations generate their own project team, their own timeline, and their own sign-off criteria, all of which typically end at go-live or shortly after. Contract-term verification is rarely on that project's closing checklist, because it was never the project's mandate. That leaves it as an orphaned task unless someone claims it explicitly. The controller or AP lead is usually the right owner, because they see the invoices the checks are meant to catch problems in, and because they are the ones who will explain a margin gap to the CFO later if the checks did not happen. Scope the check to the vendors carrying the most spend rather than attempting full coverage immediately. A concentrated review of the top vendors, run inside the first 90 days, catches the terms most likely to matter in dollar terms. Broader coverage can follow once the highest-risk vendors are confirmed clean. For the wider pattern this sits inside, start with the [margin drift](/guides/cfo-agenda-mid-market-manufacturing) guide. ## Common questions ### How soon after go-live should we run this check? Within the first 90 days, while the migration team and its documentation are still available to answer questions about what was migrated versus rebuilt. Waiting longer makes it harder to trace a discrepancy back to a specific migration decision, because normal operations will have layered more changes on top of the original cutover. ### Does our ERP vendor's implementation partner already check this? Implementation partners are typically scoped to move data and configure the system to go live, not to verify every migrated rate against the signed contract. Ask directly what validation was performed on pricing and tax configuration specifically, since general data-migration testing does not necessarily include contract-level verification. ### What if we don't have a copy of every vendor contract on file? Start with the vendors you can verify and flag the rest as a separate finding. A missing contract is itself a control gap worth raising, since it means procurement cannot confirm what any system, old or new, should be charging that vendor. ### Should we hold payments while we run this check? No. Holding payments broadly creates its own vendor relationship and cash flow costs. Run the check in parallel with normal payment cycles, and flag specific invoices for manual review only where a vendor's rate card or tolerance setting is confirmed uncertain. ### Is this specific to one ERP platform? No. The failure mode comes from how migration projects are scoped and staffed, not from any single platform's technical limitations. The same rate-card, tax-configuration, tolerance, and vendor-master risks appear across ERP migrations generally. --- 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