Din lastprognosYour Load Forecast

En praktisk guide till lastprognoser för elnätsföretag — bygg, köp eller lägg ut, och hur ni undviker att bara köpa resultatet utan förståelsen. A practical guide to load forecasting for grid companies — build, buy, or outsource, and how to avoid buying the output without the understanding.

Det här är den andra fördjupningsguiden och tar vid från Din mätdata steg 2, där lastprognoser var ett av fyra användningsfall som drog nytta av en gemensam datainfrastruktur. Guiden förutsätter att den infrastrukturen finns, eller pekar tillbaka dit, och handlar om de beslut prognosarbetet i sig kräver.

1 · Vilken prognos behöver ni egentligen?

“Prognoser” är inte ett enda beslut. Det finns fyra tidshorisonter, med engelska förkortningar som slutar på LF för load forecasting (VSTLF = mycket kort sikt, STLF = kort sikt, MTLF = medellång sikt, LTLF = lång sikt), och de gör olika jobb i ett kraftsystem:

Horisont	Tidsram	Beslut den stödjer
VSTLF	Minuter till timmar	Realtidsdrift av nätet
STLF	Dagen före till en vecka	Upphandling, marknadsbud, schemaläggning
MTLF	En vecka till ett år	Underhåll, kapacitetsoptimering
LTLF	Bortom ett år	Investeringsplanering, nätutvecklingsplan, FNA

Sverige har redan en standard för nedre delen av den tabellen: Energiforsks nationella metodik täcker MTLF/LTLF-lagret som matar nätutvecklingsplanen och FNA. Lagret utan standard är STLF: den operativa prognosen för dagen före, som styr upphandling och marknadsdeltagande, där det är upp till varje elnätsföretag, balansansvarig eller aggregator att bygga sin egen kompetens. Allt i den här guiden handlar därför om det lagret.

Att namnge vilken horisont och vilka beslut prognosen gäller för är första steget, inte en formalitet. Ett elnätsföretag som säger att det “behöver prognoser” utan att namnge horisonten menar förmodligen att man vill ha alla fyra på en gång, och det är så ett prognosprojekt kör fast innan det ens har börjat.

2 · Ligger ni egentligen efter?

Ingen ska läsa den här guiden och dra slutsatsen att det egna elnätsföretaget ligger unikt långt efter. En PREDATOR-studie som intervjuade åtta svenska elnätsföretag fann att många helt saknar en intern datadriven prognosmodell: planeringen bygger på erfarenhetsbaserad bedömning och tumregelsextrapolering. En separat kartläggning av 50 elnätsföretag fann brister även i stor skala: 28 % saknar dokumenterad metodik, 40 % saknar dokumenterade effektmallar och 36 % validerar inte systematiskt (bara 19 % validerar löpande mot utfall).

Det här är inte ett problem bara för små elnätsföretag. Vattenfall Eldistribution är Sveriges största elnätsföretag sett till nätområde, och enligt en Uppsalastudie som utvärderade bolagets CoordiNet-prognoser var CoordiNet första gången företaget tog fram lastprognoser för nätet (studien säger inte vad som fanns tidigare). Man framställde inte heller prognosen själv; arbetet lades helt ut på Expektra. Om Sveriges största elnätsföretag börjar på samma ställe som alla andra är “vi har inte byggt det här än” det normala utgångsläget, inte en varningssignal.

3 · Bygga, köpa eller låna?

Det finns fyra realistiska vägar, och de är inte en skala från dåligt till bra:

Bygg: RISE:s föreslagna struktur för ett elnätsföretag som utvecklar detta internt, stegvis snarare än på en gång: analysera vilka solceller, laddboxar och värmepumpar som redan finns, utifrån mätdata och anslutningsregister, aggregera dem till aktuella lastprofiler som stäms av mot faktiska mätvärden, och extrapolera tillväxten med hjälp av demografiska och ekonomiska indikatorer. Det organisatoriska hindret, att hitta personal som kan både elnät och dataanalys, beskrivs som lika stort som det tekniska.

