VBA Workbook_Open in Excel — ein Makro automatisch beim Öffnen der Datei ausführen (und wo der Code liegen muss)

TL;DR — Workbook_Open ist eine Ereignisprozedur: Excel ruft sie für Sie auf, sobald die Datei fertig geöffnet ist, sodass ein Makro sich selbst ausführen kann — ohne Schaltfläche und ohne Zutun des Benutzers. Zwei Dinge entscheiden über Erfolg oder Misserfolg. Erstens: es muss im ThisWorkbook-Objekt liegen, nicht in einem gewöhnlichen Module — fügen Sie es in Module1 ein, und es feuert schlicht nie. Zweitens: es läuft nur, wenn Makros aktiviert sind und die Datei eine makrofähige Arbeitsmappe ist (.xlsm/.xlsb); öffnet der Benutzer sie mit blockierten Makros, passiert nichts, und kein Fehler wird angezeigt.

' Dieser Code liegt im ThisWorkbook-Objekt (Doppelklick auf "ThisWorkbook"
' im Projekt-Explorer — NICHT in Module1).
Private Sub Workbook_Open()
    Worksheets("Dashboard").Activate
    Range("A1").Select
    MsgBox "Welcome back — data last refreshed " & Format(Now, "dd mmm, hh:nn")
End Sub

Die meisten Makros warten auf eine Schaltfläche, ein Tastenkürzel oder das Makro-Dialogfeld. Ein Ereignismakro ist anders: Sie rufen es nie auf — Sie registrieren es, und Excel führt es aus, wenn etwas geschieht. Workbook_Open ist das erste Ereignis, dem die meisten Menschen begegnen, weil „mach das jedes Mal, wenn die Datei geöffnet wird“ ein so verbreiteter Wunsch ist: zum Dashboard springen, eine Abfrage aktualisieren, die Oberfläche einrichten, einen Öffnungs-Log stempeln. Es ist zugleich das Ereignis, das die Leute am häufigsten nicht zum Feuern bringen — fast immer aus einem von zwei Gründen, die dieser Artikel unübersehbar macht.

Was Sie lernen

Das mentale Modell — ein Ereignishandler, den Sie registrieren, kein Makro, das Sie ausführen
Die eine Regel, die über alles entscheidet — der Code muss in ThisWorkbook liegen
Warum es stillschweigend nie läuft — Makrosicherheit und das falsche Dateiformat
Workbook_Open gegenüber dem alten Auto_Open und welches Sie verwenden sollten
Warum Ereigniscode schnell und absturzsicher sein muss — er begrüßt den Benutzer bei jedem Öffnen

Das mentale Modell: ein Ereignishandler, den Sie registrieren, kein Makro, das Sie ausführen

Ein normales Makro ist ein Verb, das Sie aufrufen: Sie drücken eine Schaltfläche, und Sub RefreshData läuft. Eine Ereignisprozedur ist das Gegenteil — Sie schreiben sie einmal, legen sie an einem bestimmten Ort mit einem exakten Namen ab, und dann entscheidet Excel, wann sie aufgerufen wird. Sie führen Workbook_Open nicht aus; Sie versprechen Excel „das ist zu tun, wenn diese Arbeitsmappe geöffnet wird“, und Excel hält dieses Versprechen für Sie.

Das kehrt um, wie Sie über „wohin gehört dieser Code“ denken. Bei einem normalen Makro spielt der Ort kaum eine Rolle. Bei einem Ereignis ist der Ort die Registrierung. Excel sucht Workbook_Open an genau einer Stelle — dem eigenen Codemodul der Arbeitsmappe, genannt ThisWorkbook — und nirgendwo sonst. Der Name und der Ort zusammen sind der ganze Vertrag.

Die Regel, die über alles entscheidet: er muss in ThisWorkbook liegen

Das ist der häufigste Grund, warum ein Workbook_Open „nicht funktioniert“: Der Code wurde in ein gewöhnliches Modul eingefügt. Workbook_Open ist ein Member des Workbook-Objekts, also muss sein Handler im Codemodul der Arbeitsmappe liegen — ThisWorkbook — nicht in Module1.

Projekt-Explorer (Strg+R im VBA-Editor)
 └─ VBAProject (YourFile.xlsm)
     ├─ Microsoft Excel Objects
     │   ├─ Sheet1 (Sheet1)      ← Arbeitsblatt-Ereignisse gehören hierher
     │   └─ ThisWorkbook         ← Workbook_Open gehört HIERHER (Doppelklick)
     └─ Modules
         └─ Module1              ← ein Workbook_Open hier feuert NIE

Es gibt einen schnellen Weg, das Grundgerüst jedes Mal richtig hinzubekommen: Öffnen Sie den Code-Bereich von ThisWorkbook, wählen Sie im linken Dropdown (Objekt) Workbook und dann im rechten Dropdown (Prozedur) Open. Excel schreibt Ihnen die exakte Signatur:

Private Sub Workbook_Open()

End Sub

