Forecasting geocoding costs as your address volume grows

Budget season arrives and someone puts a line item in the spreadsheet labelled "geocoding API." Then they ring the engineering team, who give a number that is either wildly high (they quoted the batch backfill once a month for all time, as if addresses keep arriving fresh every day forever) or wildly low (they forgot the backfill entirely and quoted only the steady-state trickle). Neither number survives the first actuals comparison.

The reason the estimate goes wrong is almost always the same: the person forecasting does not distinguish between the two fundamentally different cost events, does not factor in how caching changes the marginal call rate, and has not checked whether the data pipeline deduplicates addresses before sending them to the API. Fix those three things and your forecast lands within ten percent of reality.

This post gives you a concrete worksheet, explains the two meters CSV2GEO uses (which differ depending on whether you use the batch web tool or the REST API), and walks through three real-world growth scenarios so you can map your situation to a number before you speak to finance.

---

The two meters you need to understand

CSV2GEO exposes geocoding through two surfaces, and they bill differently. Most engineers know this intellectually; most budget forecasts treat them identically and get burned.

Batch web tool — credits equal rows. When you upload a CSV through the web interface, each row in the file consumes one credit, regardless of how many fields the row contains or how the geocoding resolves. Upload a file with 40,000 rows, spend 40,000 credits. This is the right surface for a one-time backfill or an occasional offline enrichment job where your team does not want to write integration code. The billing unit is the row count of the file.

REST API — credits equal calls. When your application code calls /api/v1/geocode, each HTTP request consumes one call credit. If your code sends one request per address, one address equals one call. If your code batches addresses into a single request (where supported), the batch counts as one call. This is the right surface for production pipelines, real-time enrichment, and anything that needs to run programmatically on a schedule. The billing unit is the number of HTTP requests your code makes.

The practical implication: a team that geocodes a thousand addresses via the web batch tool spends exactly 1,000 credits. A team that calls the REST API in a loop with one address per request also spends 1,000 credits. A team that calls the REST API but sends ten addresses per request spends 100 credits for the same result — but only where the endpoint supports batching. When you are forecasting, you need to know which surface your pipeline uses and whether it batches. Both are stated here because most forecasts assume one surface and quietly swap to the other six months in.

The free tier is 3,000 calls per day — no credit card required. Paid plans start at $54/month for 100,000 calls. The published tiers are the prices; for anything at the volume where you need a custom conversation, the honest answer is to talk to us. Numbers are on the pricing page.

---

The worksheet

Here is the forecast formula. It fits in four rows of a spreadsheet and produces a defensible monthly call estimate.

monthly_calls =
  (new_records_per_month × 1)
  + (total_backlog_rows ÷ amortisation_months)
  - (monthly_calls × cache_hit_rate)

Which simplifies to:

monthly_calls =
  ((new_records_per_month + backlog_rows_per_month) × (1 − cache_hit_rate))

Where:

• `new_records_per_month` — the number of net-new addresses entering your system each month that have never been geocoded. Do not count updates to existing records unless the street address component changed.
• `backlog_rows_per_month` — your total historical backlog divided by the number of months over which you plan to amortise it. A 500,000-row backlog processed over 10 months is 50,000 rows per month.
• `cache_hit_rate` — the fraction of geocoding requests you can serve from a local cache rather than calling the API. Discussed in detail below. A conservative starting estimate for a typical CRM or logistics dataset is 0.40; many teams reach 0.70 after tuning.

Apply this once to get a raw call estimate, then price it against the published tiers. The number you get is your baseline. The three sections below explain how to drive it down.

---

Step 1: Separate backfill cost from steady-state cost

This is the single error responsible for most bad geocoding budget estimates. The backfill is a spike, not a constant.

Suppose you have 800,000 historical customer records that have never been geocoded. You plan to geocode all of them in Q1 to enrich your customer data warehouse. After that, your system ingests roughly 8,000 new customers per month.

A naive estimate multiplies 8,000 by 12 and adds 800,000, getting 896,000 calls for the year. That number is correct in aggregate but useless for monthly budgeting — it front-loads the cost catastrophically in January, then makes every subsequent month look cheap by comparison, which is the opposite of what you want when you are setting a recurring line item.

The correct model separates them:

