Your Close Is Slow Because of Handoffs That Shouldn't Exist

Every finance close has dependencies. Some are real. Most are habits nobody questioned.

This is the eighth article in Practical Lean Finance, a series that applies Lean Six Sigma tools to month-end close operations. If you're joining mid-series: Article 7 covered root cause analysis using the 5-Whys technique and fishbone diagrams. For many readers, those root causes pointed upstream. The data you need sits in someone else's hands. This article gives you a hierarchy for fixing that.

If you want the full series from the beginning, start with Article 1: SIPOC.

Every large manufacturer I've worked with has tried some version of the same playbook to speed up the close. Build a shared service center. Split tasks between local controllers and a record-to-report team. When nobody is sure who owns what, document the split with a RACI matrix. When the RACI doesn't make things faster, add procedures on top.

Every time, the close gets slower. Not because the people are wrong. Because each of those moves adds handoffs. And at the end, local controllers, operations managers, and the service center all maintain separate versions of the same numbers, because nobody trusts anyone else's file.

The playbook treats slow closes as an organizational design problem. It's usually a data ownership problem. Two teams track the same numbers in parallel. One sends, the other waits. The handoff is the bottleneck. And instead of eliminating the handoff, the organization builds infrastructure around it.

This article is about asking a different question first: does this handoff need to exist at all?

In the manufacturing close I mapped for this series, roughly a third of all close hours depended on teams outside Finance. Most close leads default to the same answer: negotiate a deadline. Chase, remind, thank, repeat. And when that fails, formalize the chase into an SLA with a deadline and an escalation clause. It feels like progress. It's usually a workaround dressed as a solution.

The Five-Fix Hierarchy

There are five ways to fix an upstream dependency. They should be tried in order, because the first ones remove the problem entirely while the last one just schedules around it.

Fix 1: Eliminate the dependency. Before you negotiate anything, ask one question: does this data already exist somewhere Finance could access it directly? In most ERP systems, the purchasing data and the inventory movements are already there. Finance just needs read access to the right module, or a scheduled report that drops into a shared folder automatically. No email. No person in the loop. The dependency disappears.

This is the fix that gets overlooked most often, because it doesn't feel like a fix. It feels like an IT ticket. Request read access. Configure a scheduled extract. Set up a notification if the file doesn't land. Coordination cost going forward: zero. But nobody thinks of it because the close team has been collecting this data by email for years and the email became the process.

Fix 2: Co-own a shared artifact. This is the big one. I'll spend a full section on it below.

Fix 3: Standardize the input. Where you still need a handoff, build the template yourself. Locked structure, validated fields, dropdown selections mapped to your GL codes. The upstream team fills it in. Less work for them because they stop guessing what Finance wants. Zero reformatting for you. In Lean terms, this is poka-yoke (error-proofing) applied to cross-functional handoffs. If you followed Article 3, you've already mapped where these handoffs happen. Now lock the format so the handoff can't arrive broken.

Fix 4: Restructure around the timing. If Tax can't finalize VAT calculations before invoices post, don't fight the calendar. Where policy and materiality allow, split your task: estimate now using a documented basis, true-up when the final numbers arrive. That's continuous close thinking from Article 5: pulling work earlier to level the load instead of stacking everything at the same deadline.

Fix 5: Formalize with an SLA. Reserved for dependencies where a human being must exercise judgment by a deadline. I'll cover what this looks like at the end. But notice: it's fifth on the list. Not first.

The order matters. Each fix lower on the list carries more coordination cost. Eliminating the dependency costs you one IT ticket and nothing thereafter. An SLA costs you ongoing monitoring, escalation conversations, and relationship maintenance. Every month. Indefinitely.

How do you know which fix applies? Start with one question: does the data already exist in a system? If yes, that's Fix #1. If two teams track the same underlying numbers for different purposes, that's Fix #2 territory. If a person still needs to send input, lock the format (Fix #3). If the input can't arrive in time but can be estimated safely, restructure around the timing (Fix #4). Only if a human being must exercise genuine professional judgment by a deadline do you reach for Fix #5.

The Separate Versions Trap

Before you pick up the phone to chase upstream data, ask this: why are Finance and the other department maintaining separate versions of the same data?

Procurement tracks purchase orders in their system. Finance tracks PO accruals in a separate spreadsheet. Same underlying numbers. Two files.

Operations tracks production costs: material consumption, labor allocation, machine hours, yield rates. Finance tracks the same costs in a different format for the monthly accrual. Same numbers. Two trackers.