Köp kommersiell mjukvara: Vitec Energys Aiolos Forecast Studio är en kommersiell produkt som underhålls löpande och täcker allt från samma dag till flera år framåt.

Köp som tjänst: Expektra är den faktiska leverantören bakom Vattenfall Eldistributions CoordiNet-prognoser. Ett elnätsföretag behöver inte bygga eller ens driva modellen; man kan köpa själva prognosen som en löpande tjänst.

Öppen källkod: OpenSTEF, som tillgängliggörs av LF Energy, byggdes av nederländska elnätsföretaget Alliander för samma problem med kapacitetsbegränsningsprognoser och gjordes öppet specifikt för att bli ett delat branschalternativ till proprietära verktyg. Det kan därför passa ett elnätsföretag som vill undvika att låsas till en leverantör men inte är redo att utveckla en hel lösning från grunden.

Verktyget Bygga eller köpa prognosen? gör om den här jämförelsen till en poängsatt rekommendation utifrån er egen förmåga, tidsplan, budget och hur beroende ni vill vara av en leverantör, i stället för en generell rangordning.

→ Bygga eller köpa prognosen?

4 · Köper ni resultatet, köp förståelsen också

Studien som nämndes ovan utgår själv från problemet: när arbetet lades ut på en extern leverantör saknade Vattenfall Eldistribution en detaljerad förståelse för hur de egna prognoserna fungerade. Studiens första fas var en omgång intervjuer med leverantören och Vattenfalls egen personal för att hitta luckorna: inte en teknisk lösning, utan en organisatorisk.

De två informationsluckor intervjuerna lyfte fram var på grundläggande nivå: hur långt i förväg prognosen för dagen före respektive samma dag faktiskt tas fram, och hur de underliggande modellerna för de två skiljer sig åt (studien beskriver senare båda som samma algoritm med olika viktade parametrar). Det här är den typ av frågor ett elnätsföretag borde kunna svara på om prognoser man förlitar sig på operativt, oavsett om tjänsten är utlagd eller köpt som mjukvara:

Vilka indata använder modellen faktiskt?
Hur långt i förväg tas varje prognostyp fram, och varför skiljer det sig mellan dem?
Vem inom organisationen kan förklara varför träffsäkerheten var låg en specifik dag, utan att ringa leverantören?

Kan ingen svara på den tredje frågan är prognosen en svart låda elnätsföretaget är beroende av men inte äger, oavsett hur pålitlig den är i genomsnitt.

5 · Vad som faktiskt ställer till det för er prognos

Wiss felanalys gäller en marknad och är beskrivande, men fynden är värda att känna till bortom Uppsala. Av sju undersökta felfaktorer dominerade två: stora nätanvändare som avviker från sin inlämnade produktionsplan, och avropad flexibilitet.

Motsägelsefullt nog minskade prognosfelet i regel under högbelastningsperioder (extrem kyla, höga priser och flexibilitetsaktiveringar när felet mäts mot uppskattad last utan flex; mätt mot uppmätt last ökade aktiveringarna felet), precis de förhållanden där träffsäkerhet betyder mest för kapacitetshantering. Studiens analys är beskrivande och kan inte fastställa signifikans, så det är ett betryggande fynd, men inte en anledning att strunta i kvalitet: en prognos som tränats på bristfälliga indata klarar sig inte lika bra. En platt, uppskattad sträcka av “intervalldata”, som Ei hittade vid sin tillsyn av mätningen, är lätt att ta för riktiga mätvärden när markeringen för beräknat värde har försvunnit, och den försämrar då prognosen på det sätt som föregående guide beskriver.

Det finns också en strukturell risk, även om den inte går att åtgärda direkt: när många balansansvariga svarar på samma prissignal med liknande prognosmodeller kan deras fel synkroniseras snarare än ta ut varandra. Bättre individuell prognostisering gör inte automatiskt systemet mer stabilt, en dynamik som utforskas i sin helhet under efterfrågeflexibilitetens systemrisker.

