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.

How the Upload Works

• Drop the file on the Consumption page — anywhere on the page works, or use Choose file. There is no separate wizard and no Save button: the file is read, checked and saved as soon as it reads, and Undo upload puts the project back the way it was.
• Columns are found for you — the column-mapping form only appears when the date or the reading column can't be identified. Change how it's read (on the file row) lets you correct a column, the units (kWh, Wh or average kW) or whether timestamps mark the start or end of each interval.
• One review, three questions — right meter (NMI, register or sheet used), right period (how much of the bill period the data covers) and clean (anything worth fixing). A clean file with no choices to make skips the review and goes straight to the profile.
• Fixes are always your call, and each has its own Undo — Divide by 1,000 for readings exported in Wh, Review and cap for one-off spikes, Fill from similar days for missing intervals, Treat as outage for all-zero days. Undoing a fix also undoes any fix that was calculated on top of it.
• Bill coverage is the share of the bill period's days that have measured readings. Below 100% bill-based checks use only the overlapping days; at 0% they can't run, so check the file or the bill dates.

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 rows is read first, and the review lists every sheet so you can pick a different one without editing the workbook.
• Raw NEM12 — upload the file as-is, no conversion needed. If it carries more than one register, the import (E) register is used and the review lists the others so you can change it. A solar export (B) register can be sent to Existing Solar instead of discarded. The next upload for the same NMI reuses your choice.
• 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. The simulation runs hourly, but a sub-hourly file also keeps its own peak per month, day type and hour, and the demand-charge saving is scaled to those peaks so a 30-minute spike the hourly average smooths away is not counted as shaved. Projects uploaded before this was added pick it up on the next upload of the interval file.
• 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.
• More than a year — a file with two years of readings is kept whole; pick which 12 months to model in the review (latest 12 months, the 12 months ending with the bill, or the two years averaged).
• 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 check in the review, not a block — replace the file, fix the NMI on Bill Data, or confirm it's the same site.

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. The import register is used for consumption; change it under Right meter? in the review. If a solar export register is present, Use for Existing Solar routes it there 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. The import register is used by default; pick a different one under Right meter? in the review — 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. Nothing is saved until it reads: pick the two columns in the form that appears, or use “Help me map this”, 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, 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.