Why Census figures in .id tools can differ from the ABS website

If a Census figure in an .id tool doesn't match QuickStats or the General Community Profile on the Australian Bureau of Statistics (ABS) website, one of four things is usually behind it.

The ABS adjusts Census counts at random to protect confidentiality. .id and the ABS sometimes use different Census variables for what looks like the same measure. .id builds its areas to follow your LGA’s chosen custom boundaries, not ABS ones. And the Census counts the same population in more than one way. Knowing which applies helps you decide which source to use, as neither is more accurate than the other.

Key concepts

1. Random adjustment

To protect confidentiality, the ABS randomly adjusts Census values by a small amount, including the totals in tables. The ABS calls this introduced random error or perturbation. The ABS describes this process for the 2021 Census. It has a negligible effect on the underlying pattern of the statistics, but in ABS tables you may notice two effects. The rows or columns of a table may not add exactly to its total. And a table for a large area may not equal the sum of the tables for the areas inside it. Since 2016 the ABS has supplied the same total for a population whichever way it is classified, and advises using that total.

.id adds up the components of a table to produce its total, rather than using the total the ABS supplies. This is so percentages always add to 100% (except in multi-response variables like Ancestry and Long-term health conditions). It means an .id total can differ slightly from the ABS provided total for the same table – you’ll find that you can’t get percentages adding to 100% using the ABS table.

Small counts carry the most error relative to their size. Don't rely on any figure under 10 (these small counts are also subject to the most non-sampling error in the Census - people make mistakes on Census forms), and treat percentages calculated from small counts with care, because a small adjustment can change them a lot. This also applies to change over time, as the perturbation may be applied in different ways from one Census to the next, even if a number hasn’t changed, it can appear to have changed as a result.

2. A different variable

QuickStats and .id tables sometimes draw on different Census variables or combinations of categories for what looks like the same measure. For example, the ABS may publish a variable called 'Highest educational attainment', which has similar categories to 'Non-school qualification' but combines some school and non-school qualifications, and so will provide slightly different figures. They also in many cases use a different total population for a table. For example, when publishing dwelling counts by dwelling structure, the ABS include only occupied dwellings as standard, while .id’s categories include all dwellings. This can have a large effect in areas with a lot of unoccupied dwellings.

3. Geography

.id builds your small areas from a range of geographies starting from SA1 level, so they follow your council's boundaries and not the ABS standard areas. .id cuts a suburb that crosses your LGA boundary at the edge, so the .id figures cover only the part inside your council's area, unless you've specifically asked to include areas outside. .id also cuts SA1s where a small area boundary crosses them, and apportions population differently in earlier years depending on the number of dwellings either side of a boundary at the time. An .id suburb and the ABS suburb of the same name (the ABS calls these Suburbs and Localities) won't match when the suburb crosses your boundary, and in some cases don’t match exactly even when they don’t, as ABS Suburbs and Localities are a best fit geography themselves. See How small areas are built in Community Profile and Social Atlas.

4. Different counts of the same population

The Census count comes in two forms, and Community Profile reports both.

Usual residence counts people at their usual address (where they live or intend to live for six months or more at the time of Census). It's the basis for every person characteristic, including age, ancestry, income and travel to work, where comparisons are done back as far as 2001.
Enumerated counts people where they were on Census night. It's the basis for dwelling and household counts such as household income and tenure type, and for person counts when comparing back to 1996 and 1991 when UR counts were not available.

Usual residence counts aren't available before 2001, so comparisons that reach further back use the enumerated basis. Each table in Community Profile shows its reference population in the box at the top right. That's either usual residence or enumerated and, in some cases, a subset such as people aged 15 and over or people born overseas.

The ABS often refer to household counts as Usual Residence, though technically they are enumeration counts. That’s because household types are coded including information about people temporarily absent on Census night. E.g. a couple where one partner is away on Census night will be recorded correctly as a couple based on usual residence, and not a lone person household. But the absent person will be counted on an enumeration basis wherever they are.

Estimated Resident Population (ERP) is a third figure, and while based originally on Census, it is not considered part of the Census dataset. It's the ABS's estimate of how many people usually live in an area, adjusted for people missed in the count and for residents temporarily away. ERP is usually higher than the Census usual residence count, but not necessarily higher than the enumerated count in areas with many visitors. After each Census, the ABS revises the previous five years of ERP, and it makes minor revisions to earlier years at every annual release. For help choosing between the figures, see Which population figure should I use in Community Profile?

How to tell which reason applies to your figure

Work through the figure in this order.

In Community Profile, check the reference population in the box at the top right of the table. If one source uses usual residence and the other enumerated, you're comparing different counts.
Check the geography. If the area is a suburb that crosses your LGA boundary, an ABS suburb of the same name will differ. Sometimes SA2s have the same name as a suburb but a different area as well. Check the boundary used via a map if needed.
Check the variable. If both sources claim the same measure, find out whether they use the same Census variable. On the ABS version, there may be a footnote like 'Excludes non-classifiable households', which is a sure sign that it has been treated differently. Also check .id’s data notes for the topic for similar information.
Check the numerical difference. If it’s small (<10 or so) it’s likely just due to random adjustment.

If none of these explains the gap, email support@id.com.au for help to work it out.

Frequently asked questions

Q: Why don't the categories in a table add up to the total?

A: The ABS applies a small random adjustment to every Census table, so in an ABS table a breakdown won't always add exactly to its total, which is closer to the 'true' population. In .id tables, the total is the sum of the components, so a breakdown does add to its total, meaning the total doesn’t always match ABS exactly. The adjustment is there so no individual can be identified by subtracting one table from another.

Q: Can I trust small numbers?

A: Not on their own. Don't rely on any figure under 10. Small counts are the most affected by random adjustment, and the effect on percentages calculated from them can be large. The effect on change over time can also be larger than individual adjustments if they are adjusted in different directions.

Q: Why do Social Atlas and Community Profile give different totals?

A: They're built from different ABS tables (which include randomisation), so the totals can differ slightly. For a total usual resident or enumerated population, use the population summary table in Community Profile.

Q: Why does adding up my suburbs give a different number to the LGA?

A: Each small area carries its own adjustment, so the errors build up as you add them. The LGA figure is closer to the truth than the sum of its suburbs, so use it for an LGA total (while .id adds categories to derive a total in a classification, we don’t do this for geography, so we’ll use the provided total in any category for the LGA rather than adding small areas).

In any population of more than 1,000 people, these differences in total counts are normally statistically insignificant. If you're comparing Estimated Resident Population rather than Census counts, see Which population figure should I use in Community Profile?