Who's Waiting on Whom? Mapping Dependencies in Your Close

Every close I've run that blew its deadline had the same autopsy: some task everyone assumed was "just a formality" turned out to be blocking three downstream reconciliations. Nobody noticed until day 6, when the person who needed it started asking where it was. By then we'd lost a full day we could never get back.

Slow tasks aren't usually the problem. A bank rec that takes 90 minutes takes 90 minutes whether you close in 3 days or 10. What kills your timeline is sequencing—work that can't start until other work finishes, chained together in ways nobody has ever written down. This is about making those chains visible before they trip you.

Why dependencies stay invisible

Most close checklists are flat lists. Task 1, task 2, task 3, each with an owner and a due date. What that list never shows is which tasks feed which. Your accruals schedule looks like one line item. But if depreciation, prepaid amortization, and the intercompany true-up all pull from it, that single line is actually a gate holding back three people.

The person maintaining the accruals schedule has no idea they're a bottleneck. Their due date says day 4. They deliver on day 4, technically on time. But the three downstream owners needed it by end of day 2 to hit their day-4 targets. Everyone met their individual deadline and the close still slipped two days.

I've seen this exact pattern in teams of five and teams of fifty. The bigger the team, the more brutal it gets, because the chain gets longer and the person at the front can't see the person at the back.

How to actually map your dependencies

You don't need software to start—you need one honest conversation and a whiteboard. But you do need to ask the right question, and the right question is not "what do you do?" It's:

"Before you can start this task, what has to be finished first? And after you finish, who's waiting on your output?"

Step 1: List outputs, not just activities

For each task, write down what it produces. "Reconcile prepaids" produces an adjusted prepaid balance and a JE. That JE feeds the trial balance. Now you have an edge in your dependency map, not just a floating task.

Step 2: Trace the JE handoffs

Journal entries are where most hidden dependencies live. Post them in the wrong order and you're reversing and reposting. Map every JE to its source data and its posting sequence. In one close I inherited, the revenue cutoff JE depended on the shipping log, which depended on the warehouse manager exporting a report he only ran on request. That single manual export sat on the critical path and nobody had documented it.

Step 3: Find the critical path

Once you have the chain, add up the longest sequence of dependent tasks. If task A (4 hours) feeds B (6 hours) feeds C (3 hours), that path is 13 hours minimum no matter how many people you throw at it. That's your critical path. Everything else has slack. Most teams optimize the wrong tasks—they speed up work that already had slack while the critical path sits untouched.

A concrete example

Here's a real chain from a mid-market close I ran:

• Day 1: Close AP subledger → produces final AP balance
• Day 2: Accrue unrecorded liabilities (needs final AP to avoid double-counting) → produces accrual JE
• Day 2: Reconcile AP to GL (needs the accrual JE posted) → produces clean AP rec
• Day 3: Flux analysis on expenses (needs clean AP rec) → produces variance commentary
• Day 4: Management reporting package (needs flux commentary)

Five tasks, four owners, one chain. When the AP subledger close slipped half a day, the reporting package slipped half a day too—the delay traveled the whole length of the chain. But the AP clerk never knew their half-day slip would push the CFO's board deck. That information didn't exist anywhere they could see it.

Why Excel stops working here

A spreadsheet checklist can hold owners and due dates fine. What it can't do is enforce or surface dependencies. You can add a "predecessor" column, but nobody updates it, and even if they do, the spreadsheet won't tell the downstream owner the moment their input is ready. It won't stop someone from marking a task complete when its predecessor isn't done. It won't recalculate everyone's realistic start time when one task slips.

I've maintained the elaborate Excel close tracker with color-coded tabs and conditional formatting. It looks impressive in a screenshot. In practice it's a snapshot of intentions that goes stale by day 2, because keeping it current is itself a full-time task nobody owns.

A structured close platform like ComplyBar treats dependencies as first-class objects. You define that the AP rec depends on the accrual JE, and the system won't let the rec become actionable until the JE is signed off. When an upstream task finishes, the downstream owner gets notified that moment—not when they think to check. When something slips, the ripple effect shows up automatically instead of surfacing as a surprise on day 6.

The difference is between a document that records your process and a system that runs it. One tells you what happened after the fact. The other tells the AP clerk their delay just pushed four downstream owners, while there's still time to react.

Your concrete takeaway

Before your next close, sit down with your task list and do one thing: for every task, write who produces its input and who consumes its output. Then trace the longest unbroken chain. That chain is your close's true duration—not the sum of your task hours, and not your target date.

You'll almost certainly find at least one person on the critical path who has no idea they're there. Fixing that—giving them an earlier real deadline and making the dependency visible—will save you more time than speeding up any single task ever could.