> ## Documentation Index
> Fetch the complete documentation index at: https://docs.salvidia.com/llms.txt
> Use this file to discover all available pages before exploring further.

# What good data looks like

> What a usable record contains, why units and reporting periods cause most errors, and the checks worth running on a file before you trust anything in it.

Most bad footprints are not caused by bad maths. They are caused by a file that looked fine, went in cleanly, and was wrong in a way nobody checked for.

This page covers what a usable record contains, the two things that cause most errors, and what to check before you trust a file.

## What a complete record contains

Any figure you collect needs six things attached to it. Miss one and the record is either unusable or, worse, usable but wrong.

| Element                       | Why it matters                                                  |
| ----------------------------- | --------------------------------------------------------------- |
| **What**                      | The activity: electricity, diesel, landfill waste, a flight     |
| **How much**                  | The quantity, as a number                                       |
| **In what unit**              | kWh, litres, tonnes, km. Without this the number is meaningless |
| **For which site or entity**  | So it reconciles against your boundary                          |
| **Over exactly which period** | Start and end dates, not just a year label                      |
| **From which source**         | The bill, report, or export it came from                        |

That last one is what makes an inventory auditable. A number nobody can trace back to a document is a number you cannot defend, however accurate it happens to be.

## Units cause most errors

A quantity without its unit is not data. And the same activity is routinely billed in different units by different suppliers, which is where the errors come from.

The ones that catch people out:

* **Gas** is billed in megajoules, kilowatt-hours, or cubic metres depending on the retailer. These differ by more than an order of magnitude. Always carry the unit across from the bill rather than assuming.
* **Waste** arrives in kilograms from some contractors and tonnes from others. A thousandfold error here is easy to make and hard to spot, because both numbers look plausible on their own.
* **Refrigerants** are quoted in kilograms of a named gas. The gas type matters as much as the quantity, since global warming potentials differ enormously between them.
* **Distance** can be miles rather than kilometres, particularly from overseas suppliers.
* **Flights** may be logged one way or return. A return flight recorded as a single leg halves that emission.
* **Freight** is often needed as tonne-kilometres, which almost nobody has directly. You derive it: weight in tonnes multiplied by distance travelled. A carrier giving you consignment weights and routes has given you enough.

The rule that prevents nearly all of this: **record the unit the source gave you, and convert afterwards.** Converting in your head while transcribing is where errors enter, and once converted the original is gone.

## Periods cause the rest

Reporting years are neat. Billing periods are not, and the mismatch produces errors that survive review because every individual figure looks correct.

**Bills rarely align to your reporting year.** A quarterly bill running 15 June to 14 September straddles an Australian financial year end. You apportion it by days, and you note that you did.

**Invoice date is not service date.** An invoice issued in July for June consumption belongs to June. Sorting a ledger export by invoice date will silently shift a month of energy into the wrong year.

**Estimated meter reads get corrected later.** Many bills are estimates, reconciled when an actual read happens. If you collected the estimate and the actual arrived afterwards, your figure is stale and the correction may be sitting in a later bill.

**Twelve months does not mean twelve bills.** Monthly billing often produces thirteen invoices in a year, or eleven. Count the days your bills cover, not the number of documents.

## A good record and a bad one

Same site, same quarter, same underlying consumption.

**Weak:**

> Sydney office electricity, 2025, about 40,000 kWh

Three problems. "2025" could be calendar or financial year. "About" means somebody estimated and did not record how. And there is no source, so nobody can check any of it.

**Usable:**

> Sydney HQ, 42,180 kWh, 1 April 2025 to 30 June 2025, from retailer portal export dated 12 July 2025, actual read, 100% GreenPower under contract EN-4471

Everything is here: site, quantity, unit, exact period, source, whether the read was actual, and the contract that determines the market-based figure. A reviewer can verify every element without asking you a question.

You will not always achieve the second version. When you cannot, write down which parts are missing rather than rounding the gap away.

## Check a file before you trust it

Five checks catch nearly everything, and they take minutes.

1. **Do the totals reconcile?** Sum the file and compare against the bill or report total. If they differ, something was filtered, duplicated, or dropped in export.
2. **Is anything off by a factor of a thousand?** Scan for values that are wildly larger or smaller than their neighbours. That pattern is almost always kg entered where tonnes were expected, or the reverse.
3. **Do the sites match your boundary?** Compare the site list in the file against the entities in your assessment. A site in the file that is not in your boundary means one of the two is wrong.
4. **Are any periods duplicated or missing?** Sort by date and look for overlaps and gaps. Overlaps double count. Gaps understate.
5. **Does it pass the plausibility test?** An office of forty people using the electricity of a small factory is a data problem, not a discovery. If a figure surprises you, check it before you record it.

## When the data does not arrive

Sometimes it will not, and the assessment still has to be finished.

Estimate from the best proxy available: a comparable site, a comparable period, floor area, headcount, or an industry benchmark. Then record three things: what you estimated, the method you used, and why the actual figure was unavailable.

A documented estimate is accepted practice under every standard. A blank is not, because a blank reads as zero, and zero asserts that the emissions do not exist. That assertion is far harder to defend than an approximation with a note attached.

## Where to go next

* [How to collect your data](/collecting-data/how-to-collect)
* [Requesting data from other people](/collecting-data/requesting-data)
* [Working with data in Salvidia](/platform/working-with-data)