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

# Settlement Management

> Handles the complete settlement lifecycle

The Engrate Settlement Management API gives you one integration surface for DE and NL settlement workflows. It is designed for BRPs, VPPs, and flexibility operators that need deterministic processing, strong validation, and auditability across market-specific rules.

For BRPs without direct grid connections, settlement is balance-group centric: you work with nominated and allocated portfolio positions rather than meter-operator tasks. This page focuses on what your integration must ingest, validate, and reconcile in each market.

### Settlement views

<Frame caption="Settlement tab overview">
  <img src="https://mintcdn.com/engrate/bWsQb7-p0XQV47Ll/images/settlement-overview.png?fit=max&auto=format&n=bWsQb7-p0XQV47Ll&q=85&s=dea93f5da875cfa38b054dd7274d450b" alt="Settlement overview tab" width="1024" height="693" data-path="images/settlement-overview.png" />
</Frame>

<Frame caption="Control energy prices view">
  <img src="https://mintcdn.com/engrate/bWsQb7-p0XQV47Ll/images/settlement-prices.png?fit=max&auto=format&n=bWsQb7-p0XQV47Ll&q=85&s=c2d43c6285a937b029d34e284fe93788" alt="Settlement prices tab" width="1024" height="693" data-path="images/settlement-prices.png" />
</Frame>

<Frame caption="Aggregation object configuration view">
  <img src="https://mintcdn.com/engrate/bWsQb7-p0XQV47Ll/images/settlement-configuration.png?fit=max&auto=format&n=bWsQb7-p0XQV47Ll&q=85&s=4d6c2cdbbc1d39e2467043f4803bfc8d" alt="Settlement configuration tab" width="1024" height="693" data-path="images/settlement-configuration.png" />
</Frame>

## DE vs NL at a glance

| Topic                | Germany (DE)                                                                | Netherlands (NL)                                                                      |
| -------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| Regulatory model     | MaBiS role/process model                                                    | TenneT imbalance and MMC-Hub model                                                    |
| Main operating focus | Balance-group and clearing lifecycle across NB/LF/BKV/BIKO                  | ISP-level imbalance and pricing exchange with TenneT                                  |
| Core BRP data        | Supplier aggregate and clearing list flows with explicit status progression | `A20` imbalance series, `A19` adjustment series, plus supporting informational series |
| Message pattern      | Structured process exchanges with formal status states and clearing loops   | SOAP technical receipt + asynchronous acknowledgement + correction/re-issue flow      |
| Time handling        | Process deadlines and versioned settlement states                           | UTC + `PT15M` intervals with `92/96/100` DST day handling                             |
| Typical BRP concern  | Data-state consistency and clearing outcomes                                | Imbalance/adjustment correctness and settlement amount traceability                   |

## Germany (DE) - MaBiS-oriented settlement for BRPs

In DE, settlement is process- and role-driven. For BRP integrations, the key counterparties are **NB**, **LF**, **BKV**, and **BIKO**.

### What matters for a BRP without grid connection

* **Role-based exchange:** data and corrections move between defined market roles, not via direct grid-operation flows.
* **State-based lifecycle:** BIKO-managed states (for example `Pruefdaten` and `Abrechnungsdaten`) define processing stage and settlement readiness.
* **Built-in reconciliation loops:** clearing and validation feedback are part of normal operation, including manual clarification in specific cases.
* **Versioned traceability:** state changes and payload revisions must remain auditable end-to-end.

### DE implementation focus in this API

* Ingest and version DE settlement payloads.
* Expose reconciliation and objection workflows on top of process states.
* Keep a full audit trail from draft to settlement-grade records.

## Netherlands (NL) - TenneT BRP imbalance settlement

In NL, BRP settlement is driven by the imbalance process and strict message validation in the TenneT ecosystem.

### What matters for a BRP without grid connection

* **Imbalance-first model:** settlement is computed per ISP from program vs allocation, then adjusted by activated services.
* **Core series contract:** `A20` is the settlement base, `A19` is the aggregated adjustment, with supporting informational series as needed.
* **Two-step validation path:** technical receipt first, functional acknowledgement second; rejected payloads are corrected and re-issued.
* **Strict temporal rules:** UTC intervals, `PT15M`, and DST-aware `92/96/100` interval days.

### NL implementation focus in this API

* Normalize TenneT/MMC-hub exchanges into actionable API states.
* Validate business-type semantics and interval completeness before downstream processing.
* Provide explicit breakdowns for imbalance, adjustments, and pricing.

## Why this helps BRPs without grid connections

* You run settlement from market documents and balancing series without building separate DE/NL process engines.
* You use consistent API primitives for validation, reconciliation, objections, and traceability across both markets.
* You keep regulatory fidelity while maintaining a single integration layer.

<Note>
  **Regulatory basis used**

  This section reflects DE MaBiS process guidance and TenneT NL implementation guides for Schedule and Aggregated Imbalance Information.
</Note>

<Card title="API reference" icon="code" horizontal href="/api-reference/settlement-management/overview">
  Explore how to interact with the Settlement Management API
</Card>