HR has their payroll data. You have your payroll accrual workpaper. Sales has their pipeline. You have your revenue recognition schedule.

Every one of these pairs represents a handoff that exists because someone, years ago, decided it was easier to build a parallel version than to share one. Over time, the parallel version became the process. The email asking for "the latest numbers" became a monthly ritual. The ritual became a dependency. The dependency became a bottleneck.

A 2025 Ledge survey of 100 finance professionals found that 56% selected dependency on other departments and regions as a blocker preventing faster closes, the most cited blocker in the survey. Not system limitations. Not headcount. Other departments. XPLM's 2023 industry study of 126 executives found a similar pattern in manufacturing: fragmented systems, email-based data exchange, and departmental silo thinking were identified as persistent barriers to data flow. In three out of four companies surveyed, data was still exchanged by email rather than made available in the systems where it's actually used (XPLM, 2023). That study focused on product engineering data, not finance close operations. But the dynamic is the same. When your performance is measured by your department's output, sharing your data feels like sharing your leverage.

The fix is simpler than that: stop having two versions.

Speaking One Language

Fix #2 on the hierarchy is the highest-value move on the entire list. It's also the hardest, which is why most teams skip it and go straight to the SLA.

Reports shouldn't be built by Finance, for Finance. They should be built as shared efforts across work streams. One artifact, designed together, that both teams actually use. I call this "speaking one language."

Here's what it looks like in practice.

Manufacturing stream. I watched this work at a site where Operations and Finance maintained completely separate production cost trackers for two years. Operations tracked yield, throughput, and cycle time. Finance tracked standard cost variance, WIP valuation, and overhead absorption. Same production orders. Different files. Every month, someone in Finance spent half a day reformatting what Operations had already compiled. The fix: a single cost report that follows a production order from launch to completion. Operations sees their operating metrics. Finance sees the GL impact. When the close starts, the monthly accrual is already sitting in the report Operations has been updating all along.

Capex stream. This one is less obvious but equally expensive. A project manager tracks milestones: engineering complete, equipment ordered, installation started, commissioning date. They care about scope, schedule, and budget burn. Finance tracks the same project for completely different reasons: when does the asset transfer from CIP to fixed assets? When does depreciation start? What's the capitalization split between internal labor and external contractors?

Same project. Two tracking files. The PM updates a project status spreadsheet. Finance maintains a separate CIP register and reconciles it against the PM's numbers every month. When commissioning slips by two weeks, the PM updates their tracker the same day. Finance finds out at month-end when the CIP-to-asset transfer date doesn't match their depreciation schedule.

The shared artifact: a single project status report where the PM reads milestone progress, budget status, and timeline risk, and Finance reads CIP balance, expected transfer date, and the available-for-use assessment that triggers depreciation. When the PM moves a commissioning date, the financial impact updates in the same file. No email. No reconciliation. When the close starts, every capital project's status is already current.

Commercial stream. Sales tracks pipeline conversion: lead to opportunity, opportunity to closed deal, deal to cash. Finance needs the same underlying data for revenue recognition timing and receivables forecasting. Today, Sales has a CRM dashboard and Finance has a separate revenue schedule, and someone emails a reconciliation between them every month. The shared artifact: a commercial funnel report where Sales reads pipeline conversion and Finance reads rev rec inputs. Same numbers. One file. Zero handoff.

The same logic applies across every function. Every cost center head monitors their spending against budget; Finance monitors the same numbers for variance analysis and accruals. One dashboard handles both.

This isn't a technology project. It doesn't require a new system. A spreadsheet works. A shared folder works. A BI dashboard works. The technology is the least interesting part. The agreement is what matters.

Fix #2 takes effort. You're looking at a few months to build the shared artifact, get buy-in from the other team, and prove it works through a full close cycle. But once it's running, the dependency is gone permanently. And something bigger changes. Finance is no longer the department that chases data. You're the department that builds the connections between teams.

Who Gets to Build the Bridge

There's a practical question the framework doesn't answer on its own: who has the standing to propose a shared artifact to another department?

Fix #1 is easy. Anyone can file an IT ticket requesting read access to the purchasing module. Fix #3 is mostly internal: you build the template, you send it. Fix #5 is a negotiation, but one with clear precedent.

Fix #2 is different. Walking into Operations with a prototype and saying "let's build something together" requires a level of cross-functional credibility that a staff accountant doesn't usually carry. Nothing against staff accountants. This is a design consideration. If the shared artifact covers production costs for an entire site, the conversation belongs to the controller or the close lead who has a relationship with the Operations Director.

