ERP Migration Data Governance: How to Protect P2P Controls Through an S/4HANA Cutover

ERP migration data governance is the set of named owners, documented controls and sign-off evidence that keeps procure-to-pay protected while data moves from a legacy ERP system into S/4HANA. It matters because a cutover does not pause fraud risk — it concentrates it. For the days or weeks when vendor data sits between two systems, the automated checks your accounts payable team depends on are often switched off, bypassed or not yet configured in the new ERP system.

That window is when fraudsters succeed. UK Finance reported £1.28 billion stolen through payment fraud in 2025, with authorised push payment losses up 19% year on year, and Trustpair’s own UK research found 93% of UK companies were targeted by fraud at least once. A shared services organisation mid-cutover is an unusually attractive target: approval chains are in flux, temporary manual processes become normalised, and nobody is quite sure who owns the supplier record this week.

The governance stakes have also risen sharply. The ECCTA 2023 failure to prevent fraud offence came into force on 1 September 2025, and Provision 29 of the 2024 UK Corporate Governance Code now requires boards to declare the effectiveness of material internal controls for financial years beginning on or after 1 January 2026. A migration that quietly suspends payment controls for three weeks is now a reportable problem, not just an operational one.

This guide takes a governance-led view of the cutover for shared services and GBS teams. If your team is accountable for both operational continuity and risk management, Trustpair’s vendor data management platform for GBS leaders is built around that overlap.

Key Takeaways

• A cutover is a control event, not just a technical one. Every automated P2P control in the legacy system needs a mapped equivalent or a documented compensating control before go-live.
• Name an enterprise data owner for supplier records and a separate process owner for P2P controls before data extraction begins. Unowned vendor master data is the most common root cause of post-cutover payment errors.
• Never migrate dirty data. Roughly 30% of vendor master files contain errors or anomalies, and migration inherits every one of them.
• Provision 29 and the ECCTA failure to prevent fraud offence mean cutover gates must close on evidence, not confidence: reconciliations, parity reports and an independent control owner signature.
• Confirmation of Payee is not supplier bank verification. Validate bank details against independent sources, because the same data you are trying to verify cannot be its own control.

Why Do P2P Controls Break During an S/4HANA Cutover?

P2P controls break because they are spread across disconnected systems, configurations and people, while migration programmes track data objects rather than control coverage. The supplier record migrates. The three-way match tolerance built on custom code does not.

With SAP ending mainstream maintenance for Business Suite 7 core applications at the end of 2027, and most enterprise resource planning migrations taking 12 to 24 months, many organisations are compressing timelines. That is where control continuity gets traded for schedule.

The failure modes we see most often:

• Automated controls lose their trigger. A duplicate-invoice check keyed to a legacy supplier ID stops firing once identifiers are normalised.
• Approval hierarchies flatten. Workflow is rebuilt in the new system and delegation rules get simplified “for now”.
• Bank detail controls go manual. Amendments move to email and spreadsheet because neither ERP database is authoritative.
• Segregation of duties erodes. Migration teams get broad access to both environments, rarely time-boxed.
• Nobody owns exceptions. Reconciliation breaks are logged with no owner empowered to block go-live.

Teams that already run a defined global procure-to-pay operating model with a named process owner enter a cutover with a control inventory that simply needs mapping, rather than discovering it mid-programme.

How Do You Build the Business Case for ERP Data Migration?

Quantify what your current P2P pain points cost today, then price the control failure risk the migration itself introduces. Sponsors fund migrations on efficiency and cost savings arguments, then under-fund the data workstream. A control-led case corrects that before extraction starts.

• Document current pain points. Pull 12 months of data on duplicate payments, payment rejections, onboarding cycle time, manual bank verification hours, invoice exception rates and audit findings on supplier data. These double as your pre-cutover baseline.
• Quantify control failure financially. Combine the probability of an erroneous payment reaching execution, average payment value, volume in the exposure window and the historically low recovery rate on misdirected funds. Note that PSR reimbursement rules do not protect corporates in the way they protect consumers — business APP losses reached £75.6 million in 2025, and recovery is largely on you.
• Add the governance cost. Provision 29 remediation, a qualified internal controls declaration, and the reputational exposure of an ECCTA enquiry all belong in the business case alongside direct loss.
• Size the data effort separately. Profile record volumes, duplicate rates and remediation effort per category. Budget at least three pilot cycles — the first always finds mapping defects.
• Align sponsors to outcomes. Get written agreement on a data quality threshold at go-live, a control continuity commitment, a parity standard and a rollback trigger.

