BRAVE Validation: How to Verify Your Appraisal Data

Why BRAVE Validation Matters

A BRAVE file with incorrect data is worse than no BRAVE file at all. If a cap rate is entered as 75% instead of 7.5%, or if the NOI does not reconcile with the income and expense figures, the bank's underwriting model ingests garbage. The loan decision downstream is compromised before anyone notices.

BRAVE validation exists to catch these problems before they reach a bank's system. There are two layers of validation worth understanding: the official BRAVE validator maintained at usebrave.org, and the additional verification checks that extraction services like AppraisalAPI run to ensure data accuracy.

This guide covers both.

Part 1: Official BRAVE Validation at usebrave.org

The official BRAVE validator is the authoritative tool for checking whether a BRAVE file meets the standard's requirements. It is hosted at usebrave.org and is free to use.

What the Validator Checks

The official validator runs the following checks against your BRAVE XLSX or CSV file:

All fields optional. The 99 fields in BRAVE are all optional — empty or blank values pass validation for every data type. The validator does not enforce required fields; it focuses on ensuring that populated fields contain correctly typed values.

Data types correct. Every BRAVE field has a defined data type: String, Decimal, Int32, DateTime, Boolean, or Enum. Monetary values and rates must be parseable as numbers (Decimal), not text strings like "$1,250,000" or "7.5 percent." Dates must be valid DateTime values, not freeform text like "March 2026." Boolean fields accept "Yes"/"No". The Property.DevelopmentStatus field is validated as an Enum. The validator rejects files where data types do not match the spec.

Values within reasonable ranges. A cap rate of 200% is not a cap rate — it is a data entry error. The validator checks that numeric fields fall within plausible ranges. Cap rates should be between 0% and 20%. Vacancy rates should not exceed 100%. Year built should not be in the future. These range checks catch transposition errors and unit-of-measure mistakes that would otherwise slip through.

Cross-field logic (not currently enforced). The BRAVE specification documents cross-field checks such as NOI = EGI - Operating Expenses. However, testing against the usebrave.org validator confirms that these cross-field checks are not currently enforced — a file with inconsistent NOI, EGI, and expense values will still pass validation. This is why additional verification checks (like those AppraisalAPI runs) are valuable for catching mathematical inconsistencies.

How to Use the Validator

Using the official BRAVE validator takes about 10 seconds:

Go to usebrave.org
Upload your BRAVE XLSX or CSV file
Wait for the validator to process (typically under 10 seconds)
Review the results

The validator uses a simple color-coded system:

Green — the field or check passed validation
Red — the field or check has an issue that needs correction

Fix any red items, re-upload, and validate again until you get a clean result.

When to Validate

Validate your BRAVE file before sending it to a bank. This is especially important if:

You created the BRAVE file manually in Excel
You used an automated extraction tool and want to confirm the output
You are submitting to a lender with strict BRAVE requirements like Bank OZK
You modified a previously validated file

Running the validator is free and takes seconds. There is no reason to skip it.

Part 2: AppraisalAPI's Additional Verification Checks

When AppraisalAPI extracts BRAVE data from an appraisal PDF, we run a separate set of verification checks on top of the extraction. These checks are not part of the official BRAVE standard — they are our own quality controls designed to catch errors introduced by the LLM extraction process.

Think of it this way: the official BRAVE validator checks whether a file conforms to the standard. Our verification checks ask whether the extracted data is internally consistent and complete, regardless of format compliance.

Why Additional Checks Are Needed

LLM-based extraction is powerful but not infallible. A model might extract the NOI from the wrong section of a 200-page appraisal. It might confuse an as-stabilized value with an as-is value. It might capture the appraiser's name but miss the license number on a different page.

Our verification layer catches these issues before you ever download the file. Each check produces one of three results:

Pass — the data looks correct and consistent
Warn — something is missing or inconsistent, worth reviewing
Skip — insufficient data to run the check (not enough fields were present in the source document)

The Eight Verification Checks

Here is every check AppraisalAPI runs, with an explanation of what each one catches.

