Wenn zwei Systeme im Betrieb miteinander sprechen sollen — die Warenwirtschaft mit dem Buchhaltungssystem, die Zeiterfassung mit der Lohnabrechnung, das Auftragssystem mit dem Lager — fällt schnell das Wort Schnittstelle. Was damit gemeint ist, bleibt für die meisten Verantwortlichen unklar: eine Datei, ein Zusatzprogramm, eine Vereinbarung? Für die Entscheidung, ob ein Vorhaben machbar und bezahlbar ist, brauchen Sie kein Programmierwissen. Sie brauchen ein Bild davon, wie eine Anfrage aussieht, was zurückkommt, wer sich dabei ausweist und wo die Grenzen liegen. Dieser Beitrag erklärt Programmierschnittstellen ohne Vorkenntnisse, führt durch die Angaben einer Schnittstellendokumentation und endet mit den Fragen, die Sie einem Systemanbieter stellen können, ohne selbst technisch zu werden. Wer danach beurteilen kann, ob ein System überhaupt anbindbar ist, spart sich Angebote für Vorhaben, die an der Technik des Herstellers scheitern. Der Leistungsumfang dazu steht unter Schnittstellen.
Das Wichtigste in Kürze
- Eine Schnittstelle ist kein Programm und keine Datei, sondern eine Vereinbarung: Welche Fragen ein System beantwortet, wie diese Fragen gestellt werden müssen und in welcher Form die Antwort zurückkommt.
- Jede Anfrage durchläuft dieselben fünf Schritte (Projekterfahrung): Adresse aufrufen, ausweisen, Rechte prüfen lassen, Antwort mit Statuszeichen und Daten entgegennehmen, Aufrufgrenzen einhalten. Wer diese fünf Punkte klären kann, kann ein Vorhaben einschätzen.
- Das Datenformat ist selten das Problem, die Rechte sind es: Ein Zugang, der nur lesen darf, taugt für Auswertungen, aber nicht für automatische Buchungen — und ein Zugang mit Vollrechten gehört nicht in eine Anbindung, die nur Adressen abgleichen soll.
- Ein System gilt als anbindbar, wenn es eine öffentlich zugängliche Dokumentation, eine Testumgebung, benannte Versionen mit Ankündigungsfristen und einen technischen Ansprechpartner gibt. Fehlen zwei dieser vier Punkte, steigen Aufwand und Risiko deutlich.
- Fehlt eine Schnittstelle vollständig, bleiben geplanter Dateiaustausch, Datenbankzugriff mit Zustimmung des Herstellers oder die Ablösung des Systems — Bildschirmnachahmung ist die teuerste Variante, weil jede Oberflächenänderung sie stoppt.
Eine Schnittstelle ist ein vereinbarter Weg für Anfrage und Antwort
Der Begriff Schnittstelle beschreibt weder ein Zusatzprogramm noch eine Datei, sondern eine Vereinbarung zwischen zwei Systemen: Welche Fragen darf das eine System dem anderen stellen, in welcher Form muss die Frage gestellt werden, und was kommt zurück. Eine Programmierschnittstelle — häufig mit dem englischen Kürzel API bezeichnet — ist genau diese Vereinbarung, festgehalten in einer Dokumentation und im System des Anbieters umgesetzt. Wenn Ihr Anbieter sagt, sein System habe eine Schnittstelle, sagt er damit zunächst nur: Es gibt einen offiziellen Weg, von außen an bestimmte Daten und Funktionen heranzukommen. Welche Daten das sind und welche Funktionen, steht damit noch nicht fest.
Ein Vergleich aus dem Betrieb trägt weit: Die Schnittstelle ist der Bestellschalter eines Lagers. Wer etwas braucht, tritt an den Schalter, weist sich aus, nennt die Artikelnummer und bekommt entweder die Ware oder eine Auskunft, warum nicht. Niemand betritt dabei selbst das Lager, niemand räumt eigenmächtig Regale um. Genau das ist der Sinn: Das andere System behält die Kontrolle darüber, was herausgegeben und was verändert werden darf. Der Schalter hat Öffnungszeiten, eine Warteschlange und einen Katalog dessen, was ausgegeben wird — alle drei Begrenzungen haben in der Technik eine direkte Entsprechung und entscheiden später darüber, was eine Anbindung leisten kann.
Daraus folgt das Wichtigste für jede Machbarkeitsfrage: Eine Anbindung kann nur das, was der Schalter hergibt. Wenn die Schnittstelle einer Branchensoftware Aufträge ausliefert, aber keine Positionen dazu, dann lässt sich daraus keine Auswertung nach Artikeln bauen — unabhängig davon, wie viel Aufwand jemand hineinsteckt. Deshalb steht am Anfang eines Vorhabens nicht die Frage, was gebaut werden soll, sondern was die beteiligten Systeme überhaupt herausgeben. Diese Prüfung gehört in die Prozessanalyse und nicht in die Umsetzung.
Drei Begriffe, die oft vermischt werden
Was bei einer Anfrage tatsächlich passiert
Jede Anfrage an eine Schnittstelle läuft nach demselben Muster ab, gleich ob es um eine Kundenadresse oder um eine Lagerbuchung geht. Wenn Sie dieses Muster einmal gesehen haben, können Sie in einer Besprechung mit dem Systemanbieter mitreden, ohne selbst Technik zu betreiben. Wichtig ist vor allem der letzte Schritt: Auf jede Anfrage folgt eine Antwort mit einem Statuszeichen, und dieses Statuszeichen entscheidet darüber, ob die Anbindung stillschweigend danebenliegt oder einen Fehler sichtbar macht.
Schritt 1: Die Adresse aufrufen
Jede Funktion einer Schnittstelle hat eine eigene Adresse, ähnlich einer Internetadresse. Eine Adresse liefert Artikel, eine andere Kunden, eine dritte nimmt Aufträge entgegen. Diese Adressen stehen in der Dokumentation und ändern sich nicht ohne Ankündigung.
Schritt 2: Sagen, was gewollt ist
Zur Adresse gehört eine Absicht: abfragen, anlegen, ändern oder löschen. Dazu kommen Zusatzangaben, etwa eine Kundennummer oder ein Zeitraum. Erst beides zusammen ergibt eine vollständige Frage.
Schritt 3: Sich ausweisen
Mit der Anfrage geht ein Zugangsschlüssel mit. Das andere System prüft, ob der Schlüssel gültig ist und ob der dahinterliegende Zugang die gewünschte Aktion überhaupt ausführen darf. Ohne gültigen Schlüssel endet die Anfrage hier.
Schritt 4: Die Antwort entgegennehmen
Zurück kommt ein Statuszeichen und meist ein Datenpaket. Übliche Zeichen: erfolgreich, nicht angemeldet, nicht erlaubt, nicht gefunden, zu viele Anfragen, Fehler im Zielsystem. Jedes dieser Zeichen erfordert eine eigene Reaktion in der Anbindung.
Schritt 5: Das Ergebnis verarbeiten
Erst jetzt entsteht der Nutzen: Der Datensatz wird übernommen, ein Beleg wird angelegt, eine Kennzahl wird fortgeschrieben. Fehlerhafte Antworten wandern in eine Wiedervorlage, statt unbemerkt zu verschwinden.
Jede Funktion einer Schnittstelle hat eine eigene Adresse, ähnlich einer Internetadresse. Eine Adresse liefert Artikel, eine andere Kunden, eine dritte nimmt Aufträge entgegen. Diese Adressen stehen in der Dokumentation und ändern sich nicht ohne Ankündigung.
Zur Adresse gehört eine Absicht: abfragen, anlegen, ändern oder löschen. Dazu kommen Zusatzangaben, etwa eine Kundennummer oder ein Zeitraum. Erst beides zusammen ergibt eine vollständige Frage.
Mit der Anfrage geht ein Zugangsschlüssel mit. Das andere System prüft, ob der Schlüssel gültig ist und ob der dahinterliegende Zugang die gewünschte Aktion überhaupt ausführen darf. Ohne gültigen Schlüssel endet die Anfrage hier.
Zurück kommt ein Statuszeichen und meist ein Datenpaket. Übliche Zeichen: erfolgreich, nicht angemeldet, nicht erlaubt, nicht gefunden, zu viele Anfragen, Fehler im Zielsystem. Jedes dieser Zeichen erfordert eine eigene Reaktion in der Anbindung.
Erst jetzt entsteht der Nutzen: Der Datensatz wird übernommen, ein Beleg wird angelegt, eine Kennzahl wird fortgeschrieben. Fehlerhafte Antworten wandern in eine Wiedervorlage, statt unbemerkt zu verschwinden.
In der Praxis sieht eine Anfrage samt Antwort so aus wie im folgenden Beispiel. Sie müssen das nicht schreiben können — es hilft aber, es einmal gesehen zu haben, weil in Angeboten und Dokumentationen genau diese Bestandteile auftauchen: Adresse, Absicht, Zugangsschlüssel, gewünschtes Format, Statuszeichen und Datenpaket.
GET /api/v1/artikel/4711 HTTP/1.1
Host: warenwirtschaft.intern.example
Authorization: Bearer ZUGANGSSCHLUESSEL
Accept: application/json
--- Antwort ---
HTTP/1.1 200 OK
Content-Type: application/json
{
"artikelnummer": "4711",
"bezeichnung": "Rohrschelle 22 mm",
"bestand": 148,
"lagerort": "H-03-02",
"stand": "2026-05-29T08:14:00+02:00"
}Zwei Dinge sind an diesem Beispiel wichtig. Erstens der Zeitstempel: Eine Antwort bleibt eine Momentaufnahme, und die Frage, wie alt ein Wert sein darf, gehört fachlich geklärt, nicht technisch. Zweitens die Nummer 200 in der Antwortzeile — das Statuszeichen für erfolgreich. Kommt stattdessen 401, fehlt der Ausweis; bei 403 ist der Ausweis gültig, aber die Rechte reichen nicht; bei 404 existiert der Datensatz nicht; bei 429 wurden zu viele Anfragen gestellt; ab 500 liegt der Fehler im Zielsystem. Diese Zahlen sind branchenüblich und begegnen Ihnen in jeder Dokumentation wieder.
Datenformate: wie die Antwort aussieht und warum das selten das Problem ist
Für die Form der übertragenen Daten haben sich wenige Formate durchgesetzt. Das im Beispiel gezeigte Format mit geschweiften Klammern heißt JSON und ist heute der Regelfall. Ältere Systeme und viele Branchenstandards nutzen XML, das dieselben Inhalte mit spitzen Klammern und Kennzeichnungen abbildet und in regulierten Bereichen weiter verbreitet ist. Für den reinen Massenaustausch — Preislisten, Stammdaten, Buchungsstapel — kommt weiterhin die einfache Textdatei mit Trennzeichen zum Einsatz, im Alltag als CSV bezeichnet.
Die gute Nachricht für die Planung: Das Format ist fast nie der Grund, warum ein Vorhaben scheitert. Umwandlungen zwischen diesen Formaten sind Routine. Was tatsächlich Aufwand macht, sind Bedeutungsunterschiede — wenn ein System Nettopreise führt und das andere Bruttopreise, wenn Kundennummern in einem System mit führender Null gespeichert werden und im anderen ohne, wenn Datumsangaben ohne Zeitzone übertragen werden. Diese Fragen klärt man am Tisch und nicht im Programmcode; sie gehören zur Datenintegration und sind der Teil, den Angebote regelmäßig unterschätzen.
| Kriterium | Schnittstelle mit Sofortantwort | Geplanter Dateiaustausch |
|---|---|---|
| Aktualität | Antwort in Sekunden | So aktuell wie der letzte Lauf |
| Typischer Einsatz | Bestand, Preis, Auftragsstatus | Stammdaten, Buchungsstapel, Preislisten |
| Datenmenge je Vorgang | Einzelne Datensätze | Große Mengen auf einmal |
| Fehlerbild | Fehler sofort sichtbar | Fehler fällt oft erst am Folgetag auf |
| Voraussetzung beim Anbieter | Dokumentierte Schnittstelle nötig | Export- und Importfunktion genügt oft |
| Aufwand in der Einrichtung | Höher, dafür laufend genauer | Niedriger, dafür mehr Nacharbeit |
Ausweis und Rechte: wer fragt, und was gefragt werden darf
Zwei Fragen werden hier häufig vermischt. Die erste lautet: Wer stellt die Anfrage? Das ist der Ausweis. Die zweite lautet: Was darf dieser Fragende? Das sind die Rechte. Der Ausweis wird meist über einen Zugangsschlüssel geführt, eine lange Zeichenkette, die das andere System vergibt. In größeren Systemen kommt ein Verfahren zum Einsatz, bei dem der Schlüssel zeitlich begrenzt gilt und regelmäßig erneuert wird — für Ihre Planung bedeutet das lediglich, dass die Erneuerung automatisch ablaufen muss und nicht an einer Person hängen darf.
Die Rechte sind der Punkt, an dem Vorhaben tatsächlich scheitern. Ein Zugang, der ausschließlich lesen darf, eignet sich für Auswertungen und für die Auswertung von Kennzahlen, aber nicht für automatische Buchungen. Umgekehrt gehört ein Zugang mit Vollrechten nicht in eine Anbindung, die nur Adressen abgleichen soll. Für jede Anbindung sollte ein eigener technischer Zugang mit genau den benötigten Rechten eingerichtet werden — nicht der Zugang eines Mitarbeiters. Verlässt diese Person den Betrieb und wird ihr Konto gesperrt, steht sonst über Nacht der Datenaustausch.
- Eigener technischer Zugang je Anbindung, benannt nach dem Zweck und nicht nach einer Person
- Nur die tatsächlich benötigten Rechte, im Zweifel zuerst nur lesend und später erweitert
- Zugangsschlüssel getrennt von der Anwendung hinterlegt und nicht in Dokumenten oder Nachrichten weitergegeben — das BSI empfiehlt, Zugangsdaten nicht im Programmcode abzulegen (BSI)
- Ein festgelegtes Vorgehen für den Fall, dass ein Schlüssel bekannt wird: sperren, neu vergeben, Anbindung nachziehen
- Protokoll darüber, welche Anbindung wann welche Daten geholt oder geschrieben hat — im Streitfall die einzige belastbare Auskunft
- Übertragung ausschließlich verschlüsselt, erkennbar am Adressbeginn mit https
Grenzen der Aufrufhäufigkeit und was sie im Betrieb bedeuten
Kein Anbieter lässt beliebig viele Anfragen zu. Üblich ist eine Obergrenze je Minute, je Stunde oder je Tag, im Fachjargon Rate Limit genannt. Wird sie überschritten, antwortet das System mit dem Statuszeichen 429 und häufig mit einer Angabe, wie lange gewartet werden soll. Für Sie ist das keine technische Randnotiz, sondern eine Planungsgröße: Sie bestimmt, wie viele Datensätze pro Stunde übertragen werden können und ob eine erste Vollübernahme von Stammdaten eine Stunde oder ein Wochenende dauert.
Praktisch heißt das: Eine Anbindung darf nicht alle Daten ständig neu abfragen, sondern nur die Änderungen seit dem letzten Lauf. Fast jede brauchbare Schnittstelle bietet dafür einen Filter nach Änderungsdatum. Fehlt dieser Filter, wird jede Abfrage zur Vollübertragung — das ist bei fünfhundert Artikeln unerheblich und bei achtzigtausend Artikeln ein Ausschlusskriterium. Fragen Sie diesen Punkt früh ab, er verändert den Aufwand einer Anbindung stärker als das Datenformat.
Die Grenze gehört ins Angebot
Versionen: Schnittstellen ändern sich, Anbindungen ziehen nach
Eine Schnittstelle ist kein fertiges Bauteil, sondern ein gepflegtes. Anbieter erweitern Felder, ändern Strukturen und schalten alte Stände ab. Damit bestehende Anbindungen davon nicht überrascht werden, wird die Schnittstelle versioniert: In der Adresse taucht eine Kennung wie v1 oder v2 auf, oder die Version wird in der Anfrage mitgegeben. Solange Sie eine feste Version ansprechen, bleibt Ihre Anbindung stabil, auch wenn der Anbieter parallel eine neue Version bereitstellt.
Interessant ist deshalb weniger, ob versioniert wird, sondern wie mit Abschaltungen umgegangen wird. Seriöse Anbieter kündigen das Ende einer Version mit Frist an, veröffentlichen eine Änderungsübersicht und stellen einen Umstiegsleitfaden bereit. Fehlt das, tragen Sie das Risiko: Eine Anbindung, die jahrelang lief, hört an einem Dienstagmorgen ohne Vorwarnung auf zu arbeiten. Deshalb gehören Ankündigungsfrist und Änderungsübersicht in die Vertragsunterlagen und nicht in ein Telefonat.
Zwei Fragen zur Version vor jeder Beauftragung
Was in einer Schnittstellendokumentation steht
Eine Schnittstellendokumentation wirkt beim ersten Blick abschreckend, folgt aber stets demselben Muster. Sie müssen sie nicht vollständig verstehen. Es genügt, sechs Angaben zu finden — wenn alle sechs vorhanden sind, ist eine Anbindung planbar; fehlen zwei davon, beginnt die Umsetzung mit Rückfragen an den Hersteller und wird entsprechend teurer.
Verzeichnis der Adressen
Eine Liste aller ansprechbaren Funktionen mit Angabe, was jede zurückgibt. Prüfen Sie hier zuerst, ob die von Ihnen benötigten Daten überhaupt aufgeführt sind.
Anmeldeverfahren
Wie ein Zugangsschlüssel beantragt wird, wie lange er gilt und wer ihn vergeben darf. Steht hier nur eine Mailadresse des Vertriebs, rechnen Sie mit Wartezeit.
Beschreibung der Felder
Welche Felder eine Antwort enthält, welchen Typ sie haben und welche Pflichtangaben beim Schreiben nötig sind. Hier zeigt sich, ob Ihre Auswertung fachlich möglich ist.
Fehler und Statuszeichen
Eine Übersicht der Rückmeldungen mit Bedeutung. Fehlt sie, muss jede Fehlerbehandlung durch Ausprobieren entstehen — ein häufig unterschätzter Kostenpunkt.
Grenzen und Versionen
Erlaubte Aufrufe je Zeitraum, Filter nach Änderungsdatum, aktuelle Version und Umgang mit Abschaltungen. Diese Angaben bestimmen den Betrieb, nicht die Einrichtung.
Testumgebung und Beispiele
Ein separates System mit Testdaten und vollständige Beispielanfragen. Ohne Testumgebung wird auf Echtdaten entwickelt — das ist im laufenden Betrieb nicht zumutbar.
Sie können diese sechs Punkte selbst abhaken, ohne eine Zeile zu programmieren. Öffnen Sie die Dokumentation, suchen Sie nach den Begriffen Endpunkt oder Adresse, Authentifizierung, Felder, Fehlercodes, Limit und Sandbox oder Testzugang. Was Sie in zwanzig Minuten nicht finden, wird auch in der Umsetzung nicht auftauchen. Diese kurze Prüfung ersetzt keine technische Bewertung, sortiert aber die Fälle aus, die von vornherein aufwendig werden.
Woran Sie erkennen, ob ein System überhaupt anbindbar ist
Zwischen der Aussage, ein System sei offen, und einer tatsächlich nutzbaren Schnittstelle liegen im Alltag Welten. Bitkom weist darauf hin, dass fehlende Verbindungen zwischen vorhandenen Systemen zu den häufig genannten Hürden der Digitalisierung im Mittelstand gehören (Bitkom). Die folgenden Anzeichen lassen sich ohne technische Prüfung erkennen und sagen mehr aus als die Formulierung im Angebot.
- Gutes Zeichen: Die Dokumentation ist öffentlich abrufbar, ohne Anmeldung und ohne Verkaufsgespräch
- Gutes Zeichen: Es gibt eine Testumgebung mit Beispieldaten, die Sie vor der Beauftragung nutzen dürfen
- Gutes Zeichen: Der Anbieter benennt einen technischen Ansprechpartner, nicht nur eine Vertriebsadresse
- Gutes Zeichen: Versionen werden benannt und Abschaltungen mit Frist angekündigt
- Warnzeichen: Die Schnittstelle ist nur in einem höheren Vertragspaket enthalten und wird je Verbindung zusätzlich abgerechnet
- Warnzeichen: Es gibt nur einen Datenexport auf Knopfdruck, aber keinen automatisierbaren Weg
- Warnzeichen: Der Anbieter verlangt, dass jede Anbindung von ihm selbst umgesetzt wird, ohne Zugang für Dritte
- Ausschlusskriterium in der Praxis: Es gibt keine Dokumentation, sondern nur die Zusage, man werde das im Projekt klären
Der letzte Punkt verdient Nachdruck. Eine Zusage ohne Dokumentation verschiebt die Klärung in die Umsetzung, also in die Phase, in der jede Stunde bezahlt wird. Wenn ein Systemwechsel ohnehin ansteht, ist die Anbindbarkeit ein Auswahlkriterium wie Preis und Funktionsumfang — und einer der Gründe, warum die Ablösung von Altsystemen oft günstiger ausfällt als der Versuch, ein geschlossenes System nachträglich zu öffnen.
Eine Schnittstelle ist keine Datei, die einmal übergeben wird, sondern eine Vereinbarung, die im Betrieb gepflegt werden muss.
Diese Fragen stellen Sie dem Systemanbieter
Die folgenden Fragen können Sie wörtlich übernehmen. Sie sind so formuliert, dass die Antwort auch für Nicht-Techniker verwertbar ist, und decken genau die Punkte ab, die später über Aufwand und Machbarkeit entscheiden. Schriftliche Antworten sind mündlichen vorzuziehen — nicht aus Misstrauen, sondern weil dieselbe Frage im Vertrieb und in der Technik häufig unterschiedlich beantwortet wird.
- Gibt es eine dokumentierte Programmierschnittstelle, und ist die Dokumentation vor Vertragsschluss einsehbar?
- Welche Daten und Funktionen sind darüber erreichbar, und welche ausdrücklich nicht?
- Ist der Zugang lesend, schreibend oder beides, und lassen sich Rechte je Zugang einschränken?
- Wie wird ein technischer Zugang eingerichtet, wie lange dauert das, und kostet er extra?
- Wie viele Anfragen sind je Minute oder Tag erlaubt, und was passiert bei Überschreitung?
- Gibt es einen Filter nach Änderungsdatum, damit nicht bei jedem Lauf alle Daten übertragen werden?
- Welche Version ist aktuell, und mit welcher Frist werden alte Versionen abgeschaltet?
- Gibt es eine Testumgebung mit Beispieldaten, die wir vor der Beauftragung nutzen dürfen?
- Wer ist technischer Ansprechpartner, und in welcher Zeit wird auf Rückfragen geantwortet?
- Ist die Nutzung der Schnittstelle im bestehenden Vertrag enthalten oder an ein anderes Paket gebunden?
Aus den Antworten ergibt sich fast von selbst, ob eine Anbindung ein überschaubares Vorhaben oder ein Projekt mit offenem Ende ist. Zwei Antworten wiegen dabei besonders schwer: die Rechte und der Änderungsfilter. Wer nur lesen darf, kann auswerten, aber nicht entlasten. Wer bei jedem Lauf alles übertragen muss, zahlt dauerhaft für Datenmengen, die niemand braucht.
Wenn es keine Schnittstelle gibt: die Ausweichwege
Nicht jedes System im Mittelstand hat eine nutzbare Schnittstelle, gerade ältere Branchenlösungen nicht. Das bedeutet nicht das Ende des Vorhabens, verändert aber den Weg. Der einfachste Ausweichweg ist der geplante Dateiaustausch: Das System legt in festen Abständen einen Export ab, ein zweites Programm holt die Datei, prüft sie und übergibt die Daten weiter. Das ist unelegant, aber robust — und für Stammdaten, Preislisten oder Buchungsstapel häufig völlig ausreichend.
Der zweite Weg ist ein lesender Zugriff auf die Datenbank des Systems, ausdrücklich mit Zustimmung des Herstellers. Ohne diese Zustimmung ist davon abzuraten: Der Zugriff kann Gewährleistungsansprüche berühren, und ein Systemupdate kann die Datenstruktur ohne Vorwarnung ändern. Der dritte Weg — die Nachahmung von Bildschirmeingaben, also ein Programm, das eine Oberfläche wie ein Mensch bedient — ist der teuerste. Er funktioniert, bis der Hersteller ein Feld verschiebt. Als Übergangslösung mit begrenzter Laufzeit hat er seinen Platz, als Dauerlösung selten.
Unabhängig vom gewählten Weg gilt dieselbe Anforderung: Jeder Austausch braucht eine Protokollierung, eine Wiedervorlage für Fehlerfälle und einen benannten Zuständigen. Ein Datenaustausch, der niemandem gehört, fällt irgendwann aus und wird erst bemerkt, wenn eine Auswertung nicht mehr stimmt. Diese Betriebsfragen behandeln wir unter Prozessautomatisierung — sie entscheiden über den Nutzen stärker als die Wahl der Technik. Rechtliche Fragen, etwa zu Aufbewahrung und Auftragsverarbeitung, sollten im Einzelfall fachlich geprüft werden; die elektronische Rechnungsstellung im Geschäftsverkehr zwischen Unternehmen ist in Deutschland seit 2025 mit Empfangspflichten verbunden (Umsatzsteuergesetz) und ein häufiger Anlass, Systeme erstmals ernsthaft zu verbinden.
Verwandte Artikel
Wann Middleware nötig ist — und wann nicht
Middleware vermittelt zwischen Systemen, die nicht direkt miteinander sprechen. Wann eine Direktverbindung reicht und ab wann sich die Zwischenschicht rechnet.
Rechnungsprüfung automatisieren: der Drei-Wege-Abgleich
Bestellung, Wareneingang und Rechnung maschinell abgleichen: welche Felder verglichen werden, wo das Toleranzband liegt und wer den Klärfall bekommt.
Software auswählen: Lastenheft und Anbietervergleich
Wie ein Betrieb vor dem Kauf entscheidet: Mengengerüst erheben, schlankes Lastenheft in einer Woche schreiben, Anbieter gewichtet vergleichen, Vertrag prüfen.