Who Owns Existing Data in an ERP Migration Governance Model?

Supplier records need one named enterprise data owner; P2P controls need a separate process owner. The split is deliberate — the data owner is accountable for accuracy, the process owner for whether controls actually operate. One person holding both tends to self-certify, which will not satisfy a Provision 29 review.

Role	Accountability	Typical holder
Enterprise data owner, vendor master	Accuracy, completeness, approval of all supplier record changes	Head of master data or GBS data lead
P2P process owner	Control design, operation, continuity through cutover	AP or P2P process owner
Data steward, per system	Record maintenance and defect remediation in their source system	Regional or entity steward
Control owner, per control	Attests a specific control operates in the target system	Internal controls or internal audit lead
Project manager	Phase gates, evidence bundles, escalation	Programme director

In a multi-entity environment, every source system needs a named steward with explicit authority. Define in writing who can create a supplier record, who approves a bank detail change, which system is authoritative during transition, and how conflicts between business units are resolved. Publish the RACI and keep it in version control.

Make ownership measurable rather than nominal: the vendor master data governance KPIs covering accuracy, SLAs and auditability you will run after go-live should be the same metrics you use as gate criteria during the programme.

What Are the Phases of an ERP Data Migration Process?

A phased approach runs through six stages, each with explicit entry and exit criteria. Phases that overlap without criteria are how unvalidated data reaches production.

1. Assess. Profile every source system and object. Exit: documented volumes, quality baseline, known defect categories.
2. Extract. Pull financial data and supplier records under controlled conditions. Exit: completeness validated per source, file hashes logged.
3. Cleanse. Prepare data by deduplicating, standardising and retiring records. Exit: agreed quality KPIs met.
4. Map. Define field-level transformations into S/4HANA structures. Exit: mapping specification signed by data and process owners.
5. Test. Run iterative pilot loads and reconcile. Exit: defect thresholds met across consecutive pilots.
6. Cutover. Execute the production load with gate sign-offs. Exit: parity confirmed, monitoring active.

Allocate dedicated capacity rather than borrowing AP analysts part-time. They deprioritise migration work the moment month-end arrives — precisely when quality slips.

How Do You Extract Data Without Disrupting Live Operations?

Use defined cut-off windows plus incremental delta runs, so live operations continue while extracted datasets stay reconcilable. A single full extract taken weeks before go-live will be stale, and stale supplier data is a control risk in itself.

• Document the exact timestamp of each extract and freeze supplier changes during the window, or route them through a logged exception queue.
• Schedule delta runs between the baseline extract and cutover so in-flight changes are not silently lost.
• Log a checksum for every extraction file. This proves to auditors that what loaded into S/4HANA is what left the legacy system, unaltered.
• Reconcile record counts and control totals per source, per object, for every run. Count-only reconciliation is insufficient for financial data.

How Do You Cleanse and Standardise Supplier Data Before Migration?

Handle data cleanup before migration, never after. Loading unclean records inherits every existing problem and adds transformation complexity on top. Around 30% of vendor master files contain errors and anomalies, so assume remediation at scale.

• Profile for duplicates. Run detection across name variants, registration numbers, addresses and bank accounts. Two records for one supplier with different bank details is the classic condition in which a fraudulent account hides for months.
• Standardise fields. Normalise country codes, postcode formats and registration structures. Validate Company Registration Numbers against Companies House, VAT numbers against HMRC, and UTRs where held. For international suppliers, standardise IBAN and SWIFT formats alongside UK sort code and account number pairs.
• Normalise identifiers. Move to one format across the estate and keep a legacy-to-target crosswalk, or open purchase order reconciliation becomes manual.
• Retire obsolete records. Apply a documented policy — no transactions in 24 months and no active contract — with data owner approval. Blocking rather than deleting preserves performance history while removing the record from payment selection, and retention decisions should align with UK GDPR accuracy and storage limitation obligations under the Data Protection Act 2018.

