Two Departments, Same Work: The Payroll Cost of Duplicated Effort

The tolerated pain

In a growing business, departments solve their own problems. Sales keeps a spreadsheet of active customers and their contract terms. Finance keeps another, built from invoices. Operations keeps a third, because it needs delivery addresses and site contacts. Each team updates its version every week. None of them knows the others are doing almost the same work.

The same thing happens with reports, price lists, supplier checks, stock counts and customer onboarding. Two people in different departments chase the same customer for the same document. Two analysts build similar monthly summaries from the same raw data. A manager in one branch creates a template that already exists in another.

This is different from two people being unsure whose job a task is. That problem, unclear responsibility inside a team, has its own costs. Duplication across departments usually happens when each team is clear about its own job and simply cannot see what the rest of the business is doing.

Why businesses tolerate it

Nobody can see it. Each department's work looks reasonable on its own. The duplication only appears when you look across teams.
Each version is slightly different. Sales' customer list has columns finance does not need, so the overlap is not obvious.
Trust is low. Teams keep their own copy because they do not trust another department's data to be current.
Systems do not share. When applications are not connected, building your own list is often the fastest way to get the job done.
Budgets are departmental. No single manager pays the full cost, so no one is motivated to remove it.

What the evidence shows

Duplicated work is common enough that it is measured in workplace surveys. Asana, a work-management software vendor, reports in its Anatomy of Work research that the average knowledge worker spends 209 hours a year on duplicative work. Asana sells tools that address the problem, so the figure should be read with care, and it does not describe any particular business. It does suggest the waste is large enough to be worth measuring.

IBM's explainer on data silos describes the mechanism. It defines silos as isolated collections of data that prevent sharing between departments, systems and business units, and notes that different teams may store duplicate datasets in separate systems and then have to correlate and reconcile them manually before the data can be used. That reconciliation is a second layer of duplicated effort on top of the first.

Lean thinking has a name for the underlying waste. The Lean Enterprise Institute's list of the seven wastes includes overproduction, producing ahead of what is actually needed, and unnecessary processing. Two departments maintaining the same list is both.

Operational symptoms

different departments quoting different figures for the same customer, product or month;
customers asked for the same information by two teams;
several spreadsheets with similar names in different shared folders;
meetings spent working out whose numbers are right;
new employees told to "build your own list, ours is out of date";
a change, such as a new price, applied in one place but not the others.

The customer-record version of this problem is covered in the financial impact of departments keeping separate customer records. This article looks more widely at any work that is repeated across teams.

How the pain becomes money

Payroll cost of the duplicate work: the business pays two or more people to produce the same output.
Reconciliation cost: time spent comparing versions and agreeing which is right.
Error cost: decisions made on the out-of-date version, and corrections afterwards.
Customer cost: repeated requests and inconsistent answers erode confidence.
Opportunity cost: skilled people spend hours on copies instead of on improvement or service.

An illustrative cost model

This example is illustrative. Every figure is an assumption for a hypothetical business. Picture a Gauteng distribution business with 80 staff across sales, finance, operations and procurement.

Assumption	Value
Recurring outputs produced in two or more departments	6 (customer lists, price lists, stock summaries, supplier checks, sales reports, onboarding packs)
Duplicate hours per output per week	3
Reconciliation hours per output per week	1
Average loaded hourly cost	R320
Working weeks per year	46

Duplicate work: 6 × 3 hours × 46 weeks = 828 hours; 828 × R320 = R264,960
Reconciliation: 6 × 1 hour × 46 weeks = 276 hours; 276 × R320 = R88,320
Illustrative total: about R353,000 a year

That figure excludes the cost of decisions made on the wrong version, which is often larger. Test the assumptions by asking each department to list its recurring outputs and then laying the lists side by side.

Not every overlap is waste. Sometimes two teams genuinely need different views of the same information, and a second copy is a reasonable short-term workaround. The question is whether the copy is deliberate, owned and refreshed from a trusted source, or whether it was built because nobody knew the first one existed. Only the second kind should be removed, and it is usually the larger share.

When it becomes commercially urgent

management reports from different departments disagree and nobody can say why;
customers complain about being asked for the same thing twice;
the business is adding branches or departments, so every duplicate multiplies;
a system change or new software purchase is being planned;
headcount requests arrive from several teams for similar administrative roles.

What better looks like

The goal is not to centralise everything. It is to agree that each important output has one owner and one source, and that other departments use it instead of rebuilding it.

One source per dataset. Decide which system or team owns customers, products, prices and suppliers. The approach is explained in how to decide which system owns which data.
Shared outputs. A single report or list that all departments can view, filtered for their needs, replaces several copies.
Connected systems. Where teams use different applications, integration moves data between them instead of people.
Visibility of work in progress. A shared view of who is working on what makes duplication visible before it happens.

Some businesses use evidence from their own systems to find duplication. Microsoft's overview of process mining in Power Automate describes how event data from business systems can be used to show how processes actually run and where inefficiencies sit. Most small businesses will not need that level of tooling to start, but the principle is the same: look at what actually happens, not what the organisation chart says.

The wider pattern, where each department improves its own part while the whole gets worse, is explored in when every department optimises its part but the whole process gets worse.

Practical first steps

Inventory recurring outputs. Ask each department to list every spreadsheet, report and checklist it maintains on a regular cycle.
Compare across teams. Put the lists side by side and mark anything that covers the same customers, products, suppliers or periods.
Estimate the hours. For each overlap, ask how long each copy takes to maintain each week.
Choose an owner. For the biggest overlaps, agree which team keeps the master version and how others will access it.
Retire the copies. Archive the duplicate versions so they cannot drift back into use.

The bottom line

Duplicated effort across departments is hard to see because each copy looks like legitimate work. The business pays for it twice, then pays again to reconcile the differences and to fix the mistakes they cause. Making shared outputs visible, owned and trusted turns those hours back into capacity.

Sources and further reading

How Work About Work Gets in the Way of Real Work [2026] • Asana (last verified 10 October 2026)
What Are Data Silos? - IBM (last verified 10 October 2026)
What are the 7 Wastes in Lean? - Lean Enterprise Institute (last verified 10 October 2026)
Overview of process mining in Power Automate - Power Automate (last verified 10 October 2026)