Strom-Arbitrage sauber rechnen: Die 7 Parameter, die Excel fast immer unterschlägt

Viele Arbitrage-Rechnungen sehen am Anfang gleich aus: Man nimmt eine Preisreihe, legt eine Batteriegröße darauf, lässt ein paar Lade-/Entladevorgänge laufen – und bekommt eine schöne Kurve „Erlös pro Jahr".

‍

Das Problem: Im Gewerbe scheitert die Arbitrage selten daran, dass es keine Preisschwankungen gibt. Sie scheitert daran, dass die Batterie nicht so fahren darf, wie das Excel es annimmt.

‍

In der Praxis ist Arbitrage ein Zusammenspiel aus Zeitauflösung, Betriebsgrenzen, Abrechnung und Verschleiß. Wenn eines davon fehlt, wird aus „sieht gut aus" schnell „passt nicht zum Betrieb" oder „passt nicht zur Rechnung". Dieser Artikel zeigt sieben Parameter, die in schnellen Modellen häufig fehlen – und wie ihr sie so einbaut, dass euer Case belastbarer wird.

1) Zeitraster: Warum 15 Minuten im Gewerbe oft der Default sind

Arbitrage lebt von kurzen Fenstern. Ein günstiges Zeitfenster kann innerhalb einer Stunde auftreten und wieder verschwinden – genauso wie eine Lastspitze. Wenn ihr nur stündlich rechnet, passiert meist eines von zwei Dingen:

‍

• Ihr „glättet" die relevanten Minuten weg und unterschätzt Restriktionen (z. B. Peaks).
• Oder ihr unterstellt der Batterie, sie könne innerhalb einer Stunde perfekt genau das machen, was in der Realität durch Anschlussgrenzen und Reserven nicht geht.

Deshalb ist die einfache Faustregel: Wenn der Lastgang und der Betrieb in Viertelstunden gedacht werden, sollte die Optimierung das auch tun. Selbst ein grobes 15-min-Modell ist oft näher an der Realität als ein sehr „sauberes" Stundenmodell.

→ Wie man einen 15-min-Lastgang richtig auswertet: Lastgänge richtig analysieren

2) Roundtrip-Wirkungsgrad: Nicht nur „ein Wert", sondern fahrweisenabhängig

Der Roundtrip-Wirkungsgrad (η_roundtrip) beschreibt, wie viel der beim Laden aufgenommenen Energie nach einem vollständigen Lade-/Entladevorgang wieder nutzbar abgegeben werden kann. Ein fixer Wert wie „η = 0,9" ist als erste Näherung okay – aber für belastbare Arbitrage-Rechnungen sollte man im Blick behalten: η_roundtrip ist in der Praxis nicht konstant, sondern hängt unter anderem ab von

‍

• der gefahrenen Leistung (C-Rate),
• dem State-of-Charge-Bereich (SoC),
• der Temperatur und der Betriebsführung.

Wichtig: Der Zusammenhang ist nicht einfach monoton. Bei hohen C-Raten (intensiver Arbitragebetrieb) sinkt η spürbar. Bei sehr kleinen C-Raten oder langen Standby-Phasen können dagegen Selbstentladung und Hilfsverbrauch den effektiven Wirkungsgrad ebenfalls drücken – auch das wird in schnellen Modellen oft übersehen.

‍

Warum das relevant ist: Arbitrage nutzt häufig genau die Zeitfenster, in denen man den Speicher intensiv fährt. Wenn der tatsächliche Wirkungsgrad unter diesen Betriebsbedingungen niedriger ist als angenommen, verschiebt sich die wirtschaftliche Schwelle (ab welchem Spread sich das Laden/Entladen lohnt) spürbar.

‍

Pragmatisch reicht oft schon eine einfache Verbesserung gegenüber „fix η": entweder konservativer ansetzen oder mit zwei Betriebsfällen arbeiten (z. B. „moderate Leistung" vs. „hohe Leistung"), statt ein Kennfeld zu überfrachten.

3) Zyklenkosten/Degradation: Sonst ist jeder Zyklus „gratis" – und das macht jede Spreizung profitabel (im Modell)

Das ist einer der häufigsten Gründe für „zu gute" Arbitrage-Ergebnisse: Das Modell sieht jede zusätzliche Lade-/Entladebewegung als Gewinnchance – weil sie keine Kosten hat. In der Realität erzeugt jede durchgesetzte kWh Verschleiß.

