Renaming Your 1004 Creates a 3-Million-Row Spreadsheet Nightmare

Let’s talk about how to adapt products & rate sheets for UAD 3.6

We wanted to. Then we did the math: 3 million rows in a single rate sheet. Hard pass.

But I get the instinct! You've got years of history with your current product list. Pricing logic. Reporting. Training. All built around form numbers. Now UAD 3.6 is requiring us to change and it’s hard, many don’t know where to start.

But holding on to the past isn’t worth it.

Here’s how we adapted to UAD 3.6 and came out with something way simpler.

Form numbers were simple. "1004" meant one thing to everyone. Literally the same PDF form, filled out by an appraiser.

Pricing was easy: Form X costs $Y. Done.

The shorthand worked because forms were rigid. Same sections, same fields, same output every time. An appraiser knew exactly what a 1004 looked like. A lender knew exactly what they were ordering. Everyone spoke the same language.

The problem? Rigid forms couldn't handle variety. Manufactured homes, condos with weird ownership structures, properties with ADUs, mixed-use buildings. Everything got shoehorned into forms that didn't quite fit.

Everyone acknowledged that data was limited, but we were so locked into these forms that getting better data wasn't worth the friction.

UAD 3.6 forces the friction by making the report dynamic. One report format adapts based on the property characteristics you provide up front. That's genuinely better for data quality and flexibility.

But that flexibility has a cost. And if you're not careful, it'll bury you.

Under UAD 3.6, the order form doesn't just ask "which form do you want?" It asks questions about the property itself.

The core fields include:

Beyond those, there are additional fields that affect the complexity of the assignment: property value, square footage, lot size, whether there's an ADU, outbuildings, amenities, rural designation, and more.

All of this information flows to the appraiser so they can accurately scope the assignment before accepting. That's good. Better data upfront means fewer surprises later.

OK I get that UAD 3.6 asks these questions. But the question remains:

When we first sat down to figure out how to handle UAD 3.6 pricing, we did the obvious thing: count the permutations if we combined the variables into form names or single use “products”.

If you tried to create a unique product for every possible combination of order form fields, here's what you'd get:

That's just the products.

Now let’s add location-based pricing.

Let's be optimistic and set custom rates for each state, and maybe only 3-4 different county based prices per state. That's 50 states + 200 county overrides…per product.

11,520 products × 250 locations = nearly 3 million pricing rows.

And that's the conservative scenario. If you needed county-level overrides across all 3,200+ US counties? You're looking at over 36 million possible rows.

That’s an absurd number of rows to manage.

This killed the idea that we should try and mirror the old way and forced us to start from scratch.

The basic math convinced us that flattening everything into products was a dead end.

So we designed a different structure. Three tiers that work together.

These represent the core type of work being done. They're determined by two things: valuation method and property type.

Traditional appraisal on a condo? That's one product. Desktop appraisal on a manufactured home? That's another.

We use priority rules to handle edge cases. What if it's a manufactured condo? The priority order decides which characteristic "wins" and determines the product code.

This gives us around 45 base products total. Manageable. Understandable. Something a human can actually look at and make sense of.

Here's the key insight: complexity factors don't belong in the base product. They belong in modifiers that stack on top.

Why? Because pulling them out simplifies everything.

We have fewer prices to manage and fewer locations to worry about. Plus, we're itemizing parts of the order that historically got lumped together where nobody knew those items impacted the rate.

Take rural properties. If you baked "rural" into your base products, you'd need a separate product for every combination: Traditional Rural, Traditional Condo Rural, Desktop Rural, Desktop Condo Rural, and on and on. Your product list doubles or triples overnight.

Instead, we use a Rural modifier. The base product stays the same. Rural adds a fee on top. Simple, visible, and you're not managing hundreds of redundant products. Best part? We don’t have to get familiar with every county in the US. We can let our system determine how far away the property is from our appraisers and it recommends the modifier automatically.

