Energy market-communication clearing agent (GPKE, GeLi Gas, MaBiS, Redispatch 2.0)

Every German Stadtwerk exchanges standardised EDIFACT messages with grid operators, suppliers and metering operators for supplier switching, meter data, balancing and feed-in. When a message is rejected or data do not match, the case lands in the "Clearing" (Klaerfall) queue, where specialists trace it by hand through billing system, master data and mailbox. An agent can read the rejection, classify it, find the cause in the source systems and draft the right answer. Today this is realistic as a decision-support copilot; autonomous sending is early and needs deep, utility-specific integration.

Problem & value

• Today: a market-communication back office (Marktkommunikation) works through APERAK rejections, clearing lists, plausibility failures and deadline-bound reply processes. Each case needs lookups in the billing system, the metering-point master data and often the process description. In larger utilities this is a dedicated team; in a Stadtwerk it is a few people who also carry EEG and Redispatch 2.0 settlement. The gap analysis behind this entry estimates about 60 h per month for clearing and about 30 h per month for EEG/Redispatch 2.0 settlement in a typical Stadtwerk (internal estimate, not a measured benchmark).
• AI value: faster triage (right team, right deadline), a ready explanation of the likely cause instead of blank-page research, drafted replies in the correct message format, and less dependence on one expert's memory of the rules.
• Pressure: the rules keep moving. The BDEW publishes an Umsetzungsfragenkatalog (current published version 1.11, valid from 1 October 2022) covering GPKE, GeLi Gas, WiM, MaBiS, MPES, grid-operator switching and over/under-quantity billing [1]. Redispatch 2.0 is being developed further by Bundesnetzagentur decision BK6-23-241 of 07.05.2026 on the balancing of redispatch measures (BilAReM); check the decision text for the exact rules and dates [2]. The future MaBiS-Hub and a possible hub-based electricity market communication from 2032 (a study of options, not a decision) mean today's clearing practice will change again [3][4].
• Evidence: no independent benchmark for AI in energy clearing was found. Savings figures here are estimates; measure your own baseline first.

Variants

• Supplier-side clearing (Vertrieb): rejections of registrations, cancellations, meter-reading and invoice disputes (UTILMD, MSCONS, INVOIC/REMADV).
• Grid-operator-side clearing (Netz): answering suppliers, plausibility of meter data, grid-usage billing.
• Balancing (MaBiS): reconciling balancing-group time series and differences with the grid operator.
• EEG feed-in and Redispatch 2.0: matching plant master data, resource IDs and balancing model with the connection grid operator, reconciling settlement data.
• Metering-point operator (MSB): rejected orders and master-data mismatches around smart-meter rollout.

How it works

1. inbound EDIFACT / email / portal case (APERAK, CONTRL, clearing list)
2. parse message (message type, process step, reference IDs, error codes)
3. classify (error class, responsible party, process and deadline)
4. gather evidence (billing system, metering-point and plant master data, earlier messages)
5. retrieve rules (process description, BDEW Anwendungshilfe, in-house playbook)
6. diagnose (likely cause + confidence, deterministic checks first)
7. draft action (corrected message, reply to partner, internal correction ticket)
8. clerk review and release (four-eyes on anything that changes master data or sends a message)
9. send via existing MaKo system + audit log

• Deterministic first: EDIFACT parsing, code lists and format checks are rules, not LLM work. The LLM explains, classifies free-text clearing emails, links evidence and drafts text.
• Tool use: read-only queries against billing system and master data; write actions only as drafts.
• Human-in-the-loop: release by a clerk; auto-send only for narrow, proven case classes after a long shadow period.

Data preparation

Which data: a history of rejected messages with the final resolution, metering-point and plant master data, the contract and balancing-model data, partner (market-role) master data, and the current BDEW/BNetzA process descriptions and message guides.

Where it lives: the billing and MaKo system (SAP IS-U / SAP S/4HANA Utilities, Wilken ENER:GY, Schleupen SchleupenCS, others), the shared MaKo mailbox, a ticket system or Excel clearing lists, and PDF process documents.

