How Many Business Processes Still Depend on Someone Moving a File?

Some business processes still depend on someone remembering to move a file from one system to another. The work gets done every day, but the process behind it often goes undocumented.

Ask the finance team, the warehouse and the sales office the same question:

Which files do you regularly download from one system and upload into another?

The answers often come quickly. A payment file prepared for the bank. An order list uploaded to a supplier portal. A price list emailed to distributors every Monday.

These tasks are part of how the business operates. Yet the person moving the file may be the only visible link between the two systems.

A 2025 survey by Parseur and QuestionPro offers a useful indication of the time involved in related manual work. Among 500 U.S. professionals surveyed, respondents reported spending more than nine hours a week transferring data from emails, PDFs and spreadsheets into other systems. That is more than a full working day each week, according to the respondents themselves.

The survey measures manual data entry rather than file transfers specifically. Still, it points to a broader operational question: how much work happens between systems without being recognised as a process in its own right?

Why is this work so difficult to count?

Companies maintain inventories of their software, applications and infrastructure. The manual work that connects them can be much harder to see.

A process diagram might show an ERP system and a bank portal. It rarely explains what happens when a finance specialist exports a payment file, checks its contents and prepares it for the next system.

That person may perform the same task every morning. The task may be essential to the payment process, yet remain undocumented as a separate operational dependency.

The same applies to recurring order files, reports and supplier updates. The business sees the completed work. The manual steps that make it happen can remain outside the process documentation.

Where do these hidden steps appear?

They tend to fall into three categories.

1. The manual hand-off

Someone downloads a file from one system and uploads it to another. The same price list is emailed to distributors every Monday. An order export is uploaded to a supplier portal.

These are usually the easiest steps to identify. Ask the people who perform the work regularly, and the recurring tasks begin to emerge.

The key is to look for repeated actions rather than one-off exceptions. A file uploaded once during a special project is different from a payment file that someone must prepare every business day.

2. The spreadsheet in the middle

Sometimes, the file passes through a spreadsheet before reaching its destination.

An engineering team exports data, adjusts formulas and sends the updated workbook to another department. Finance combines information from several systems before preparing a report. Operations maintains a spreadsheet that has survived multiple system upgrades.

A NAFEMS survey of engineering professionals, presented in 2018, found that critical spreadsheets were widely shared through network drives and email, often with limited version control. More than 35% of respondents expected their critical spreadsheets to remain in use for over five years.

Although the survey is several years old, it illustrates a persistent challenge: a spreadsheet can become an informal part of a process, connecting people and systems in ways that are difficult to document.

The question is whether the spreadsheet is simply helping someone analyse information or has become a recurring step required to move data between systems.

3. The hand-off that runs automatically

A script written years ago. A scheduled job on a single server. A small integration that moves a file every night.

Nobody needs to click a button, so the task appears automated.

But who knows what the script does? Who checks whether it ran successfully? Who can maintain it if its original author leaves?

Automation removes the need for someone to perform the task manually. It doesn’t automatically remove the dependency on the person who understands how it works.

The dependency often becomes visible when the script fails, the destination changes or its owner is unavailable.

A process can run automatically and still depend on someone who knows how to keep it running.

How do you count these processes?

Start with the people who perform the work, then compare their answers with what the systems actually run.

Three short exercises can reveal a surprising amount.

First, ask each team what it sends, downloads or uploads regularly. Include daily tasks, weekly routines and month-end activities. Ask about files exchanged with banks, suppliers, customers, logistics partners and other internal departments.

Second, list the automated jobs and scripts. Record what each one does, when it runs, who created it and who can maintain it. Include tasks running on individual servers as well as those managed through existing platforms.

Third, look for recurring attachments and spreadsheets. Check whether the same file or report is sent to the same recipients on a regular schedule. Look for spreadsheets that repeatedly receive data from one system before someone passes the results to another.

Then ask three questions about every item on the list:

• What triggers this task?
• Who would notice within an hour if it stopped?
• If the person responsible were away for two weeks, what would a colleague need to know to keep it running?

If the answer to the last question is “ask whoever built it”, the process depends on knowledge held by one person.

That is an important finding in itself.

What changes when file movement becomes part of a defined process?

A recurring file transfer can be defined, scheduled and monitored as a process rather than left as a manual task or an undocumented script.

This is where managed file transfer becomes relevant.

Xferity allows file-transfer flows to be configured with a schedule, destination and retry policy. It supports protocols and storage options including SFTP, FTPS, AS2, S3-compatible storage, WebDAV and Azure Blob.

When a transfer fails, retry policies can handle subsequent attempts. Idempotency checks help prevent duplicate deliveries during retries, while dead-letter handling provides a defined place for transfers that cannot be completed automatically. Metrics, logs and alerting hooks provide visibility into what happened.

For file exchanges between compatible systems, a transfer can run according to a defined schedule, with retry policies and a recorded history of each attempt.

Instead of relying on a person to run a script or remember a recurring transfer, the team can monitor the flow, investigate failures and hand over responsibility with a clearer record of how the process works.

The same approach applies when a partner’s system supports a compatible protocol or storage endpoint. Manual uploads to web portals and email-based hand-offs require a different solution unless the receiving workflow supports integration.

Security controls are part of the same process, including encryption, integrity checks and endpoint-specific trust settings.

The important change is that the transfer no longer relies on someone remembering to perform the task and then noticing if something goes wrong.

So, how many business processes still depend on someone moving a file?

The exact number is rarely available from a system report alone. It often requires asking the people who keep these processes running.

Some tasks are manual hand-offs. Others rely on spreadsheets or scripts that have become essential to daily operations.

The first step is to identify them. The next is to understand which ones are worth automating, which need better monitoring and which require clearer ownership.

Start with the files that moved between your systems this week.

How many were transferred automatically - and how many moved because someone remembered to do it?