Which payments have prior approval evidence?
You review eight payment approvals at the fictional Alder Supply Co.
The question
The case policy requires an approved event in the authoritative history for the exact payment ID before release. The dashboard is green for all eight. The controls lead owns the decision on exceptions.
| Payment IDs | Count | |
|---|---|---|
| Confirmed prior approval | A–E | 5 |
| Apparently late approval | F and G | 2 |
| Approval missing | H | 1 |
The records initially show the times as displayed.
“Identify what the event history supports and what needs follow-up.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: How do you classify the records?
What would you do here? Open the move you’d make.
Clear all eight because the dashboard is green
Tempting, but it misses something. The case requires evidence of approval before release for each payment.
Record two confirmed late approvals and one missing
Tempting, but it misses something. The opening display does not establish a common time basis.
Keep five prior, two apparent late and one missing
The strong move. This distinguishes confirmed evidence from an apparent exception.
See how a strong candidate says it
“I would report five confirmed prior approvals, two apparently late and one missing. I would check how the times are displayed before confirming either apparent exception.”
Why it works: The green dashboard status does not supply the order of the events.
Step 2: Does F still look late?
F’s approval appears at 10:05 in UTC+1. Its release appears at 09:30 UTC. G’s authoritative approval and release times use the same basis and confirm G is late.
What would you do here? Open the move you’d make.
Clear F after converting its approval to UTC
The strong move. F was approved at 09:05 UTC and released at 09:30 UTC.
Keep F late because 10:05 is after 09:30
Tempting, but it misses something. Those displayed times use different offsets.
Clear both F and G because one display was misleading
Tempting, but it misses something. G’s authoritative history still shows a late event.
See how a strong candidate says it
“F’s approval at 10:05 UTC+1 is 09:05 UTC, 25 minutes before release. The count is six prior approvals, one late and one missing.”
Why it works: F and G are different records. The common time basis clears F and confirms G’s late approval.
Step 3: Does the draft clear H?
A newly found request draft has H’s exact payment ID but contains no approval event.
What would you do here? Open the move you’d make.
Clear H because the draft has the exact payment ID
Tempting, but it misses something. The case requires both the exact ID and an approval event.
Keep H open and ask for the approval event
The strong move. The draft does not establish approval or its timing.
Label H late because the approval is missing
Tempting, but it misses something. A missing event gives no time to compare with release.
See how a strong candidate says it
“I would keep H missing. The draft confirms the request ID. I still need the approval event in the authoritative history.”
Why it works: The case distinguishes the creation of a request from an approved event.
Step 4: What remains for follow-up?
The authoritative export shows H’s approved event for the same payment ID 2 minutes before release.
What would you do here? Open the move you’d make.
Send only the updated dashboard because seven passed
Tempting, but it misses something. The controls lead needs the events behind the remaining exception.
Report two exceptions because H was missing at opening
Tempting, but it misses something. The newly supplied event resolves H before this review closes.
Report seven prior approvals and send G for follow-up
The strong move. This reflects the latest evidence and keeps the decision with the controls lead.
See how a strong candidate says it
“Seven payments have prior approval. G remains late, one of eight in this sample, or 12.5%. I would send the corrected workpaper and G’s events to the controls lead.”
Why it works: The authoritative event clears H. The confirmed late event for G remains in the record.
The answer, in short
- Decision
- Send the confirmed late approval for G to the controls lead.
- Because
- The common time basis clears F and the authoritative approval event clears H.
- What would change it
- A verified correction to G’s event order would change the result.
Common traps
- Compare both times on one basis.
- Check for an approved event on the exact payment ID.
Check your answer
- I kept apparent timing issues open at first.
- I converted F’s approval to UTC.
- I distinguished a request draft from an approval.
- I reported the remaining exception to the controls lead.
Last reviewed Nov 11, 2026