The segregation gap a walkthrough found before a single sample test ran

This is a composite, illustrative scenario, not an account of a named client. Walking through the vendor payment process end to end — not testing a sample of payments, but sitting with the accounts executive and watching each system step — showed that the same user ID that could edit a vendor's bank account details in the ERP vendor master also had approval rights on the payment batch that would pay that vendor. No transaction sample would have revealed this, because every individual payment in the sample had a valid invoice, a valid approval, and matched the vendor master at the time it was paid — the risk was entirely in what that one person could do, not in anything that had visibly gone wrong yet.

Why sample testing structurally cannot find this

A substantive sample of payments checks whether each payment, as it happened, was properly supported and approved. If the same person who could change a vendor's bank account also approved the batch, every payment in the sample still looks procedurally correct — there is an invoice, there is an approval, the amounts tie. The exposure is that this one person has the technical ability to redirect a payment to an account they control and then approve the payment themselves, and that capability doesn't show up in any individual transaction unless and until it's actually misused. A walkthrough of access rights, done by asking what each role can do in the system rather than what each transaction shows, is the only procedure that surfaces it.

What the walkthrough covered

1. 01Sat with the accounts executive and traced a single vendor master change end to endLogged in with their own credentials, located the screen to edit a vendor's bank details, and confirmed the system allowed the save with no second-person approval workflow attached to that specific field.
2. 02Traced the payment approval screen under the same loginThe same user ID had approval rights in the payment run module, confirmed by checking the ERP's own role and access-rights report rather than taking a verbal description.
3. 03Pulled the ERP's user access report for the full accounts payable teamOne other person, in addition to this executive, held the same combined access — not an isolated one-off configuration.
4. 04Checked the audit trail for any actual bank-detail changes followed closely by a payment to that vendorNo instance was found where this had actually been exploited, which mattered for how the finding was framed — a control design gap rather than evidence of an actual loss.

What went into the file

• The access-rights report showing the two users with combined edit and approval rights.
• The walkthrough narrative establishing how the gap was identified, independent of any transaction sample.
• The audit-trail check confirming no evidence of actual exploitation, documented so the finding is clearly scoped as a design deficiency.
• The remediation agreed with management — splitting vendor master edit rights from payment approval rights, with a maker-checker workflow added specifically to bank-detail changes.