VBA CStr, CDate & Val in Excel — Text richtig in Zahlen und Datum umwandeln

Getestet mit: Excel 365 v2509 · Excel 2021 · Excel 2019 · zuletzt geprüft am 10.06.2026

Kurzfassung — CStr, CDate, Val, CLng und CDbl sind die Umwandlungs-Funktionen: Sie ändern den Typ eines Werts — Text in eine echte Zahl, Text in ein echtes Datum, eine Zahl in Text. Das ist das Gegenteil von Format, das nur ändert, wie ein Wert aussieht. Verstehst du den Unterschied, stoppst du die größte einzelne Quelle stiller VBA-Datenbugs.

Sub ConvertDemo()
    Debug.Print CStr(1234.5)            ' "1234.5"        Zahl    -> Text
    Debug.Print CDbl("1234.5") * 2      ' 2469            Text    -> Zahl, dann echte Rechnung
    Debug.Print CLng("42")              ' 42              Text    -> Long-Ganzzahl
    Debug.Print CDate("2026-04-01")     ' ein echtes Datum, das man sortieren und subtrahieren kann
    Debug.Print Val("12px")             ' 12              liest Ziffern, stoppt beim ersten Nicht-Ziffer-Zeichen
End Sub

Das Denkmodell: Umwandlung ändert, was ein Wert IST

Ein Bereinigungs-Rundgang durch diesen Cluster: Trim macht Daten sauber, Format lässt sie richtig aussehen, und die C…-Funktionen machen sie zum richtigen Typ. Das sind drei verschiedene Aufgaben, und die Todsünde ist, die letzten beiden zu verwechseln.

Eine Zelle, die 2026-04-01 anzeigt, kann ein echtes Datum sein (sortierbar, subtrahierbar, nach Monat filterbar) oder nur Text, der so aussieht. Format erzeugt die zweite Sorte; CDate die erste. Wenn deine Daten nicht sortieren oder deine „Zahlen" nicht summieren, hast du fast immer Text, wo du einen echten typisierten Wert brauchtest — und der Fix ist eine Umwandlung, kein weiteres Formatieren. Nimm CDate/CDbl/CLng, um Text in das zu verwandeln, was er vorgibt zu sein, und CStr, um bewusst in die andere Richtung zu gehen.

Die eine Regel: CDate liest mehrdeutige Daten nach dem Gebietsschema des Rechners

Das ist die Regel, die in einem Team stillschweigend Daten zerstört:

CDate zerlegt eine Datumszeichenkette anhand der Regionseinstellungen des PCs, auf dem es läuft. CDate("01/02/2026") ist auf einem US-Rechner der 2. Januar und auf einem europäischen der 1. Februar. Gleiche Mappe, gleicher Code, andere Daten — und nichts gibt einen Fehler.

Es gibt keine Warnung, denn beide Lesarten sind gültige Daten. Der Bug zeigt sich erst, wenn die Datei zu einer Kollegin mit anderen Einstellungen wandert oder auf einem für eine andere Region konfigurierten Server läuft — und bis dahin sind die falschen Daten in einem Monat voller Berichte eingebrannt.

' ⚠ GEFAHR — das Ergebnis hängt davon ab, wessen PC es ausführt
d = CDate("01/02/2026")          ' 2. Jan in den USA, 1. Feb in den meisten Teilen Europas

' ✓ SICHER — baue das Datum aus seinen Teilen, gebietsschema-unabhängig
d = DateSerial(2026, 2, 1)       ' immer der 1. Februar, auf jedem Rechner

Der Fix ist, CDate gar keine mehrdeutigen Zeichenketten mehr zu geben. Hast du die Quelle im Griff, zerlege die Teile und baue das Datum mit DateSerial(Jahr, Monat, Tag) — es nimmt drei Zahlen und kann nicht falsch gelesen werden. Musst du "01/02/2026" akzeptieren, Split es an "/" und entscheide die Reihenfolge selbst, statt sie dem Gebietsschema zu überlassen. Behandle CDate nur bei eindeutigen Formaten wie ISO "2026-04-01" als sicher.

Die zweite Falle: Val ist gebietsschema-blind, CDbl ist es nicht

Beide machen aus Text eine Zahl, aber sie sind sich beim Dezimaltrennzeichen uneinig, und diese Uneinigkeit frisst deutsche Daten:

• Val behandelt . immer als Dezimalpunkt und , als Stopper. Es ignoriert Leerzeichen und liest von links nach rechts, bis etwas Nicht-Numerisches kommt. Val("12px") → 12. Val("1,234.5") → 1 (das Komma stoppt es).
• CDbl achtet auf das Gebietsschema. Auf einem Rechner, auf dem das Komma das Dezimaltrennzeichen ist, ist CDbl("3,14") → 3,14.

Dieselbe Zeichenkette kippt also je nach Wahl die Bedeutung:

' Nutzer an einem deutschen PC tippt "3,14" und meint drei Komma eins vier
Debug.Print Val("3,14")     ' 3      <- das Komma stoppt; ",14" wird stillschweigend verworfen
Debug.Print CDbl("3,14")    ' 3,14   <- gebietsschema-bewusst, der gemeinte Wert

Die Regel, die dich schützt: Val für feste, englischformatierte Zeichenketten, die du kontrollierst ("12px" auf 12 reduzieren, eine selbst exportierte CSV mit .-Dezimal lesen); CDbl/CLng für alles, was ein Nutzer getippt hat oder aus einer lokalisierten Quelle kam. Sie zu mischen ist, wie eine Spalte deutscher Preise stillschweigend ihre Nachkommastellen verliert.

Die dritte Falle: CLng rundet, und nicht so, wie du denkst

