Uploading Consumption Interval Data

The consumption stage models everything — production, dispatch, the whole financial model — against the site's real interval data, so getting the upload right matters more than any other input. This guide covers every file format the upload accepts, working examples of each, and how to fix a file that refuses to go in.

What the Upload Accepts

• Vertical CSV — one row per interval, with a timestamp column and a kWh column. Date and time can be split across two columns instead of combined into one. Extra columns are fine; the mapper lets you pick which ones matter.
• Horizontal CSV — one row per day, with interval readings laid out across the columns (00:00, 00:30, 01:00, and so on). This is the shape most retailer portals export.
• Excel (.xlsx) — multi-tab workbooks are fine. The sheet with the most data wins, so you don't need to delete the other tabs first.
• Raw NEM12 — upload the file as-is, no conversion needed. If it carries more than one register, a picker appears so you choose which one to import. When the file also carries a solar export (B) register with real readings, the app suggests routing that register to Existing Solar instead of discarding it.
• Intervals — 5, 15, 30 or 60-minute readings are all accepted. When intervals need to be resampled to a coarser length, the readings are always summed, never averaged — a kWh reading is energy, not power.
• Dates — ISO (2025-07-01), slashed Australian (01/07/2025) and dotted (01.07.2025) formats are all recognised. Where a slashed or dotted date is ambiguous, day-first is assumed, matching how every Australian bill and meter export writes dates.
• Size — files up to 25MB upload directly.
• Net vs gross — “Meter (net)” means the meter reading already has any existing solar export netted out of it. If the site has existing solar, say so on the Consumption page so the model can reconstruct gross site load from the net meter reading instead of treating net usage as the whole story.
• One register per upload (non-NEM12) — a stacked multi-register export needs a single register chosen before the upload is used. Registers measure different things — consumption, export, reactive power — and summing them overstates usage rather than describing the site accurately.
• NMI cross-check — when the file carries an NMI, it's compared against the NMI on the bill already entered for the project. A mismatch is a warning, not a block — it flags that you may have uploaded the wrong site's file, but the upload still proceeds either way.

Example Formats That Work

Vertical, combined timestamp

timestamp,kwh
2025-07-01 00:00,12.4
2025-07-01 00:30,11.9
2025-07-01 01:00,11.2

Why this works: one reading per row, an unambiguous timestamp, and a kWh column that reads as energy per interval rather than an average power figure.

Vertical, split date and time

date,time,usage_kwh
01/07/2025,00:00,12.4
01/07/2025,00:30,11.9
01/07/2025,01:00,11.2

Why this works: the mapper combines the two columns into one timestamp, and the day-first slashed date is recognised automatically.

Horizontal, one row per day

date,00:00,00:30,01:00,01:30
01/07/2025,12.4,11.9,11.2,10.8
02/07/2025,13.1,12.2,11.5,11.0

Why this works: the header row names each interval's start time, and every row is a complete day of readings.

NEM12 fragment

100,NEM12,202507011200,RETAILER,MDA
200,6123456789,E1,E1,E1,N1,01009,kWh,30,
300,20250701,12.4,11.9,11.2,10.8,...,A,,,20250702120000
900

Why this works: the 200-record names the NMI and register (E1 = import), and each 300-record carries a full day of readings — upload the file untouched, exactly as the meter or portal produced it.

Convert Any File with Claude

If a retailer or metering-portal export doesn't match any of the shapes above, paste the file (or its text) into Claude with this prompt and it will do the conversion for you:

You are converting an electricity interval-data file into the simplest format the
Amperage consumption upload accepts. I will give you a file (CSV, Excel export,
NEM12, or anything else from a retailer or metering portal).

Output ONLY a two-column CSV with a header row:
timestamp,kwh
- timestamp: YYYY-MM-DD HH:MM, the START of each interval, in local time.
- kwh: energy used in that interval in kilowatt-hours (energy per interval,
  NOT average power / kW).

Rules:
1. Keep only grid-import consumption. If the file has several registers or
   streams (e.g. E1 consumption, B1 solar export, K/Q reactive), keep the
   import (E) register only. NEVER add registers together.
2. If the file covers more than one meter or NMI, keep only one (tell me which
   you kept). Never mix NMIs.
3. If you must change interval length, SUM the readings into the coarser
   interval — never average them. Do not invent finer intervals.
4. Preserve every interval in chronological order. Do not fill gaps with
   invented data; just leave missing intervals out.
5. Plain numbers only: full stop as the decimal separator, no thousands
   separators, no units in cells, no negative consumption (if consumption is
   negative, you probably picked an export or net stream — stop and tell me).
6. No footer/summary rows, no blank rows, no metadata rows.

Before the CSV, state in one line: which column/register you used, the interval
length, and the date range. Then output the CSV in a code block.

When the Upload Complains

Multiple registers found

A raw NEM12 file carries more than one register — typically an import (E) and an export (B), sometimes reactive (K/Q) as well. Pick the import register for consumption; if a solar export register is present, the export-suggestion card lets you route it to Existing Solar in one click instead of discarding it.

Stacked registers in one column

This is the non-NEM12 version of the same problem: a single column mixes readings from more than one register or meter. Choose the one register that represents grid-import consumption in the register picker — summing them all together overstates usage, sometimes drastically.

Couldn't map the columns

The upload found data but couldn't confidently identify which column is the timestamp and which is the kWh reading — often because of unusual header names or an unfamiliar layout. Map the columns manually on the Map columns step, or use the “Help me map this” button, which asks Claude to read the file and suggest a mapping for you to check.

Unparseable timestamps

Some rows have a timestamp the parser can't read — a stray header row repeated partway down the file, or a footer/summary row with no real reading. The fix action lets you skip past the bad row and reprocess; if the whole file uses a date convention the parser hasn't recognised, the Claude prompt above will normalise it for you.

Register isn't an import register

The register selected measures something other than grid-import consumption — a solar export (B) or reactive (K/Q) register. Choose an E (import) register instead; if the file only has an export register, you're looking at a solar-generation export, which belongs on the Existing Solar section, not the Consumption upload.

NMI doesn't match the bill

The NMI printed on the interval file doesn't match the NMI on the bill already entered for this project. This is advisory only — it never blocks the upload — but it's worth a second look before you save, since it usually means the file was pulled for the wrong site.

Unsupported file

The file isn't a CSV, Excel workbook, or raw NEM12 file, or it uses a decimal-comma convention (e.g. 12,4 instead of 12.4). The upload deliberately refuses to guess between a decimal comma and a thousands comma — re-export the file with a full stop as the decimal separator, or run it through the Claude prompt above, which normalises numbers as part of the conversion.