6 · Vad är en prognos egentligen värd?

En prognos för en flexibilitetsmarknad bedöms inte bara på träffsäkerhet. En leverantör som anger ett enda MAPE-tal svarar på fel fråga, för tre saker väger tyngre än det talet:

Var felet hamnar. Ett genomsnitt döljer det som spelar roll. Det som räknas är träffsäkerhet under de knappa, högprisade timmarna där ett missat prognosvärde faktiskt är dyrt, inte under en genomsnittsdag.
Punktvärde eller intervall. Ett enda medianvärde döljer hur mycket det faktiska utfallet kan avvika. En probabilistisk prognos, alltså en som även anger ett osäkerhetsband runt medianen, fångar kapacitetsöverskridanden som en punktprognos skulle missa.
Om den fortfarande är aktuell när marknaden stänger. En prognos som är korrekt beräknad ett dygn i förväg är inte användbar om marknaden behöver talet närmare realtid.

En annan måttstock gäller när prognosen samtidigt används för avräkning, alltså när den är den baseline som en flexleverantör får betalt mot. En baseline är i praktiken en prognos med en motståndare: den måste vara svår att manipulera och gå att räkna om, eftersom riktiga pengar hänger på den, och det som gör en STLF-modell bra för driften gör den inte automatiskt bra för avräkning.

→ Så mäts leveransen när NC DR kommer

Balansansvariga bär den direkta finansiella exponeringen: prognosfel översätts till obalanskostnader under den nordiska modellen, och när BSP- och BRP-rollerna utvidgas till hushållsresurser som slås ihop sprids den risken ner till allt mindre portföljer. Den fullständiga genomgången förklarar varför “bra” betyder olika saker för ett elnätsföretag som köper flexibilitet och för en flexleverantör som säljer den.

Animationen nedan spelar upp skillnaden mellan en median och ett intervall för ett enda dygn.

7 · Vad det här öppnar upp för härnäst

Ett fungerande STLF-lager förstärker de MTLF/LTLF-underlag Sverige redan standardiserar: bättre grunddata gör en nätutvecklingsplan eller FNA-prognos mer försvarbar, inte bara mer exakt på pappret. Det är också en direkt förutsättning för beslutet om att delta i en flexibilitetsmarknad. Ett elnätsföretag kan inte trovärdigt driva en lokal marknad utan en prognos som underlag för upphandlingar och avrop, vilket är precis där DSO-resan tar vid.

Verktyget Duger lastprognosen för flexibilitet? ger en snabb bild av var er egen mätning och prognosförmåga faktiskt ligger idag, innan det steget tas.

→ Duger lastprognosen för flexibilitet?

När de grundläggande korttidsprognoserna väl fungerar pålitligt blir ett betydligt svårare problem värt att undersöka: att prognostisera en tillgång som inte finns än. En Lundastudie från 2026, som utgår från snabbladdningsdata från ett nät i nordvästra Skåne (Öresundskrafts område), förutsäger en planerad stations 24-timmars topplastprofil enbart från metadata före byggnation, innan den har genererat en enda timme av sin egen last. Det är nästa nivå: inte bättre prognoser för det ni redan mäter, utan prognoser för det ni inte har byggt än.

This is the second deep dive guide, picking up from Your Metering Data step 2, where load forecasting was one of four use cases riding on a shared data pipeline. This guide assumes that pipeline exists, or points back to it, and is about the decisions forecasting itself requires.

1 · Which forecast do you actually need?

“Forecasting” isn’t one decision. Four horizons, all named “[timeframe]LF” for load forecasting (VSTLF = very short-term, STLF = short-term, MTLF = medium-term, LTLF = long-term), do different jobs in a power system:

Horizon	Timeframe	Decision it feeds
VSTLF	Minutes to hours	Real-time grid control
STLF	Day-ahead to a week	Procurement, market bidding, DR scheduling
MTLF	A week to a year	Maintenance, capacity optimization
LTLF	Beyond a year	Investment planning, DNDP, FNA

Sweden already has a standard for the bottom of that table: Energiforsk’s national methodology covers the LTLF/MTLF layer feeding DNDP and FNA submissions. The layer without a standard is STLF: the day-ahead operational forecast that actually drives procurement and market participation, left to each DSO, BRP, or aggregator to build as commercial know-how. Everything in this guide is about that layer, because it’s the one nobody has already solved for you.

Naming which horizon and which downstream decision it feeds is the first move, not a formality. A DSO that says it “needs forecasting” without naming the horizon usually means it wants all four at once, which is how a forecasting project stalls before it starts.

2 · Are you actually behind?

Nobody should read this guide and conclude their DSO is uniquely behind. A PREDATOR study interviewing eight Swedish DSOs found many have no internal data-driven forecasting model at all: planning runs on expert judgment and rule-of-thumb extrapolation. A separate survey of 50 DSOs found gaps at scale too: 28% have no documented methodology, 40% no documented power templates, and 36% do not validate systematically (only 19% validate continuously against actuals).

The sharper point: this isn’t a small-DSO problem. Vattenfall Eldistribution is Sweden’s largest grid company by network area, and according to an Uppsala University evaluation of its CoordiNet forecasts, CoordiNet was the first time it created load forecasts for the grid (the thesis doesn’t say what forecasting existed before). It didn’t build that forecast itself either; it outsourced the work entirely to Expektra. If Sweden’s largest DSOs are starting from the same place as everyone else, “we haven’t built this yet” is the normal starting condition, not a red flag.

3 · Build, buy, or borrow?

This is the decision the rest of the guide hangs on. Four real paths exist, not a spectrum from bad to good:

Build: RISE’s proposed structure for a DSO building this in-house, staged rather than attempted all at once: analyze the current DER inventory from AMI and connection registers, aggregate it into current-state load profiles validated against real measurements, extrapolate growth using demographic and economic indicators. The organizational barrier (staff combining power-system domain knowledge with data-science capability) is named as being as significant as the technical one.

Buy commercial software: Vitec Energy’s Aiolos Forecast Studio is an active, commercially maintained option covering intraday through multi-year horizons.

Buy as a service: Expektra is the actual provider behind Vattenfall Eldistribution’s CoordiNet forecasts. A DSO doesn’t have to build or even operate the model; it can buy the forecast itself as an ongoing service.

Open source: OpenSTEF, hosted at LF Energy, was built by Dutch DSO Alliander for the same congestion-forecasting problem and open-sourced specifically to become a shared industry alternative to proprietary tools, a real option for a DSO wary of vendor lock-in but not ready to build a full stack from nothing.

No path here is presented as the right default. Most DSOs seem to drift into one without comparing it against the others, which is exactly how Vattenfall ended up in the position the next step describes.

The Forecast Build vs. Buy Decision Helper turns this comparison into a scored recommendation based on your own capability, timeline, budget, and appetite for vendor dependence, rather than a generic ranking.

→ Forecast Build vs. Buy Decision Helper

4 · If you buy it, buy the understanding too

This comes from a real failure, not a hypothetical one. That same thesis states plainly, as its own starting problem, that the outsourcing left Vattenfall Eldistribution without a detailed understanding of how its own forecasts worked. The thesis’s first phase was a dedicated round of interviews with the vendor and Vattenfall’s own staff to find where the gaps were: not a technical fix, an organizational one.

The two information gaps the interviews surfaced were basic, once named: how far in advance the day-ahead versus the intraday forecast is actually generated, and how the underlying models for the two differ (the thesis later describes both as the same algorithm with differently weighted parameters). These are the kind of questions a DSO should be able to answer about any forecast it relies on operationally, whether outsourced or bought as software:

