Eine Bestellung kommt rein. Per Mail mit PDF im Anhang, über das Lieferantenportal, manchmal noch als Fax, das längst zur Mail geworden ist. Und dann setzt sich jemand hin und tippt sie ab. Artikelnummer, Menge, Liefertermin, von Hand in die Maske. Im Jahr 2026.
Das kostet nicht nur Zeit. Es kostet Verlässlichkeit. Wer abtippt, vertippt sich, und aus 120 Stück werden schnell 1.200. Der Bestelleingang hängt an der Person, die die Maske kennt. Ist sie im Urlaub, krank oder in Rente, staut sich der Stapel. Die naheliegende Frage lautet: Lassen sich Bestellungen nicht automatisch erfassen?
Doch. Nur scheitert es selten am Wollen. Es scheitert an einem Missverständnis darüber, was die eigene Datenbank kann und was nicht.
Access ist die Hand, nicht das Ohr
Der eigentliche Grund liegt tiefer und hat nichts mit Faulheit zu tun. Microsoft Access kann von außen nicht angesprochen werden.
Access ist eine Desktop-Anwendung. Sie läuft nur, wenn ein Mensch sie geöffnet hat, auf einem PC, in einer Sitzung. Sie hat keine Adresse, unter der sie erreichbar wäre, und keinen Prozess, der wartet, bis eine Bestellung eintrifft. Eine eingehende Mail, ein Webformular, ein Lieferantensystem, all das kann Access nicht von sich aus mitbekommen.
Was Access gut kann, ist das Gegenteil: nach außen greifen. Per VBA verschickt es Mails, schreibt in den SQL Server, ruft eine Schnittstelle auf, exportiert eine Datei. Alles in dem Moment, in dem ein Mensch davorsitzt und arbeitet. Access ist die Hand, die hinausgreift. Es ist nicht das Ohr, das lauscht.
Genau deshalb sitzt da ein Mensch und tippt. Er ist die Brücke zwischen dem eingehenden Ereignis und einer Datenbank, die das Ereignis selbst nicht hört.
Power Automate ist das Ohr, das immer erreichbar ist
Was fehlt, ist etwas, das rund um die Uhr läuft und von außen ansprechbar ist. Früher war das ein Windows-Dienst oder eine geplante Aufgabe, die jemand bauen und dauerhaft pflegen musste. Heute übernimmt das Power Automate, der Automatisierungsdienst aus der Microsoft Power Platform. Er läuft in der Cloud, ist immer an und reagiert auf Auslöser, ohne dass jemand etwas öffnet.
Damit wird die Aufgabenteilung sauber:
- Power Automate ist das Ohr. Es fängt das eingehende Ereignis ab: eine neue Mail im Sammelpostfach, ein abgeschicktes Formular, eine Datei im SharePoint, ein Aufruf aus dem Webshop.
- Der SQL Server ist der gemeinsame Rücken. Hier liegen die Daten, hier schreiben beide Seiten hinein.
- Access bleibt die Hand. Bearbeitung, Prüfung, die Komfortmasken, in denen deine Leute ohnehin schon arbeiten.
Ein typischer Ablauf: Die Bestellung trifft im Sammelpostfach ein. Power Automate erkennt die Mail, liest die Felder aus (bei strukturierten Formularen direkt, bei freien PDFs mit etwas Nacharbeit) und schreibt eine neue Zeile in eine Eingangs-Tabelle des SQL Servers. Beim nächsten Öffnen sieht der Einkauf die Bestellung in der gewohnten Access-Maske. Niemand hat sie abgetippt.
Der entscheidende Punkt: Power Automate schreibt nicht in Access, sondern in den SQL Server, aus dem Access liest. Das funktioniert nur, wenn die Daten auch dort liegen.
Wo der Weg an Grenzen stößt
Drei ehrliche Voraussetzungen.
Erstens, das Backend muss SQL Server sein. Liegt deine Datenbank noch als Access-Datei auf einem Netzlaufwerk, gibt es nichts, in das ein Cloud-Dienst sinnvoll schreiben könnte. Dann ist die Reihenfolge klar: erst das Backend nach SQL Server holen, dann automatisieren. Struktur vor Tool, nicht andersherum. Wie dieser Schritt aussieht und wie Access, SQL Server und Power Platform sauber zusammenspielen, habe ich unter Access mit SQL Server und Power Platform kombinieren beschrieben.
Zweitens, steht dein SQL Server im eigenen Haus, braucht der Cloud-Dienst eine Brücke ins Netz. Sie heißt On-premises data gateway: ein Rechner im Firmennetz, der immer läuft und die Verbindung hält. Bei Azure SQL entfällt das, dann reden Cloud und Datenbank direkt miteinander.
Drittens, es kostet etwas. Der Zugriff auf SQL Server läuft über einen sogenannten Premium-Connector. Der ist im kostenlosen, in Microsoft 365 enthaltenen Power Automate nicht dabei. Du brauchst Power Automate Premium, derzeit rund 15 US-Dollar pro Nutzer und Monat (Stand Mitte 2026, bei jährlicher Bindung). Für eine Handvoll Bestell-Erfasser ist das überschaubar, bei vielen Beteiligten lohnt vorher die Rechnung.
Und ein Realismus-Hinweis dazu: Ein Flow sollte nicht blind in die Wirk-Tabellen schreiben. Eine Eingangs-Tabelle, in der zunächst alles landet, und ein kontrollierter Übergang in die echten Daten halten Müll-Bestellungen draußen. Automatisch heißt nicht ungeprüft.
Bestellungen automatisch erfassen, ohne das System zu wechseln
Du wechselst kein System. Access bleibt, das ERP bleibt, deine Masken bleiben. Du schließt eine einzige Lücke: den Punkt, an dem heute ein Mensch eine Bestellung von einem Bildschirm auf einen anderen überträgt.
Der spürbare Unterschied liegt nicht zuerst in gesparten Minuten, sondern darin, dass der Bestelleingang nicht mehr an einer Person hängt. Die Bestellung ist im System, sobald sie ankommt, nicht erst, wenn jemand Zeit hat. Ob sich das rechnet, hängt vom Volumen ab. Bei drei Bestellungen am Tag eher nicht, bei 30 schon.
Wenn dein Access-Backend bereits auf SQL Server liegt, ist dieser Schritt kleiner, als die meisten denken. Wer einmal draufschauen lassen möchte, ob sich das im eigenen Haus lohnt, erreicht mich über sesoft.de/kontakt.
Quellen
- Microsoft Learn: On-premises data gateway in Power Automate verwalten
- Microsoft: Power Automate, Preise und Pläne (Premium-Preis Stand Mitte 2026)
- sesoft.de: Access mit SQL Server und Power Platform kombinieren
Autor
Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU rund um Microsoft Access, VBA und SQL Server. Sein Schwerpunkt liegt darauf, gewachsene Datenbanken pragmatisch zu erweitern statt sie teuer zu ersetzen, zuletzt zunehmend mit der Power Platform als Brücke nach außen.