Cleansing data at this scale is where artificial intelligence and automated duplicate detection earn their place, because rules-based matching alone misses name and address variants. Decide tooling in parallel, not mid-programme: see our comparison of how to choose the best vendor data cleansing solution and our ERP data migration challenges and mitigation roadmap.

How Do You Map Legacy Data Into S/4HANA and Validate It?

Map every field with a documented, version-controlled transformation rule, validated on samples before any full load. Undocumented mapping is the defect category that surfaces latest and costs most.

• Produce a field-level specification covering source field, target field, data type, mandatory status, default values and handling of unmapped legacy fields — including anything driven by custom code.
• Write each rule in business language as well as technical logic, so the process owner can validate intent rather than syntax.
• Store specifications in a repository with change history. When a pilot produces unexpected results, you need to know which version caused it.
• Pay particular attention to control-relevant fields: payment terms, payment method, bank details, blocking indicators, CIS and withholding tax codes, and approval attributes. A field that looks cosmetic can be the trigger for an automated check.

Quality assurance then runs through repeated pilot loads. Use a subset spanning entity types, currencies, countries and supplier categories — not the first 1,000 records. Reconcile AP open items, ageing buckets, open purchase orders and supplier counts by status against legacy reports. Maintain one defect log with severity, root cause, named owner and target date, and set acceptance thresholds in advance: zero critical defects across two consecutive pilots. Thresholds negotiated after a failed pilot are not thresholds.

Which P2P Controls Must Survive the Cutover?

Every control that prevents or detects a misdirected, duplicate or unauthorised payment must survive, either like-for-like or as a documented compensating control. Build the inventory before the mapping phase closes.

Cover at minimum: supplier creation approval, bank detail change verification, duplicate supplier and duplicate invoice detection, three-way match tolerances, payment run approval and release, segregation of duties between supplier maintenance and payment release, payment file integrity checks, and sanctions screening against OFSI, FCDO, EU and UN lists.

For each control, record where it operates today, where it will operate after cutover, who owns it, whether it is automated or manual, and its status during transition. Where an automated control cannot be live at go-live, document the compensating control explicitly — what it is, who performs it, how often, what evidence it produces, and when automation will be restored.

An undocumented gap is an accepted risk nobody accepted. In the UK that now carries specific consequences: it will fail internal compliance requirements and external regulatory requirements, undermine the board’s Provision 29 declaration, and weaken any defence that reasonable fraud prevention procedures were in place under ECCTA.

Why Confirmation of Payee Is Not Supplier Verification

UK finance teams frequently treat Confirmation of Payee as the bank detail control, and during a cutover that assumption becomes expensive. CoP checks whether the payee name you enter matches the name on the destination account. It does not confirm that the account belongs to the supplier you contracted with, that the bank details in your migrated master file are the ones the supplier actually issued, or that the supplier’s email was not compromised when those details changed.

Risk mitigation here depends on independent verification of account ownership against banking data sources, mapped to the legal entity on the contract. Teams with a standardised supplier onboarding process across countries restore control coverage faster than those rebuilding country by country.

How Do You Run Parallel Validation and Sequence a Multi-ERP Cutover?

Run the same reports in both systems over the same period and measure parity against pre-agreed metrics, then gate cutover on those metrics. Parallel running without defined thresholds generates reassurance rather than assurance.

• Define parity numerically: supplier record count by status, AP open item total and count, ageing distribution by bucket, open purchase order value and count, payment run totals by method and currency.
• Run reports concurrently, ideally daily for financial objects. Reports at different cut-offs cannot be compared, and most “parity failures” are timing artefacts.
• Use one defect log shared with the pilot phase, and escalate unresolved mismatches to the control owner, not just the technical team. A parity break is a control signal.

Most organisations then run a hybrid estate for months. Document, by entity and process, what stays on legacy platforms and for how long — ambiguity produces duplicate supplier creation across systems. For every interface, specify direction, frequency, authoritative source and the reconciliation that proves it worked. Stagger cutovers by sub-estate, avoiding month-end, quarter-end and peak payment runs, and keep cross-system risk on the programme board agenda.

