Skip to main content
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

Settlement overview tab
Settlement prices tab
Settlement configuration tab

​
DE vs NL at a glance

TopicGermany (DE)Netherlands (NL)
Regulatory modelMaBiS role/process modelTenneT imbalance and MMC-Hub model
Main operating focusBalance-group and clearing lifecycle across NB/LF/BKV/BIKOISP-level imbalance and pricing exchange with TenneT
Core BRP dataSupplier aggregate and clearing list flows with explicit status progressionA20 imbalance series, A19 adjustment series, plus supporting informational series
Message patternStructured process exchanges with formal status states and clearing loopsSOAP technical receipt + asynchronous acknowledgement + correction/re-issue flow
Time handlingProcess deadlines and versioned settlement statesUTC + PT15M intervals with 92/96/100 DST day handling
Typical BRP concernData-state consistency and clearing outcomesImbalance/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.
Regulatory basis usedThis section reflects DE MaBiS process guidance and TenneT NL implementation guides for Schedule and Aggregated Imbalance Information.

API reference

Explore how to interact with the Settlement Management API