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

# German Market Domain Model

> Control areas, balancing groups, schedules, quarter-hours and the home area

## Control areas and balancing groups

Germany's transmission grid is divided into four TSO **control areas**
(Regelzonen):

| Control area | TSO                  |
| ------------ | -------------------- |
| `50Hertz`    | 50Hertz Transmission |
| `Amprion`    | Amprion              |
| `TenneT`     | TenneT TSO           |
| `TransnetBW` | TransnetBW           |

n:lead operates **one balancing group (Bilanzkreis) per control area** for
the customer. A balancing group is a virtual energy account with its TSO:
all physical in-feeds/out-takes and all commercial schedules of the
portfolio in that area are booked into it.

<Warning>
  A balancing group must **net to zero for every quarter-hour**. Residual
  imbalances are settled at the imbalance price (Ausgleichsenergie) — the
  entire purpose of this service is to nominate schedules that avoid that.
</Warning>

## What a schedule contains

A balancing-group **schedule** consists of:

* the **production forecast** of the portfolio in that area (in-feed),
* the **consumption forecast** (off-take),
* **all trades with counterparties**: the EPEX/ECC exchange delivery (home
  group only) and the cross-control-area transfers between our own groups.

Trades are **aggregated per direction and counterparty**: for each
counterparty there is at most one incoming and one outgoing series, values
are non-negative, and a negative flow simply appears in the opposite
direction. A correct schedule sums to zero at every interval:

```text theme={null}
production − consumption + trades = 0
```

The physical side (load, generation) is allocated into the balancing group
by the DSOs/TSO based on metering — the BRP does not nominate it; the
forecasts in the schedule are the BRP's declared expectation of it. n:lead
computes these quantities from your data and submits the resulting
schedules to the TSOs.

## Quarter-hours and daylight saving

Everything is quarter-hourly in **Europe/Berlin**, local midnight to
midnight:

| Day type                                 | Intervals |
| ---------------------------------------- | --------- |
| Normal day                               | **96**    |
| Spring-forward day (02:00→03:00 skipped) | **92**    |
| Fall-back day (02:00–03:00 twice)        | **100**   |

The service computes the expected count from the timezone database and
rejects forecasts with any other length — a 96-value forecast for a DST day
is a validation error, not something to silently pad.

## One bidding zone, one home area

Germany is a **single day-ahead bidding zone**: the EPEX day-ahead trade is
one volume for the whole German position. Physical delivery (via ECC, the
exchange's clearing house) lands in **one** balancing group — the **home
balancing group**, in a home control area agreed as part of your setup.

That creates the central distribution problem this service solves: the other
three balancing groups never see the exchange delivery directly, so the home
group must pass their share on via **matched cross-control-area transfer
pairs** (out of home / into target). How the quantities are derived is on the
[Core Algorithm](/concepts/algorithm) page.

## Sign conventions

| Quantity        | Positive means                                        |
| --------------- | ----------------------------------------------------- |
| `net`           | long / surplus (production exceeds consumption)       |
| `open_position` | must **buy**                                          |
| `total_open`    | Germany buys on EPEX                                  |
| trade series    | flow in the direction stated (`in`/`out`), values ≥ 0 |