VBA WorksheetFunction in Excel — Excels eigene Funktionen aus Code aufrufen (und die zwei Arten, wie sie fehlschlagen)

Kurz gesagt — Application.WorksheetFunction ist der Weg, über den VBA Excels über 450 eingebaute Funktionen erreicht, sodass Sie SUM, VLOOKUP oder COUNTIF nie als handgestrickte Schleife nachbauen. Es gibt zwei Arten, eine davon aufzurufen, und der Unterschied ist alles. Application.WorksheetFunction.VLookup(...) löst einen Laufzeitfehler aus, sobald es keinen Treffer gibt — nehmen Sie es, wenn Erfolg erwartet wird und ein Fehltreffer laut sein soll. Application.VLookup(...) (ohne das .WorksheetFunction) gibt einen Fehlerwert zurück, den Sie mit IsError prüfen — nehmen Sie es, wenn ein Fehltreffer normal ist. Und die Variable, die ein Application.X-Ergebnis auffängt, muss ein Variant sein, sonst stürzt sie mit Fehler 13 ab, bevor Sie überhaupt prüfen können.

' Wie oft kommt "West" in Spalte B vor? Eine Zeile, keine Schleife.
Dim ws As Worksheet: Set ws = ThisWorkbook.Worksheets("Sales")
Dim n As Long
n = Application.WorksheetFunction.CountIf(ws.Columns("B"), "West")
MsgBox "West appears " & n & " times"

Zu einer For Each-Schleife zu greifen, um eine Spalte zu summieren oder einen Wert nachzuschlagen, ist der häufigste Weg, auf dem VBA gleichzeitig langsam und fehlerhaft wird. Excel bringt bereits eine Rechen-Engine mit — Hunderte optimierte Funktionen —, und WorksheetFunction ist die Tür dorthin. Die Kunst ist nicht, mehr Code zu schreiben; sie besteht darin zu erkennen, wann Excel die Funktion schon hat, und sie aufzurufen. Diese Anleitung dreht sich um die eine Tatsache, über die jeder stolpert: es gibt zwei Aufrufstile, und sie schlagen auf entgegengesetzte Weise fehl.

Was Sie lernen

• Das mentale Modell — Excels Engine ausleihen, sie nicht in einer Schleife nachbauen
• Die wichtigste Regel — WorksheetFunction.X stürzt bei Misserfolg ab, Application.X liefert einen prüfbaren Fehler
• Die Typ-Falle — warum die Ergebnisvariable ein Variant sein muss
• Welche Funktionen Sie aufrufen können, welche nicht, und die, die Sie nicht aufrufen sollten
• Einen ganzen Bereich übergeben, statt Zelle für Zelle zu schleifen
• WorksheetFunction gegenüber dem Schreiben einer Formel in eine Zelle

Das mentale Modell: die Engine ausleihen, nicht neu bauen

Jede Tabellenfunktion, die Sie kennen — SUM, AVERAGE, VLOOKUP, MATCH, COUNTIF, SUMIF, MAX, TRIM, PROPER —, ist aus VBA über Application.WorksheetFunction erreichbar. Sie rufen keine VBA-Kopie der Funktion auf; Sie rufen dieselbe Engine auf, die das Blatt nutzt, sodass das Ergebnis exakt der Formel entspricht.

Das ist wichtig, weil die Alternative fast immer schlechter ist. Eine For Each-Schleife, die eine Spalte summiert, Treffer zählt oder nach einem Nachschlagewert sucht, ist länger zu schreiben, langsamer im Lauf und leichter falsch zu machen als die eine Funktion, die Excel bereits optimiert hat. WorksheetFunction.Sum(ws.Range("B2:B100000")) liefert in einem Durchgang; das Schleifenäquivalent quält sich durch 100.000 Iterationen interpretierten VBAs. Behalten Sie dieses Bild im Kopf — Excel hat die Funktion, ich muss sie nur aufrufen — und die meisten Fragen der Art „Wie berechne ich X in VBA?“ beantworten sich von selbst.

