Tax Jurisdiction Resolution & Address Cleansing

Sales tax and VAT rates are jurisdiction-specific — sometimes down to the city, county, or special taxing district. A tax engine keyed on the wrong state, city, or postcode string produces the wrong rate.

The problem

Free-text addresses supplied by customers are inconsistent — abbreviated states, missing postcodes, unit numbers jammed into the street line. Feeding that directly into a tax engine risks parsing errors that put the transaction in the wrong jurisdiction entirely.

How address standardisation helps

Standardising the address first isolates state, city, and postcode into clean fields, while providing standardized expansions where street abbreviations ("5th Ave" → "5th Avenue") and city/state representations are canonicalized. This gives tax engines and geocoders structured inputs for precise rooftop jurisdiction boundary matching.

Example

curl -X POST "https://api.goodvat.com/v1/address/normalize" \
  -H "Authorization: Bearer $GOODVAT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "query": "350 5th Ave New York NY 10118" }'

{
  "houseNumber": "350",
  "road": "5th ave",
  "postcode": "10118",
  "city": "new york",
  "state": "ny",
  "country": "USA",
  "expansions": [
    "350 5th avenue new york ny 10118 usa",
    "350 5th avenue new york new york 10118 usa"
  ]
}

Key response fields

Field	Why it matters here
`expansions`	Canonical address strings used to cross-reference municipal boundary shapefiles and special taxing district tables.
`state`	Primary driver of US sales tax / country-level VAT rate selection.
`city`	Needed for city-level sales tax add-ons in home-rule jurisdictions.
`postcode`	Finer-grained jurisdiction lookups (special districts, ZIP+4 boundaries).
`country`	Determines which tax regime (VAT, GST, sales tax) applies.