Corporate payment approval matrix testing verifies that each payment is routed to the people authorised by the organisation's approval rules, and that unauthorised users cannot approve or release it. It checks how rules based on factors such as payment amount, legal entity, account, currency or payment type interact with user roles and workflow states, including boundary values and rejected actions.
What to verify in the approval matrix
Start by translating the approved matrix into testable rules. Confirm the conditions that select an approval path, the number and order of approvals required, and any restrictions on who may approve. Include role-based access control (RBAC), which grants permissions according to a user's assigned role, as well as account-level entitlements and delegated authority where they apply.
Check that the implemented rules match the authorised configuration. A test environment with stale roles or a different matrix version can produce misleading results, so record the configuration version and verify that test users have the intended permissions before execution. Use synthetic or otherwise approved test data, and avoid sending real payments unless the test is explicitly authorised and controlled.
Test each decision condition at its boundaries. For a threshold of £10,000, test a payment just below the threshold, exactly at £10,000 and just above it. Confirm whether the matrix uses the payment amount, an aggregate amount or another defined basis. Repeat relevant cases for different entities, currencies or payment types if those fields affect routing.
Check both permitted and prohibited actions. For example, verify that a payment creator cannot approve their own payment when the policy requires separate people. Try a user with no approval entitlement, an approver assigned to the wrong account, and an expired or revoked delegate. Confirm that the system blocks the action and records the result appropriately.
Test the full payment workflow
A matrix decision is only one part of the workflow. Verify that each approval changes the payment to the correct state, that the next authorised approver receives the task, and that the payment remains held until every required approval is complete. Check rejection, cancellation, amendment and resubmission paths. A material amendment may require approvals to restart, depending on the configured policy.
Where the workflow connects to a payment hub, file processor or bank channel, check that an incomplete or rejected payment is not released downstream. After final approval, confirm that the correct payment details and approval status reach the next system. This forms part of end-to-end testing and can expose mismatches between portal permissions, workflow rules and downstream release controls.
Inspect the audit trail for the payment, including the user, action, timestamp, decision and relevant workflow state. Verify that records remain associated with the correct payment after an amendment or resubmission. Test the application behaviour as well as any available service or database evidence, since a correct screen message alone does not prove that the payment was held.
Worked example
Assume an illustrative policy requires one approver for payments up to and including £10,000, and two distinct approvers for payments above £10,000. The creator cannot approve their own payment. These rules are examples only; use the organisation's approved matrix as the expected result.
| Test case | Expected result |
|---|---|
| Creator submits £10,000 | One eligible approver is required; the creator cannot approve it. |
| Creator submits £10,000.01 | Two distinct eligible approvers are required. |
| First approver approves a payment above £10,000 | Payment remains pending; it is not released. |
| Second approver is the creator or first approver | Approval is blocked if the policy requires distinct users. |
| User without the relevant account entitlement approves | Action is denied and the payment remains pending. |
Run each case from a known payment state and verify the resulting state, assigned tasks, permissions and release status. Reset or create fresh test data between cases where earlier actions could affect later results. In a continuous integration (CI) pipeline, keep these tests isolated from real payment channels and make the environment's approval configuration explicit.
Frequently asked questions
How should a changed approval matrix be tested before it takes effect?
Test the proposed configuration in a controlled environment against the approved change, including cases that should move to a different approval path and cases whose routing should remain unchanged. Verify the effective date and confirm that payments already in progress follow the organisation's defined migration or grandfathering rule.
Should approval tests include simultaneous actions by two users?
Yes, when concurrent approvals or payment updates are possible. Start both actions from the same workflow state and verify that the system records valid decisions once, prevents duplicate or conflicting transitions, and leaves the payment in the correct state.
How can matrix tests cover accumulated payment limits?
Create related payments for the same entity, account or period where the policy applies a cumulative limit. Test totals below, at and above the limit, and verify how cancellations, rejected payments and pending approvals affect the aggregate.