The ERP Cutover That Froze the Payment Run
A Toronto-based services firm is migrating from a legacy treasury workstation to a new ERP treasury module over a weekend. The project plan calls for a Friday evening cutover, with the first automated payment run scheduled for Monday morning. The legacy system holds 340 vendor banking records and 22 standing payment templates. During testing, the team found that 18 vendor records failed validation because the new system requires a structured bank identifier format that the legacy records do not follow. The vendor master data owner is on vacation. The project manager proposes loading all records and fixing the 18 afterward, arguing that only a small fraction are affected. The treasury operations lead is concerned about duplicate or misdirected payments and about the audit trail during the transition. The go-live date was set by the CFO to align with a fiscal quarter start.
1. Evaluate the project manager's proposal to load all records and remediate afterward.
Read the worked answer
The proposal is not acceptable for payment data. Loading records that fail validation means the system either rejects them at run time, producing failed payments, or accepts them with incomplete identifiers, which creates a risk of misdirected payment. Neither outcome is recoverable after the fact in the same way a reporting error is; a payment sent to the wrong account may not be recoverable at all.
The correct sequencing is to remediate the 18 records before the first payment run. That requires the vendor master data owner or a delegate with authority to confirm bank details, because changing a vendor's banking information is a control-sensitive action and should follow callback verification. Loading unverified data and correcting later inverts the control.
The remaining 322 records should be reconciled against the legacy system on a record-by-record basis before go-live, not sampled, because a duplicate vendor record can cause a double payment that is difficult to reverse.
If the 18 cannot be remediated before Monday, the defensible option is to run the first payment cycle from the legacy system for those vendors only, with a documented manual workaround and dual approval, while the records are corrected.
2. Recommend how to manage the go-live decision and the audit trail given the CFO's fixed date.
Read the worked answer
Separate the date from the readiness criteria. The CFO set the date for fiscal alignment, but the decision to run payments through the new system should depend on a checklist, not the calendar.
Recommendation: hold the cutover for payment processing while proceeding with the rest of the module if it can be isolated. Run the first cycle in parallel: process payments in the legacy system and generate a shadow run in the new system, then reconcile the two outputs before switching. This costs a week of duplicated effort but produces evidence that the new system pays the right vendors the right amounts.
For the audit trail, document the 18 exceptions, the verification performed on each, who authorized the change, and the date. Retain the legacy records and the reconciliation. If a manual workaround is used, require dual approval and log every manual payment.
Escalate the vacation issue as a control gap: a single data owner with no delegate is a single point of failure for a control-sensitive process. The post-implementation review should recommend a named backup with documented authority for vendor banking changes. The project manager's schedule pressure should not override the payment control, and the treasury operations lead's concern should be recorded as a formal risk acceptance if the CFO chooses to proceed anyway.