How peer matching works

Peer matching compares a project against similar projects to identify whether its costs appear unusually high or low. This page describes the current matching rules used by the system.

Metrics checked

Initial cost per primary unit

Compares the project’s initial cost divided by its primary functional unit.

Lifecycle cost per primary unit

Compares the project’s lifecycle cost divided by its primary functional unit.

The system aims to find at least 12 suitable peer projects before producing a reliable comparison.
How matching expands:
The system searches in nested stages. It starts with the closest match and only broadens the search if fewer than 12 usable peers are found.
  • First, it tries the closest size band.
  • Within that size band, it tries same function, then any function.
  • Within each function stage, it tries same country, then same country group, then global.
  • Within each geography stage, it tries same reporting year, then ±2 years, then ±5 years, then any reporting year.

If enough peers are found at any stage, the system stops and uses that peer set.

View country groups used for peer matching

Order of peer matching

Peer matching is applied in a fixed order:

Order Criterion How it expands Explanation
1 Size band 80%-125% of reference size 67%-150% of reference size 50%-200% of reference size Any size The system starts with the closest size range, then widens the acceptable project size if too few peers are found.
2 Function Same function Any function If the project type has a Function attribute and the reference project has a value, the system first tries to match the same function. It then relaxes this requirement.
3 Geography Same country Same country group Global The system first looks in the same country, then the same country group, then globally.
4 Reporting year Same reporting year Within 2 years Within 5 years Any reporting year Within each size/function/geography stage, the system first looks for projects from the same reporting year, then widens the year range.
Example: the system first tries projects of a similar size, with the same function, in the same country, and from the same reporting year. If that does not produce enough peers, it widens the reporting-year range first within that same size/function/geography stage. Only after all reporting-year options have been tried for that combination does it move to the next geography/function/size stage.

Location matching

The system prefers peers from the same country. If there are not enough matches, the geographic constraint is gradually relaxed.

Stage Rule Description
Same country country Peers must be from the same country as the reference project.
Same country group country_group If too few peers are found, the search expands to countries in the same geographic country group.
Global global Country and country group are no longer used as filters if insufficient peers are available.

Projects excluded from matching

  • The project itself is excluded from its own peer group.
  • Projects without usable cost data are excluded.
  • Projects without a usable primary unit value are excluded.
  • Projects with a different project type may be excluded depending on the matching stage.
  • Projects that are not visible to the current user are excluded or anonymised according to access rules.

Size matching bands

The system starts by looking for projects of a similar size. If too few peers are found, it broadens the size range step by step.

Stage Internal rule Size range Description
Closest size match size_0.8-1.25 80% - 125% of reference Peers between 80% and 125% of the reference project size.
Broader size match size_0.67-1.5 67% - 150% of reference Peers between 67% and 150% of the reference project size.
Wide size match size_0.5-2.0 50% - 200% of reference Peers between 50% and 200% of the reference project size.
Any size size_any Any size Size is no longer used as a filter if too few peers are available.

How to interpret the result

  • Peer matching is intended as a benchmarking guide, not a valuation or audit conclusion.
  • A project may be an outlier for valid reasons such as specification, abnormal site conditions, scope differences, procurement route or local market conditions.
  • If project costs or attributes change, the peer check should be refreshed.