Utility advance-payment (Abschlag) forecasting and explanation

German household electricity, gas and heat customers pay monthly Abschläge that are settled once a year. If the Abschlag is too low the customer faces a painful back payment; if it is too high the supplier owes a refund and receives complaints. Most Stadtwerke still derive the amount from last year's consumption or a flat average and adjust it by hand after the annual bill. A forecast per customer, combining meter history, weather and price changes, plus an automatically drafted explanation, makes the amount fairer and cuts the manual adjustment work and the follow-up calls. Honest status: the forecasting part is well understood; fully automatic write-back into the billing system is still rare.

Problem & value

• Today: the Abschlag is set at contract start from an estimate and recalculated after the annual bill. Under §41b Abs. 3 EnWG it must follow the consumption of the previous billing period or the average of comparable customers; if a household makes it credible that its consumption is considerably lower, this must be taken into account [1]. Staff check change requests, price-change effects and complaints one by one in the billing system and write letters by hand.
• Why it hurts: price changes, moves, a new heat pump or PV system, and mild or cold winters make last year's figure a poor predictor. The Bundesnetzagentur notes that an adjustment is especially appropriate when price or expected consumption changes, and that overpayments must be offset or paid out within two weeks [2]. Customers who get an increase without a plausible reason may object [2].
• AI value: better individual forecasts (fewer large back payments and refunds), a worklist of contracts that really need a change, and a consistent explanation text. Less liquidity noise for the utility as well. Savings of roughly 20-40 percent of the manual adjustment time are a plausible estimate for a typical Stadtwerk (the gap analysis counts about 20 hours per month); there is no published benchmark.
• No invented numbers: blog claims about forecast-error reductions from vendors were not verifiable and are not used here.

Variants

• Electricity (households, small commercial): BDEW standard load profiles (H0 from 1999, H25 / P25 / S25 from 2025, the latter for households with PV and battery) serve as the baseline for new customers [3]; smart-meter data improves it where available.
• Gas and district heat: strongly temperature-driven; the BDEW/VKU/GEODE SigLinDe procedure maps daily mean temperature and a customer value to daily consumption and is a good feature source [3].
• Prosumer and heat-pump customers: PV, storage and heat pumps break the standard profiles; these need individual models.
• Small business (SLP customers): same logic, but contract terms differ (§41b applies to Haushaltskunden; commercial terms are set by contract).
• Customer-side tool: a portal widget "what will my year cost" with meter reading entry.

How it works

1. meter readings + contract data + payment history (billing system)
2. cleaning (estimated vs. real readings, move-in/move-out, meter exchange, plausibility)
3. features (annual consumption, trend, household and heating data, temperature, price change)
4. forecast of annual consumption per customer (gradient boosting or hierarchical time series; standard load profile as fallback for new customers) with uncertainty band
5. cost projection with current price components (energy, grid fee, levies, taxes)
6. proposed Abschlag = (projected cost - credits already paid) spread over the remaining months, with rules for minimum change, rounding and rate-of-change caps
7. LLM drafts the explanation (why up or down, what the customer can do, how to report a reading)
8. human review of exceptions
9. write-back to billing system
10. customer notice
11. after the annual bill: compare forecast vs. actual, retrain

• Forecast core: classical tabular ML or per-customer time-series models; an LLM is not the forecaster. Time-series foundation models can be tested for short histories.
• LLM role: explanation, tone and language (see also LANG-012 for routing of incoming requests). All numbers come from the calculation, never from the LLM.
• Human in the loop: first sections of the customer base are reviewed in batch; contracts with large changes, hardship signals or open complaints always go to a clerk.

Data preparation

Which data: meter readings with reading type (customer, utility, estimated), annual bills, price sheets by date, contract and customer master data, payment history, complaints and requests to adjust, local temperature series from the German weather service (DWD) or a commercial provider.

Where it lives: the utility billing / CIS system (typically SAP IS-U / S/4HANA Utilities, Wilken ENER:GY, Schleupen, other regional systems), the meter data management system, the CRM, and e-mail or the customer portal for customer-reported readings.

Typical gaps: many estimated readings, missing move-in readings, split histories after supplier or meter changes, price data kept as PDFs, no flag for heat pump or PV, and a customer portal that does not capture readings.