Multi-ERP vendor management is where headcount assumptions break, because each additional estate multiplies manual reconciliation across procurement data and supply chain processes. Teams that cope are usually those already able to scale supplier controls without adding headcount.

What Evidence Should Each Cutover Gate Require?

Each gate requires an evidence bundle, not a verbal confirmation. Gates without evidence requirements are just scheduling checkpoints — and under Provision 29, the evidence bundle is what the board’s declaration ultimately rests on.

Gate	Criteria	Required evidence
Data quality	Cleansing KPIs met; zero critical duplicates	Profiling report, duplicate resolution log, data owner sign-off
Mapping	All fields mapped and business-validated	Signed specification, sample validation results
Pilot	Thresholds met in two consecutive loads	Reconciliation reports, defect log extract
Parity	Parity metrics met across the parallel window	Side-by-side parity reports, exception register
Control	All P2P controls mapped or compensated	Control inventory with per-control attestations
Go-live	All prior gates closed; rollback tested	Consolidated evidence bundle, executive sign-off

Treat every reconciliation as a permanent artefact — timestamped, preparer and reviewer named, archived. Control owners must sign their own controls and must not report into the migration programme. Define each rollback plan before the gate is attempted, including decision owner, trigger thresholds and handling of in-flight transactions.

What Are the Most Common ERP Migration Mistakes?

Mistake	Consequence	Countermeasure
Under-resourced cleansing	Dirty data migrates; defects surface post go-live	Ring-fenced capacity with its own budget line
Undocumented data ownership	Nobody can approve or block changes	Published RACI with named individuals, not teams
Pilots skipped to save time	Mapping defects found in production	Two consecutive passing pilots before go-live
Mappings assumed, not validated	Control-relevant fields silently wrong	Mandatory business sign-off on samples
Controls lapse during cutover	Fraud exposure plus a Provision 29 and ECCTA problem	Control inventory with compensating controls
Relying on CoP alone for bank details	Fraudulent or outdated accounts carried forward	Independent verification of account ownership

How Do You Manage Change and Resource the Programme?

Change management determines whether controls survive in practice, because continuity depends on people following new processes under pressure.

• Map impacted groups: AP, procurement, treasury, internal controls, IT, regional finance and major suppliers each have different exposure.
• Run P2P workshops before mapping is frozen, so your internal team surfaces edge cases while changes are cheap. Workshops after mapping are briefings.
• Deliver user training on the new processes, not just new screens — particularly bank detail change procedures, which are where fraud enters.
• Publish weekly status updates covering gate status, parity metrics and open critical defects, with a named executive escalation path.

On resourcing: appoint a programme data owner with regional deputies, name cross functional leads from each affected business unit, and appoint a control owner per control. Where capacity is short, an independent consultant or contract workers can carry cleansing and reconciliation effort, but control ownership and sign-off must stay with permanent staff. Evaluate Trustpair for automated supplier bank account validation across 190 countries with continuous monitoring and native ERP connectivity — the capability that matters through a cutover is validation against external banking sources rather than the records you are migrating, with a full audit trail per assessment. Alongside it, standardise reconciliation templates and logging conventions up front so gate evidence is comparable across waves.

Quick ERP Migration Checklist for P2P Controls

Work through this in the final two weeks. Every item closes with evidence.

1. Confirm supplier ownership assignments are published and acknowledged.
2. Validate supplier bank details against independent evidence, prioritising high-value and recently changed accounts.
3. Reconcile open purchase orders across systems, by value and count.
4. Validate AP ageing parity across all buckets, not just the total.
5. Confirm every P2P control is mapped or formally compensated.
6. Secure documented sign-off per gate from an independent control owner.
7. Verify the rollback plan is tested and the decision owner is available.
8. Enable 30 days of enhanced performance monitoring covering bank detail changes, new supplier creation, duplicate payment alerts and payment rejections.

Standardise five reconciliation templates to support this: supplier master counts by status and entity; AP open items by entity and currency with ageing breakdown; open purchase orders by entity and category; payment run totals by method, currency and bank account for the first three runs; and a bank detail validation register capturing supplier, account, source, date, result and validator.