Sold Comparables API: Building Valuation Evidence

A nearby sale is not automatically a comparable. The house across the road might have twice the floor area, a large extension or a different tenure. A flat in the same postcode may sit in a newer block with parking and a long lease. Treating every close transaction as equal can produce a precise-looking but weak valuation.

A sold comparables API narrows transaction data around a subject property so an application can build an evidence set. The software still needs rules for relevance, outliers and uncertainty. A good result helps a person understand the market evidence; it does not hide judgement behind an average.

What makes a sale comparable

The strongest comparable resembles the subject property in the ways buyers are likely to value, completed recently enough to reflect a similar market and sits in a genuinely comparable location.

Important dimensions include:

• Location: street, micro-market, transport barriers and local character.
• Recency: how much market movement may have occurred since completion.
• Property type: detached, semi-detached, terraced, flat or another category.
• Size: internal floor area, accommodation and plot where relevant.
• Tenure: freehold, leasehold and important lease characteristics.
• Condition: refurbished, average, dated or requiring substantial work.
• Built form: purpose-built flat, conversion, bungalow, standard house or unusual design.
• Transaction context: new build, related-party transfer or another non-typical circumstance where known.

Not every field exists for every sale. Your interface should show which attributes supported the match and which were unavailable. Missing evidence should reduce confidence rather than being treated as a match.

Begin with the subject property

Before requesting comparables, establish a clear subject record. At minimum, confirm the postcode and complete address. Add property type, bedrooms and floor area where they are known from a reliable source.

Do not infer a missing attribute merely to make the search work. If bedroom count is unknown, say so. If an EPC records floor area, retain the certificate date and source. A user-entered floor area should remain distinguishable from a sourced value.

The UPRN address endpoint can resolve identity, while the EPC endpoint and interior floor-area endpoint can provide supporting property attributes.

The more clearly the subject is defined, the easier it is to explain why a sale was included.

Request nearby sold comparables

The Property Insights sold comparables endpoint accepts a postcode, optional address and lookback period in months.

curl --get "https://propertyinsights.co.uk/api/v1/property/sold-comparables" \
  -H "x-api-key: $PROPERTY_INSIGHTS_API_KEY" \
  --data-urlencode "postcode=EX1 2AB" \
  --data-urlencode "address=12 Example Street" \
  --data-urlencode "months=36"

Use a fictional address in documentation and demonstrations. Keep the real API key on the server.

The response gives the application a focused starting set. It should not be converted immediately into one average. First inspect property type, date, address, price and any available matching context.

Comparable quality depends on several dimensions that should remain visible to the reviewer.

Set a sensible lookback window

A shorter window reflects recent market conditions but may contain too few sales. A longer window adds evidence but increases the need to adjust for market movement and property change.

There is no universal best window. Use the density and type of market:

• In an active urban area, six to twelve months may produce enough similar transactions.
• In a quiet suburban street, eighteen to thirty-six months may be necessary.
• For rural or unusual properties, a longer period and wider geography may still produce weak evidence.

Change one constraint at a time. If a six-month search returns nothing, extend the timeframe before also expanding the area and relaxing the property type. This lets the reviewer understand which compromise introduced each sale.

Store the chosen lookback in a report. "Comparable sales" without a period is difficult to audit later.

Treat geography as a market boundary, not a circle

Radius is convenient for software, but local markets do not always form neat circles. Railway lines, school catchments, main roads, estates, waterfronts and town boundaries can separate prices over a short distance.

Use distance as a first filter, then inspect local context. A comparable on a similar street slightly farther away may be stronger than a closer sale across a major boundary.

For flats, the same block or development can be especially relevant, provided floor level, size, condition, parking and lease terms are considered. For standard houses, the same street pattern and built form may matter more than postcode alone.

An application can support this judgement by showing a map and full addresses rather than only a sorted table.

Rank evidence without pretending it is objective truth

A comparable score can help order candidates. It should not obscure the inputs or imply that a high score guarantees equivalence.

A practical ranking might give more weight to:

1. Same property type.
2. Similar floor area where available.
3. Same street or micro-market.
4. Recent completion date.
5. Similar bedroom count.
6. Similar tenure and built form.

The weighting depends on the property. Floor area can be particularly useful for flats, while plot and outbuildings may matter for rural homes. Keep the score explainable and allow a professional reviewer to exclude a candidate with a reason.

Record both automated and manual decisions. A simple audit entry such as "excluded: new-build apartment in a different development" is more useful than silently deleting the row.