Typical gaps: resolutions are rarely written down in structured form; master data are inconsistent between billing system, GIS and metering; knowledge is held by one or two clerks; message versions change on fixed dates so old examples may be wrong.

Preparation steps: 1. Export two to three years of rejected messages with the clerk's resolution (see PREP-005, PREP-020). 2. Define error classes together with the clerks and label a test set of 200-300 cases (PREP-018, PREP-019). 3. Build a curated rule base from the current process descriptions and your own playbook (PREP-013). 4. Mark each rule with its valid-from date, because messages are versioned. 5. Clean up metering-point and plant master data mismatches that cause repeat rejections (DATA-003). 6. Pseudonymise customer data in exports used for development (PREP-022).

Tools: EDIFACT parsers and code-list validators, billing-system export, spreadsheet for the test set.

Rough share of effort: high, 40-50 percent of the project, most of it integration and rule curation. See GUIDE-003.

Implementation paths

Which path for whom

• SMB (Stadtwerk) — Path B: few off-the-shelf AI products cover clearing; the realistic route is a small build on cloud APIs in an EU region, read-only on the billing system, or a service provider's add-on.
• Enterprise (large utility, MaKo service provider) — Path B: volume justifies integration with the MaKo platform and own evaluation; strong governance.
• Developer (software vendor) — Path C: vendors of billing and MaKo software embed self-hosted open models in their products.

Path A — Buy

• MaKo and billing platforms: SAP IS-U / Utilities, Wilken, Schleupen and regional IT service providers (Rechenzentren of Stadtwerke associations) offer clearing workbenches with rule-based support. AI features are mostly roadmap or pilot in 2026; ask for production references.
• Choose A when: your platform vendor ships a clearing assistant that works on your version.

Path B — Build on cloud APIs

• Models: an EU-hosted LLM or a frontier model in an EU region with structured output, for classification, explanation and draft text.
• Orchestration: an agent framework or n8n-style workflow with read-only connectors to billing system, mailbox and master data; drafts are written back as tickets.
• Choose B when: you have an IT team or partner who can build the integration and an evaluation set.

Path C — Self-host

• Stack: open-weight LLM (roughly 30B class) plus retrieval over the rule base on one workstation or pro GPU (HW2-HW3), EDIFACT parsing in code.
• Choose C when: customer data may not leave the premises or you build a product for many utilities.

Path D — Custom training

Fine-tune a small classifier on your labelled rejection history (error class, responsible party). Only worth it above several thousand cases per year; a few hundred labelled cases already help.

State of the art (2026)

• Mature: rule-based validation of EDIFACT, code lists and APERAK error codes; LLM text classification and explanation of free-text clearing emails.
• Early: agents that follow a clearing case across billing system, master data and message history and draft the correct reply. We found no independent evidence of production use in German utilities; treat vendor claims with caution.
• Not yet advisable: unattended sending of messages. Wrong messages trigger counter-reactions from partners, deadline breaches and wrong settlements.
• Moving target: the electricity rules change at fixed dates (GPKE, MaBiS, Redispatch 2.0 balancing; check the decision for dates), and the BNetzA is working on a hub-based future [2][3][4]. Rule bases must be versioned and refreshed.
• Limits: LLMs can invent rule references or code meanings; every statement must cite the source rule or system record.

Shared resources & combinations

• Same stack (agent-framework + workflow-automation): AGENT-004 order entry, AGENT-006 reconciliation and AGENT-021 data entry reuse connectors and review UI.
• Legacy UI: where the billing system has no API, AGENT-003 (computer-use) is a fallback, with the risks that brings.
• Classification and routing: LANG-012 and DOC-014 for clearing emails and PDF attachments.
• Governance: AGENT-025 for agent monitoring, AGENT-018 for compliance control logs.
• Domain neighbours: ANOM-008 (meter and grid anomalies), OPT-022 (redispatch optimisation on the grid side), PRED-007 (feed-in forecasts relevant for Redispatch 2.0 planning values).
• Best leverage together: clean master data (DATA-003) prevents rejections in the first place, which saves more than any agent that processes them.

Effort, cost & KPIs

