Daten aus Haufe X360 per OData automatisch in Excel laden und aktualisieren

Am besten startest du mit einer klaren Frage aus dem Alltag – und leitest daraus eine Standard-Auswertung oder eine Allgemeine Abfrage (Generic Inquiry) ab, die du später auch per OData bereitstellen kannst. In Haufe X360 sind für Controlling und Buchhaltung typischerweise solche Abfragen realistisch:

• Offene Posten (Debitoren/Kreditoren): OP-Liste, OP-Stichtagsliste, zukünftig fällige Belege, OPs pro Periode (ggf. auch nach Projekt)
• Salden & Finanzsicht: Saldenlisten (z. B. nach Konto, nach Lieferant, mit/ohne Währung), Buchungsperioden-Übersichten, Auswertungen fürs Monatsende
• Rechnungen & Zahlungen: Debitorenrechnungen (bezahlt/offen), Zahlungseingänge inkl. Zuordnung, Gutschriften und Verrechnungen
• Kunden-/Lieferantenstamm: Debitoren/Kreditoren-Stammdaten, Ansprechpartner, Zahlungsbedingungen, Mahnstufen (sofern genutzt)
• Warenwirtschaft: Artikelstamm, Lagerbestände, Artikelbewegungen, Bestellungen/Wareneingänge, Lieferscheine/Warenausgänge
• Projektcontrolling: Budgetstatus, Abrechnungsstand, abrechenbare/nicht abrechenbare Zeiten, Auslastung und Projekt-Drilldown bis auf Belegebene

So bist du schnell nah an echten Fragen aus dem Tagesgeschäft – und baust dir eine Abfrage, die du später nicht jedes Mal neu „zusammenexportieren“ musst.

Damit Excel auf eine Abfrage zugreifen kann, muss sie in Haufe X360 für OData freigegeben sein. Häufig passiert das über einen Bereich wie „Customization“ oder eine entsprechende Konfiguration.

Wichtig ist dabei weniger der Klickweg als die Betriebslogik dahinter:

• Du kannst oft nicht nur Standardabfragen, sondern auch eigene Abfragen freigeben.
• Freigaben sind ein Steuerungsinstrument: Nicht jede Abfrage sollte nach außen gehen.

Praxis-Tipp: Starte klein. Nimm zuerst eine Abfrage (z. B. Kundenstamm), bringe den Ablauf zum Laufen und erweitere dann Schritt für Schritt.

Praxis-Tipp 2: Benenne Abfragen so, dass der Zweck klar ist (z. B. „OData_Controlling_Rechnungen_2025plus“ statt „Query1“). Das spart später Rückfragen.

In Excel stellst du dann die OData-Verbindung her (inkl. Anmeldung) und lädst die Abfrage entweder als Tabelle oder direkt ins Datenmodell.

Der entscheidende Punkt für den Alltag ist die Aktualisierung. Denn erst, wenn der Refresh zu eurem Prozess passt, wird aus der Lösung ein Werkzeug.

Du kannst zum Beispiel steuern, ob aktualisiert wird:

• beim Öffnen der Datei
• in regelmäßigen Abständen
• manuell per „Aktualisieren“-Knopf

Ein praxistauglicher Kompromiss ist oft:

• Im Tagesgeschäft: manuell aktualisieren (damit sich während der Bearbeitung nichts verschiebt)
• Vor Monatsabschluss/Meeting: „Refresh + Pivot aktualisieren“ als feste Routine

Rohdaten sind selten sofort reporting-fähig. Power Query hilft dir, die Daten einmal sauber zu „ordnen“, ohne dass du später alles neu bauen musst.

Statt zehnmal dieselben Handgriffe zu machen, definierst du die Schritte in Power Query. Besonders häufig sind das:

• Spalten reduzieren: Nur behalten, was du für Auswertungen wirklich brauchst
• Filter setzen: z. B. Zeitraum, Status, relevante Buchungskreise
• Datentypen sauber setzen: Datum als Datum, Beträge als Zahl, IDs konsistent als Text oder Zahl

Wenn du im Laufe der Zeit merkst, dass eine Spalte fehlt oder ein Filter anders sein sollte, passt du die Schritte an – statt eine Datei neu aufzubauen.

Viele Probleme wirken auf den ersten Blick wie „Excel-Probleme“, sind aber in Wahrheit Daten- oder Prozessprobleme.

Zwei Punkte sind besonders wichtig:

• Eindeutige Schlüssel: Beziehungen im Datenmodell brauchen stabile IDs. Wenn du über Namen verknüpfst, sind Tippfehler, Umbenennungen und Dubletten vorprogrammiert.
• Dubletten im Stamm: Wenn ein Kundenstamm nicht eindeutig ist, lässt sich keine saubere 1:n-Beziehung aufbauen.

Wenn hier etwas hakt, ist das kein Rückschritt – es ist ein wertvoller Hinweis, wo Stammdatenpflege und Verantwortlichkeiten geschärft werden sollten.

Starte mit einer Abfrage und einem klaren Ziel (z. B. Kundenstamm + Pivot). Wenn das stabil läuft, nimm die nächste Abfrage dazu (z. B. Rechnungen) und baue Beziehungen.

Das klingt langsam, ist aber in der Praxis schneller: Du verhinderst, dass du zu früh Komplexität aufbaust

Viele Performance-Probleme entstehen, weil zu viel geladen wird. Ein gutes Reporting ist selten „alles“, sondern „genug, um die Frage zu beantworten“.

Drei einfache Hebel:

• nur benötigte Spalten laden
• früh filtern (z. B. Zeitraum, Status)
• überlegen, ob du für Management-Reporting eine verdichtete Sicht brauchst

OData ist bequem – und genau deshalb braucht es Regeln. Ohne Governance wird die Lösung schnell zum Wildwuchs.

Bewährt hat sich, mindestens zu klären:

• wer Abfragen für OData freigibt
• welche Inhalte nach außen dürfen (z. B. personenbezogene Daten)
• wie Abfragen dokumentiert werden (Name, Zweck, Verantwortlicher)

Ein einfaches Rollenmodell kann reichen:

• Fachlicher Owner (Controlling): definiert Felder und Logik
• Technischer Owner (IT/Power-User): Berechtigungen, Freigaben, Stabilität
• Daten-Owner (Fachbereich): Stammdatenpflege und Konsistenz

Der Refresh muss zum Arbeitsablauf passen. Manche Teams wollen beim Öffnen sofort aktuelle Zahlen, andere brauchen bewusst einen stabilen Stand während der Bearbeitung.

Eine pragmatische Regel kann sein: „Der Bericht ist gültig, wenn er nach dem Refresh eine Plausibilitätsprüfung bestanden hat.“

Viele Reporting-Lösungen funktionieren, bis der wichtigste Mensch im Urlaub ist. Ein minimaler Standard hilft, Wissen im Team zu halten.

Zum Beispiel:

• Zweck der Abfrage
• wichtigste Felder (Schlüssel, Kennzahlen)
• Refresh-Regel (wann/wer)
• Ablageort und Dateiname

• Excel kann sehr viel. Wenn aber mehrere Nutzer, Dashboards, Berechtigungen und Veröffentlichung ins Spiel kommen, ist Power BI oft die passendere Stufe. 

  Ein praxistauglicher Weg ist: erst in Excel prototypisch bauen (Fachlogik, Datenmodell), dann – wenn sinnvoll – nach Power BI überführen.