Address Verification Software: API Validation vs Physical Field Verification (And When You Need Each)

Address verification software is two different products wearing the same name. The first is an API: Google's Address Validation API charges $17 per 1,000 requests, Melissa charges roughly $0.009 per US address, and both return an answer in under a second, this address exists, it's formatted correctly, mail can be delivered there. The second is an operation: a field agent physically visits the address to confirm the customer actually lives or works there, which costs $2–10 per visit and takes one to five days.

If you run e-commerce checkout or clean a mailing list, you need the first. If you run KYC, loan origination, or credit checks, especially in markets like Nigeria, India, or Southeast Asia where a verified physical address is a core underwriting input, the API alone can't do the job. An address can be perfectly valid and deliverable while the loan applicant has never set foot in it.

This guide covers both: what the API validators cost and prove, when you need boots on the ground instead, and how field-verification teams run the whole operation from a Google Sheet and a map without buying enterprise software.

Address Verification Software Covers Two Different Jobs

Before comparing tools, be precise about which question you're answering. API validation answers: does this address exist in a postal database, is it standardized, and is it deliverable? Field verification answers: is the person who gave us this address actually associated with it?

Those are different risk problems. A fraudulent loan application usually contains a real address, fraudsters copy them from listings. An API validator will wave it through, because the address is genuinely valid. Only a visit (or utility-bill matching, which has its own gaps) establishes the link between the person and the place.

The inverse is also true. Sending a field agent to confirm an address that doesn't geocode, has a typo'd street name, or sits in the wrong postal code wastes a $2–10 visit on something a fraction-of-a-cent API call would have caught. The teams that run this well use both, in sequence.

1. API validation proves: the address exists, is correctly formatted, and is deliverable. Cost: $0.003–$0.017 per check. Speed: milliseconds.

2. Field verification proves: the customer actually lives or works at the address. Cost: $2–10 per visit. Speed: 1–5 business days.

3. Use API validation for: checkout forms, mailing lists, shipping, CRM hygiene.

4. Use field verification for: KYC, loan origination, credit checks, tenant screening, agent/merchant onboarding.

Address Validation API Options: Smarty, Loqate, Google, Melissa

If your job is the software half, checking that addresses exist and are deliverable, four vendors cover most teams. Pricing below is current public pricing as of June 2026; all four use volume tiers, so the per-check cost drops as volume rises.

Smarty starts at $17/month for 1,000 US lookups and scales to $485/month for 170,000, with international verification priced separately at roughly $1.50–$3.00 per 1,000 depending on country. It's the common pick for US-heavy volume with a developer-friendly API.

Google Address Validation API charges $0.017 per request (about $17 per 1,000), dropping to $0.0136 above 100,000 requests per month. Google's monthly free credit covers a meaningful starter volume, and coverage rides on the same data as Google Maps, strong in markets where postal databases are thin.

Melissa sells credits: $30 buys 10,000 credits, a US address verification consumes 3 credits (about $0.009 per check) and a global address consumes 10. Loqate prices per-lookup on a pay-as-you-go credit model with 12-month credit validity, but publishes fewer numbers, expect a sales conversation for committed volume.

Any of the four will catch typos, standardize formats, and flag undeliverable addresses. None of them will tell you whether your loan applicant has ever been to the address. For that, you need the second half of this article.

When an API Isn't Enough: Physical Field Verification for KYC and Credit

In Nigeria, India, and much of Southeast Asia, address verification is a regulated or de-facto-required step in customer onboarding for banks, microfinance lenders, and asset financiers. The check isn't "is this address real", it's "does this applicant demonstrably live or work here," because residence stability is an underwriting signal and a recovery requirement if the loan defaults.

The standard operation: a verification agent visits the address, confirms it physically exists and matches the application, and asks neighbors or gatekeepers whether the customer is known there. The outcome is typically one of three statuses, address exists and customer known, address exists but customer not known, or could not locate the address at all.