‍

Wenn ihr das ignoriert, optimiert ihr in Richtung „maximaler Durchsatz", also viele kleine Zyklen überall dort, wo ein bisschen Spread ist. Das wirkt in der Summe groß, aber ist operativ und wirtschaftlich oft nicht sinnvoll.

Ein pragmatischer Einstieg ist ein einfacher Kostenansatz:

‍

• Kosten pro Throughput (€/MWh), die durch die Batterie laufen, oder
• Kosten pro (Äquivalent-)Vollzyklus.

Für aktuelle Lithium-Ionen-BESS-Projekte liegen typische Zyklenkosten je nach Zellchemie, Auslegung und angenommener Restlebensdauer grob im Bereich von 3–10 €/MWh Throughput – was bedeutet, dass ein Spread von unter 5–10 €/MWh nach Wirkungsgradverlust und Verschleiß kaum noch Deckungsbeitrag liefert.

‍

Diese Größenordnung hilft, beim Modellieren schnell unplausible Ergebnisse zu erkennen. Damit zwingt ihr die Optimierung, nur die Zeitfenster mitzunehmen, bei denen nach Verlusten und Verschleiß noch etwas übrig bleibt.

‍

Hinweis Kalenderalterung: Zyklenkosten erfassen nur die nutzungsabhängige Degradation. Batterien altern aber auch zeitabhängig – unabhängig davon, wie viel sie fahren. Für Cases, bei denen die Batterie planmäßig viele Reserven hält (→ Punkt 5) oder saisonal wenig genutzt wird, kann die Kalenderalterung die dominante Größe sein und sollte separat berücksichtigt werden.

→ Wie ein MiSpeL-konformer Arbitrage-Case mit realen Zyklusannahmen rechnet: Use Case: MiSpeL-konforme Speicherauslegung für Arbitrage 2026

4) kW vs. kWh: Viele dimensionieren nach Energie, doch Arbitrage braucht Zugriff auf Zeitfenster (Leistung)

Ein Speicher kann groß sein (viel kWh) und trotzdem schlecht für Arbitrage funktionieren, wenn er nicht genügend Leistung (kW) hat – oder wenn der Anschluss die Leistung begrenzt.

Ein einfaches Bild hilft:

• kWh sagt: Wie lange kann ich fahren?
• kW sagt: Wie viel schaffe ich innerhalb des relevanten Zeitfensters?

Arbitrage-Fenster sind oft kurz. Wenn ihr dann nur mit geringer Leistung laden/entladen dürft, „verpasst" ihr einen Teil der Wertigkeit, selbst wenn der Spread im Preis groß ist.

‍

Für Angebote ist das ein extrem wichtiger Punkt: Ein Business Case, der kWh optimiert, aber kW als Nebensache behandelt, ist im Gewerbe fast immer angreifbar.

→ Wie Leistungs- und Energiedimensionierung in Multi-Use-Cases zusammenspielen: Use Case: Nachrüstung BESS Multi-Use Szenarien

5) SoC-Grenzen und Reserven: In der Realität steht selten 100 % Batterie für Arbitrage bereit

In Single-Use-Rechnungen fährt die Batterie oft „frei" zwischen 0 und 100 %. Im Gewerbe ist das selten so. Selbst bei einem Setup, das primär Arbitrage machen soll, gibt es meist praktische Reserven:

‍

• Sicherheitsreserve (Betrieb / Verfügbarkeit)
• Reserve für Peak-Ereignisse (wenn der Standort es erwartet)
• Begrenzte SoC-Fenster aus Lebensdauer-/Betriebsgründen

Der Effekt ist banal, aber groß: Wenn ihr Reserven nicht modelliert, plant ihr mit Kapazität, die später nicht genutzt werden darf. Dann ist der Case im ersten Jahr „zu gut", im Betrieb aber dauerhaft unter Plan.

→ Wie SoC-Management und Peak-Shaving-Reserve im Betrieb zusammenspielen: Peak Shaving im C&I: Umsetzung & Praxisbetrieb

6) Anschluss- und Netzrestriktionen: Excel lässt Batterien oft „durch Wände fahren"

Ob separater Anschluss oder Bestandsanschluss – es gibt fast immer harte Grenzen, die den Betrieb formen:

‍

