> ## Documentation Index
> Fetch the complete documentation index at: https://docs.engrate.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Schedule Lifecycle

> How energy schedules move from creation through TSO acceptance to anomaly reconciliation

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

```mermaid theme={null}
%%{init: {'theme': 'base'}}%%
flowchart TD
    create["Create schedule\nPOST /schedules"]
    validate["Platform validates\nEIC codes, intervals,\ngate closure"]
    build["Build market document\nESS XML (DE) or CIM XML (NL)"]
    deliver["Submit via AS4\nMako365 (DE) or MMC Hub (NL)"]
    nrr["NRR received\ndelivery confirmed"]
    ack["ACK from TSO\ndocument acknowledged"]
    cnf["CNF from TSO\nvalues accepted or rejected"]
    ano["ANO from TSO\nanomaly report"]
    reconcile["Reconciliation\ncompare values"]

    create --> validate
    validate --> build
    build --> deliver
    deliver --> nrr
    nrr --> ack
    ack --> cnf
    cnf --> ano
    ano --> reconcile
```

### 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. Tracking delivery progress through the Delivery Status endpoint is coming soon.

### 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](/api-reference/schedule-management/models/exchange-priority) flags.

## Versioning model

Each [Schedule](/api-reference/schedule-management/models/schedule) can have multiple [Versions](/api-reference/schedule-management/models/schedule-version). 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**.

| TSO        | Identifier         | Receiver EIC       |
| ---------- | ------------------ | ------------------ |
| 50Hertz    | `50HERTZ_DE_TSO`   | `10XDE-VE-TRANSMK` |
| Amprion    | `DE-AMPRION-TSO`   | `10XDE-RWENET---W` |
| TenneT DE  | `TTG_DE`           | `10XDE-EON-NETZ-C` |
| TransnetBW | `DE-TRANSNETBWTSO` | `10XDE-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**.

| TSO       | Identifier   | Receiver                 |
| --------- | ------------ | ------------------------ |
| TenneT NL | `TENNET_TSO` | `8716867111163` (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 favor 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](/api-reference/schedule-management/models/audit-log) with before/after state snapshots, event metadata, and correlation IDs. This provides full traceability for compliance and debugging.

<Tip>
  See the [Schedule Management API Overview](/api-reference/schedule-management/overview) for a quick reference of all endpoints and supported markets.
</Tip>