1. Property Identification Fields Present

What it checks: Are the five core property identification fields populated?

Property name
Street address
City
State
Property type

Why it matters: If the extraction missed the property address, something went fundamentally wrong. This check is a canary — if it fails, the entire extraction needs review.

2. Final Value Conclusion Extracted

What it checks: Did the extraction capture the reconciled final value from the appraisal?

Why it matters: The final value conclusion is the single most important number in any appraisal. It maps to Value.ReconciledFinal in BRAVE. If this field is missing, the BRAVE file is incomplete for underwriting purposes.

3. Valuation Approach(es) Identified

What it checks: Was at least one valuation approach value extracted? The three approaches are:

Income approach value (Value.IncomeApproach)
Sales comparison approach value (Value.SalesApproach)
Cost approach value (Value.CostApproach)

Why it matters: Most commercial appraisals use at least two approaches. If no approach values were found, the extraction likely failed to parse the valuation sections of the report.

4. NOI = EGI - Operating Expenses

What it checks: Does the extracted Net Operating Income equal the Effective Gross Income minus Total Operating Expenses, within a 5% tolerance?

Why it matters: The official BRAVE validator does not currently enforce this cross-field check, which makes this AppraisalAPI verification step especially important. If the NOI does not reconcile, the model may have pulled figures from different sections of the report (for example, a stabilized NOI paired with a historical expense figure). A warning here means you should verify which income scenario the numbers belong to.

5. Cap Rate Consistent with NOI / Value

What it checks: Does the stated overall cap rate approximately equal NOI divided by the final value conclusion? The tolerance is 0.5 percentage points.

Why it matters: If the appraisal states a 6.5% cap rate but NOI / Value implies 8.2%, either the cap rate, the NOI, or the value was extracted from the wrong context. This check catches mismatches between the income and valuation sections.

6. Total Assessed = Land + Improvements

What it checks: Does the total assessed value equal the sum of the land assessed value and the improvement assessed value, within a $100 tolerance?

Why it matters: Tax assessment data appears in a structured table in most appraisals. If the total does not equal its components, the extraction likely misread the table or confused assessed values with market values. This maps to the Property.Tax.AssessedValueTotal, Property.Tax.LandValue, and Property.Tax.ImprovedValue BRAVE fields.

7. Appraiser Credentials Captured

What it checks: Were the appraiser's name and license number both extracted?

Why it matters: Appraiser credentials are required for regulatory compliance. They typically appear on the certification page or letter of transmittal. If the name was found but the license number was not, the model may have missed a page or the license was in an unusual location. This maps to Appraiser.Name and Appraiser.LicenseNum in BRAVE.

8. Report Date and Valuation Date Present

What it checks: Were both the report date and the effective date of valuation extracted?

Why it matters: These two dates serve different purposes. The report date (Job.ReportDate) is when the appraisal was completed. The valuation date (Value.Date) is the effective date of the value opinion, which may differ. Banks need both for compliance and loan timing. If either is missing, the extraction needs review.

How Verification Results Appear

When you extract a BRAVE file through AppraisalAPI, the verification results are included alongside your download. You will see a summary like:

7 of 8 checks passed

Each check is listed with its status and a brief detail. For example:

Property identification fields present — Pass — Name, address, city, state, type all found
Cap rate consistent with NOI / Value — Warn — Stated 6.50%, implied 7.12%

A warn result does not mean the data is wrong. It means the data deserves a second look. Sometimes an appraiser's report genuinely has a cap rate that does not perfectly reconcile due to rounding or loaded cap rate adjustments.

Using Both Layers Together

The recommended workflow for maximum confidence in your BRAVE data:

Extract your appraisal PDF through AppraisalAPI
Review the AppraisalAPI verification results — address any warnings
Upload the BRAVE file to the official validator at usebrave.org for format compliance
Submit the validated file to your bank

This two-layer approach catches both extraction errors (our checks) and format compliance issues (the official validator). Together, they ensure your BRAVE file is accurate, complete, and ready for bank ingestion.