Die wichtigste Regel: zwei Aufrufstile, zwei Fehlerarten

Das ist die eine Sache, die Sie mitnehmen sollten. Dieselbe Funktion lässt sich auf zwei Arten aufrufen, und sie verhalten sich völlig unterschiedlich, wenn der Vorgang fehlschlägt — etwa, wenn ein Nachschlagen nichts findet.

' Stil 1: WorksheetFunction.X - STUERZT ab, wenn es keinen Treffer gibt.
Dim price As Double
price = Application.WorksheetFunction.VLookup("Widget", ws.Range("A:C"), 3, False)
' Ist "Widget" nicht da: Laufzeitfehler 1004, und die Ausfuehrung stoppt.

' Stil 2: Application.X (ohne .WorksheetFunction) - GIBT einen pruefbaren Fehler zurueck.
Dim result As Variant
result = Application.VLookup("Widget", ws.Range("A:C"), 3, False)
If IsError(result) Then
    MsgBox "Widget not found"      ' sauber behandelt, kein Absturz
Else
    MsgBox "Price is " & result
End If

Dieselbe Funktion, dieselben Argumente — doch WorksheetFunction.VLookup wirft bei fehlendem Treffer, während Application.VLookup einen #N/A-Fehlerwert zurückgibt, den IsError abfängt. Keiner ist „richtig“; sie dienen unterschiedlichen Absichten:

• Nehmen Sie WorksheetFunction.X, wenn Sie erwarten, dass der Vorgang gelingt, und ein Fehlschlag bedeutet, dass wirklich etwas nicht stimmt. Der Absturz ist ein Feature — er stoppt das Makro, statt einen falschen Wert weiter nach unten fließen zu lassen.
• Nehmen Sie Application.X, wenn ein Fehltreffer ein normales Ergebnis ist, das Sie behandeln wollen — ein Nachschlagen, das seinen Schlüssel finden kann oder auch nicht, ein meistens vorhandener Wert. Sie prüfen IsError und verzweigen.

Der Bug Nummer eins bei diesem ganzen Thema ist, WorksheetFunction.Match zu nutzen, um zu prüfen, ob etwas existiert, und dann von Fehler 1004 überrascht zu werden, wenn es nicht existiert. Existenzprüfungen sind genau der Fall für Application.Match + IsError.

Die Typ-Falle: das Ergebnis muss ein Variant sein

Stil 2 funktioniert nur, wenn die Variable, die das Ergebnis aufnimmt, einen Fehlerwert halten kann. In VBA kann das nur ein Variant. Deklarieren Sie sie enger, und schon die Zuweisung selbst fliegt Ihnen um die Ohren:

Dim result As Double
result = Application.VLookup("Widget", ws.Range("A:C"), 3, False)
' Nicht gefunden: Fehler 13 "Typen unvertraeglich" - ein Double kann #N/A nicht halten

Die Lösung ist schlicht Dim result As Variant. Dann lässt sich IsError(result) gefahrlos aufrufen, und bei Erfolg nutzen Sie den Wert wie gewohnt. Das ist die stille zweite Hälfte des Musters „gibt einen Fehler zurück“: Application.X-Ergebnisse gehen in einen Variant, immer. Vergessen Sie es, und die Typunverträglichkeit verdeckt genau die Fehlerbehandlung, die Sie aufbauen wollten.

Welche Funktionen Sie aufrufen können — und die, die Sie nicht sollten

Der Großteil der Bibliothek ist verfügbar, doch drei Ränder lohnen sich zu kennen:

