Most connections between an ERP like SAP and the accounting side in DATEV start harmlessly. Someone needs the month's bookings in the other system, exports them quickly as a file and uploads them across. It works the first time, and that is exactly the trap. The one-off export becomes a fixed habit, the habit becomes a script, and half a year later part of the finance flow hangs on a file that lives in one person's head.

You do not spot an island on day one, but on the first special case. A document is reversed, an account changes, a field arrives in a new format, and suddenly the export no longer fits. Because nobody treated the bridge as its own system, there is no place where the error surfaces and no rule for what should happen next. The data now exists twice, in two truths, and the month-end close turns into a search.

The two systems are not the problem. The bridge nobody treats as a system is.

The way out is not bigger software but a deliberate decision: the connection between SAP and DATEV is itself a flow with an input, rules, exceptions and an owner. Plan it that way and you build a road, not an island.

There are essentially three ways to move data between two core systems, and they differ sharply in durability. The first is the documented interface: both sides offer defined ways to hand over documents and bookings in a structured form, and you address those ways directly. This is the most stable approach because the format is agreed and does not change just because a screen changes.

The second way is file or format exchange. One system writes a file in an agreed format, the other reads it in. Done cleanly this is a legitimate route, especially when one side offers no open interface. It only becomes risky when the format itself is improvised and follows no agreement both sides know.

The third way is the screen trick: a robot clicks through the mask and types values as if it were a human. It can bridge a gap when there is neither an interface nor a format, but it is the most fragile route because any change to the screen stops it. As a permanent solution for financial data it rarely holds up.

The order is also the ranking. Take the interface if it exists. Take an agreed format if not. Take the screen trick only when both are missing, and then deliberately as a bridge.

Whether a connection holds is decided less by the route than by a handful of properties that are easy to skip because they are invisible on day one. The most important is clean master data. Chart of accounts, cost centres, tax keys and document types must be mapped onto each other unambiguously between both systems. If that mapping is wrong, numbers move to the wrong place, and the error only surfaces at the close, where it is expensive.

Almost as important is idempotency, a clumsy word for a simple rule: the same document must not arrive twice. If an export is repeated because a run broke off, the receiving side must recognise what it already has. Without that safeguard you get double bookings, and in accounting those are the most unpleasant kind of error.

Then comes the error path. There will always be documents that do not run through cleanly because an account is missing or a value is implausible. A good integration neither throws such cases away nor books them blindly, but sets them aside visibly and hands them to a person. A log that shows what was transferred and when makes the close traceable. And like any flow, the connection needs a person who owns it when something changes on either side.

Before you connect SAP and DATEV, answer these five questions. If you get stuck on one, you have found the future island, and before it forms.

• Which documents and bookings should flow in which direction, and how often?
• How do you map master data, meaning accounts, cost centres, tax keys and document types?
• How do you prevent double bookings when a run breaks off and is repeated?
• What happens to a document that does not go through, and who decides then?
• Who owns the connection in operation when one side changes?

Core sentence: a connection is in small part a question of tooling and in large part a question of alignment. Who skips the alignment builds an island they later drain at high cost.

An export is already an integration.

A one-off export moves data, but it has no rules for exceptions, no protection against duplicates and no owner. That is exactly how it becomes an island.

The connection is purely an IT topic.

The hard decisions are functional: which account matches which, what is a tolerable error, when does a human step in. IT builds the bridge, but accounting decides where it leads.

API integration, Data quality, Exception handling, Data sovereignty.

Must I always take the interface, or is a file export enough?

Take the documented interface if both sides offer it, because it is the most stable. An agreed, stable format is a legitimate second route when one side has no open interface. Only the improvised format without agreement is risky.

How do I reliably prevent double bookings?

Every document needs a unique identifier, and the receiving side checks before taking it over whether it already knows that identifier. That way a run can be repeated safely without anything being booked twice.

What belongs in the error path?

Cases that do not go through land visibly in a list rather than a bin, with the reason they are stuck. A named person looks in regularly, corrects or approves. Without that path, silent errors pile up until the close.

No external statistics or client results are asserted as verified. SAP and DATEV are named here as systems, not as partnerships. Concrete format and interface questions are checked against the real stack before implementation.