Die Signatur ist fest. Sie lautet Private Sub Workbook_Open() — keine Argumente, exakt so geschrieben, in ThisWorkbook. Benennen Sie sie um, fügen Sie einen Parameter hinzu oder verschieben Sie sie, und sie ist kein Ereignishandler mehr, sondern eine gewöhnliche (nie aufgerufene) Sub. Die Regel: Wenn ein Auto-Öffnen-Makro nicht feuert, prüfen Sie zuerst seinen Ort — in 90 % der Fälle liegt es in einem Module statt in ThisWorkbook.

Die Regel dahinter, warum es stillschweigend nie läuft: Makros müssen aktiviert sein

Selbst am richtigen Ort läuft Workbook_Open nur, wenn Excel Makros ausführen darf — und wenn nicht, gibt es keine Warnung und keinen Fehler. Drei Dinge schalten es klammheimlich ab:

Die Datei ist nicht makrofähig. VBA überlebt nur in .xlsm oder .xlsb. Speichern Sie eine Arbeitsmappe mit Code als einfache .xlsx, entfernt Excel jedes Makro — auch Workbook_Open — mit nur einer beiläufigen Nachfrage. Das Ereignis ist schlicht verschwunden.
Makros sind durch die Sicherheit deaktiviert. Öffnet der Benutzer die Datei und belässt sie in der geschützten Ansicht oder klickt am Banner „Inhalt aktivieren“ vorbei, ohne zu aktivieren, laufen keine Makros, also feuert das Ereignis nicht.
Ereignisse sind auf Anwendungsebene abgeschaltet. Hat früherer Code Application.EnableEvents = False gesetzt und nie zurückgesetzt, bleiben Workbook- und Worksheet-Ereignisse für die gesamte Sitzung unterdrückt.

Die Design-Lektion ist wichtig: Lassen Sie die Korrektheit von Daten niemals allein von Workbook_Open abhängen. Für Komfort ist es perfekt — zu einem Blatt springen, eine Ansicht aktualisieren —, aber wenn ein Benutzer die Datei mit abgeschalteten Makros öffnet, lief Ihr „läuft immer“-Code eben nicht. Behandeln Sie es als angenehme Zugabe, die das Erlebnis verbessert, nicht als Garantie. (Wenn Ihr Ziel nur ist, Benutzer am Sicherheitsbanner vorbeizubringen, siehe Makros in Excel aktivieren.)

Workbook_Open gegenüber Auto_Open: Nutzen Sie das Ereignis, nicht das Relikt

Sie werden zwei Wege sehen, um Code beim Öffnen auszuführen, und sie sind nicht dasselbe:

Auto_Open ist der veraltete Mechanismus (aus der Ära von Excel 5/95). Es ist eine schlichte Sub Auto_Open(), die in einem gewöhnlichen Module liegt. Aus Gründen der Abwärtskompatibilität funktioniert es noch, aber es ist ein Relikt.
Workbook_Open ist das moderne Ereignis, das in ThisWorkbook liegt.

Sie unterscheiden sich auf Weisen, die schmerzen:

	`Workbook_Open` (Ereignis)	`Auto_Open` (veraltet)
Wo es liegt	`ThisWorkbook`	ein gewöhnliches `Module`
Feuert bei `Workbooks.Open` (per Code geöffnet)	Ja	Nein (braucht `.RunAutoMacros`)
Wenn beide existieren	läuft zuerst	läuft danach
Status	aktuell, empfohlen	nur Abwärtskompatibilität

Das Merkenswerte: Öffnet ein anderes Makro Ihre Datei mit Workbooks.Open "Report.xlsm", feuert Workbook_Open, Auto_Open jedoch nicht (es sei denn, Sie rufen ausdrücklich wb.RunAutoMacros xlAutoOpen auf). Allein dieser Unterschied ist der Grund, warum automatisierte Pipelines an Auto_Open scheitern. Schreiben Sie Workbook_Open; greifen Sie zu Auto_Open nur, um sehr alte Dateien zu pflegen.

Die Regel, die verhindert, dass es jedes Öffnen ruiniert: schnell und absturzsicher sein

Workbook_Open läuft, bevor der Benutzer irgendetwas tun kann — also erlebt der Benutzer alles, was es tut, als „wie lange die Datei zum Öffnen braucht“ und „ob die Datei überhaupt sauber öffnet“. Zwei Gewohnheiten halten es zivilisiert:

Private Sub Workbook_Open()
    On Error GoTo Fail                 ' das Öffnen soll nie beim Benutzer abstürzen
    Application.ScreenUpdating = False

    Worksheets("Dashboard").Activate
    Range("A1").Select

    Application.ScreenUpdating = True
    Exit Sub
Fail:
    Application.ScreenUpdating = True   ' den Zustand immer wiederherstellen, auch bei Fehler
    MsgBox "Startup skipped: " & Err.Description, vbExclamation
End Sub

