Skip to content

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]
  1. Create Community — define name, type, allocation method, and pricing mechanism
  2. Create Members — add the legal entities that form the REC
  3. Create Meters — configure DSO meters (CPEs) and optional internal meters for complex structures
  4. Create Contracts — configure the retailer/aggregator contract for each CPE
  5. Create Resources/Assets — register all generation, storage, and consumption assets, including their meter association and ownership shares
  6. Upload Meter Data — provide 15-minute measurement data for each ISP
  7. Market Clearing — the LEM algorithm matches buyers and sellers
  8. Settlement — financial computation of revenues and costs per member
  9. 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