Connecting Excel, email and specialist software

In many businesses the most important information sits in three places: in the mailbox, in a spreadsheet and in the specialist software. This text explains why that happens, which ways of connecting them exist and which fits which case.

ForAdministration, departments, IT managers
LevelPractice
Reading timeabout 7 minutes
Updated16 October 2026

What you will learn

Why the three worlds arise in the first place
Which four ways of connecting them exist and what they cost
Which questions you need to settle beforehand
How to tell that the spreadsheet has become the leading system

Why three worlds arise

The specialist software can do a lot, but not everything. What it cannot do ends up in a spreadsheet — because a spreadsheet is available immediately and asks nobody. What does not fit there stays in the mailbox, because everything arrives there anyway.

That is not bad organisation but an obvious reaction. It only becomes expensive when the same information is maintained in two places: then there are two versions, and nobody knows which one applies.

Four ways of connecting

File exchange: One system writes a file, the other reads it — usually overnight. Simple, robust, possible anywhere. Price: the data is up to a day old.
Database access: One system reads the other's database directly. Quick to set up and dangerous: it bypasses the rules of the target system and breaks when that system is updated.
Interface: Both sides talk to each other through an agreed point. The cleanest way, with validation and feedback — and the one that needs coordination.
Email evaluation: Incoming emails are evaluated automatically. Sensible when the sender cannot change the format, and always error-prone, because free text is not a format.

In practice the nightly file exchange often wins — not because it is elegant, but because it works and takes nothing away from anyone. The question that decides it is: how up to date does the data really need to be?

An example from practice

The spreadsheet has become the leading system

A business maintains prices in the specialist software and promotional prices in a spreadsheet. When preparing a quote, the salesperson looks in the spreadsheet first, because the prices there are more current. After a year, the prices in the specialist software are wrong for a third of the items.

Technically the solution is a reconciliation. Organisationally, however, one question must be answered first: which system leads? Without that decision the reconciliation overwrites both sides in turn — and the situation becomes worse than before.

What must be settled beforehand

Which system leads when there are contradictions?
Which fields are transferred — and which deliberately are not?
How up to date must the data be: in minutes, hours or by the next morning?
What happens to a record that fails validation: discard, report, defer?
Who notices when the transfer has not run for three days?

The last question is the one that most often stays open — and the one that makes the difference between a connection you can operate and one that eventually stops silently.

And if the spreadsheet is to stay?

That is a legitimate wish. A spreadsheet is a good tool for calculating and sorting, and nobody has to abolish it to end double entry. The practical route is usually: the spreadsheet stays as an analysis tool but loses the role of data holder. It is filled, not maintained.

Common misconceptions

Almost every system can at least export or import a file. That is enough for a nightly reconciliation — which is sufficient in many cases.

Technically possible, practically risky: you bypass the checks of the target system, and the next update can change the structure. As a permanent solution only with the vendor's explicit approval.

Higher timeliness costs effort and creates more failure cases. For many processes, the state as of this morning is exactly right.

Read on

What is an API?How an agreed connection works.

Which processes are suitable?Criteria for a good candidate.

API integrationOur service on the topic.

About the author

Fabian Lücker is managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and design, and writes here about decisions that come up in real projects.

Questions about the article? Write to us