Power BI Spalte nicht gefunden: So löst du den Fehler in Power Query

Definition

„Power BI Spalte nicht gefunden“ ist eine Power-Query-Fehlermeldung, die entsteht, wenn ein Transformationsschritt auf eine Spalte referenziert, die in diesem Abfragezustand nicht existiert. Es handelt sich nicht um ein Visualisierungs- oder DAX-Problem, sondern um ein Schema- bzw. Spaltenproblem in Power Query und im M (M-Code).

Einleitung

Wenn Power Query eine Spalte nicht findet, kippt oft die ganze Aktualisierung: Dataset-Refresh schlägt fehl, Dashboards sind „rot“ und jemand muss manuell nachfassen. Das passiert besonders häufig bei Excel-Dateien, die monatlich neu kommen, oder wenn Quellsysteme Felder umbenennen. Mit einem sauberen Debug-Pfad und ein paar robusten M-Code-Mustern bekommst du das stabil in den Griff.

Warum Power Query die Spalte „nicht findet“

Fast immer ist die Spalte nicht „magisch verschwunden“, sondern mindestens eines davon ist passiert: Die Spaltenüberschrift wurde geändert (auch minimale Unterschiede zählen), die Spalte wurde entfernt, oder ein früherer Schritt hat sie umbenannt. Typisch sind auch unsichtbare Leerzeichen, unterschiedliche Groß-/Kleinschreibung oder Spalten, die nur in manchen Dateien vorhanden sind.

Besonders fragil sind Schritte, die hart Spaltennamen ansprechen: Umbenennen, Entfernen von Spalten, Zusammenführen/Erweitern von Tabellen und „Geänderter Typ“. Sobald die Quelle das Schema ändert, passt der feste Spaltenverweis nicht mehr.

Fehler schnell eingrenzen: Debug in 4 Schritten

Power Query zeigt dir ziemlich genau, wo es knallt. Der schnellste Weg ist immer: erst lokalisieren, dann reparieren.

• Zum ersten roten Schritt in „Angewendete Schritte“ springen und die Vorschau prüfen.
• Einen Schritt zurückgehen: Ist die Spalte dort noch da? Wenn ja, zerstört der rote Schritt das Schema.
• In der Quelle prüfen (z. B. Excel): heißt die Spalte wirklich identisch, inkl. Leerzeichen?

Wenn du unsicher bist, öffne „Erweiterter Editor“ und suche im M (M-Code) nach dem Spaltennamen. Ein fester Text wie

"Umsatz"

Schritt-für-Schritt: typische Reparaturen (konkret)

1) „Geänderter Typ“ entschärfen

Der Auto-Schritt „Geänderter Typ“ referenziert oft Spalten, die später fehlen. Löschen ist erlaubt, aber besser ist: Typisierung erst nach stabiler Spaltenauswahl setzen und nur für Spalten, die wirklich immer da sind.

2) Spaltenauswahl robust machen

Wenn sich die Quelle ändert, ist „Spalten entfernen“ riskant. Stabiler ist eine bewusste „Spalten auswählen“-Logik: Nur die benötigten Spalten weitergeben und fehlende Spalten tolerieren (damit der Refresh nicht abbricht, sondern z. B. leere Werte liefert).

3) Überschriften normalisieren

Bei Excel ist der Klassiker: „Kostenstelle “ (mit Leerzeichen) statt „Kostenstelle“. Eine einfache Normalisierung hilft: Überschriften trimmen/vereinheitlichen, bevor du umbenennst oder typisierst. Nutzen: weniger „kleine“ Überschriften-Änderungen, die sonst alles stoppen.

Dynamische, robuste Ansätze (wenn sich Spalten wirklich ändern)

Wenn du mit Dateien arbeitest, deren Spaltenüberschriften sich fachlich verändern dürfen, brauchst du ein Muster, das diese Variation einkalkuliert. Drei pragmatische Optionen:

• Gezielt entpivotieren: Nicht „alle Spalten“, sondern nur ein definierter Satz an Wertspalten. Der Rest bleibt unangetastet.
• Mapping-Tabelle: Eine kleine Zuordnung (Alter Name → Neuer Name) als separate Tabelle, die du in Power Query anwendest. Damit musst du nicht jeden Monat im Query rumklicken.
• Optional Columns: Schritte so bauen, dass fehlende Spalten nicht zum Abbruch führen, sondern mit Default/Null weiterlaufen.

Der Nutzen ist simpel: weniger operative Ausfälle und weniger manuelle Nacharbeit in Teams, die eigentlich Reports konsumieren wollen statt Abfragen zu reparieren.

Mini-Story: Excel-Datei wechselt – Bericht fällt aus

Ein Team lädt monatlich eine neue Excel-Datei in Power Query. Im Februar heißt die Spalte „VK Preis“, im März „Verkaufspreis“. Der Refresh bricht mit „Spalte nicht gefunden“ ab, weil ein Umbenennen-Schritt den alten Namen erwartet.

Lösung: Mapping-Tabelle ergänzt (VK Preis → Verkaufspreis) und Typisierung so umgestellt, dass sie erst nach der Normalisierung greift. Ergebnis: Ab dann laufen neue Dateien durch, ohne dass jemand den Bericht „retten“ muss.

Troubleshooting-Checkliste

• Ist die Spalte in der Quelle vorhanden und exakt gleich benannt (Leerzeichen!)?
• Welcher ist der erste rote Schritt in „Angewendete Schritte“?
• Passiert es nach „Geänderter Typ“, Umbenennen oder Entfernen von Spalten?

Voraussetzungen, Aufwand, lohnt sich das?

Voraussetzung ist kein großes Projekt: Du brauchst Zugriff auf die Quelle und die Power-Query-Abfrage. Der Aufwand lohnt sich fast immer dann, wenn Refresh-Fehler wiederkehren oder mehrere Leute von denselben Daten abhängen. Jede robuster gemachte Abfrage reduziert Stillstand im Reporting und spart Zeit, die sonst in manuelle Excel-Korrekturen fließt.

Zu „Kosten?“: Der größte „Preis“ ist meist nicht Beratung, sondern ungeplante Unterbrechung und wiederkehrende Nacharbeit. Robustheit ist eine kleine Investition, die laufende Störfälle reduziert.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn mehrere Abfragen voneinander abhängen, Refresh im Power BI Service laufen muss oder wenn du das Problem nicht isolieren kannst, ohne das Modell zu gefährden. Dann sorgt ein kurzer, strukturierter Check (Quelle → Schritte → M-Code) oft schneller für Stabilität als „Trial & Error“.

Wenn ihr dauerhaft weniger Feuerwehreinsätze wollt, ist das Ziel nicht nur die Reparatur, sondern ein Muster: klare Spaltenlogik, Normalisierung, Mapping und wartbare Schritte.