Same logic applies to government loans like FHA and VA, high-value properties, large square footage, big lots, ADUs, outbuildings, and more.

Some modifiers apply automatically based on the order data. If someone enters a $1.5 million contract price, the high-value modifier kicks in without anyone having to remember to add it. Others are selected manually during order creation, like a rush fee or enhanced scope request.

The formula is simple: Order price = Base product + applicable modifiers.

This approach also reduces errors. You don't need a separate county override just because those counties happen to be rural. That also has flaws because some counties include metro areas and rural areas all in the same county. So instead, expect a rural fee on top of the base price whenever that box is checked. The pricing logic lives in one place, not scattered across thousands of location-specific rows.

Pricing cascades from broad to specific: National default → State override → County override.

You only set exceptions, not every single location.

If California needs different pricing, you set a California override. If LA County is different from the rest of California, you add that override too. Everything else inherits from the level above. If Riverside county is the same as the State price, then you don’t have to have an override for Riverside properties. Fewer rows means easier to manage price sheets.

Instead of millions of rows in your fee schedule, you have thousands at most. Usually far fewer.

Instead of 11,520 products, you have 45.

Instead of recreating everything when a new variable appears, you add one modifier.

Less complexity, fewer errors, easier to maintain.

Back to the original question: why can't you just rename your forms?

Because the form number was shorthand for assumptions that no longer hold.

Under the old system, you'd order a "1004" without knowing much about the property. The appraiser would show up, discover it's a 6,000 square foot home with an ADU and a pool, and then the phone calls would start.

"This is more work than a standard 1004. The fee needs to go up."

Now you're stuck. Accept the higher fee and deal with re-disclosure, or find another appraiser and start over. Either way: delays, price changes, re-disclosures, and frustration from all parties.

UAD 3.6 captures that information upfront. Yes, it's more work at order entry. But accurate data means accurate pricing the first time and faster turnaround. Now you're not dealing with surprise fee increases mid-assignment.

Your old "1004" price assumed a specific type of property. But now "1004" could mean a dozen different things. A small single-family home and a 5,000 square foot house with an ADU are both "1004s" under the old naming. But they're completely different assignments.

Assignment logic fails because you're routing wildly different properties to the same bucket.

Historical reporting becomes meaningless because your categories are too broad to compare. How do you analyze trends when "1004" includes everything from starter homes to mini-estates?

The form number was doing more work than it looked like. Renaming it puts a fresh coat of paint on a car that’s already broken down.

I want to be clear: the structure I just described isn't something the industry has adopted across the board.

We developed it because we needed to solve the problem for our own platform. We looked at the GSE specs, ran the math, and realized there had to be a better way than creating thousands of products.

But here's what's interesting. When we looked at how sophisticated lenders already handled complexity, even in the legacy world, they were doing something similar. Add-on fees for FHA. Rush fees. Complex property fees. They just weren't calling it a "modifier system."

We took that pattern and made it explicit, structured, and scalable.

Whether you use our platform or not, you'll need to solve this problem somehow. We think this approach makes the most sense.

Yes, rebuilding your product list is work.

But it's not just compliance busywork.

A properly structured product list means:

The organizations that do this thoughtfully will have an advantage. The ones that try to force the old system into the new format will spend years patching holes.

If you're trying to figure out how to approach this for your own company, we're happy to talk through it. No pitch, just honest help. We've spent a lot of time thinking about this problem and we're glad to share what we've learned.

The shift from forms to fields isn't optional. November 2026 is the deadline.

If your product list is still built around form numbers, it needs to change. Not get renamed. But completely rebuilt.

Next time, I'll walk through exactly how we rebuilt our own product structure. What we tried, what failed, and what we ended up with. Plus, we'll introduce something that might save you a lot of time.

Want to follow along as we publish more UAD 3.6 guidance? Subscribe and we'll send new articles straight to your inbox.