| Month | Backfill calls | New record calls | Total | |---|---|---|---| | Jan | 266,667 (800k ÷ 3) | 8,000 | 274,667 | | Feb | 266,667 | 8,000 | 274,667 | | Mar | 266,667 | 8,000 | 274,667 | | Apr–Dec | 0 | 8,000 | 8,000 |

After Q1 the recurring cost is 8,000 calls per month, which sits comfortably within a single paid tier. The Q1 cost is a one-time capital expenditure you can budget separately or fund from a project budget rather than an operational line. These are two different conversations with finance; conflating them loses both.

In your worksheet, always fill in the backfill row with total_backlog ÷ months_to_complete. If you plan to finish the backfill in one month, that is total_backlog ÷ 1. If you want to spread it over six months to stay on a smaller plan, divide by six.

---

Step 2: Apply the cache hit rate before you commit to a plan tier

The cache hit rate is the most powerful lever in the forecast. It is also the most commonly omitted. Most teams treat geocoding as a stateless lookup: address in, coordinates out, repeat. They bill for every lookup. A cached pipeline treats the lookup as idempotent and expensive — worth doing once and storing the result in a key-value store, a database column, or an in-memory cache so the second call for "123 Main St, Boston, MA" never reaches the API.

A full treatment of how to build this is in Caching Geocoding Results — 90% Cost Reduction. The budget-planning implication is simpler: you need to estimate your dataset's address repeat rate before you commit to a plan tier.

Three archetypes:

High-churn CRM data. A SaaS company adds new customers at a steady rate and rarely revisits old ones. Address repeat rate might be 20-30%. A cache saves some calls but not a transformative amount. Use a 0.25 cache hit rate in your worksheet.

Delivery routing or field-service dispatch. The same stops recur every week. A technician who services 150 buildings on a fixed circuit will hit the same addresses hundreds of times per year. Cache hit rates of 0.70-0.85 are realistic once the initial population is geocoded. The marginal cost of year two is almost nothing.

Insurance policy or lease renewal book. Addresses are stable; the same pool is re-evaluated quarterly. After the initial geocoding run, a cache produces near-100% hit rates on renewal cycles. The ongoing cost is essentially the rate of new policies entering the book.

Put your archetype's estimate into the worksheet. If you are uncertain, use 0.40 as a conservative starting point and revisit after three months of instrumented pipeline logs. Your observability layer should be recording cache hits alongside API calls — if it is not, Observability for Geocoding Pipelines covers what to instrument.

---

Step 3: Deduplicate your input before it reaches the API

Deduplication is distinct from caching. Caching avoids redundant API calls at runtime by storing results locally. Deduplication removes redundant records from your input dataset before any API call happens — so the redundant rows never enter your pipeline at all.

Consider a logistics company that ingests daily driver manifests from six regional offices. Each office exports a full route list, not a delta. The same depot address in every manifest gets geocoded six times per day unless you deduplicate across manifests before geocoding. At 250 working days per year, one duplicated depot address costs 1,500 unnecessary calls per year. Multiply by 400 recurring depot addresses in the network and you are spending 600,000 calls per year that produce zero new information.

The fix is a normalisation step that runs before the geocoding call: canonicalise the address string (uppercase, strip trailing whitespace, normalise unit and suite abbreviations), compute a hash of the canonical form, and look up the hash in a seen-addresses table. If the hash exists and the geocode result has not expired, skip the API call and return the cached result. If the hash is new, geocode it and store both the hash and the result.

A detailed implementation guide is in Deduplicating Geocoded Addresses with Stable Keys. The budget impact is direct: on a dataset with 30% duplicate addresses — common in CRM exports and multi-source data pipelines — deduplication reduces your effective call volume by 30% before caching even enters the picture. Chain the two together and teams regularly land at 50-60% of their naive call estimate.

In your forecast worksheet, apply deduplication as a multiplier on new_records_per_month:

effective_new_records = new_records_per_month × (1 − dedup_rate)

Use 0.15 as a conservative dedup rate if you have not measured it. For data pipelines that aggregate from multiple source systems, 0.30-0.40 is typical.

---

Step 4: Model three growth scenarios

A single-point estimate is not a forecast; it is a guess. A budget forecast should show the model under three conditions so finance understands the range and the assumptions behind it.

