Home > Insights > One House, Six Records: Why Your Address Data Doesn’t Match 

One House, Six Records: Why Your Address Data Doesn’t Match 

October 8, 2026

  • A typical address lives in the GIS address point layer, the CAD system, the Master Street Address Guide, the assessor’s parcel file, the permitting database, and the utility billing file, or six records for a single location. 
  • Each of the six is maintained by a different office, on a different update schedule, and checked against a different source of authority. None is a copy of the others. 
  • Most of the drift between them comes from five ordinary administrative events: annexation, street renaming, structure subdivision, accessory dwelling conversions, and system migration. 
  • The authority to assign an address rarely comes with responsibility for updating all the systems that depend on it. 
  • Utility billing is often the most accurate of the six records, but the one every other department checks the least. 

Say an addresser assigns a new unit: 4701 First Street, Apartment B. That single decision must impact six different departmental databases if it’s going to properly do its job. Keeping those records aligned across offices is the work of address data governance, and in most jurisdictions no office owns it: 

  • The GIS address point layer needs to geocode a point to the door a responder would actually use, including its unit number. 
  • The Master Street Address Guide needs the street name and range to match the road centerline, or else the call never validates in the first place. 
  • The assessor’s office needs a stable link to a parcel identifier, a different key than the street address, and one that doesn’t update on the same clock. 
  • Utility billing needs a single service point per account; in a duplex or larger multiunit, that means multiple accounts and multiple records. 
  • The permitting system requires the record to exist before the structure does, since permits get filed before anybody moves in. 

Nothing is forcing these six systems to agree or tell anyone when they stop agreeing, and they’ll usually fall out of agreement over time. The only time an error is detected is when something operational doesn’t work: a dispatcher is forced into a callback because the unit number is missing, an assessor’s file has a parcel but no matching address point. 

Divergence isn’t usually a mistake. It’s the result of ordinary administrative work that’s being done correctly, in fact. But it’s happening in six different processes that were never designed to talk to each other. 

For instance, a parcel gets moved from one jurisdiction’s authority to another’s after an annexation; the Master Street Address Guide’s community name updates on its own approval schedule, separate from the GIS boundary layer. 

Or a street renaming and renumbering happens, but CAD and records-management systems retain the old values on purpose because open case files still reference them. A single-family home gets subdivided into three units, but the addressing authority isn’t looped in on it. 

An accessory dwelling gets permitted and built, but its record simply sits in the permitting system because there’s no process for moving it into the address dataset. Or a CAD or records-management system reaches end of life and gets replaced. The new one imports the address table exactly as it stood on cutover day, which turns out to be the last day the two sets of records agree. From go-live it drifts from every other system, and a migration plan that budgeted carefully for the import rarely assigns anyone to keep watching after it.

Each of these is a case of a department doing its job competently: The records division is just keeping retired street names to protect the integrity of an open case, while the permit office is properly issuing a permit before construction. They’re examples of data drift that just arise from correct procedures, not errors, and they keep accumulating. 

An office that relies on an address record sometimes doesn’t have any authority to create or correct one. Addressing authority can sit with a county engineer, an enterprise GIS department, IT, planning, or public works. Or in some jurisdictions, that role hasn’t been assigned to any office at all. In case like that, whoever has historically assigned addresses keeps doing it, by custom rather than by rule. When that person leaves, their experience leaves with them. 

Even when authority is clearly assigned, an addressing job can end with the department’s specific task. A new address may be added at 4701 First Street, Apartment B within one department, but getting that into CAD, the tax roll, the utility file? That’s a different job, and often nobody is accountable for it. In other words, the responsibility for creating (or modifying) an address doesn’t come bundled with the responsibility of propagating it across other systems. So, it doesn’t happen. 

Regional aggregation just compounds the issue. A shared dataset built from six municipalities will have six authoritative sources populating it, each controlling its own records, with none subordinate to the aggregator. A regional GIS team might request edit rights and be turned down because of who holds authority. 

One of the six typical systems happens to be consistently more reliable than the others: utility billing. That makes all the sense in the world; a utility that bills the wrong service address won’t collect, so ensuring the addresses are correct is compulsory. Yet it’s also the address record that every other department consults the least. 

The combination of high accuracy but low circulation occurs across jurisdictions of every size and type. The department with the cleanest address data rarely gets checked first when another team’s record looks wrong. 

An obvious question is, “why?” While some jurisdictions may use utility billing as a source for validation, it’s not a shared system or single source of truth. As we’ve seen, since address work is so fragmented, cross-departmental use is difficult. And data sharing may be limited by privacy rules, agreements, and proprietary ownership concerns. 

The six offices in the 4701 First Street scenario followed their normal procedures. GIS placed the point based on the information it received. CAD dispatched from the address on file. The assessor linked the parcel to the address available at intake. Utility billing corrected its record after a missed payment exposed the problem. Each system served its stated purpose, but the records still ended up out of sync. 

A routine quality check within one department won’t expose this problem. The GIS layer can’t flag a value that CAD never received because its own validation rules don’t require it. Finding the mismatch requires comparing all six records with one another and with permits, parcels, imagery, and utility accounts. That work is separate from checking a single system for internal errors.

Without this comparison, a jurisdiction may overestimate the quality of its address data. Each office sees only the records and rules inside its own system, so the gaps between them stay hidden. As do the problems that arise from those gaps, until they become very real.