• maximale Bezugsleistung aus dem Netz,
• maximale Einspeiseleistung (wenn Einspeisung überhaupt vorgesehen/zulässig ist),
• Trafo-/Schaltanlagenlimits,
• Schutz- und Regelvorgaben,
• und ganz praktisch: Betriebsregeln am Standort.

Viele schnelle Modelle haben diese Limits nicht oder nur als grobe Nebenbedingung. Die Folge: Die Batterie lädt genau dann, wenn das Werk schon am Limit ist – oder entlädt, obwohl Einspeisung so gar nicht vorgesehen war. Das ist keine „kleine Abweichung", sondern eine andere Welt.

‍

Wenn ihr nur einen Restriktionsblock sauber modelliert, dann diesen: kW-Limits am Anschluss (Import/Export) plus SoC-Grenzen. Das bringt Modelle oft schlagartig näher an den Betrieb.

→ Wie ein separater Netzanschluss die Restriktionslogik grundlegend verändert: Arbitrage: Eigener Netzanschluss für Batteriespeicher im C&I

7) Tarif- und Abrechnungskomponenten: Der Spotpreis ist selten das, was am Ende zählt

Auch wenn ihr Börsenpreise nutzt: Im Gewerbe entscheidet die Rechnung. Und die besteht nicht nur aus „ct/kWh".

Typische Stolpersteine:

‍

• Ein dynamischer Tarif bildet den Börsenpreis nicht 1:1 ab (Aufschläge, Struktur, Regeln).
• Netzentgelt- und Leistungskomponenten können die optimale Fahrweise stark beeinflussen.
• Das Mess- und Abrechnungsraster (Stunde vs. Viertelstunde) kann die Modelllogik kippen.

Ein guter Reality-Check ist daher: Könnt ihr eure Modelllogik auf einer echten Rechnung (oder einem echten Tarifblatt) nachvollziehbar abbilden? Wenn nicht, ist das Risiko hoch, dass ihr am „falschen Preis" optimiert.

→ Wo genau sich Arbitrage und dynamische Tarife in der Abrechnung unterscheiden: Arbitrage vs. dynamische Tarife im Gewerbe
→ Wie dynamische Tarife im C&I-Segment funktionieren: Dynamische Stromtarife im C&I: Chance + Herausforderung

Mini-Framework: Ein sauberer Arbitrage-Case in 5 Schritten

1. Zeitbasis festlegen: 15-min, wenn Lastgang/Restriktionen so vorliegen.
2. Batterie realistisch parametrisieren: Leistung, Energie, η, SoC-Fenster, Zyklenkosten (inkl. Plausibilisierung gegen ~3–10 €/MWh).
3. Restriktionen explizit machen: Anschluss (Import/Export), Reserven, Betriebsregeln.
4. Ziel sauber formulieren: Was soll primär optimiert werden (Kosten senken, Erlöse, Robustheit)?
5. Plausibilisieren: Nicht „ein Jahr simulieren und fertig", sondern 2–3 repräsentative Wochen manuell prüfen: Ergibt die Fahrweise betrieblich Sinn? Passt sie zur Abrechnung?

Typische Fehlerbilder (kurz aus der Praxis)

• „Preisreihe rein, Ergebnis raus" ohne Zyklenkosten → viele kleine Zyklen, unrealistisch gute Erlöse.
• Stundenmodell bei Viertelstundenrealität → Peaks und Fenster werden falsch getroffen.
• kWh-Optimierung ohne kW-Engpassanalyse → Batterie groß, Wirkung klein.
• Tarif ignoriert → Modell optimiert auf Spot, Rechnung folgt anderer Logik.
• Restriktionen zu spät → der Betrieb muss später „konservativ" begrenzen, Business Case schrumpft.

Praktische Checkliste: Was ihr für eine belastbare Rechnung mindestens braucht

• 15-min-Lastgang (oder zumindest repräsentative Wochen in hoher Auflösung)
• klare Anschluss-/Leistungsrestriktionen (Import/Export, Trafo/Schutz, Betriebsregeln)
• Tarif-/Beschaffungslogik (Preisblatt, Komponenten, Zeitraster)
• Speicherparameter (kW/kWh, SoC-Grenzen, η-Annahme, Zyklenannahme inkl. Kalenderalterung)
• Zielbild (nur Arbitrage oder Multi-Use mit Prioritäten)

‍