Here is a worked example for a mid-size property management company geocoding tenant addresses. Current figures:

• Historical backlog: 120,000 addresses
• New tenant move-ins per month: 2,200
• Planned backfill timeline: 4 months
• Cache hit rate (archetype: high-churn tenant data): 0.35
• Dedup rate (tenant data from two source systems): 0.20

Base case — steady growth at current rate:

backlog_per_month    = 120,000 ÷ 4         = 30,000 (months 1–4 only)
effective_new        = 2,200 × (1 − 0.20)  = 1,760
gross_monthly        = (30,000 + 1,760)     = 31,760 (months 1–4)
gross_monthly        = 1,760               (months 5+)
after_cache          = 31,760 × (1 − 0.35) = 20,644 (months 1–4)
after_cache          = 1,760 × (1 − 0.35)  = 1,144  (months 5+)

Months 1–4: ~20,644 calls/month. Months 5–12: ~1,144 calls/month. The 100,000-call paid tier covers months 1–4 with room; steady-state months could drop to a smaller plan. Total year-one calls: ~91,808.

Upside scenario — tenant acquisition doubles:

New move-ins rise to 4,400/month from month five onward. Everything else equal. Months 5–12 steady-state rises to ~2,288 calls/month. Still comfortably within the base tier. The growth scenario does not materially change the budget.

Downside scenario — backfill rushes in month one:

Finance asks you to complete the backfill in one month rather than four to unlock a data quality initiative. Month one: (120,000 + 1,760) × (1 − 0.35) = 79,144 calls. That sits just under the 100,000-call tier but close enough that a worse-than-expected dedup rate could push it over. Budget a buffer call to talk to us if month-one volume might exceed the published tier ceiling.

Running these three scenarios takes ten minutes in a spreadsheet and produces a range your finance partner can actually work with: "We expect to spend between £X and £Y in month one, then settle to £Z recurring from month five." That is a fundable conversation.

---

Step 5: Translate calls to pounds (or dollars) and build the line item

With a call forecast in hand, the cost translation is mechanical. The published pricing is at csv2geo.com/pricing/api. Do not apply any discounts or volume breaks that are not published there — if your forecast suggests a volume where a custom arrangement makes sense, the correct budget line is "estimated from published tiers, subject to commercial discussion" and the correct action is to talk to us before the budget is locked.

For the property management example above:

• Months 1–4: ~20,644 calls/month → the $54/month for 100,000 calls tier covers this comfortably
• Months 5–12: ~1,144 calls/month → the free tier (3,000 calls/day, no credit card) likely covers this entirely

That makes year-one cost roughly $54 × 4 = $216 for the paid months, with steady-state potentially free. Add a 20% buffer for estimation error and round to $260. That is the number that goes in the budget. It is defensible, it is derived from first principles, and it will not embarrass you when actuals come in.

If your volumes are materially higher — say, 10 million calls per year — the published tiers are the starting point and the honest answer is that the right budget line is "talk to us" until you have a commercial quote. Do not invent an extrapolated rate and present it as confirmed pricing.

---

The three levers, ranked by effort

When the first-pass forecast comes out higher than you want, here is the order in which to pull the levers:

1. Deduplication (lowest effort, highest yield for multi-source pipelines). A normalisation and hash-lookup step before the geocoding call is a few hours of engineering. On data pipelines that aggregate from multiple sources, a 20-40% reduction in effective call volume is realistic. Do this first.

2. Caching (medium effort, transformative for stable address pools). A key-value cache with a long TTL (addresses do not move on human timescales) can eliminate 60-90% of repeat calls after the initial population run. The engineering investment is moderate — a Redis or database-backed cache, a lookup-before-call pattern, and a TTL management policy. For delivery routing, field-service, and renewal-book use cases, this pays back in weeks.

3. Amortising the backfill (lowest engineering effort, pure budget planning). If the backfill is driving the cost spike, spread it over more months. The API handles the same total volume; you pay the same total cost; but the monthly peak is lower and you may stay in a cheaper plan tier throughout. The only cost is time — the backfill takes longer.

Pulling all three levers on the property management example above reduced year-one cost from a naive estimate of 504,000 calls (no caching, no dedup, backfill in one month) to 91,808 calls — an 82% reduction with no loss of data quality.

---

A note on the free tier in your forecast

