Prioritize exceptions that block a specific close task

Order the queue by documented work dependencies

Connect each item to the task it blocks so the next investigation releases useful work rather than merely reducing the item count.

When an exception needs a supplier invoice schedule, ParseMill can extract the invoice PDFs into Excel and keep source references available for checking. That gives the reviewer a concrete starting point. Bank reconciliation, accounting judgments and posting stay in your accounting system.

The responsible reviewer confirms each blocking relationship and the task acceptance conditions. This is a proposed workflow control, not an accounting materiality rule. Keep exceptions and close tasks as separate records, with stable identifiers, so changes to one relationship do not silently change unrelated work.

Build a dependency matrix

Create one row per exception-to-task relationship: exception ID, close-task ID, specific dependency, reviewer-confirmed blocking state, next action, owner and evidence required to release the link. Keep the task’s other acceptance conditions visible outside the exception map. A task with no remaining exception links may still require its normal final review.

Microsoft: Sorting data supports sorting by several columns. Intuit: Reconcile an account describes statement comparison. This proposed matrix organizes the resulting work dependencies; sort by task to inspect readiness and by exception to inspect the impact of resolving one issue.

Test a many-to-many dependency fixture

In this synthetic fixture, account-package handoff T1 has two blockers. Exception X2 also blocks a separate review T2. The task names and decisions are invented to demonstrate the relationship check.

Resolving X1 releases one link but leaves T1 blocked by X2. Resolving X2’s source decision may release its T1 link while T2 still awaits the schedule check. Count X2 once as an exception and twice as a relationship; do not inflate the case backlog because it affects two tasks.

Release links before releasing the handoff

When evidence arrives, record which dependency it resolves and obtain the required reviewer decision. Reassess every task linked to that exception. Then inspect all remaining blockers for each task. Do not propagate a case-level closed label into automatic task readiness unless the actual relationship conditions and other acceptance checks have been verified.

• Preserve distinct exception and task identifiers.
• Record every confirmed blocking relationship.
• Release only links whose evidence conditions are met.
• Check other blockers before changing task readiness.
• Retain age and next-action ownership alongside the map.

If a task is resequenced or cancelled, review its links explicitly. Removing a task does not necessarily resolve the underlying exception, which may affect other work. If a new task is discovered to depend on the same issue, add the relationship with its reviewer-confirmed reason instead of creating a duplicate exception.

Check the triage result at the next checkpoint

Test the fixture in three stages: release X1, release X2 for T1, then complete T2’s schedule check. T1 must remain blocked after the first stage; T2 must remain blocked until its own condition is met. Ask a colleague to identify the next action from each task view and each exception view.

Use the related workflow guide for the wider exception process and the workflow audit checklist to inspect close handoffs. The useful outcome is a traceable readiness decision based on all current dependencies, rather than a priority list that treats each exception as affecting only one task.