Banks either run this in-house with a verification team or outsource it to field-verification agencies that charge per completed visit. Either way, somebody is coordinating dozens to hundreds of visits a week across a city, assigning agents to zones, tracking turnaround time, and reporting outcomes back to credit operations. That coordination problem is a logistics problem, and it's almost always run from a spreadsheet.

How to Run a Field Verification Operation From a Google Sheet and a Map

Here's a real shape of this workflow (anonymized): a Lagos field-verification team runs 315 address checks per week from a single Google Sheet. Each row is one check, customer reference, address, assigned agent, visit date, outcome, turnaround time. In a typical week, 255 visits come back "address exists and customer known," 51 come back "could not locate," and the remainder land somewhere in between. The team maps the whole batch to assign agents by zone and to QA coverage at the end of the week.

The sheet structure that works: one column each for Customer ref, Address, Agent, Visit date, Status, and Comments. Keep status values to a fixed picklist (Verified / Customer not known / Could not locate / Pending), free-text outcomes make the weekly numbers impossible to roll up.

Then put the batch on a map. With InstaMaps (a free Google Sheets add-on), you rename the tab to start with "layer_", open the add-on, and every address in the sheet becomes a pin, the AI detects the address column automatically. From there the map does three jobs the sheet can't:

1. Zone-based assignment: see the week's 300+ addresses spatially and split them by area, so one agent isn't crossing the city for two visits while another covers a single district. Filter by the Agent column to check each person's load before dispatch.

2. Outcome QA: color pins by the Status column, verified vs. could-not-locate. A cluster of red "could not locate" pins in one district is a signal: bad address data from one loan officer, a new development the geocoder doesn't know, or an agent who isn't actually visiting. The sheet shows you 51 failures; the map shows you whether they're random or concentrated.

3. Coverage tracking: filter the map by visit date to confirm the week's batch was actually worked, and spot zones where pending visits are piling up before they breach the turnaround SLA.

4. No per-agent license: the sheet is shared with the team, the map reads the sheet, and the whole stack costs nothing, relevant when the alternative is a field-service platform priced per seat for an operation whose margin is a few dollars per visit.

Pre-Screen Every Batch With a Free Bulk Geocoder

One cheap discipline cuts the "could not locate" rate before any agent leaves the office: bulk-geocode the batch first. An address that won't geocode at all, no match, or a match that lands in the wrong city, has a high probability of failing the physical visit too. Catching it at the desk costs nothing; catching it in the field costs a wasted visit.

InstaMaps has a free bulk geocoder at /tools/geocoder: paste the week's addresses, and it returns coordinates plus a flag for anything that didn't resolve. Route the non-resolving rows back to the loan officer or customer for correction instead of dispatching them. Teams that add this step typically pull a meaningful slice of the failure rate out before it costs field time, in the Lagos example above, 51 of 315 visits (16%) came back "could not locate," and a geocode pre-screen is the cheapest lever against that number.

This is also where the API validators from earlier slot into a field operation: if you're at the volume where $0.009 per check is trivial against $2–10 per visit, run every address through Melissa or Smarty as the first gate, geocode what passes, and send agents only to addresses that cleared both.

Choosing Your Stack: API, Field, or Both

If you ship products or send mail, an address validation API is the whole answer. Pick on coverage for your countries and volume pricing. Smarty for US-heavy volume, Google for global coverage, Melissa for low-cost credits, Loqate for committed enterprise volume.

If you underwrite credit or onboard regulated customers in markets where residency must be proven, field verification is non-negotiable and the software question becomes an operations question: how do you coordinate, dispatch, and QA hundreds of visits a week without a per-seat platform eating the margin. A shared Google Sheet with disciplined columns, mapped with a free add-on, covers assignment, status tracking, and outcome QA for teams doing 50–500 visits a week.

The strongest setup is the sequence: API validation as the first gate (kill the typos and fakes for under a cent each), bulk geocoding as the second (kill the unlocatable addresses for free), and field agents only for addresses that survived both. Every check you eliminate upstream is $2–10 saved downstream.

At a Glance

Common Questions