• Nicht alles ist verfügbar gemacht. Eine Handvoll neuerer oder volatiler Funktionen taucht auf WorksheetFunction nicht auf. Fehlt ein Name, können Sie meist auf Application.Evaluate ausweichen oder die Formel in eine Zelle schreiben (siehe unten).
• Manche Funktionen hat VBA bereits nativ — nehmen Sie diese stattdessen. Rufen Sie nicht WorksheetFunction.Left, Mid, Right, Trim, Upper oder Lower auf. VBA hat sein eigenes Left, Mid, Right, Trim, UCase, LCase, die schneller sind und keinen Umweg über Excel nehmen. (Eine Feinheit: VBA Trim entfernt nur führende und nachgestellte Leerzeichen, während WorksheetFunction.Trim auch innere Doppelleerzeichen zusammenzieht — sie sind also nicht identisch, und gelegentlich wollen Sie die Tabellenversion.)
• Namen weichen manchmal ab. Der VBA-Elementname passt meist zur Funktion, aber ein paar tragen Excels ältere interne Schreibweise. Im Zweifel tippen Sie Application.WorksheetFunction. und lassen IntelliSense auflisten, was wirklich da ist.

Die Faustregel: Greifen Sie zu WorksheetFunction für die schweren analytischen Funktionen, in denen Excel gut ist — Nachschlagen, bedingte Zählungen und Summen, Statistik —, und nutzen Sie VBAs eigene Schlüsselwörter für einfache String- und Rechenarbeit.

Übergeben Sie einen ganzen Bereich, schleifen Sie nicht Zelle für Zelle

Der größte Geschwindigkeitsgewinn ist zugleich der am leichtesten zu übersehende. WorksheetFunction-Funktionen nehmen Bereiche, geben Sie ihnen also den ganzen Bereich einmal, statt zu schleifen und pro Zelle aufzurufen:

' LANGSAM - ruft die Engine einmal pro Zeile auf.
Dim i As Long, total As Double
For i = 2 To lastRow
    total = total + ws.Cells(i, "B").Value
Next i

' SCHNELL - ein Aufruf, die Engine schleift intern.
total = Application.WorksheetFunction.Sum(ws.Range("B2:B" & lastRow))

Die schnelle Fassung ist nicht nur kürzer; sie schiebt die Iteration hinab in Excels kompilierte Engine, statt sie in interpretiertem VBA laufen zu lassen. Dasselbe gilt für CountIf, SumIf, Average, Max, Min — geben Sie ihnen den Bereich und lassen Sie sie zählen. Wenn Sie sich dabei ertappen, eine Summe in einer Schleife aufzuaddieren, wartet dort fast immer eine Tabellenfunktion darauf, aufgerufen zu werden.

WorksheetFunction gegenüber einer Formel in einer Zelle

Es gibt eine dritte Möglichkeit, und zu wissen, wann man ihr den Vorzug gibt, hält Ihren Code ehrlich. WorksheetFunction berechnet einen Wert einmal, im Code — das Blatt ändert sich nie, und die Antwort rechnet sich nicht neu, wenn es die Daten tun. Eine Formel als Zeichenkette in eine Zelle zu schreiben (ws.Range("D2").Formula = "=SUM(B2:B100)") hinterlässt eine lebendige Formel, die sich für immer aktualisiert.

Nehmen Sie WorksheetFunction, wenn Sie eine Zahl jetzt brauchen, innerhalb Ihrer Logik — eine Schwelle zum Vergleichen, eine Zählung zum Verzweigen, eine Summe, die Sie in einen Bericht stempeln. Schreiben Sie eine Formel in die Zelle, wenn der Nutzer ein Ergebnis sehen soll, das beim Bearbeiten korrekt bleibt. Zu WorksheetFunction zu greifen und dann seine statische Antwort dort einzufügen, wo eine Formel hingehört hätte, ist ein verbreiteter Weg, auf dem Berichte klammheimlich veralten.

Wie ExcelMaster hilft

WorksheetFunction packt überraschend viel Entscheidung in einen einzigen Aufruf: welchen der zwei Stile man nimmt, ob das Ergebnis einen Variant braucht, ob ein natives VBA-Schlüsselwort besser wäre und ob der Wert einmal berechnet oder als lebendige Formel belassen werden soll. Jede dieser Entscheidungen hat eine Fehlerart, die eine falsche Antwort liefert — oder bei Daten abstürzt, die Sie nicht getestet haben.

