Earlier sale of Subject Property

In a valuation lifecycle, there are two distinct phases. The first in the valuation request; provided by the customer, who is rendering an estimated value on some basis - like a Contract amount.

The other is the valuation response, completed by the valuer.

Where a contract of sale is provided, the //RecentSale@SalePrice should generally be equal to, but not the same field as the //EstimatedValue figure.

Scenarios where this may differ? The valuer has found an updated contract of sale which is different to what the customer provided.


ValEx expects to find //SalesMarket nodes for FullRegistered and other shortform related valuations.

We require:



Which is equivalent to the Sales Evidence tab in ValEx itself.

Important to remember:
//SalesMarket/MultiTierMarketComment is required when you specify //SalesMarket[@MultiTierMarket="Yes"]

Report Integrity

ValEx is looking to ask more questions around the contract of sale, you can read more in the main article

New document upload notification

We'll be adding a New Document Upload notification in an release of ValEx (approximately July 27th), as discussed in the forum.

We'll also be adding new document types into ValEx itself.

You will be able to subscribe your valuation firm to this event, and receive emails with attached documents.

In the longer term, we'll model this in LIXI WorkFlow as an AmendedValuationRequest.

Maxium document/packet sizes

Just a quick note to point out the value of ensuring your maximum packet upload size is sufficient to handle a valuation response.

A construction valuation request with full supporting documents can reach anywhere up toe the 10MB mark regularly.

A typical valuation response will have a report PDF, as much data as can be put into the LIXI document itself, several photos - it's pretty easy to edge up to around the 3-4MB mark.

We suggest testing your service to handle large LIXI documents, and contacting us if you have any questions.

Valuation Requests and Inspection Contacts

ValEx needs to know:

  • Borrower(s)
  • Inspection Contact(s) (Who will provide access to the property)

See our example request.

The xpaths we need are:

  • //RelatedParty[@RelPartyType="Other" AND @RelPartyDescription="Applicant"] - A borrower / applicant
  • //RelatedParty[@RelPartyType="Other" AND @RelPartyDescription="Access Provider"] - Access provider / inspection contact

ValEx also needs to have as much contact information as possible in the access provider segment.

Recommended Documents to Sight

In the Value section of a report, we capture recommended documents to sight.

We look at:

Which will populate:

We iterate over all available \\ResponseSupportingDoc[@RequestorToSight="Yes"] and concatinate the descriptions

For example:

<ResponseSupportingDoc DocType="TitleSearch" DocAttached="No" RequestorToSight="Yes">
	<Identifier UniqueID="VXDR-0000030267" Type="VPMAssigned" /> 
	<Description>Certificate of title and survey plan</Description>
<ResponseSupportingDoc DocType="Other" DocAttached="No" RequestorToSight="Yes">
	<Identifier UniqueID="VXDR-0000030268" Type="VPMAssigned" /> 
	<Description>Pictures of cats</Description>

Should produce "Recommended Docs to Sight: Certificate of title and survey plan, Pictures of Cats".


We're seeing an increasing use of the comments field for information like:

  • contact details such as 'best time to call'
  • generic information such as title details

The comments field is located at: /ValuationTransaction/Comment


    As is (Completed Dwelling or Vacant Land); AgentVendor; 
General Comments: BROKER CONTACT:JOHN SMITH - PHONE - 0211111111
Call during business hours.
Title Details: Tenure type: Freehold Is primary title: Yes Other title description: LOT X DP XYZ123 </Comment>

Please ensure that you are correctly parsing this information as we anticipate that the value of the detail in this field may increase in the future.

Building Modification Details

We can now capture the BuildingModification fields from the packet if the report type is TBE-Dwelling or TBE-Unit.

LIXI Mappings

Field XPath
Tender Date //BuildingModification/ContractDate/Date
Tender Price //BuildingModification/@TenderPrice - as a double or omitted (even though it says xs:string)
Check Cost //BuildingModification/Description
TBE Builder //BuildingModification/@RelatedEntityRef (Add a RelatedParty)

* We do not parse Check Cost from BuildingModification/@CheckCost, because it is an enumerated Yes|No type. As a workaround, we parse from BuildingModification/Description.

** BuildingModification/@Type should be set to ToBeErected.



<BuildingModification Type="ToBeErected" TenderPrice="500000">         <Identifier UniqueID="Dummy_Value"/>         <Description>750/sqm</Description> 	<RelatedEntityRef RelatedID="TestBuilderId-12345"/> 	<ContractDate><Date>2007-12-05</Date></ContractDate> </BuildingModification>

LIXI RealEstate/Residential Types vs Valex Residential Property Types

Here's a quick summary of how our system maps LIXI //RealEstate/Residential/@Type Types to ValEx residential property types.

Note: Property types should not be confused with Report Type (or even Service Type).

LIXI RealEstate/Residential Types Valex Internal Types
  1. FullyDetachedHouse
  2. LuxuryHouse
  1. NewStrataTitleUnit
TBE Unit
  1. UnitStudentAccom
Student Accomodation
  1. StrataTitleUnit
  2. CompanyTitleUnit
  3. StudioUnit
  4. BedsitterBachelor
  5. SingleBedroomLess50m2
  6. StudioWarehouseApt
  7. HomeUnit
  1. Townhouse
  1. AptUnitFlat
  2. ServicedApt
  3. Apartment
  1. SemiDetachedHouse
  1. VacantLand
Vacant Land
  1. VacantRuralResidentialSite
  2. RuralResidentialWithDwelling
  1. HolidayHome
  1. OwnerBuilderHouseConstruction
  2. LicencedBuilderHouseConstruction
TBE Dwelling
  1. HolidayRental
  2. RentalFlats
Rental Flats
  1. Duplex
  1. Villa
  1. LandWithMinorImprovements
Land with Minor Improvements
  1. Terrace

We don't map and would fail on the following types:

  • ConvertedCommercialProperty
  • ConvertedMotelUnits
  • ConvertedIndustrialProperty
  • Timeshare
  • RentalGuarentte
  • GovtRentalGuarentee
  • ResortUnit
  • PropertyDevelopment
  • LuxuryOther
  • UnitSudentAccom
  • MotalHotelUnit
  • AgedCareUnit

Property Types for for NAB, Commercial, and Rural Security Categories

We also support Commercial and Rural property types under //vx:Job/vx:Property/@Type.

Rejecting / Declining jobs via LIXI

Sometimes your Valuation Firm is just too busy to accept a job. ValEx models this process via the Declined workflow.

We'd love to see more Valuation Firms implement this, as it can be a handy timesaver - no more logging into two systems.

We're mainly interested in receiving:

A reason for rejecting - which must be one of the following:

  • DoNotConductValuationsForClient
  • DoNotCoverPostcode
  • InsufficientFeeForLocality
  • InsufficientFeeForValuationWouldConductFor
  • Capacity
  • ConflictOfInterest


A supporting comment for the rejection:

For instance, "Valuation Firm is currently too busy"


Take a look at the sample xml.

Rejecting a Valuation Request based on Fee for Localtity

If "InsufficientFeeForLocalityWouldConductFor” is selected as the rejection reason a second field can be passed in for the dollar amount of what the valuation would be done for:

             <vx:Declined ReasonCode="InsufficientFeeForLocalityWouldConductFor" Amount="250" />

XPath of the amount:

New workflow for Valuation Firms - In Progress

We've added the ability to understand In Progress workflow from Valuation Firms.

You can now add Appointments via this packet, and also remove all Delays from a Job - this is more in line with LIXI's specified behaviour.

There is no requirement for Valuation Firms to implement this new workflow at this time.