> ## Documentation Index
> Fetch the complete documentation index at: https://docs.symmetry.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Data and accuracy

> How Payroll Point geocodes an address, the shapefile data behind tax determination, how to read geocode quality, and what to do when a location resolves incorrectly.

Payroll Point's accuracy rests on two things: how precisely an address is converted to coordinates, and how current the boundary data those coordinates are matched against is.

## From address to coordinates

Every lookup begins by normalizing and validating the address against official postal data, then geocoding it to a latitude and longitude. The target is rooftop accuracy, meaning a point inside the property boundary rather than an approximation.

Precision matters because tax boundaries don't follow postal lines. Two addresses sharing a ZIP code can sit in different school districts, and a JEDD boundary can run down the middle of a street. A ZIP-level approximation is often enough in a state with only state-level taxes, and not nearly enough in one with local taxes.

You can bypass normalization entirely by passing latitude and longitude directly, which is useful for new developments that aren't yet in postal data.

## The boundary data

Coordinates are matched against roughly 35,000 geospatial tax boundary shapefiles, drawn from three sources:

* The U.S. Census Bureau
* State and local taxing jurisdictions
* Symmetry's own proprietary research

Boundaries change as jurisdictions are created, dissolved, or redrawn. Shapefile updates ship with Payroll Point releases and are listed under **Shapefile Updates** in the [release notes](/prp/changelog), so you can see which jurisdictions changed and when.

Address and geocoding data comes from Melissa Data, Symmetry's geodata provider. Its version is recorded in the release notes too, so you can tell exactly which data build a given release resolved addresses against.

## Reading geocode quality

Every lookup returns result codes describing what happened during normalization and geocoding. They tell you how much confidence to place in a result.

| Family | What it reports                                                            |
| ------ | -------------------------------------------------------------------------- |
| `AS`   | Address status, including whether the address is valid and deliverable     |
| `AC`   | Address changes made during normalization, such as a corrected street type |
| `AE`   | Address errors, where the address could not be verified                    |
| `GS`   | Geocode status, from rooftop level down to ZIP centroid                    |
| `GE`   | Geocode errors                                                             |
| `AV`   | How far the address was verified, from state level to sub-premise          |
| `AX`   | An address exception was applied                                           |
| `SA`   | A suggested address was used instead of the input                          |

The `GS` family is the one to watch. `GS05` and `GS06` indicate rooftop-level geocoding. `GS01` through `GS04` mean the point was resolved to street, neighborhood, community, or state level instead. In states with local taxes, anything below rooftop deserves review. See [Payroll Point result codes](/prp/references/result-codes) for the full list.

## When a location resolves incorrectly

Two different tools handle two different problems:

* **Address suggestions** substitute a close match when an address cannot be validated at all.
* **Address exceptions** override the coordinates when an address validates but resolves to the wrong place.

They differ in scope as well as purpose: a suggestion affects one lookup, an exception applies to everyone in your organization. See [Address suggestions vs address exceptions](/prp/core-concepts/suggestions-vs-exceptions) for how to choose, and [Verify addresses and geocoordinates](/prp/portal/verify-addresses) for verifying a location first.