> ## 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.

# Balancing Sums

> The TSOs' daily preview of the smart-meter part of the portfolio: the BK-SZR of Kategorie C

Every day, for the day before, the transmission system operator (TSO)
sends the balance responsible party (BRP) the **Bilanzkreissummenzeitreihen
of Kategorie C** (BK-SZR, MaBiS code `ZA0`). There is one per control area
and Zeitreihentyp. Each covers the market locations whose aggregation the
TSO carries for our balancing group: smart meters (iMS) balanced on
quarter-hour values, once their network operator has handed the
aggregation to the TSO. The TSO activates the series when the first such
market location is assigned to the balancing group, and sends it **every
calendar day for the previous day by 13:00**, weekends and holidays
included.

The series is informational: MaBiS does not use it in settlement, which
runs on the monthly Kategorie A/B series. It is the earliest view of what
the smart-meter part of the portfolio actually consumed or fed in. That
makes it the input for checking the forecast of those customers.

`GET /v1/sum-time-series/category-c?date_from=YYYY-MM-DD[&date_to=YYYY-MM-DD]`

Use the same key as for `POST /v1/forecasts`.

```bash theme={null}
curl "$NLEAD_BASE_URL/v1/sum-time-series/category-c?date_from=2026-10-01&date_to=2026-10-07" \
  --header "X-API-Key: $NLEAD_API_KEY"
```

| Parameter | Meaning |
| - | - |
| `date_from` | First delivery day (German calendar day); at most 180 days back — a `422` names the earliest day |
| `date_to` | Last delivery day, inclusive. Defaults to `date_from`; at most 31 days per call and at most 31 days ahead of today |

The answer has one entry per delivery day, and per day one entry per
series. In the example below, `values` and `statuses` are cut to four of
the 96 entries.

| Field | Meaning |
| - | - |
| `control_area` / `control_area_eic` | The control area the TSO formed the sum for |
| `balancing_group_eic` | The balancing group; `sub_balancing_group` names a sub-balancing group (e.g. `CLOOVER_GRUEN`), `null` for the main one |
| `series_type` | Zeitreihentyp: `LGS` measured consumption, `EGS` measured feed-in, … |
| `metering_point` | The MaBiS metering point (Zählpunkt) of the series |
| `sender_mp_id` | Who sends it: the TSO |
| `unit` | `kWh` — **energy per quarter hour**, not average power |
| `values` | One value per quarter hour of the German day (96, 92 or 100), in order; `null` where nothing has arrived yet |
| `statuses` | The MSCONS qualifier of each value: `220` true value, `67` substitute value, `Z18` provisional, `Z30` missing — the TSO formed the sum with values missing, so it is a lower bound |
| `complete` | Every quarter hour has a value and none is marked `Z30` |
| `total` | Sum of the received values, `Z30` quarter hours included |
| `quality_codes` | The distinct qualifiers in `statuses` |
| `received_at` / `message_references` | When the latest message for the day arrived, and the messages behind it |

```json theme={null}
{
  "category": "C",
  "date_from": "2026-10-13",
  "date_to": "2026-10-13",
  "days": [
    {
      "delivery_day": "2026-10-13",
      "interval_count": 96,
      "series": [
        {
          "control_area": "TenneT",
          "control_area_eic": "10YDE-EON------1",
          "balancing_group_eic": "11X0-0000-0929-3",
          "sub_balancing_group": null,
          "series_type": "LGS",
          "metering_point": "4033872000058BKA00000067718950TLG",
          "sender_mp_id": "4033872000058",
          "obis": "1-1:1.29.0",
          "unit": "kWh",
          "values": [0.0, 0.0, 0.0, 0.0],
          "statuses": ["220", "220", "220", "220"],
          "received_intervals": 96,
          "complete": true,
          "total": 0.0,
          "quality_codes": ["220"],
          "received_at": "2026-10-14T12:37:00+02:00",
          "message_references": ["TB184815634A"]
        }
      ]
    }
  ]
}
```

Things to know:

* **Listed before it arrives.** A series appears for every day its
  metering point is activated, whether or not values have arrived. Until
  the TSO sends the day, `values` holds `null` and `complete` is `false`.
  After a deactivation it is listed only on days for which the TSO still
  sends values; if it is activated again, it is listed again from the new
  start.
* **Corrections replace.** If the TSO sends a quarter hour again, the
  later value replaces the earlier one, and `received_at` moves with it.
* **Only part of the portfolio.** The series covers only the market
  locations the TSO aggregates. It does not cover customers on
  standard load profiles (SLP/TLP), customers with conventional meters, or
  smart-meter customers whose aggregation is still with the network
  operator. Compare it only with the forecast share of the customers it
  covers. A whole-portfolio forecast would show a standing gap that is not
  forecast error.
* **Converting to your forecast's unit.** The values are energy per quarter
  hour in `unit`, normally kWh. If your forecast is in `MW` (average power),
  divide the kWh by 250 (÷1000 to MWh, ×4 for the quarter hour). If it is
  in `MWH` (energy per quarter hour), divide by 1000.
* **History.** The bridge reads the messages of the last 180 days. A
  `date_from` before that is refused with `422`, naming the earliest day
  available; the messages are listed on the
  [troubleshooting page](/api-reference/troubleshooting).
* **Read-only.** Calling the endpoint sends nothing to the market. A sandbox
  key works the same way.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.