Identify outliers and non-comparable sales

An outlier is not necessarily a data error. It may reflect a superior refurbishment, development potential, a distressed condition or a transaction context that is not visible in the core record.

Flag rather than automatically discard:

• Prices far outside the initial cluster.
• New builds among older housing.
• Sales with a different property type.
• Very old transactions.
• Records with incomplete or conflicting addresses.
• Properties with much larger or smaller floor area.
• Multiple sales that may refer to subdivisions or merged units.

The reviewer can then research the reason. Removing every inconvenient result can create confirmation bias, especially when the expected valuation was entered before the comparable search.

Adjustments need a clear basis

Comparable analysis often requires adjustments for time, size and condition. These should be visible assumptions rather than hidden changes to the source price.

For example, a report might show:

• Recorded sold price and date.
• Market movement to the valuation date.
• Difference in floor area.
• Known extension or condition difference.
• Adjusted indication.
• Reason and person or rule applying the adjustment.

Use the House Price Index API for broad market context, not as proof of exact movement for one street. HPI and comparable residuals can both reflect market change, so avoid applying overlapping adjustments twice.

Condition is particularly hard to automate. Listing images may be old, unavailable or subject to usage restrictions. A manual inspection usually carries more weight than a generic condition label inferred from sparse data.

Sparse markets and unusual properties

Converted churches, large rural homes, mixed-use buildings and one-off designs rarely have perfect comparables. The correct response is wider uncertainty, not increasingly remote evidence presented with the same confidence.

Try a controlled sequence:

1. Extend the timeframe.
2. Widen the geography within similar market areas.
3. Relax one property attribute.
4. Use price-per-area evidence where appropriate.
5. Add broader market trend context.
6. Refer for human valuation when the evidence remains weak.

Document each relaxation. A client should be able to see that the final set includes older or more distant evidence.

New builds also need care. Incentives, warranties, specification and developer pricing can create a premium that does not carry into nearby resale stock. Keep new-build status visible rather than mixing it silently into the average.

Presenting comparables in a report

A client-facing report should let the reader inspect evidence without turning the page into a database dump.

For each selected comparable, show:

• Address or an appropriate location description.
• Completion date.
• Sold price.
• Property type and tenure where available.
• Distance from the subject.
• Floor area or bedrooms where sourced.
• Why it was selected.
• Any adjustment or warning.

Then show the valuation range, not only a single number. Explain which comparable supports the lower and upper parts of the range.

A useful report keeps the source sale, relevance and adjustment visible.

The Property Information Pack API can include sold evidence in a branded PDF. The report still needs limitations stating that it is not a survey, legal title report or RICS valuation.

Comparables and automated valuations

The Property Valuation API combines sold comparables with market context to produce a modelled estimate and confidence information. Comparables make that estimate easier to explain, but they do not remove model risk.

Use both outputs together:

• The AVM provides a consistent estimate and range.
• The comparable set shows the transaction evidence.
• Confidence indicates how much support the model found.
• Human review considers features missing from structured data.

If the automated estimate sits far outside the strongest comparable cluster, investigate before presenting it. The discrepancy may reveal a property match error, stale input, unusual feature or thin data.

Sold comparables checklist

• Confirm the subject property before searching.
• Use an explicit lookback period.
• Change one search constraint at a time.
• Keep property type, date and location visible.
• Flag outliers before excluding them.
• Record manual selections and reasons.
• Avoid double-counting HPI or size adjustments.
• Widen uncertainty when evidence is sparse.
• Show source transactions beside the valuation range.
• Escalate unusual or high-stakes properties for professional review.

Frequently asked questions

How many comparables are enough?

Quality matters more than a fixed number. Three strong, recent and genuinely similar sales can be more informative than twenty weak nearby records.

How recent should a comparable be?

Use the shortest period that produces enough relevant evidence. Extend it in controlled steps and account for market movement when older sales are included.

Is the nearest sale always best?

No. Property type, size, tenure, condition and micro-market can make a slightly more distant sale much more relevant.

Can a comparables API replace a valuer?

No. It can organise evidence and support consistent analysis. Unique features, condition and the purpose of a formal valuation may require a qualified professional.

Should outliers be deleted automatically?

Not without investigation. An outlier may reveal a real property difference or transaction context. Flag it and record the exclusion reason.

Start with a confirmed property and a clear valuation date. Then test the sold comparables endpoint and design the interface around evidence quality rather than the largest possible result set.