Core concept·7 min read

Understanding the comparable grid in UAD 3.6

The grid is no longer a fixed rectangle of cells — it is structured, repeatable comparable data. Here is how to think about it and keep it consistent.

In this guide

Rules coveredUAD1461

Worked examplesSingle-family (SF1)

Ask the copilot about this guide — it has read the whole hub and cites what it uses.

On the old form the grid was a rectangle of cells you typed into, and its internal math was on you. In UAD 3.6 there is no grid — there are properties. Each comparable is a full PROPERTY record with its own ValuationUseType, and the side-by-side grid a reader sees is assembled from those records at render time. You're not filling a grid anymore; you're describing a set of properties, and the grid is a report of them.

What the SF1 grid is actually made of

SF1 doesn't contain "three comp columns." It contains nine PROPERTY records, each with a role — and only three of them are the sales comparables you see bracketed in the grid.

9
PROPERTY records in the file: 1
SubjectProperty: 3
SalesComparable: 5
PropertyAnalyzedNotUsed

That last group is the one appraisers forget exists — properties you pulled, considered, and chose not to bracket with. They still live in the file with their own reduced set of required fields. Get the tag wrong and a not-used property suddenly inherits a comparable's requirements, or vice versa.

Traditional Appraisal$491,000

Single-family (SF1)

Detached · Site Built · 3 comps

Worked example$491,000

Single-family (SF1)

SF1: 1 subject + 3 sales comps + 5 analyzed-not-used, all one file. Open it to see how the rendered grid maps back to those records.

See the full sample report Explore it in the copilot

The adjustments have to add up — literally

Each comparable carries its adjustments as COMPARABLE_ADJUSTMENT records, and the net adjustment isn't a number you type independently — it's expected to equal the sum of the individual line items. On paper, a transposed digit and a hand-totaled net that never got re-added is invisible. As data, it's a cross-field check waiting to catch you. Here's the shape of it for a single comparable:

Adjustment line	Amount
Sale price	$505,000
Location	+$5,000
Gross living area	−$8,000
Condition	−$4,000
Net adjustment (= sum of the three lines)	−$7,000
Adjusted sale price	$498,000

The net adjustment must equal the sum of the line items — validated automatically for every sales comparable (UAD1461).

UAD1461FatalField 22.15.08Rule details →

Rule logic: If @ValuationUseType = "SalesComparable" and SalePriceNetTotalAdjustmentAmount does not equal the sum of ComparableAdjustmentAmount across all instances of COMPARABLE_ADJUSTMENT
Fix: Make sure the net adjustment equals the sum of the line-item adjustments for every sales comparable — don't hand-total it separately from the lines.
Seen in a sample: $30,760 in Single-family (SF1)

Ask the copilot how to fix UAD1461 →

The grid is also a map

Because the comparables are real property records with locations, the report renders a comp map alongside the grid — here's the one delivered with SF1. It's not decoration: a reviewer uses it to sanity-check that your comparables actually bracket the subject geographically.

SF1 sales comparable map — subject and three comparables plotted — The sales-comparable map delivered with the SF1 sample report.

Exactly one subject — and it's easy to get wrong

There must be exactly one PROPERTY with ValuationUseType SubjectProperty. Zero and it's not a report; two and it's a Fatal error. This sounds impossible to trip until you build a report by copying a prior one as a template — now you've got the old subject and the new subject both tagged, and nothing on the form visibly shows two subjects.