What inputs does the model actually use?
How far ahead is each forecast type generated, and why does that differ between them?
Who inside the organization can explain why a specific forecast day was inaccurate, without calling the vendor?

If nobody can answer the third question, the forecast is a black box the DSO depends on but doesn’t own, regardless of how accurate it is on average.

5 · What actually breaks your forecast

Wiss’s error analysis covers one market and is descriptive, but its findings are worth knowing beyond Uppsala. Of seven candidate error factors examined, two dominated: large grid users deviating from their submitted production plan, and flexibility activations.

Counterintuitively, forecast error generally decreased during high-load periods (extreme cold, high prices, and flexibility activations when measured against estimated load without flex; measured against metered load, activations increased the error), precisely the conditions where accuracy matters most for capacity management. The thesis’s analysis is descriptive and can’t establish significance, so it’s a reassuring finding, not a license to ignore quality: a forecast trained on contaminated interval data won’t show the same resilience. A flat, synthetically-estimated stretch of “interval data”, the finding from Ei’s own metering supervision, is easy to mistake for a real reading once the calculated flag is lost and will degrade a forecast silently, in exactly the way the previous guide covers in full.

There’s a second, structural risk worth knowing about even if it isn’t yours to fix directly: when many BRPs respond to the same price signal using similar forecasting models, their errors can synchronize rather than cancel out. Better individual forecasting doesn’t automatically make the system more stable, a dynamic explored in full under demand response’s grid-level risks.

6 · What is a forecast actually worth?

A forecast for a flexibility market isn’t graded on accuracy alone. A vendor quoting a single MAPE figure is answering the wrong question, because three things matter more than that number:

Where the error falls. An average hides everything that matters. What counts is accuracy in the scarce, high-price hours where a miss is actually expensive, not on an average day.
A point value or a range. A single median value hides how far the actual outcome could still miss it. A probabilistic forecast, one that also states an uncertainty band around the median, catches capacity breaches a point forecast alone would miss.
Whether it’s still current when the market clears. A forecast that’s excellent computed a day ahead isn’t useful if the market needs the number closer to real time.

A different bar applies once the forecast doubles as a settlement instrument, which is exactly what happens whenever it defines the baseline an FSP gets paid against. A baseline is, in effect, a forecast with an adversary: it has to be manipulation-resistant and recalculable, because real money moves against it, and the same discipline that makes a good STLF model for operations doesn’t automatically make a good one for settlement.

→ How delivery will be measured under NC DR

BRPs carry the direct financial exposure: forecast error translates into imbalance-settlement charges under the Nordic model, and as the BSP/BRP framework extends to aggregated household resources, that exposure cascades down to smaller and smaller portfolios. The full treatment covers why “good” splits differently for a DSO’s buy-side forecast than an FSP’s sell-side one.

The animation below plays out the difference between a median and a band over a single day.

7 · What this unlocks next

A working STLF layer strengthens the LTLF/MTLF submissions Sweden already standardizes: better ground-truth data makes a DNDP or FNA forecast more defensible, not just more accurate on paper. It’s also the direct precondition for the flexibility-market participation decision. A DSO can’t credibly run a local market without a forecast to trigger procurement calls, which is exactly where the DSO journey picks the question up.

The Forecast Suitability Assessment gives a quick read on where your own metering and forecasting capability actually stand today, before taking that step.

→ Forecast Suitability Assessment

Once basic STLF is running reliably, a genuinely harder problem becomes worth attempting: forecasting an asset that doesn’t exist yet. A 2026 Lund University study, working from fast-charging station data from a grid in northwestern Skåne (Öresundskraft’s service area), predicts a planned station’s 24-hour peak-load profile from pre-construction metadata alone, before it has generated a single hour of its own load. That’s the next-level version of everything this guide covers: not better forecasting of what you already measure, but forecasting what you haven’t built yet.