Accuracy

How the inputMethod, load profile, and feed-in data affect the reliability of scan results — and which combinations deliver the best predictions.

Accuracy tiers

The accuracy of scan results depends primarily on how well the engine knows the property's hourly consumption pattern. We distinguish two tiers based on the inputMethod:

Tier	Input method	Stars	What the engine knows
Studio	`"studio"`	★★★★★	Real measured consumption at 15-min or hourly resolution
Known	`"known"`	★★★★	Exact annual total (from energy bill), but generic hourly shape

Each tier affects the hourly consumption[h] array used in the 8,760-hour simulation. Since self-consumption, self-sufficiency, and savings all depend on the hour-by-hour overlap between production and consumption, the load profile shape is the single most important accuracy driver.

Studio profile

With inputMethod: "studio", you provide a customProfileId that references a pre-uploaded load profile via the Studio API:

The engine uses the exact measured values for each hour of the year. This captures:

Evening peaks from cooking and EV charging
Weekend patterns (typically higher daytime consumption)
Seasonal variation (heating, lighting, holidays)
Baseload from always-on appliances

This is the gold standard for accuracy. Self-sufficiency predictions are typically within ±2–3% of actual performance.

Studio input

{
  "inputMethod": "studio",
  "customProfileId": "clx1234...",
  "yearlyKwh": 5200
}

The yearlyKwh field is still accepted with studio profiles, but it is overridden — the engine always derives the actual annual kWh from the profile's hourly sum and writes it back to the scan metadata. The profile shape is never scaled to match the provided yearlyKwh.

Known consumption

With inputMethod: "known", you provide the annual consumption in kWh (typically from the energy bill) but no hourly breakdown:

Known input

{
  "inputMethod": "known",
  "yearlyKwh": 5200
}

The engine generates a synthetic load profile by scaling a standard Dutch residential consumption curve to match the provided yearlyKwh. The standard curve captures typical patterns (morning/evening peaks, seasonal variation) but does not reflect household-specific behaviour.

Accuracy impact: Annual totals (savings, payback) are typically within ±10–15% of actual. Hourly metrics (self-sufficiency) may deviate by ±5–8 percentage points due to the generic load shape.

Gross load reconstruction

When a property has existingPv (existing solar panels), the engine must reconstruct the gross load — the total consumption the household would have without any solar. This is critical because:

Meter data and energy bills reflect net consumption (after solar self-consumption)
The optimizer needs gross consumption to correctly model adding or replacing panels
Without reconstruction, self-consumption from existing PV would be double-counted

All flows use the same universal formula:

gross[h] = max(0, import[h] − export[h] + production[h])

Why import − export + production?

Think of your electricity meter during a single hour. It records:

import — power drawn from the grid (what you buy)
export — power sent to the grid (solar surplus you sell)

Meanwhile, your solar panels produce production kW. Part of that production is consumed immediately (self-consumption), and the rest is exported. Your actual total consumption is:

consumption = import + self_consumption

Since self_consumption = production − export, we get:

consumption = import + (production − export)
          = import − export + production

The max(0, ...) clamp handles small numerical mismatches between weather model and actual solar output that could produce negative values.

Hourly energy balance

┌─────────────────────────────┐
│        Solar panels         │
│     production = 3.2 kW     │
└──────┬──────────────┬───────┘
       │              │
  self-consumed    exported
    2.0 kW         1.2 kW
       │              │
       ▼              ▼
┌─────────────┐  ┌─────────┐
│  Household  │  │  Grid   │
│  load: 3.5  │←─│ import  │
│     kW      │  │ 1.5 kW  │
└─────────────┘  └─────────┘

gross = 1.5 − 1.2 + 3.2 = 3.5 kW ✓

Source of each term

The three variables come from different sources depending on how the scan was created:

Source	`import`	`export`	`production`
Studio — template + solar	Studio `result` (net import per hour)	Studio `exportResult`	Studio `productionResult`
Studio — P1 + export	Raw P1 meter import (hourly)	Raw P1 meter export (hourly)	Calculated from panel specs + weather data
Studio — P1 import-only	Raw P1 meter import (hourly)	`0` (no export column)	Studio `productionResult`
Known + `yearlyExportKwh`	Standard profile scaled to `yearlyKwh`	`yearlyExportKwh` distributed hourly using solar production shape	Calculated from panel specs + weather data
Known, no export	Standard profile scaled to `yearlyKwh`	`0` (not provided)	Calculated from panel specs + weather data

When no export data is available, the formula simplifies to gross[h] = import[h] + production[h]. This assumes all solar production is self-consumed, which overestimates gross load slightly. Providing yearlyExportKwh (from the energy bill's "teruglevering") corrects this.

Feed-in data impact

Export data directly affects the accuracy of gross load reconstruction — it's not just a nice-to-have, it's used in the core formula.

Studio profiles (hourly export)

Smart meter P1 data can include both import and export columns at hourly resolution. When available, the engine uses the actual metered export in the reconstruction formula. This is the most accurate path because both sides (import and export) come from real measurements.

Known consumption (`yearlyExportKwh`)

When using inputMethod: "known" with existingPv, you can provide yearlyExportKwh — the annual feed-in total from your energy bill ("teruglevering"). The engine distributes this annual total across 8,760 hours using the calculated solar production shape:

export[h] = (production[h] / annual_production_sum) × yearlyExportKwh

This proportional distribution assumes export happens when the sun shines — a reasonable approximation that significantly improves gross load accuracy compared to assuming zero export.

Impact comparison

Export data	Gross load quality	Why
Hourly meter export (studio P1)	★★★★★	Real per-hour measurements
`yearlyExportKwh` (known)	★★★★	Annual total distributed using calculated solar production shape
No export data	★★★	Assumes all solar self-consumed — overestimates gross

Accuracy by scenario

Combining input method, existing PV, and feed-in data:

Scenario	Input method	Existing PV	Export data	Overall accuracy
Studio + no existing PV	`"studio"`	No	N/A	★★★★★
Studio + existing PV + export data	`"studio"`	Yes	Yes	★★★★★
Studio + existing PV, no export	`"studio"`	Yes	No	★★★★
Known + no existing PV	`"known"`	No	N/A	★★★★
Known + existing PV	`"known"`	Yes	Optional	★★★

View the full scan creation API