CLng und CInt schneiden nicht ab — sie runden, mit dem kaufmännischen Runden (Hälfte zur geraden Zahl):

Debug.Print CLng(2.5)       ' 2   <- rundet zur GERADEN Zahl, nicht auf
Debug.Print CLng(3.5)       ' 4
Debug.Print Int(2.7)        ' 2   <- Int/Fix schneiden stattdessen ab

Willst du „immer kaufmännisch aufrunden" oder „die Nachkommastellen abschneiden", ist CLng das falsche Werkzeug — nimm Int, Fix oder WorksheetFunction.Round. Und denk daran: CInt läuft über 32.767 über; nimm CLng für alles, was eine reale Anzahl sein könnte.

Noch eins auf der Textseite: CStr(123) gibt "123", aber das ältere Str(123) gibt " 123" mit einem führenden Leerzeichen, das fürs Vorzeichen reserviert ist — und Str nutzt immer ., egal welches Gebietsschema. Für sauberes Zahl-zu-Text schlägt CStr (oder Format, wenn du ein bestimmtes Aussehen willst) Str jedes Mal.

Wann was

Die Meinung: lass nie das Gebietsschema über deine Daten entscheiden

Hier die Linie: implizite Umwandlung und CDate auf mehrdeutigen Zeichenketten sind Zeitbomben, keine Bequemlichkeiten. Der Code, der someDate = rng.Value oder CDate(textZelle) macht und auf deinem Rechner „einfach funktioniert", ist derselbe Code, der auf dem Server stillschweigend Februar statt Januar erzeugt. Er besteht jeden Test, den du fährst, weil du sie auf deinem PC fährst.

Also wandle bewusst und eindeutig um. Baue Daten mit DateSerial. Zerlege Nutzerzahlen mit CDbl, feste Zeichenketten mit Val, und wisse, welche du in der Hand hast. Kommt eine ganze Spalte als „als Text gespeicherte Zahlen" an, ist der echte Fix kein Formatierungsdurchgang — es ist eine Umwandlung an der Importgrenze, einmal, mit festgenageltem Gebietsschema. Verbrannt werden die Teams, die der impliziten Lesart vertrauten; die anderen sind die, die das Format selbst bestimmten.

Häufige Umwandlungsfehler (und die Lösung)

Wenn sich die Umwandlungen häufen — beschreibe die gewünschten Daten

Du wolltest keinen Rundgang durch CDate gegen DateSerial. Du wolltest „lies diesen Export, in dem die Daten tt/mm sind und die Beträge Kommas nutzen, und lade ihn korrekt in mein Modell". Bis du IsDate abgesichert, das Gebietsschema festgenagelt, CDbl über Val gewählt und die mehrdeutigen Daten neu gebaut hast, ist die Umwandlungs-Mechanik das Makro. ExcelMaster Agent lässt dich stattdessen die Daten beschreiben — „die Daten in Spalte A sind tagweise zuerst, die Beträge in B nutzen ein Komma als Dezimaltrennzeichen; wandle sie in echte Daten und Zahlen um" — und schreibt Python, das sie eindeutig zerlegt und vorher deine Arbeitsmappe sichert. Kostenlos testen →

Verwandte Anleitungen

• VBA Trim — warum es deine Leerzeichen nicht entfernt (und der Chr(160)-Fix)
• VBA Format — Datum, Zahlen & warum Formatieren deine Rechnung kaputtmacht
• VBA InStr — Text in einer Zeichenkette finden
• VBA Split — eine Zeichenkette in ein Array verwandeln
• VBA For-Schleife in Excel — 8 praxisnahe Beispiele

FAQ

Wie wandle ich in VBA eine Zeichenkette in eine Zahl um? Nimm CDbl oder CLng für Eingaben von Nutzern oder aus lokalisierten Quellen, denn sie achten auf das regionale Dezimaltrennzeichen: CDbl("3,14") ist 3,14 auf einem Komma-Dezimal-Rechner. Nimm Val nur für feste, englischformatierte Zeichenketten, die du kontrollierst, da Val immer . als Dezimalpunkt behandelt und beim ersten Nicht-Ziffer-Zeichen stoppt.

Was ist der Unterschied zwischen CStr und Str in VBA? CStr wandelt eine Zahl sauber in Text um und folgt dem Gebietsschema; Str reserviert ein führendes Leerzeichen fürs Vorzeichen (Str(123) ist " 123") und nutzt immer . als Dezimalpunkt, egal welche Region. Bevorzuge CStr für Zahl-zu-Text.

Warum liefert CDate in VBA das falsche Datum? Weil CDate mehrdeutige Zeichenketten wie "01/02/2026" anhand der Regionseinstellungen des Rechners zerlegt — 2. Jan in den USA, 1. Feb in weiten Teilen Europas. Baue Daten mit DateSerial(2026, 2, 1) aus Teilen, um sie gebietsschema-unabhängig zu machen, und reserviere CDate für eindeutige Formate wie ISO "2026-04-01".

Rundet oder schneidet CLng in VBA ab? CLng (und CInt) runden, mit kaufmännischem Runden — CLng(2.5) ist 2, CLng(3.5) ist 4. Um stattdessen abzuschneiden, nimm Int oder Fix; um kaufmännisch aufzurunden, WorksheetFunction.Round. Beachte: CInt läuft über 32.767 über, also nimm CLng für größere Werte.

Wie vermeide ich „Typen unverträglich" beim Umwandeln in VBA? Prüfe zuerst die Eingabe: If IsNumeric(s) Then n = CDbl(s) und If IsDate(s) Then d = CDate(s). Diese Prüfungen verhindern, dass eine versehentlich nicht-numerische oder ungültige Datumszeichenkette mitten in der Schleife einen Laufzeitfehler auslöst.