Umschließen Sie es immer mit Fehlerbehandlung. Ein unbehandelter Fehler hier wirft dem Benutzer im Moment des Öffnens einen rohen VBA-Fehler ins Gesicht und kann Einstellungen wie ScreenUpdating oder EnableEvents abgeschaltet zurücklassen. Stellen Sie den Zustand im Handler wieder her. (Das ist dieselbe Disziplin, die in VBA On Error behandelt wird.)
Halten Sie schwere Arbeit heraus oder machen Sie sie sichtbar. Eine langsame Abfrage oder eine große Schleife in Workbook_Open sieht genauso aus wie eine eingefrorene Datei. Ist die Arbeit unvermeidlich, zeigen Sie eine Statusmeldung oder verlagern Sie sie hinter eine Schaltfläche, die der Benutzer bewusst drückt.

Workbook_Open gehört zu einer ganzen Familie von Workbook-Ereignissen — Workbook_BeforeClose, Workbook_BeforeSave, Workbook_SheetChange —, die alle in ThisWorkbook liegen. Seine Vettern auf Blattebene reagieren auf das, was innerhalb eines Blatts geschieht: Worksheet_Change, wenn eine Zelle bearbeitet wird, und Worksheet_SelectionChange, wenn sich der Cursor bewegt.

Wie ExcelMaster hilft

Workbook_Open einzurichten ist ein kleines Ritual mit scharfen Kanten: richtiges Objekt, exakter Name, makrofähige Datei, Fehlerbehandlung, das Öffnen nicht aufhängen. Machen Sie eines davon falsch, ist das Symptom stets dasselbe wenig hilfreiche „nichts ist passiert“.

ExcelMaster lässt Sie stattdessen das Ergebnis beschreiben. Sagen Sie „springe jedes Mal, wenn diese Datei geöffnet wird, zum Blatt Dashboard und aktualisiere die Pivot-Tabelle“, und es schreibt den Handler, legt ihn in ThisWorkbook ab und umschließt ihn so, dass ein Fehler das Öffnen nicht zum Absturz bringt. Die Datei gehört weiterhin Ihnen, und Sie können jede Zeile lesen — Sie überspringen aber den Teil, in dem ein Makro stillschweigend die Ausführung verweigert, weil es in Module1 gelandet ist.

Häufig gestellte Fragen

Wohin gehört Workbook_Open-Code in Excel?

In das ThisWorkbook-Objekt, nicht in ein gewöhnliches Modul. Öffnen Sie den VBA-Editor (Alt+F11), suchen Sie ThisWorkbook unter „Microsoft Excel Objekte“ Ihres Projekts, doppelklicken Sie darauf und legen Sie dort Private Sub Workbook_Open() ab. Eine Workbook_Open-Sub in Module1 sieht identisch aus, feuert aber nie, weil Excel das Ereignis nur im eigenen Codemodul der Arbeitsmappe sucht.

Warum läuft mein Workbook_Open-Makro nicht?

Fast immer eines von drei Dingen: Der Code liegt in einem Module statt in ThisWorkbook; die Datei wurde als .xlsx gespeichert (was alle Makros entfernt) statt als .xlsm; oder der Benutzer hat sie mit deaktivierten Makros geöffnet und nicht auf „Inhalt aktivieren“ geklickt. Prüfen Sie zuerst den Ort — das ist die häufigste Ursache. Stellen Sie außerdem sicher, dass kein früherer Code Application.EnableEvents = False hinterlassen hat.

Was ist der Unterschied zwischen Workbook_Open und Auto_Open?

Workbook_Open ist das moderne Ereignis, das in ThisWorkbook liegt. Auto_Open ist das veraltete Makro, das in einem gewöhnlichen Modul liegt. Der entscheidende praktische Unterschied: Workbook_Open feuert, wenn die Datei von einem anderen Makro geöffnet wird (Workbooks.Open), Auto_Open jedoch nicht, es sei denn, Sie rufen RunAutoMacros auf. Verwenden Sie Workbook_Open; behalten Sie Auto_Open nur zur Pflege alter Dateien.

Läuft Workbook_Open, wenn ein Makro die Datei öffnet?

Ja. Wenn Code Workbooks.Open "Report.xlsm" ausführt, feuert das Workbook_Open dieser Arbeitsmappe ganz normal. Müssen Sie es gezielt unterdrücken — etwa in einem automatisierten Stapelverarbeitungsjob —, setzen Sie Application.EnableEvents = False vor dem Workbooks.Open-Aufruf und danach wieder auf True.

Wie öffne ich eine Arbeitsmappe, ohne Workbook_Open auszuführen?

Halten Sie die Umschalttaste gedrückt, während die Datei öffnet, um Workbook_Open für dieses eine Öffnen zu überspringen. Per Code setzen Sie Application.EnableEvents = False vor Workbooks.Open und danach wieder auf True. Beides ist nützlich, wenn ein Start-Makro sich danebenbenimmt und Sie in die Datei gelangen müssen, um es zu reparieren.

Getestet in

Getestet in: Excel 365 (Windows 11), VBA 7.1 — zuletzt geprüft am 02.08.2026.