Preparation steps: 1. Export three to five years of readings, bills and price history per contract (see PREP-005). 2. Mark real versus estimated readings and handle meter exchanges and moves. 3. Build a price-change table by date and component, and a weather table by postcode region. 4. Define the business rules for Abschlag changes (thresholds, rounding, maximum jump) and write them down (PREP-016). 5. Build a hold-out set of last year's bills with known actual consumption for backtesting (PREP-018). 6. Restrict access to customer consumption data (PREP-023).

Tools: the billing system's reporting export, Python (pandas, scikit-learn, LightGBM), a spreadsheet.

Rough share of effort: about 35 percent of the project, mostly reading history and price data cleaning. See GUIDE-003.

Implementation paths

Which path for whom

• SMB (small Stadtwerk, energy supplier) - Path B: a small data science service on top of a billing export plus a hosted LLM for the letters. Few vendors sell this as a stand-alone product.
• Enterprise (larger utilities) - Path B: same pattern, integrated into the CIS with process automation and approval rules; often delivered by the CIS vendor or a utility IT service provider.
• Developer - Path C: open-source forecasting stack and a small self-hosted LLM, as product builders serving several utilities.

Path A - Buy

• Billing and CIS vendors and utility IT service providers (SAP for Utilities, Wilken, Schleupen and regional IT subsidiaries) increasingly offer forecasting or "intelligent Abschlag" modules; check what is real forecasting versus a rule on last year's consumption.
• Customer-portal and energy-data products (consumption displays, load-profile analytics) may cover parts.
• Choose A when: your CIS vendor already ships the module and the price is acceptable. Expect limited transparency about the model.

Path B - Build on cloud APIs (recommended)

• Forecast: managed AutoML or a small own service (gradient boosting per segment). No LLM needed.
• Explanation: an EU-hosted LLM API with a template and the computed figures as inputs; output is checked for numbers and tone.
• Integration: read-only export from the billing system first; later a batch interface or process automation (n8n, Power Automate, SAP BTP) for write-back after approval.
• Choose B when: you want control over rules and explanation without building a platform.

Path C - Self-host

• Stack: Python with LightGBM / statsforecast, the open standardlastprofile R package or own implementation of the BDEW profiles [3], Open-Meteo or DWD open data for weather, a small open LLM (7-8B class) for letter drafts.
• Hardware: HW1 is enough for the forecast and for a small LLM at batch speed.
• Choose C when: customer data must not leave the own data centre, which is common for municipal utilities, or when serving several utilities as a product.

Path D - Custom training

Usually not needed. Customer-level models trained on the utility's own history are standard tabular ML and are covered by path B/C; a custom deep model only pays off for very large customer bases or for smart-meter data at 15-minute resolution.

State of the art (2026)

• Forecasting: tree-based models with weather and household features are the robust baseline; time-series foundation models help with short histories. Smart-meter data (where the rollout has reached the customer) clearly improves individual forecasts.
• Standard profiles are evolving: the 2025 electricity profiles add PV and battery households and monthly values [3], reflecting that the old H0 profile no longer fits all customers.
• Explanation by LLM works well when numbers are inserted from the calculation; free generation of figures is a known failure mode.
• Limits: weather in the remaining year is unknown, so the band is wide in winter for gas; moves, a new heat pump or an electric car break the history; price shocks are not predictable from consumption data. Few utilities have documented production results for individual AI-based Abschlag forecasts; treat this as early-adopter, not mainstream.
• Not solved: automatic, unattended write-back to the billing system, and fairness testing across customer groups, are still mostly manual.

Shared resources & combinations

• Highest leverage inside a Stadtwerk (what to do together): the same consumption forecast, weather feed and cleaned meter history feed several use cases at once. Build the data foundation once:
• PRED-007 (load and generation forecasting) aggregates the same customer-level forecasts for procurement and balancing energy, so Abschlag forecasts and portfolio forecasts reuse one model.
• PRED-031 (smart-meter disaggregation and personalised saving tips) shares the meter data and adds the "how to lower your bill" part of the explanation.
• PRED-003 (churn) and PRED-021 (payment behaviour and collections) use the same customer table; an Abschlag change is both a churn trigger and a dunning risk, so check them together.
• PRED-016 (cash-flow forecasting) benefits directly from more accurate advance-payment inflows.
• CONV-001 (customer chatbot) answers "why did my Abschlag go up" with the same explanation and lets customers enter readings; LANG-012 routes the related mails.
• AGENT-040 (market-communication clearing agent) uses the same billing and master data access and the same CIS integration work.
• Same stack: tabular-ml + time-series + llm-general; one small VM serves all of the above.

