Skip to main content
This guide walks through how Schedule Management works end-to-end — the mental model behind the endpoints, not just a list of operations.

​
What is a schedule?

In the European electricity market, balance responsible parties (BRPs) must declare their planned energy flows to the relevant Transmission System Operator (TSO) before delivery. These declarations are called schedules (Fahrpläne in German, programma’s in Dutch). A schedule declares, per quarter-hour interval, how much energy will flow between parties and across control areas. The TSO uses these to plan grid operations and, after delivery, to settle imbalances between what was declared and what actually happened. The Schedule Management API abstracts away the differences between markets. You submit through a single API — the platform handles ESS XML generation for Germany, CIM XML for the Netherlands, AS4 delivery, and TSO-specific validation rules.

​
Lifecycle of a schedule

​
1. Creation

Call POST /schedules with your market, TSO, delivery date, and one or more time series. The platform validates your submission — EIC codes must be registered, interval counts must match the delivery date (accounting for DST), and gate closure rules are enforced.

​
2. Document generation and delivery

The platform converts your API request into the market-specific format (ESS XML for Germany, CIM XML for the Netherlands) and submits it via AS4 to the TSO’s message broker. You can track delivery progress through the Delivery Status endpoint.

​
3. TSO response

The TSO processes your schedule and responds with a series of messages:
  • ACK — the TSO received your document (acceptance level: ack)
  • CNF — the TSO confirmed or rejected your values (acceptance level: cnf). A partial CNF (cnf_partial) means some series were accepted and others rejected.

​
4. Anomaly reports

After the schedule matching process, the TSO may send ANO messages indicating mismatches between your values and the counterparty’s values. These appear as Anomaly records on your schedule.

​
5. Reconciliation

Use the Reconciliation endpoint to get a side-by-side view of your values versus the counterparty’s, including per-interval deltas and exchange priority flags.

​
Versioning model

Each Schedule can have multiple Versions. Re-submitting for the same TSO + delivery date creates a new version rather than overwriting the previous one. Why versions exist:
  • Corrections — fix values rejected by the TSO
  • Updates — adjust values based on updated forecasts before gate closure
  • Intraday revisions — some TSOs accept revised schedules after the day-ahead gate
The TSO message ID is reused with a _v{N} suffix. When a new version is accepted, previous versions are marked is_active=false.

​
Markets and TSOs

​
Germany (DE)

German schedules use ESS XML format and are delivered via Mako365 AS4. The day-ahead gate closes at D-1 14:30 CET.
TSOIdentifierReceiver EIC
50Hertz50HERTZ_DE_TSO10XDE-VE-TRANSMK
AmprionDE-AMPRION-TSO10XDE-RWENET---W
TenneT DETTG_DE10XDE-EON-NETZ-C
TransnetBWDE-TRANSNETBWTSO10XDE-ENBW--TNGX
Series types: internal, external, foreign, production, consumption. External and foreign series require a market_agreement_id and are subject to the DA matching gate.

​
Netherlands (NL)

Dutch schedules use CIM XML format and are delivered via the MMC Hub. The day-ahead window runs from D-2 10:00 to D-1 15:00 CET.
TSOIdentifierReceiver
TenneT NLTENNET_TSO8716867111163 (EAN-13)
NL uses EAN-13 codes for party identification instead of EIC X codes.

​
Exchange priority

Exchange priority (Börsenvorrang) is a German mechanism where certain balance groups — typically exchange-connected traders — can impose their schedule values on counterparties. When an anomaly involves a counterparty with exchange priority, the discrepancy is resolved in their favour per Bilanzkreisvertrag clause 12.b. Use the reference endpoints to check exchange priority status:
  • GET /reference/exchange-priority-balance-groups — list all balance groups with exchange priority
  • GET /reference/exchange-priority-check/{eic_code} — check a specific EIC code

​
Anomalies and reconciliation

After the TSO completes schedule matching, anomaly reports (ANO documents) identify mismatches. Common causes:
  • Counterpart missing (reason code A09) — the other party didn’t submit a matching series
  • Values don’t match (reason code A54) — both parties submitted but with different values
  • DST adjustment (reason code B45) — values were adjusted for a DST transition
The reconciliation endpoint provides a structured comparison. For each affected series, you get your submitted values, the counterparty’s values, and per-interval deltas. Series with exchange priority are flagged so you know which anomalies to act on and which to ignore.

​
Audit trail

Every lifecycle event is captured in the Audit Log with before/after state snapshots, event metadata, and correlation IDs. This provides full traceability for compliance and debugging.
See the Schedule Management API Overview for a quick reference of all endpoints and supported markets.