• Path A: weeks of configuration if the vendor feature exists; add-on licence.
• Path B: 4-9 months for a read-only copilot including integration, evaluation set and a shadow period.
• Path C/D: 6-12 months plus operations effort.
• Cost drivers: integration with the billing system and rule-base upkeep, not model fees.
• KPIs: share of cases correctly classified, time to first diagnosis, share of drafts accepted unchanged, deadline breaches, repeat rejections per month, hours per clearing case.

People & change

Involve early: the head of market communication as process owner, IT/billing administrators, the data-protection officer and the IT-security officer (KRITIS or NIS2 relevance is likely for larger utilities); also legal/compliance for liability toward partners (GUIDE-005, GUIDE-010).

Works council: depends. Review logs show who corrected and released what, which can monitor performance under §87(1) no. 6 BetrVG; §90 BetrVG requires information on AI-supported work. Agree that logs are not used for individual evaluation (GUIDE-004).

AI literacy: Art. 4 AI Act requires measures for staff; train clerks on confidence, verifying cited rules and reporting wrong proposals (GUIDE-006).

Communication and pilot: present it as relief for a scarce expert team, not replacement; pilot with one case class (for example one recurring APERAK error) in shadow mode for 4-8 weeks, name an AI champion (GUIDE-008, GUIDE-009).

Typical concerns: fear that expert knowledge is devalued, fear of wrong messages to partners (four-eyes release), and dependence on the billing-system vendor.

Humans in control: no message sent and no master data changed without release.

Risks, regulation & compliance

• Market rules: GPKE, GeLi Gas, WiM and MaBiS are set by Bundesnetzagentur decisions (Beschlusskammer 6); deadlines and message formats are binding. Wrong or late messages can have settlement and regulatory consequences.
• EU AI Act: minimal risk for back-office clearing; critical-infrastructure safety components are not involved as long as the agent does not control grid operation. AI literacy duty (Art. 4) applies.
• GDPR: metering-point data, consumption and customer data are personal data; legal basis, AVV (Art. 28) with any provider, EU processing. Consumption profiles are sensitive in practice; the MaBiS-Hub procedure itself centres on pseudonymisation of meter data [3].
• Security: energy suppliers handle critical data; check NIS2 / IT-security-catalogue obligations and restrict the agent to read-only access plus drafts.
• Vendor lock-in and change: message formats and processes change on fixed dates; contracts must cover updates.
• Mitigations: versioned rule base with citations, shadow mode, restricted write rights, audit log, regular evaluation on fresh cases.

Getting started

1. Measure the baseline: clearing cases per month, error classes, hours per case, deadline breaches.
2. Identify the five most frequent rejection causes and check whether better master data can remove them.
3. Build the labelled test set and run a read-only classifier and explainer in shadow mode.
4. Ask your billing and MaKo vendor and IT service provider what they already ship and what API access exists.
5. Extend to drafted replies for the best-performing case classes; consider auto-send only after months of clean results.

Sources

1. BDEW — Umsetzungsfragenkatalog zur Marktkommunikation (BK6-20-160), covering GPKE, GeLi Gas, WiM, MaBiS, MPES — https://www.bdew.de/service/anwendungshilfen/umsetzungsfragenkatalog-zur-marktkommunikation-bk6-20-160/
2. Bundesnetzagentur — Redispatch / Einspeisemanagement (BK6-20-059, BK6-23-241 and related notices) — https://www.bundesnetzagentur.de/DE/Beschlusskammern/BK06/BK6_84_Sys_Dienst/844_redispatch/redispatch_node.html
3. Bundesnetzagentur — MaBiS-Hub procedure (BK6-24-210) — https://bundesnetzagentur.de/DE/Beschlusskammern/BK06/BK6_83_Zug_Mess/845_MaBiS_Hub/BK6_MaBiS_Hub_node.html
4. Bundesnetzagentur — Notice on the future of electricity market communication (BK6-25-000) — https://www.bundesnetzagentur.de/DE/Beschlusskammern/1_GZ/BK6-GZ/2025/BK6-25-000/2025-07-09_Hinweis_Zukunft_MaKo_Strom.html