OCEB 2 Fundamental study materials
OCEB 2 Fundamental study resources

Expense Reimbursement Gateway Errors at a Shared-Services Center

OCEB 2 Fundamental · Put your knowledge to work in context.

All case studies

Expense Reimbursement Gateway Errors at a Shared-Services Center

A shared-services center modeled its employee expense reimbursement process in BPMN 2.0. After 'Submit expense report', a parallel gateway splits into 'Manager approval' and 'Finance approval'; the branches merge at an exclusive gateway before 'Reimburse'. The policy says manager approval is always required, but finance approval is required only when the claim exceeds EUR 500. In the first quarter, 1,850 claims were processed; finance reviewed all 1,850, although only 410 exceeded EUR 500. Average cycle time was 6.8 working days against a 3.2-day target. The amount check has no default sequence flow, and 12 claims with an amount of exactly EUR 500 stalled at the gateway until manual intervention. A modeler proposes replacing the merge with a parallel join to 'keep the branches synchronized'. The process owner wants a corrected model before the next audit.

1. Diagnose the gateway errors in the current model and explain the business consequence of each. What corrected BPMN structure would you recommend?

Read the worked answer

The first error is a parallel split where the business rule is conditional. A parallel gateway creates two tokens unconditionally, so 'Finance approval' is instantiated for every claim; that explains 1,850 finance reviews when only 410 claims exceeded EUR 500. The second error is the exclusive merge after the branches. An exclusive merge does not synchronize; it passes each incoming token. Because the parallel split produced two tokens, the merge can fire 'Reimburse' twice or race with one branch still open. The modeler's proposed parallel join would synchronize, but it would also force finance approval on every claim and would deadlock on any path where finance is skipped.

Correct structure: after 'Submit expense report', use an exclusive gateway with outgoing conditions such as amount > 500 and a default flow for amount <= 500. The >500 path goes to a parallel split only for manager and finance approvals, then a parallel join; the default path goes only to manager approval. Both paths then merge at an exclusive merge before reimbursement. This matches policy, eliminates unnecessary finance work, and keeps token semantics sound.

2. How should the amount condition and default flow be specified so that the EUR 500 case and missing-data cases are handled? Is the modeler's parallel join proposal appropriate?

Read the worked answer

Conditions should be mutually exclusive and ordered so that no case is ambiguous. The finance-required condition should be explicit, for example amount > 500, not amount >= 500 if the policy threshold is 'exceeds'. The default sequence flow should carry the residual case - amount <= 500 - and should be marked as default on the exclusive gateway. Exactly EUR 500 then follows the default path (manager only) unless the policy says otherwise; that decision must be confirmed with the process owner, not inferred from the model. Missing or invalid amount is a separate business situation, not a default: model it with an interrupting boundary error event or a preceding validation task that routes to 'Request clarification'. Using the default for missing data would silently bypass finance review.

The parallel join proposal is not appropriate. A parallel join waits for all incoming tokens; on the default path finance approval never executes, so the join would never fire. Use an exclusive merge after the conditional branches and reserve parallel gateways for genuinely concurrent, mandatory branches.