Behnam Tabrizi's study of 95 cross-functional teams across 25 major corporations found that 75% were dysfunctional, failing on at least three of five performance criteria. According to Tabrizi, projects with strong governance support had a 76% success rate, while those with only moderate governance support had a 19% success rate (Tabrizi, 2015). The method works when the right person carries it.

Know this before you start. If your best Fix #2 candidate crosses a department boundary, identify who in your organization has the standing to open the conversation. The analysis stays with the practitioner. The proposal goes to someone who can negotiate the partnership.

When an SLA Actually Belongs

Not every dependency can be eliminated or co-owned. Some require a human being to make a judgment call, and that judgment can't be automated, templated, or pulled from a system.

Legal's litigation provision estimate. A lawyer assesses probability and exposure for each open case. No system holds this data until the lawyer decides. No shared artifact replaces that professional judgment.

For these genuine judgment dependencies, an SLA is the right tool. Four elements make it work.

What data. Provision estimate by matter, with probability rating. Be specific. "Send us an update" is a hope, not an SLA.

What format. The template Finance provides. Locked fields. Dropdown for probability categories. Not a free-text email. A format that arrives ready to book.

What deadline. Day +2 by noon. Specific, non-negotiable, tied to the close calendar.

What happens if it's late. This is what turns a polite request into an agreement. The fallback must be agreed with Accounting Policy, Legal, and the Controller before close. For example: Finance carries forward the prior estimate if Legal has confirmed no known new facts or events require reassessment, and flags the entry as unchanged. Legal can correct through Day +3, or it posts as-is. The point is not to punish Legal. The point is to define what Finance does when no new judgment is provided, so the close doesn't wait.

That last element, the consequence clause, is what separates an SLA from a reminder email. Most internal "SLAs" are just deadlines with no teeth. A deadline without a fallback is a request. A deadline with a fallback is a system.

The Expensive Workaround

Here's the mistake I've watched close teams make at every scale.

At the task level: they identify an upstream dependency. They quantify the cost. They negotiate a deadline. They sign an SLA. Except the data was in the ERP the whole time. One IT ticket would have killed the problem permanently. Instead, they built a monthly ritual around a handoff that shouldn't exist.

At the organizational level: they build a shared service center. Split tasks between local and SSC. A task that one person used to own becomes a submission, a review, a posting, a check, and a correction loop. Create procedures, RACI matrices, escalation paths. Each layer adds coordination cost. Each handoff multiplies. The RACI documents who does what, but never asks whether the "what" should exist. And at the end, three teams maintain separate versions of the same numbers because nobody co-owns the data.

The pattern is the same at both scales. Someone sees a problem and reaches for a structural solution (SLA, SSC, RACI) without first asking whether the dependency needs to exist. The structural solution doesn't fix the dependency. It institutionalizes it. You end up paying permanently for a problem that had a permanent fix available.

The close lead who walks into Operations with an SLA draft gets a negotiation. The close lead who walks in with a shared report prototype, framed as "here's something that would save both our teams time," gets a partner.

If your organization needs a record-to-report team sitting between local controllers and the general ledger, ask why. R2R can standardize routine work. But when R2R exists because Finance and Operations never agreed on one version of the numbers, it's not solving the close problem. It's preserving it, with a headcount and a budget line.

Run every upstream dependency through the five fixes in order. Eliminate, co-own, standardize, restructure, formalize. Most teams skip straight to #5, or worse, straight to organizational redesign, because big moves feel like progress. The first four fixes are quieter. They also make the problem disappear instead of building a department around it.

Common Pushback

These come up every time I walk through the hierarchy with a close team.

"Operations won't share their data." They won't share it as a favor. They will share it if the shared artifact gives them something they don't have today. The production cost report that shows yield alongside GL impact? Operations wants that too. They just never had a reason to build it with Finance. Frame their benefit first. If you walk in asking for data, you get resistance. If you walk in offering a tool, you get a conversation.

"We tried shared files and nobody updated them." That usually means the file was designed by Finance, for Finance, and the other team saw no value in maintaining it. A shared artifact only survives if both teams use it for their own work. If only one side benefits, it's not shared. It's an outsourced data entry job with extra steps.