The free tier — 3,000 calls per day, no credit card — is not just for prototyping. For teams with low-volume steady-state intake (a few hundred new addresses per day), the free tier is a legitimate long-term operating position. The constraint is the daily limit, not a monthly cap. A team that geocodes 500 new addresses per day, every day, with a 0.40 cache hit rate has an effective API call rate of 300 per day — well within the free tier indefinitely.

If your forecast shows steady-state calls under 3,000 per day, put the free tier in the budget as the baseline and note that the backfill months require a paid tier. That framing is accurate and it makes the cost spike look finite rather than permanent.

---

What a well-structured budget line looks like

For the benefit of anyone copying language into a budget document:

> Geocoding API — recurring operational spend > Vendor: CSV2GEO. Billing: per-call REST API, published tiers at csv2geo.com/pricing/api. > Backfill (one-time, Q1): estimated N calls at $54/month tier, total $X. > Steady-state (Q2 onwards): estimated M calls/month; within free tier / $54/month tier [delete as applicable]. > Assumptions: Y% cache hit rate on repeat addresses, Z% deduplication rate across source systems. > Sensitivity: a 20% increase in new-record intake rate increases annual spend by $A; a 20% decrease decreases it by $B. > Pricing subject to change; re-validate against csv2geo.com/pricing/api before budget lock.

That block takes five minutes to fill in once you have run the worksheet. It tells finance what you are buying, what the levers are, and what would cause the number to move. It is a budget line that can be defended in a review.

---

FAQ

What is the difference between a "call" and a "credit" in the pricing? For the REST API, one HTTP request equals one call credit. For the web batch tool, one CSV row equals one row credit. Both consume from the same plan allowance. If your pipeline mixes both surfaces — say, a batch import via the web tool and a real-time lookup via the API — both draw down the same monthly allocation.

Does the free tier reset daily or monthly? Daily. The free tier provides 3,000 calls per day. Unused calls do not roll over to the next day. For budgeting purposes, treat the free tier's effective monthly capacity as approximately 90,000 calls (3,000 × 30) — but note that a single-day spike above 3,000 will be rate-limited even if the monthly total is under 90,000. For spiky workloads, a paid plan with a monthly bucket is more predictable.

Should I count failed or errored API calls against the budget? API calls that return a valid HTTP response — including 200 OK with a no-match result and 400 Bad Request for malformed inputs — typically consume a call credit. Calls that fail at the network level before reaching the API do not. In practice, build a 5% overhead into your forecast for retries, malformed address rows, and test calls during development. The exponential backoff post covers how to keep retry volume bounded.

What if our address volume is seasonal — high in summer, low in winter? Model each month individually rather than using an annual average divided by twelve. A retail delivery business that processes three times the normal volume in November and December should forecast November and December against the relevant tier separately, then check whether upgrading to a higher tier for those two months is cheaper than overage. For anything above the published tiers, talk to us before peak season, not during it.

We have a large historical backlog but no budget to geocode it all at once. How do we prioritise? Prioritise by business value of the geocoded result, not by alphabetical order or import date. For most businesses, active customers and high-value accounts come first; dormant records from five years ago come last. A tiered backfill plan that geocodes the top 20% of records (by recency or value) in month one and processes the tail over the following year often produces 80% of the business value at 20% of the upfront cost.

Is there a trial period or a sandbox to validate our volume estimates before committing to a plan? The free tier — 3,000 calls per day — is effectively a permanent sandbox for validation purposes. Run a representative sample of your address data through the API on the free tier to validate your dedup rate, cache hit rate, and effective calls-per-record. Use those measured numbers in the forecast worksheet rather than the estimates in this post. Measured inputs produce better forecasts than assumed ones.

---

Related Articles

• Caching geocoding results — 90% cost reduction — the implementation detail behind the cache hit rate lever in the worksheet
• Deduplicating geocoded addresses with stable keys — how to normalise and hash addresses so duplicates never reach the API
• Pitching geocoding spend to your CFO — once the forecast is built, how to present it to a non-technical audience
• Benchmarking geocoding APIs — honest numbers — how to validate that the calls you are paying for are producing accurate results
• Observability for geocoding pipelines — what to instrument so your actuals match your forecast assumptions

---

*I.A. / CSV2GEO Creator*