I spent six weekends building a Python script to scrape comparable sales for my neighborhood, then opened the county assessor's actual parcel file and found eleven fields I hadn't even modeled. The script wasn't wrong. It was just answering a smaller question than the one that mattered.
That experience taught me something useful for anyone in tech who owns a home: the property tax system is one of the few financial systems in America with a public, addressable data layer. You can query it. You can diff it. And if the numbers disagree with reality, you can push back, which is exactly what a property tax appeal is designed to do.
Below is how I think about that data now, framed the way I'd frame any unfamiliar API. What the schema looks like, where the joins break, and which mistakes cost real money.
What the assessor actually stores, and why it isn't market value
Most people assume their assessment is a price. It isn't. It's a classification plus a valuation model plus a set of local rules, and those three things get combined in ways that vary wildly from one township to the next.
Think of it as three separate tables you have to join yourself:
- Physical attributes: square footage, lot size, year built, bedroom and bath counts, construction class, basement finish.
- Valuation method: cost approach, sales comparison, or income approach, depending on property type.
- Local mechanics: assessment ratios, exemptions, caps, and the mill rate applied on top.
Here's the part that trips up technical people. Sales comparison models don't care about your kitchen remodel. They care about the median of a bucket the county drew years ago, and that bucket might include homes two streets over that you'd never choose as comps.
My honest opinion: if you only read one field in your parcel record, read the living area and the construction class. Those two drive more disagreements than everything else combined.
Where the joins break: three failure modes worth knowing
Every data pipeline has failure modes. County assessment pipelines have three that show up constantly.
Stale inputs. A county might run a full reassessment every three or four years rather than annually, which means the value on your notice could reflect conditions from a market cycle ago. That lag is structural, not a mistake by any one clerk.
Uniformity drift. Two identical houses can carry very different taxable values if their records were updated in different years. The system never reconciles them until someone forces the issue.
Description errors. Square footage counted twice. An extra bathroom that doesn't exist. A finished basement that's actually a crawlspace. These are transcription problems, and they're the easiest kind to correct because you can point at physical reality.
The scale of homeownership in this country is what makes all of this matter. According to the U.S. Census Bureau, roughly two thirds of American households own the home thtwo-thirds, and property taxes sit on nearly all of those homes.
How do you build a case a reviewer can actually verify?
Appeals aren't won by being right. They're won by being checkable. That distinction has burned a lot of smart people.
When I filed my first appeal, I included a spreadsheet of sales comps and a paragraph of explanation. It was rejected, correctly, because none of my comps fell inside the window the board accepted. The rules weren't hidden. I just never read them.
What works instead is a small, tight evidence packet:
1. Your parcel record, printed as-is, so the reviewer sees what you're disputing.
2. A photo set of anything misdescribed, with dates.
3. Three to five comps, each one inside the accepted time window and inside the accepted geography.
4. A one page summary that states the specific error and the number you believe is correct.
5. The filing receipt, because deadlines are jurisdictional and a missed date is the only argument you can't recover from.
Notice what isn't there. No narrative about your mortgage payment. No argument that taxes are too high in general. Boards can only adjust what the record supports, and "my bill feels large" is not a field in the schema.
What automation can and can't do for you
I love scripting repetitive work, so I tried to automate the whole thing. It worked for maybe 60 percent of the job.
Automate this part: pulling parcel records for a radius around your address, normalizing square footage, and flagging where your record deviates from the neighborhood median. That's a straightforward loop and a spreadsheet pivot.
Don't try to automate this part: deciding which deviations are legitimate grounds and which are normal noise. Assessment districts are not uniform datasets. A 40 square foot variance might be rounding in one township and a real error in another.
Research on how property taxation actually functions across jurisdictions is genuinely uneven, which is part of why local rules matter so much. The National Bureau of Economic Research publishes work on tax policy that helps explain how these systems came to be structured so differently.
My take after going through it twice: treat software as your research assistant, not your advocate. The judgment call about whether you have grounds belongs to a human.
The boring advantage
Engineers love a clever solution. I've built fragile scrapers for problems that a phone call would have solved in ten minutes, and I suspect most people reading this have done the same.
The county record is the unglamorous option. It's a PDF. It's badly formatted. Nobody is going to star your repo over it.
But it's also the only document in this whole process that everyone else agrees on. The assessor wrote it. The board reviews it. Your comps get compared against it. When you can point at a specific field and say "this is wrong, here is proof," the conversation stops being a debate about fairness and starts being a data correction.
That's a much easier room to be in.
Handling the parts that aren't a data problem
Some of this process is genuinely administrative rather than analytical, and pretending otherwise wastes time. Knowing your appeal window matters more than any model you build.
If you're confused about consumer rights and protections when dealing with financial paperwork generally, the Consumer Financial Protection Bureau is a useful starting point for understanding how these systems are supposed to work.
On timing specifically, here's the practical rule I've landed on: your window usually opens when the reassessment notice lands and closes a few weeks later. Mark it the day the envelope arrives. Build your packet during the window, not after it.
And if the deadline passes, that isn't the end. Many jurisdictions run more than one review stage, which means a missed date moves you to the next available one rather than off the board entirely.
A short checklist before you file
- Pull your parcel record and read every field, not just the value.
- Compare living area and construction class against three neighbors.
- Photograph anything the record gets wrong.
- Confirm the comp window before you gather comps.
- Write one page. If it runs three, you're arguing and not documenting.
- File inside the window, then log the confirmation number somewhere you'll find it again.
None of this requires an engineering degree. It requires the willingness to be unexciting about it.
The next time your assessment notice shows up, try this before you do anything else: open the parcel record, find the square footage field, and check whether it matches the house you actually live in. Most people never look. That single field has changed more outcomes than any clever model I've written.
Start with the boring document. It usually finishes the job.
Further Reading
Discover more articles on similar topics across our network
Comments
Loading comments…