Meridian Distribution: Payment Factory and Duplicate Risk
A $900 million revenue distributor processes 12,000 payments a month across three ERPs and seven banks. Each business unit formats its own files; 4.1% of payments reject on first submission, mostly due to invalid IBANs and beneficiary name mismatches. Cutoff times range from 11:00 to 16:30 local, but the shared service center releases payments in a single 15:30 batch. Last year, 37 duplicate payments totaling $680,000 were identified, and two vendors were paid twice in the same week. The company is migrating to ISO 20022 and wants to centralize payment operations without disrupting vendor relationships.
1. Prioritize three remediation actions. Justify each by risk reduction and implementation feasibility.
Read the worked answer
First, implement payment validation at source: IBAN and beneficiary-name checks before file release. The 4.1% rejection rate is the largest recurring failure and is fixable without replacing the ERPs. Second, build a centralized duplicate-payment control using a unique payment reference, vendor master data, invoice number, and amount and date matching across all three ERPs. The 37 duplicates totaling $680,000 show that unit-level controls are not working. Third, create a payment hub or central release calendar that respects bank cutoffs. The single 15:30 batch misses earlier cutoffs and creates avoidable exception handling.
ISO 20022 migration should be the vehicle for the first two, not a standalone IT project: use structured creditor reference and purpose codes to improve straight-through processing. Sequence validation and duplicate controls before centralization; otherwise the hub will industrialize bad data.
2. Design the control environment for duplicate payments and segregation of duties in a shared service center.
Read the worked answer
Controls: (1) vendor master data changes approved by procurement and treasury, with bank-detail changes independently verified by callback; (2) three-way match of purchase order, receipt, and invoice before the payment proposal; (3) automated duplicate check across ERPs on invoice number, vendor, and amount, with a hold queue; (4) a unique payment reference per invoice; (5) dual approval for payments above a threshold and for all new beneficiaries; (6) segregation between master data, payment proposal, release, and reconciliation; (7) a daily exception report of payments without match or with changed bank details.
In a shared service center, the same person should not create a vendor, approve an invoice, and release payment. Use system roles, not policy memos. Reconcile the payment file to bank acknowledgements and investigate same-day repeats. The 37 duplicates suggest the duplicate check was either absent or run after release; move it pre-release.
3. Which metrics should the company report to the CFO during the ISO 20022 migration?
Read the worked answer
Report migration and control metrics together: straight-through processing rate, targeting above 98%; first-submission rejection rate, moving from 4.1% to below 1%; duplicate payment attempts caught pre-release; payments released after cutoff; average repair time per rejected payment; and percentage of payments using structured ISO 20022 fields. Add a vendor-impact metric-number of suppliers requiring manual intervention-because centralization can disrupt relationships.
Track cost per payment and exception rate by bank and ERP. A falling rejection rate with a rising duplicate-catch rate is a good sign; a falling rejection rate with no duplicate detection is not. Report weekly during migration.