The Handoff Problem: Why Close Tasks Stall Between Your Team Members

I once tracked a close that ran two days long, and when we did the post-mortem, the actual work hadn't taken two days. The accruals were booked Tuesday morning. The problem was that the senior who needed to review them didn't know they were ready until Wednesday afternoon, because the staff accountant assumed someone would "see" the completed task and the senior assumed they'd get pinged when it was done. Nobody was wrong. Nobody was slow. The task just sat there for 30 hours doing nothing.

This is the close problem almost nobody measures. We obsess over how long tasks take and ignore how long tasks wait. In most teams I've audited, idle handoff time is the single largest contributor to a long close, and it's invisible because no spreadsheet has a column for "hours spent waiting for someone to notice."

What a silent handoff actually looks like

A handoff is any point where a task changes hands: preparer to reviewer, reviewer to approver, one department feeding a number to another. A silent handoff is one where the next person doesn't get an unambiguous signal that they're now on the clock.

Here's a typical chain for a single reconciliation:

• Staff completes the bank rec and saves it to the shared drive.
• Senior reviews it and flags a $4,200 unreconciled item.
• Staff investigates and resolves it.
• Senior re-reviews and signs off.
• Controller approves as part of the final package.

That's four handoffs. If each one carries an average four-hour delay before the next person realizes they're up, you've added 16 hours of pure idle time to a task that involved maybe 90 minutes of work. Multiply that across 40 reconciliations and you understand why your close is taking six days instead of three.

Why email and Slack make it worse

The usual fix is to message the next person. "Hey, the prepaid schedule's ready for your review." The trouble is that these pings live in a different system than the work. The senior reads it on their phone during a meeting, intends to get to it, and it scrolls into oblivion. There's no durable, visible state that says this task is waiting for you specifically, right now. The signal and the work are divorced from each other.

Map your dependencies before you fix anything

Before you can build good handoffs, you need to know where they are. Sit down with your close checklist and mark every task with two things: who touches it, and what it depends on.

Two categories of dependency matter:

• Sequential dependencies: Task B can't start until Task A finishes. You can't book the depreciation entry until the fixed asset additions are finalized.
• Role handoffs: The same task moves between people. Prepared, reviewed, approved.

When you draw this out, you'll find a handful of tasks that everything else hangs on. In one mid-sized manufacturer I worked with, the entire close waited on a single intercompany elimination that one person owned. When she was out sick on day two, eleven downstream tasks stalled and nobody had documented that they were blocked by her. The dependency existed; it just lived in her head.

The bottleneck people are usually reviewers

Preparers tend to work in parallel. Reviewers and approvers are shared resources, which means they're where queues form. If one controller approves 60 tasks, every one of those tasks is competing for the same person's attention. That's exactly why the handoff into review is the most important one to make explicit.

Build explicit handoff triggers

A good handoff trigger has three properties. It fires automatically when a task's state changes, it lands in front of a specific named person, and it stays visible until that person acts. "Visible until acted upon" is the part email fails at.

Practically, that means every task carries a status that moves through defined stages, and the system reassigns ownership the moment the status changes. When the staff accountant marks the bank rec complete, ownership transfers to the senior automatically and the senior sees it in their queue, not buried in a thread. When the senior approves, it moves to the controller. No one has to remember to tell anyone.

Where Excel breaks down

A shared close workbook can track status in a column. What it can't do is notify the next owner, enforce that review happens before approval, or show you in real time which tasks are sitting idle and for how long. With a tab full of "In Review" cells, you have no idea whether something entered review five minutes ago or two days ago. You also can't tell who's blocked. Someone has to read every row and chase people manually, which is itself a full-time job during close.

A structured close platform like ComplyBar treats each task as an object with an owner, a status, and a dependency chain. When a preparer finishes, the platform reassigns the task and the next person's dashboard updates immediately. Reviewers see a queue ordered by what's waiting longest. Dependencies are enforced, so a task can't be approved before it's reviewed, and downstream tasks unlock the instant their blockers clear. The 30-hour wait I opened with simply can't happen, because the moment the accrual is marked done, it appears in the reviewer's queue with a timestamp.

Make idle time something you can see

The metric that changes behavior is time in status. Track how long each task sits in each stage. Once you can see that reconciliations spend an average of nine hours in "Ready for Review" but only 70 minutes actually being reviewed, the conversation shifts from "work faster" to "why is the handoff into review so slow," which is the real problem.

Set a threshold. If anything sits in a handoff state longer than, say, four hours during close week, it escalates. When you can watch idle time accumulate in real time, the team starts clearing their queues proactively because the delay is no longer invisible.

Your concrete takeaway

Pick your three longest-running close tasks. For each, write down every handoff and estimate the wait time at each one. Add it up. I'll wager the waiting exceeds the working by a wide margin. Then make one change: ensure every one of those handoffs produces an automatic, durable signal to a named owner that survives until they act. You'll recover more hours from killing dead time than from any push to make people work faster.