Common BRAVE Validation Errors

Every BRAVE file goes through validation — either by the lender's system, a third-party validator, or both. Understanding the most common validation errors and how to fix them will save you revision cycles and protect your professional reputation.

This guide catalogs the most frequent BRAVE validation failures based on common patterns observed in BRAVE file submissions, ranked from most to least common. For background on the real estate appraisal data that BRAVE captures, see our 99 fields guide.

Error 1: Data Type Mismatch

What happens: The official usebrave.org validator rejects fields where the data type does not match the specification. For example, entering text like "twelve" in an Int32 field (Property.NumTenantsCount) or "NOT_A_NUMBER" in a Decimal field (Property.Latitude).

Frequency: Very common in first-time BRAVE submissions, especially manually created files.

Common type errors:

Decimal fields (all monetary values, rates, coordinates) — must be parseable as numbers. No dollar signs, commas, or text.
Int32 fields (Property.NumTenantsCount, Property.ParcelCount, Property.YearBuilt, etc.) — must be whole numbers.
DateTime fields (Job.ReportDate, Value.Date, Property.RecentSaleDate, Appraiser.LicenseExpiration) — must be valid dates.
Boolean fields (Property.SoldLastThreeYrs, Income.ReservesIncluded, Income.GroundLeaseIncluded) — accept "Yes"/"No".

Fix: Ensure all values match their expected data types. See our BRAVE 99-Field Reference for the complete type specification.

Error 2: Cap Rate Range Violation

What happens: The validator enforces range checks on Value.CapRate. A cap rate value outside the 0-20% range will fail validation.

Frequency: Very common in first-time submissions.

Cause: Entering the cap rate as a value outside the expected range. For example, entering 250 when you meant 0.065 (6.5%).

Fix: Ensure cap rate values are within the 0-20% range. For complete formatting rules, see our BRAVE Cap Rate Fields Explained guide.

Error 3: Lender-Specific Field Requirements

What happens: The official BRAVE validator treats all 99 fields as optional — empty fields pass validation. However, individual lenders may require specific fields and will reject submissions where key fields are blank.

Frequency: Common across submissions.

Cause: Different lenders require different fields. A BRAVE file that passes the usebrave.org validator may still be rejected by a specific bank's internal review process.

Important fields most lenders expect:

Property.Name, Property.AddressStreet, Property.Type — core property identification
Income.NetOperatingIncome — essential for underwriting
Value.ReconciledFinal — the final value conclusion
Value.CapRate — for income-producing properties
Appraiser.Name, Appraiser.LicenseNum — regulatory compliance

Fix: Review the specific lender's requirements before exporting. Our bank-specific guides for Bank OZK cover institution-specific expectations.

Error 4: Property Type Mismatch with Lender

What happens: The lender's system flags a mismatch between the Property.Type value in your BRAVE file and their loan file classification.

Frequency: Frequent across submissions.

Cause: The appraiser classifies the property differently than the lender. For example, the appraiser uses "Mixed Use" while the lender's loan file says "Multifamily" for an apartment building with ground-floor retail. BRAVE covers office, retail, industrial, multifamily, hospitality, self-storage, and special purpose properties.

Fix: Confirm the property type classification with the lender before finalizing the BRAVE file. When in doubt, match the lender's classification and note any discrepancy in the appraisal report.

Error 5: Income Field Inconsistencies

What happens: Lender review flags that Income.NetOperatingIncome does not equal Income.EffectiveGrossIncome minus Income.OperatingExpenses.

Frequency: Frequent across submissions.

Important note: The official usebrave.org validator does not enforce cross-field math checks — so these errors will pass the validator but get caught during lender review. This makes it especially important to verify income math independently.

Fix: Recalculate the entire income waterfall. Ensure EGI minus Operating Expenses equals NOI. Use your appraisal software's built-in calculations rather than manual overrides.

Error 6: Invalid DateTime Values

What happens: DateTime fields contain values the validator cannot parse as dates. For example, entering "not-a-date" or a locale-specific format that does not parse correctly.

Frequency: Occasional across submissions.

Affected fields: Job.ReportDate, Value.Date, Property.RecentSaleDate, Appraiser.LicenseExpiration.

Fix: Ensure all date fields contain valid date values. In Excel, format date cells appropriately before entering dates to prevent auto-formatting issues.

Error 7: Enum Validation Failure

What happens: The Property.DevelopmentStatus field is validated as an Enum type. Values outside the accepted options will fail.

Frequency: Occasional across submissions.

Accepted values: "Existing" and other standard development status values as defined in the BRAVE specification.

Fix: Use the exact enumerated values from the BRAVE specification for this field.

Prevention Strategy

The most effective way to avoid validation errors is to validate before you submit. Upload your BRAVE file to AppraisalAPI.com to catch all of the errors above — plus dozens of additional checks — before your lender ever sees the file. Fixing errors proactively takes minutes; fixing them after rejection takes days.

For a complete pre-submission process, follow our BRAVE Compliance Checklist. For a general introduction to the standard, read What Is BRAVE? or learn how to create a BRAVE file from scratch.