Catch collateral data mismatches before a valuation order

A valuation order can stall before it reaches a valuer because the collateral record does not agree with the source evidence. A bedroom count was copied from an older application. Parking was entered as one space instead of two. The land area came from a rounded figure. Each difference is small on its own, but someone still has to find it, check it and decide which value belongs in the order.

A short data-quality check can bring that work forward. Match the address, retrieve the core property record and latest recorded sale, then compare those fields with the application data. The result is a focused review list for an operations specialist. It does not estimate the property’s current value or make a lending decision.

Turn six fields into a clear review task

The fixed HtAG snapshot for this example was captured on 22 September 2026. The address supplied to the workflow was matched to 12 SMITH ST, RICHMOND VIC 3121. The captured property record describes a house with 3 bedrooms, 1 bathroom, 2 car spaces and 223.68 m² of land. The property summary record was last updated on 29 August 2026.

To show how an intake check could work, the demonstration adds clearly labelled illustrative application inputs: house, 4 bedrooms, 1 bathroom, 1 car space, 210 m² of land and a last-sale date of 16 June 2019. These values are product-demo inputs. They were not returned by HtAG and they do not represent a lender’s policy.

The example rules are illustrative too. Property type and the room and car counts use exact matching. Land area goes to review when its absolute difference exceeds 5% of the captured source record. The last-sale date goes to review when the two dates differ by more than 30 days. A production team would replace those settings with its own approved tolerances.

Applied to the example, 4 of 6 fields require review: bedrooms, car spaces, land area and last-sale date. Property type and bathrooms align. The land-area difference is 13.68 m², or 6.12% of the 223.68 m² source record. The two sale dates are 365 days apart.

Interactive product concept using a fixed HtAG snapshot captured 22 September 2026. Application values, rules and routing are illustrative. The controls update the local display and make zero reader-time HtAG API calls.

Confirm the address before comparing the property

The first step is address matching. GET /address/geocode checks the supplied text against address records and returns candidate identity details. In this capture, the returned street number, street name, locality, state and postcode matched the intended Richmond address. The same canonical address key then connected the property summary and sale-history records.

That sequence avoids a common shortcut. Address standardisation can tidy text, but it does not prove that an address exists in the source. For this workflow, the useful evidence is the inspected geocode result and continuity of the returned identity across the records used in the comparison.

Show the reviewer exactly what changed

A mismatch count is useful only when the reviewer can see what sits behind it. The review row should show the application input, captured source value, applicable rule and result for every field. It should also name the four fields needing confirmation instead of presenting a vague warning.

This gives the operations team a practical next step: confirm the input before preparing the valuation order. The reviewer can return to the source document, ask for clarification or correct a transcription error through the organisation’s usual process. The comparison itself does not send an order or write to another system.

The rules should stay visible beside the results. Here, a one-bedroom difference is flagged because counts require an exact match, while 13.68 m² is flagged because it equals 6.12% of the source land area and exceeds the illustrative 5% tolerance. Clear arithmetic makes the queue easier to audit and prevents a generic alert from becoming another manual investigation.

Keep the recorded sale in its historical context

The newest captured transaction is a recorded sale of $1,475,000 on 16 June 2018. That amount belongs to the historical source record for that date. It is not the property’s current value, and the workflow does not turn it into one.

The sale record is useful here because its date can be compared with the illustrative application date. It also repeats the core physical attributes, allowing the production check to reconcile the property type, bedroom count, bathroom count, car spaces and land area across the captured summary and history before any public result is shown.

Keep the production check small and repeatable

The captured workflow used 3 operation types, 3 requests and 5 returned rows: one address match, one property-summary row and three sale-history rows. Those workload figures do not establish a charge. Teams should check current HtAG pricing for the planned request and row volume.

In a live intake flow, cache the reviewed address identity and the source snapshot used for the decision. Refresh according to the team’s process, then preserve the comparison time and rule version beside the result. That gives a later reviewer enough context to understand why a field was sent for confirmation.

Implementation appendix

This example uses three documented operations. GET /address/geocode returns address candidates for inspection. GET /property/summary supplies the core property attributes for the confirmed address key. GET /property/history, requested for sales, supplies the latest recorded transaction and the history rows used in reconciliation. See the HtAG documentation for current request and response details.

A useful first implementation is narrow: run the check for one secured property, display the six comparisons and route only the named differences to a person. The reviewer gets a clean evidence trail before the valuation-order process begins, while the application remains the system where confirmed inputs are managed. Smaller teams can start with self-service access and current pricing.