Renewable Energy Communities (REC)¶
A Renewable Energy Community (REC, or Comunidade de Energia Renovável in Portuguese) is a legal entity established under Decreto-Lei 15/2022 that allows a group of energy participants to collectively share locally produced renewable energy.
Key Concepts¶
| Term | Definition |
|---|---|
| Member | A legal entity that belongs to the REC. A member may be responsible for a DSO meter and/or own resources within the REC |
| Resource/Asset | Any electrical consumption or generation asset (house, PV plant, battery, EV charger, etc.) |
| CPE | Código de Ponto de Entrega — the unique ID of a DSO smart meter connection point |
| LEM | Local Energy Market — peer-to-peer trading between REC members |
| CSC | Collective Self Consumption — collective self-consumption means to share energy collectively between different members of a community. |
REC Structure in RECreation¶
A community is built from a tree of CPE meters, optional internal meters, and the resources they power. Each CPE meter is visible to the DSO and has a responsible member and retailer contract; internal meters always sit behind a CPE and are only visible to the asset owner(s) and the REC manager. Resources attach either directly to a CPE or to an internal meter, and can be owned fully by one member or shared between several with percentage splits.
%%{init: {"themeVariables": {"fontSize": "20px"}, "flowchart": {"nodeSpacing": 45, "rankSpacing": 60, "padding": 14}}}%%
graph TD
REC[Community - REC]
REC --> CPEA["CPE meter: PT0002...A (Member A)"]
REC --> CPEB["CPE meter: PT0002...B (Member B)"]
REC --> CPEC["CPE meter: PT0002...C (Member C)"]
REC --> CPED["CPE meter: PT0002...D (Member D)"]
CPEA --> RA["Resource: House (Member A 100%)"]
CPEB --> IMB["Internal meter: Meter B-1"]
IMB --> RB["Resource: Shared PV (Member B 60% / Member C 40%)"]
CPEC --> RC["Resource: House + PV (Member C 100%)"]
CPED --> IMD1["Internal meter: House meter"]
CPED --> IMD2["Internal meter: PV meter"]
CPED --> IMD3["Internal meter: Battery meter"]
IMD1 --> RD1["Resource: House (Member D 100%)"]
IMD2 --> RD2["Resource: PV (Member D 100%)"]
IMD3 --> RD3["Resource: Battery (Member D 100%)"]
Valid and Invalid CPE Structures¶
A CPE meter may have either a single resource directly attached or one or more internal meters, each with its own resource — but not a mix of both, and never more than one resource attached directly.
%%{init: {"themeVariables": {"fontSize": "20px"}, "flowchart": {"nodeSpacing": 45, "rankSpacing": 60, "padding": 14}}}%%
flowchart TB
subgraph g1["✅ OK: CPE with a resource"]
direction TB
C1[CPE meter] --> R1[Resource]
end
subgraph g2["❌ Not OK: CPE with two resources"]
direction TB
C2[CPE meter] --> R2a[Resource]
C2 --> R2b[Resource]
end
subgraph g3["✅ OK: CPE with an internal meter and its resource"]
direction TB
C3[CPE meter] --> I3[Internal meter]
I3 --> R3[Resource]
end
subgraph g4["❌ Not OK: internal meter + resource directly on the CPE"]
direction TB
C4[CPE meter] --> I4[Internal meter]
C4 --> R4a[Resource]
I4 --> R4b[Resource]
end
subgraph g5["✅ OK: two internal meters, each with its own resource"]
direction TB
C5[CPE meter] --> I5a[Internal meter]
C5 --> I5b[Internal meter]
I5a --> R5a[Resource]
I5b --> R5b[Resource]
end
classDef ok fill:#e6f4ea,stroke:#2e7d32,stroke-width:2px;
classDef notok fill:#fdecea,stroke:#c62828,stroke-width:2px;
class g1,g3,g5 ok
class g2,g4 notok
Top-Level Workflow¶
The typical flow from community creation to billing is:
%%{init: {"themeVariables": {"fontSize": "20px"}, "flowchart": {"nodeSpacing": 45, "rankSpacing": 60, "padding": 14}}}%%
flowchart LR
A[Create Community] --> B[Create Members]
B --> C[Create Meters]
C --> D[Create Contracts per CPE]
D --> E[Create Resources/Assets]
E --> F[Upload Meter Data per ISP]
F --> G[Market Clearing]
G --> H[Settlement]
H --> I[Billing Guide]
- Create Community — define name, type, allocation method, and pricing mechanism
- Create Members — add the legal entities that form the REC
- Create Meters — configure DSO meters (CPEs) and optional internal meters for complex structures
- Create Contracts — configure the retailer/aggregator contract for each CPE
- Create Resources/Assets — register all generation, storage, and consumption assets, including their meter association and ownership shares
- Upload Meter Data — provide 15-minute measurement data for each ISP
- Market Clearing — the LEM algorithm matches buyers and sellers
- Settlement — financial computation of revenues and costs per member
- Billing Guide — generate PDF/Excel reports for each member
Market Rates¶
RECreation supports multiple internal pricing mechanisms:
| Rate | Description |
|---|---|
VANILLA_INTERMEDIATE_MARKET_RATE |
Internal price tracks the OMIE day-ahead market reference |
FIXED_PRICE |
Fixed bilateral price set per community |
VANILLA_SDR |
Internal price tracks supply-demand ratio |
VANILLA_CV |
Internal price tracks crossing value |
BILATERAL_PRICE |
Member-to-member bilaterally agreed prices |
TREE_DNAC |
Tree Dynamic Allocation — decision-tree algorithm for dynamic allocation coefficients, used in Promoter-Anchor business models |
Note
Additional market rate types may be available. Query GET /communities/{community_id} for
the full list of supported rates for your deployment.
Community Configuration¶
Key fields when creating or reading a community:
| Field | Type | Required | Description |
|---|---|---|---|
name |
string | ✅ | Name of the community |
type |
string | ✅ | PROD (real licensed REC) or DEMO/SIMULATION |
method_alloc_coeff |
string | ✅ | Energy allocation method: PROPORTIONAL, FIXED, or DYNAMIC |
market_rate |
string | — | Pricing mechanism (required for LEM transactions) |
market_divisor |
float | — | Fraction applied to market price (default 0.5) |
market_compensation |
float | — | Compensation factor for sellers (default 0.5) |
lem_trading_fee |
float | — | Flat fee paid by sellers per LEM transaction |
settlement_sale_price_type |
string | — | INDIVIDUAL or AGGREGATED surplus settlement price |
transaction_adjustment_tolerance |
float | — | Tolerance for adjustment corrections |
phone |
string | — | Contact phone number of the community manager |
address |
string | — | Address of the community manager |
nif |
string | — | Fiscal/VAT number of the community entity |
start_date |
date | ✅ | First day (inclusive, Europe/Lisbon) on which this configuration applies |
end_date |
date | — | Last day (inclusive) on which this configuration applies. null = open-ended |
Dated configuration
The allocation, market, settlement and status fields are kept as a dated history. Updating
them with PUT /communities/{community_id} requires a start_date and only changes the
configuration from that day on (or for [start_date, end_date]). Name, identifier, phone,
address and NIF are not dated: they always show their current value. Read the
configuration for another day with GET /communities/{community_id}?effective_at=YYYY-MM-DD.
See Business Validity.
Allocation Coefficient Methods¶
The method_alloc_coeff field controls how shared energy is distributed among members:
| Method | Description |
|---|---|
PROPORTIONAL |
Each member receives energy proportional to their consumption share |
FIXED |
Each member has a pre-defined fixed coefficient |
DYNAMIC |
Coefficients are updated dynamically based on real-time data |