"Our ERP can't do scheduled extracts." Most can. The question is whether anyone in Finance has ever asked IT. In twelve years across SAP and Oracle environments, I've never seen an ERP that couldn't generate a scheduled report to a shared folder. The capability exists. The request hasn't been made because the email workaround is familiar and doesn't require an IT ticket.

"We signed an SLA but nobody follows it." An SLA without a consequence clause is a suggestion. Go back to the four elements. If there's no documented fallback for what Finance does when the data doesn't arrive, you don't have an SLA. You have a deadline that the other team can miss without consequences. Add the fallback. Agree it with the controller. Then the SLA works because the close proceeds whether the data arrives or not.

Try This Before Next Close

Pick the three upstream dependencies that cause the most pain each month. For each one, start at Fix #1 and stop at the first fix that applies.

If the data already sits in a system Finance could access, file the IT ticket. If you could build a shared report that gives the other team something they need too, sketch the artifact (their view on one side, your view on the other) and bring the sketch to the upstream team. Frame their benefit first. If you still need a handoff, lock the template. If the timing won't bend, estimate now and true-up later. Only if none of the four work, draft the SLA.

One dependency fixed structurally will save you more hours over the next twelve months than an SLA that gets ignored eleven months out of twelve.

How many of your close handoffs exist because two teams never agreed to use the same file?

FAQ

How do I get IT to prioritize an access request for the close? Quantify the cost. If you followed Article 6, you've already classified the waste. "This email handoff costs 3 hours per month and introduces a two-day wait into the critical path" is a different conversation than "can we get read access to the purchasing module." Attach the waste measurement to the IT ticket. Most IT teams prioritize by business impact, and a quantified close bottleneck qualifies.

What if the other department refuses to co-own an artifact? Drop to Fix #3. Build the template yourself, lock the format, and send it to them. You've reduced the friction even if you haven't eliminated the dependency. Meanwhile, track the time cost of the remaining handoff. When the numbers are visible and the other team sees that the handoff costs both sides, the conversation about a shared artifact gets easier. Sometimes it takes two close cycles of data before the other team comes to you.

Does this work in organizations with shared service centers? Yes, and it often matters more. SSCs multiply handoffs by design. A task that one local controller used to own gets split into submission, review, posting, and quality check. Each split is a new dependency. Run every SSC handoff through the hierarchy the same way you would any other. A common one: the SSC requests intercompany balances by email from each entity, waits, reconciles, and posts. That's a Fix #1 candidate. The balances already sit in the ERP. A scheduled extract and an automated matching report would eliminate the entire chain. You'll often find the SSC is maintaining data that already exists somewhere in the system.

How do I tell the difference between a real judgment dependency and a data dependency dressed up as one? Ask whether the upstream team adds information that doesn't exist anywhere else, or whether they're reformatting, validating, or approving information that already sits in a system. Legal's litigation provision is a real judgment call. Procurement's confirmation that a PO was received is usually not, if the goods receipt or service entry already exists in the ERP. If the "judgment" is actually a status check on data that's already in the system, it's a Fix #1 candidate, not a Fix #5.

The series so far: root cause analysis traced 78% of recurring overruns to systems and upstream handoffs. This article gave you five ways to fix those handoffs, in the order you should try them. Next: you've got the map, the measurements, the root causes, and the fixes. Article 9 covers ten KPIs, trend tracking, and a cycle that turns one month's fix into permanent improvement.

If you want the full five-fix diagnostic applied across a complete close with pre-built classification frameworks and a tracked improvement plan, that's part of Month-End Close Optimization: Run Your Close Like a System, Not a Fire Drill on GoFast.Finance.

Sources

• Tabrizi, B. (2015). "75% of Cross-Functional Teams Are Dysfunctional." Harvard Business Review, June 23, 2015. Study of 95 teams across 25 leading corporations: nearly 75% failed on at least three of five criteria. Projects with strong governance support had a 76% success rate; those with only moderate governance support had a 19% success rate.

• Ledge (2025). "The State of Month-End Close in 2025: Finance Team Benchmarks & Insights." Survey of 100 finance professionals. 56% of respondents selected dependency on other departments and regions as a blocker preventing faster closes.

• XPLM (2023). "Industry Study 2023: Employees Ignore Data Handling Guidelines." Survey of 126 industry executives. The study focuses on industrial/product data handling, not finance close specifically. It supports the broader point that fragmented systems, email-based exchange, and departmental silo thinking create recurring data-flow problems. In three out of four companies, data is still exchanged by email.

This article originally appeared in the Practical Lean Finance newsletter on LinkedIn.