Appraisal Management Software Pricing

Why a Per-Order Fee Fits Appraisal Work

An appraisal desk does not have a steady headcount problem. It has a volume problem. Order flow moves with the rate cycle, with a lender relationship starting or ending, with a seasonal purchase run. The work the platform does is per order: it takes the order in, assigns it against your eligibility rules, tracks its status, runs the quality check on the uploaded report, files the audit record, and hands the documents back out.

The fee attaches to the order, so it follows the work.

What You Get for the Fee

Your Own Deployment, Branded as You

Each client gets their own hostname, their own database, their own brand controller and views, and their own TLS certificate. Tenant configuration drives the outbound email sender and from name, company name, phone, address block, order number prefix, the archive address, and the application, borrower, and acknowledgement logos. Feature scope is configurable per install.

Order Intake and a Status Timeline That Holds Up

Every status change writes its own timestamped row with the acting user recorded. Accept and decline are separate events. The status catalog itself is editable per tenant, down to whether each status is open, who may use it, who may see it, and which of the lender, appraiser, and manager get notified when it fires.

Aging is a standing view rather than a report somebody has to run. A background job flags past due work and the manager Overdue tab and the appraiser's Overdue and Orders Due in Next 3 Days sections read it. The past due rules are configured per status, in days or hours, with a toggle for whether weekends count. The past due rules are configured per install rather than shipping seeded.

Lenders and brokers get their own portal views, and what the lender sees can deliberately differ from what the desk sees.

Panel Management and Assignment That Follows Your Rules

The panel record is a full credential file: geographic coverage by county and state, licenses, errors and omissions insurance, background checks, manager entered verifications, FHA approval and FHA states, commercial capability, fees, availability, email preferences, and documents. Appraisers maintain most of it themselves through a self service profile hub, and changes write an activity diff and fire alert emails.

Assignment runs on an eligibility engine, not a free-text picker. The filter chain covers FHA, rating, recent assignment rotation, background check, availability and county or state coverage, preferred lists, distance and radius, investor ineligibility, lender and broker ineligibility, unexpired insurance, an unexpired license in the property state, and an open order cap. Those rules are set per lender company. Automatic assignment is supported, and a workload throttle removes an over loaded appraiser from the engine. When a manager assigns by hand, the assign screen compares candidates side by side on last assigned date, open orders, overdue orders, distance to the subject property, pay amount, and management fee.

Credential expiry is chased for you. Reminder jobs run at fixed windows before a license, insurance policy, or background check lapses, and a separate job cross checks every stored license against ASC.gov and emails managers a report of expired and not found licenses.

Quality Control and Independence Mechanics

On report upload the platform parses the MISMO and UAD XML and checks it against a rule catalogue, then summarizes the result in a QA Check PDF filed to the order. A manager builds named QA Check policies out of that catalogue and assigns them per appraisal type, either as a shared standard policy or as that lender's own. A failing check prompts the appraiser to open the QA report or proceed on the record, so the engine flags and records rather than silently blocking. Whether the QA result is delivered to the lender is a per lender setting.

On independence, two mechanics are worth naming plainly. The appraiser's identity is hidden from the lender and broker side by default, gating the assigned appraiser and appraiser's company rows, and that default ships that way on every install. Assignment is a manager function that does not exist in the lender or broker portal.

A reconsideration of value is a first class object rather than a revision, with its own status, its own intake form, its own generated ROV form filed to the order, and its own audit rows.

Integrations and a Partner Order API

Integrations are named, per lender, and configured on their own screens. The per lender Third Party hub carries a fixed vocabulary of vendors, and product mapping to each vendor is self serve for a manager on the appraisal order type screen.

There is an XML order API for partners covering order create, edit, status, status acknowledgement, updated order, correction, cancel, hold, off hold, and message. The status call returns every status row the caller has not yet acknowledged and stamps them acknowledged, and the updated order call returns the diff since the caller's last read.

A loan origination system lane exists and carries real loan data inbound, mapping loan purpose, lender case and order numbers, FHA flag and case number, purchase price, the full property address, borrower and co-borrower contact details, appraisal notes, and a due date. That lane answers status and documents when the loan origination system asks for them, and it can drive hold, resume, and cancellation in.

Setting an integration up is not a self serve toggle end to end. Three layers are involved: the vendor's feature module has to be on for your install, a manager turns the individual lender on from the Third Party hub, and the vendor issues tenant wide credentials that get entered on the site level hub.

Reporting and the Audit Record

A named reports menu covers accounts payable, accounts receivable, appraiser history, company, manager direct deposit, and order volume, with further report families behind module flags. Every report has the same shape: a date range, dropdown filters for lender, appraiser, broker, company, and state, column checkboxes that control what appears, and PDF and XLS export.

The audit record is real and it lives in more than one place, which is worth knowing rather than glossing. The order carries a human readable history of field edits, integration sync results, payment events, status deletes, and approvals, with the actor named. Status history sits separately and is finer grained. File Access History is its own table on the order, logging file type, file name, user, user type, date, time, and action on every download. Change history for user and company records lives outside orders again.

What Differs From One Install to the Next

No two installs are configured alike. These are the things that genuinely vary, and they are worth knowing before a quote conversation because they shape what your install actually looks like:

• Which feature modules are on. Feature scope is per install, with per install overrides.
• Which appraisal order types you run, and how each maps to your vendors.
• Which integrations you need turned on, per lender company, and which vendors have to issue credentials.
• How assignment behaves, since the eligibility rules are set per lender company.
• What your status catalog looks like, including who is notified on each status and what the lender sees.
• Your past due rules, which are configured per install rather than shipping seeded.
• Your email templates, order form fields, and notification lists, all of which are manager editable in the application.

Pricing Questions