ExcelMaster lässt Sie stattdessen die Berechnung beschreiben. Sagen Sie „zähle, wie viele Bestellungen aus der Region West stammen“ oder „schlage den Preis jedes Produkts nach und markiere die, die wir nicht führen“, und es wählt den richtigen Aufrufstil — den abstürzenden, wo ein Fehltreffer ein echter Fehler ist, den prüfbaren, wo ein Fehltreffer erwartet wird —, deklariert das Ergebnis als Variant, wo es muss, und übergibt ganze Bereiche, statt zu schleifen. Sie behalten die Arbeitsmappe und den Code; Sie sparen sich den Teil, in dem ein unbehandelter Fehler 1004 ein Makro mitten im Bericht stoppt.

Häufig gestellte Fragen

Was ist der Unterschied zwischen WorksheetFunction und Application in VBA?

Beide rufen dieselbe Excel-Funktion auf, doch sie schlagen unterschiedlich fehl. Application.WorksheetFunction.X löst einen Laufzeitfehler aus (meist 1004), wenn die Funktion kein Ergebnis liefern kann, etwa bei einem Nachschlagen ohne Treffer. Application.X — ohne .WorksheetFunction — gibt stattdessen einen Excel-Fehlerwert wie #N/A zurück, den Sie mit IsError prüfen. Nehmen Sie das erste, wenn ein Fehlschlag das Makro stoppen soll, das zweite, wenn ein Fehltreffer ein normal zu behandelnder Fall ist.

Warum gibt WorksheetFunction.VLookup den Fehler 1004 aus?

Weil WorksheetFunction.VLookup einen Laufzeitfehler wirft, wenn der Wert nicht gefunden wird, statt #N/A zurückzugeben. Fehler 1004 bedeutet dort fast immer „kein Treffer“, nicht eine kaputte Formel. Erwarten Sie, dass manche Nachschlagevorgänge danebengehen, rufen Sie Application.VLookup in einen Variant und prüfen IsError(result), oder umschließen Sie den WorksheetFunction-Aufruf mit On Error-Behandlung.

Warum bekomme ich eine Typunverträglichkeit (Fehler 13) mit Application.VLookup?

Weil Application.VLookup einen Fehlerwert zurückgeben kann, und nur ein Variant einen solchen halten kann. Die aufnehmende Variable als Double, Long oder String zu deklarieren löst Fehler 13 in dem Moment aus, in dem das Ergebnis #N/A ist. Deklarieren Sie sie As Variant und rufen dann IsError auf, bevor Sie den Wert nutzen.

Kann ich über WorksheetFunction jede Excel-Funktion in VBA nutzen?

Die meisten, aber nicht alle. Die gängigen analytischen Funktionen — VLOOKUP, MATCH, COUNTIF, SUMIF, SUM, AVERAGE, Statistik — sind alle da. Ein paar neuere oder volatile Funktionen sind nicht verfügbar gemacht; für die nehmen Sie Application.Evaluate oder schreiben die Formel in eine Zelle. Und für einfachen Text und Rechnen bevorzugen Sie VBAs eigene Left, Mid, Trim, UCase und Operatoren gegenüber den Tabellenversionen.

Ist WorksheetFunction.Sum schneller als eine Schleife in VBA?

Ja, spürbar, bei großen Bereichen. Den ganzen Bereich an WorksheetFunction.Sum zu übergeben führt die Iteration in einem Aufruf innerhalb von Excels kompilierter Engine aus, während eine For Each- oder For-Schleife sie in interpretiertem VBA Zelle für Zelle abarbeitet. Immer wenn Sie eine Summe oder Zählung in einer Schleife aufaddieren, ist eine auf den ganzen Bereich aufgerufene Tabellenfunktion meist zugleich kürzer und schneller.

Getestet in

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

Verwandte Anleitungen: VBA VLOOKUP · VBA Remove Duplicates · VBA Advanced Filter · VBA For-Schleife · VBA Range