Effort, cost & KPIs

• Path A: weeks if the CIS vendor offers it; licence cost depends on the contract.
• Path B: 2-4 months for export, backtest, rules and letter templates; write-back adds integration effort. Running cost is small (hosting and LLM tokens for batch letters).
• Path C: similar effort plus modest operations effort.
• KPIs: mean absolute error of the forecast versus the annual bill, share of customers with a back payment or refund above a threshold, number of customer calls and complaints about Abschläge, manual hours for adjustments, share of changes accepted without edit, cash-flow variance.

People & change

Involve early: the head of customer service / billing as process owner, IT for the CIS interface, the data owners of the readings and price data, and the DPO. Management sets the fairness rules (for example a maximum monthly jump and a hardship policy). Customer service staff must see and trust the suggestion.

Works council: depends. The forecast concerns customers, not employees, but the workflow logs who accepts or changes proposals and could be used to measure clerks, which can trigger §87(1) no. 6 BetrVG; §90 BetrVG requires timely information about AI-supported work processes. Municipal utilities in public ownership involve the Personalrat. A short agreement excluding individual performance evaluation usually settles it (GUIDE-004).

AI literacy: Art. 4 AI Act requires measures for AI literacy; give clerks a short training on the uncertainty band, reasons for a deviation and when to override (GUIDE-006).

Communication and pilot: start with one tariff and one region, run the proposal in parallel to the current process for one billing cycle, compare against actual bills, and name one champion (GUIDE-008, GUIDE-009).

Typical concerns: fear that automation raises Abschläge to improve liquidity (guard: rule that the amount follows the forecast and the legal criteria, with an audit log), fear of errors (limits on changes, human review), customer trust (clear, honest explanation and an easy way to enter a reading).

Humans in control: the customer can always report a reading or credibly show lower consumption [1]; a clerk decides all exceptions.

Risks, regulation & compliance

• Energy law: §41b Abs. 3 EnWG on the basis of the Abschlag, adjustment for credibly lower consumption and due date not before delivery start [1]; refund handling per the Bundesnetzagentur [2]; price-change notices must follow the transparency rules in §41 EnWG; for basic supply the StromGVV / GasGVV apply. Legal text and case law change; verify with legal counsel.
• EU AI Act: minimal risk. The system does not decide on access to essential services or credit; it sets a payment instalment inside a legal rule. Do not turn it into a creditworthiness or disconnection decision, which would move it toward Annex III. AI literacy duty (Art. 4) applies.
• GDPR: consumption data is personal data and can reveal habits (presence, working hours); legal basis is contract performance (Art. 6(1)(b)); DPIA is advisable when smart-meter data at high resolution is used; data processing agreement for cloud and LLM providers; data minimisation (daily instead of 15-minute data where enough).
• Fairness and transparency: avoid features that proxy for protected characteristics; the customer must be able to understand and contest a change.
• Mitigations: limits on jump size, human approval for large changes, audit log, backtests per segment, monitoring of forecast error, numbers always from the calculation.

Getting started

1. Measure the baseline: how many Abschlag changes per month, hours spent, share of annual bills with large back payments or refunds, related complaints.
2. Export three years of readings, bills and prices for one tariff and clean them.
3. Backtest a simple benchmark (last year's consumption) against a gradient-boosting forecast with temperature and price features on last year's annual bills.
4. Define the Abschlag rules and a letter template; let an LLM draft the text from the computed figures.
5. Pilot in parallel with the current process for one billing cycle, then decide on write-back.

Sources

1. rewis.io - § 41b EnWG, Voraus- und Abschlagszahlungen (Abs. 3) - https://rewis.io/gesetze/enwg/p/41b-enwg/
2. Bundesnetzagentur - Abschläge (Anpassung, Guthaben, Beschwerde) - https://www.bundesnetzagentur.de/DE/Vportal/Energie/PreiseAbschlaege/Abschlaege-table.html
3. standardlastprofile - BDEW standard load profiles (H0, H25, P25, S25) and gas SigLinDe method (R package) - https://github.com/flrd/standardlastprofile
4. stromauskunft.de - How the Abschläge on the electricity bill are computed and when they can change - https://www.stromauskunft.de/blog/verbraucher/stromrechnung-abschlaege-muessen-konstant-bleiben/