Pitching geocoding spend to your CFO: a working framework

Geocoding rarely has its own budget line. It hides inside "infrastructure" or "third-party data services" and gets queried every six months by a finance team that wants to know what it actually does. The engineer who owns the integration knows it is load-bearing — bad coordinates cascade into failed deliveries, address-cleanup sprints, mis-routed field reps, and underwriting errors. But the finance team sees a recurring API charge with no obvious P&L attachment.

This post gives you the framework to change that. Not a marketing narrative — a working set of calculation templates, cost-per-record models, and a DIY-build comparison you can drop into a spreadsheet and walk through in ten minutes. Fill in your own numbers; do not borrow anyone else's.

The audience is the operations or engineering lead who needs sign-off. The goal is to get out of "discretionary spend" territory and into "cost of goods sold" territory, where the line item defends itself.

---

Why "it just works" is not a budget argument

The worst moment in a budget review is when someone asks "what would happen if we turned it off?" and you do not have a crisp answer. "Things would break" is not a budget argument. "We would fail an estimated Y% of our monthly delivery volume, each failure costing us roughly £X in re-attempts, customer-service contacts, and refund processing" is a budget argument.

The gap between those two answers is entirely about how you frame the spend before the meeting. Geocoding is unusual because the cost of the service is very small relative to the operational outcomes it protects. That asymmetry is the argument — but only if you have done the maths.

The framework below has three pillars: the cost of bad geocodes (operational harm), the cost of the API itself (unit economics), and the cost of not using the API (the DIY alternative). CFOs understand opportunity cost. Frame the conversation as "here is what we are buying, and here is what building it ourselves would actually cost" and the line item stops feeling discretionary.

---

Pillar one: the cost of bad geocodes

Before you justify the spend, quantify the harm it prevents. Different business models will have different leading indicators; pick the one that fits your operation.

Failed deliveries

If you run any kind of physical fulfilment — parcels, food, field-service technicians, medical supplies — then address quality has a direct cost when it fails. The template:

Failed deliveries per month           = Y
Cost per failure (re-attempt labour   
  + fuel + customer-service contact   
  + refund or expedite charge)        = £X per incident
Monthly cost of address failures      = Y × X

Fill in your own Y and X from your operations data. Y is usually available from your dispatch or WMS system as "address not found" or "driver returned — could not locate." X requires a bit of care: it is not just the re-delivery cost. It is the re-delivery cost plus the CS handle time for the resulting complaint plus any refund or goodwill voucher plus the downstream effect on customer retention (which is harder to quantify but real). For most operations teams, X is larger than the raw logistics cost suggests.

Now calculate what a 1% reduction in Y is worth per month. If you can geocode addresses at the point of capture — before a courier ever leaves the depot — and convert even a fraction of "could not locate" outcomes into successful first-attempt deliveries, the maths almost always dwarfs the API cost. We have written the full logistics case in more detail in Cutting Failed Deliveries with Clean Geocoded Addresses.

Manual address-cleanup hours

Every operations team that does not clean addresses at capture cleans them somewhere else — usually in a weekly export-to-spreadsheet, find-the-bad-ones, look-them-up, correct-them, re-import cycle. The template:

Addresses processed per month         = A
Manual review rate (% that need touch) = R%
Hours per reviewed address             = H
Internal hourly cost (salary + oncosts)= £C per hour

Monthly cleanup cost = A × (R/100) × H × C

This number surprises people. If you are processing 20,000 orders per month and 5% of addresses need a human to touch them, that is 1,000 address reviews. At 4 minutes per review and a £30/hr blended cost, that is £2,000 per month in labour — and that is before you count the errors that get through anyway. Geocoding at capture, with a confidence threshold that flags uncertain results for review only, typically drops R dramatically. The budget argument is the difference.

Field representative drive time

If you have a field sales or service team, bad coordinates translate directly into wasted driving time. The template:

Field reps                             = N
Average bad-coordinate incidents/week  = B per rep
Wasted drive time per incident         = T minutes
Hourly rep cost (salary + vehicle)     = £V per hour

Weekly cost of bad coordinates = N × B × (T/60) × V
Monthly                        = × 4.3

A field team of 30 reps, each losing 20 minutes a week to a "map took me to a field instead of the factory" scenario, is 10 hours of paid time per week — roughly £300/week at £30/hr. That is £1,300/month before you count the deal that went cold because the rep arrived late and flustered.

---

Pillar two: the unit economics of the API

Now that you have a monthly harm number, express the API cost in the same unit. Do not compare "API spend per month" to "operational harm per month" in the abstract — convert both to a per-record cost so the ratio is legible.

What CSV2GEO actually costs

The public pricing is at csv2geo.com/pricing/api. The live numbers:

• Free tier: 3,000 calls per day. No credit card. This is the pilot tier — enough for most teams to prove the integration before any spend is approved.
• Paid tier: starts at $54/month for 100,000 calls.

The cost-per-record calculation at the entry paid tier:

$54 / 100,000 calls = $0.00054 per geocode

That is slightly more than half a tenth of a US cent per address.

If your operation processes 20,000 orders per month, the geocoding cost at the entry paid tier is:

20,000 × $0.00054 = $10.80/month

Ten dollars and eighty cents per month to geocode every order at capture. Compare that to the manual-cleanup cost you calculated above. Compare it to even one failed delivery. The ratio is the argument.

For operations that process hundreds of thousands of records per month, the per-call cost drops at higher tiers — check the pricing page for the current bracket structure. The template is the same: take your monthly call volume, divide into the bracket cost, express as cost-per-record.

Cost per record is the CFO's unit

The reason cost-per-record matters is that it converts the spend into the same language as cost-of-goods-sold. A CFO who processes 50,000 invoices a month at $0.0003 per geocode can see that as $15/month — one dinner's worth of operational overhead. Presented as "$54/month for geocoding" it reads as a vendor relationship. Presented as "$0.0003 per invoice" it reads as a process cost, and process costs are defensible.

The other advantage of cost-per-record framing is that it scales with volume. If the business grows from 50,000 to 200,000 orders a month, the geocoding cost grows proportionally — but so does the harm it prevents. The ratio stays roughly constant, which means the argument stays roughly constant as the business scales.

---

Pillar three: the DIY alternative

The third pillar of the budget argument is the most powerful and the most often skipped. Before you justify the API spend, estimate what it would cost to not use the API — to build and operate the equivalent capability internally.

We have covered this in detail in The Real Cost of Running Your Own Geocoder. The summary template:

INITIAL BUILD COST
Senior engineer time to build the pipeline          = E₁ weeks × hourly cost
Infrastructure setup (servers, storage, networking) = £I one-off

ONGOING OPERATING COST (per year)
Server and storage costs                            = £S/yr
Data licensing or refresh costs                     = £D/yr
Engineer maintenance time                          = E₂ days/yr × daily cost
Incident response (data drift, coverage gaps)       = E₃ incidents/yr × £cost

TOTAL COST OF OWNERSHIP (3 years) = initial + (annual × 3)

The number that surprises most engineering leaders is E₁ — the initial build time. A geocoding pipeline that is production-grade (handles international address formats, normalises unicode, handles null and malformed inputs, has retry logic, has monitoring, has a test harness, deploys reliably) is a four-to-eight week senior-engineer project, not a weekend. At a loaded daily cost of £600 for a senior engineer, eight weeks is £24,000 before the first address is geocoded.

The number that surprises finance is D — data licensing or refresh costs. A self-hosted geocoder needs an address database. Curated, refreshed, global address data is not free. The refresh cycle matters: an address database that is eighteen months stale will fail on new developments, renamed streets, and post-code reorganisations. Factor in the cost of the annual or quarterly refresh, not just the initial import.

The total cost of ownership comparison almost always looks like this:

DIY (3-year TCO):  £X (large number — initial build + three years of ops)
API (3-year TCO):  £Y (small number — monthly calls at current volume × 36)

The ratio is the most defensible number in the room. You are not asking for budget for a vendor relationship; you are demonstrating that the vendor relationship is cheaper than the alternative by an order of magnitude.

---

How to structure the ten-minute budget conversation

The instinct in a budget meeting is to open with the product — "we use CSV2GEO for geocoding, it costs $54/month, we want to keep it." Do not do this. Open with the operational outcome.

A better structure:

1. State the operational stake: "Address quality failures cost us approximately £Z per month, based on Y failed deliveries at £X each."
2. Describe the mechanism: "We prevent the majority of those failures by geocoding every address at the point of capture, before it reaches dispatch."
3. State the unit cost: "That geocoding costs us $0.00054 per address — roughly $10/month at current volume."
4. Show the ratio: "The API costs us $10 to prevent a problem that costs us £Z."
5. Show the alternative: "Building this internally would cost approximately £W over three years."

Five points, ten minutes. The number at point 4 is the one that ends the conversation — it is very rarely close. If your Z is anywhere near real operational pain and your API cost is at the rate published above, the ratio will be in the range of 10:1 to 100:1.

---

How to build the one-page business case

If the ten-minute conversation needs a leave-behind, here is a structure that works.

Step 1: Quantify the current harm

Pull your actual operations data. Failed delivery rate from your WMS, manual review rate from your address team, drive-time incident count from your field ops system. Use real numbers from your last three months, averaged. Do not estimate if you have data.

If you do not have data, instrument first. Add a counter to your dispatch system for "address unresolvable" events. Run it for four weeks. Now you have real numbers.

Step 2: Express harm as a monthly cost

Apply the templates from Pillar One above. Add the three categories that apply to your operation (failed deliveries, manual cleanup, drive time) and sum them. This is your monthly "cost of bad address data."

Be conservative. Exclude the soft costs you cannot measure (customer churn, brand damage, rep morale). Use only numbers you can defend from a spreadsheet. The goal is a number a CFO will accept, not a number that wins the argument most dramatically.

Step 3: Calculate the API unit cost

Take your monthly call volume. Divide by the bracket cost from the pricing page. Express as cost-per-record. Multiply out to a monthly total.

Now add a caching factor. If you cache geocoded results — which you should, as covered in Caching Geocoding Results — 90% Cost Reduction — your effective cost-per-record is lower than the raw API price by a large factor on repeat addresses. A business that ships to the same set of customers repeatedly will see effective geocoding costs drop dramatically once the cache is warm. Model this honestly: what fraction of your monthly addresses are repeat customers versus new ones?

Step 4: Build the DIY comparison

Use the template from Pillar Three. Be honest about the engineering cost — this is not the place to lowball the estimate. A DIY build that is underestimated and then overruns is a worse outcome than a vendor relationship that costs slightly more than you projected. Finance teams remember the project that was supposed to cost £20k and cost £80k far longer than they remember a $54/month line item.

Step 5: Present the ratio, not the absolute cost

The one-page leave-behind should have one number in large type. Not the monthly API cost. The ratio: "for every £1 we spend on geocoding, we protect approximately £Z of operational value." That is the number a CFO remembers. The appendix can have the full model; the cover page has the ratio.

---

Edge cases that weaken the argument — address them first

A prepared budget defence anticipates the pushback.

"Can we just use the free tier forever?"

The free tier is 3,000 calls per day. For a small operation or a pilot, yes. For a business processing 50,000 orders per month, 3,000 calls per day is a ceiling you will hit in the first two days of the month. Be transparent: the free tier is the evaluation tier, not the production tier. The conversation should be about whether the paid tier is cost-justified, not whether you can stay on free forever.

"What if we cache everything and stay under 3,000/day?"

Caching is good practice regardless. But caching only works for repeat addresses — new customers, new delivery destinations, and address corrections bypass the cache. If your address entropy is high (logistics, gig-economy platforms, anything with a high proportion of first-time customers), the cache hit rate will be lower than you expect. Model this with real data from your address logs before you commit to a caching-based cost-reduction argument.

"Why not batch the whole thing offline and pay less?"

Batch processing is exactly what the API supports — the batch tool accepts address rows and returns coordinates in bulk. For workflows that can tolerate offline processing (nightly import of new orders, quarterly enrichment of a customer database), batching is the right architecture. The cost model is the same: credits consumed equal rows processed. What batching does not do is reduce the per-record cost — it reduces latency and simplifies the pipeline, but the credit consumption is the same.

"Could we cut the call volume by 50% with better input validation?"

Yes, and you should. Input validation upstream of the geocoder — stripping malformed strings, normalising common abbreviations, deduplicating within a session — reduces call volume and improves hit rate. The engineering investment in upstream cleaning has a real return. But it does not eliminate the need for the geocoder; it makes the geocoder work better. Include this in the three-year cost model as a one-off engineering project on the benefit side, not as an argument against the API spend.

---

What the observability layer adds to the business case

One thing that strengthens the budget argument significantly is having metrics. A finance team that asks "how do we know this is working?" deserves a real answer — not "trust us, it works."

The observability patterns for geocoding pipelines are covered in Observability for Geocoding Pipelines, but for the budget conversation, three metrics are sufficient:

1. Geocode success rate: the fraction of address submissions that return a result with confidence above your threshold. Track this weekly. A declining trend is an early warning that your input data quality is degrading or that address formats in a new market are not being handled.
2. Confidence score distribution: histogram of confidence scores across your monthly call volume. A large tail below 0.7 is evidence that your upstream address capture is broken, not that the geocoder is failing — useful for redirecting a "the geocoder is costing us money" conversation to "our checkout form is capturing bad data."
3. Cache hit rate: the fraction of geocoding calls that were served from cache rather than from the API. For a mature operation with a warm cache, this should be 40-70%+ depending on your customer repeat rate. Showing this number to finance demonstrates that you are actively managing the cost, not just letting the API bill accumulate.

These three numbers fit on one slide. They show that the spend is monitored, that the system is working, and that the team is managing cost actively.

---

Frequently Asked Questions

How do I find my actual failed-delivery rate if my WMS does not track it explicitly?

Start with courier exception codes. Most dispatch and courier systems log outcomes per shipment, and "address not found," "unable to locate," and "customer not present at given address" are separate codes. Pull the last 90 days, filter for address-type exceptions, and divide by total shipments. That is your baseline Y. If your system does not have exception codes, look at re-delivery attempts — any order that generates a second delivery attempt is a proxy for a first-attempt failure, even if the reason is ambiguous.

The CFO wants a payback period, not a ratio. How do I calculate that?

Payback period = (cost of switching to paid tier) / (monthly harm reduction). Cost of switching is usually $0 — there is no setup fee, and the free tier transitions to paid by adding a payment method. Monthly harm reduction is the most conservative estimate of what improves in month one: if you geocode at capture and immediately reduce failed deliveries by even a small fraction, the harm reduction in the first month is real. The payback period is typically measured in days, not months, which is why the ratio framing is often more persuasive — a two-day payback period sounds implausible to a CFO who is used to six-month software paybacks.

What if our volume is too low to justify moving off the free tier?

If 3,000 calls per day is enough for your operation, stay on the free tier. The free tier is a fully-functional production tier — it is not rate-limited to a degraded version of the API. The only constraint is the daily call ceiling. If you are comfortably below 3,000 calls per day and do not expect volume growth in the next 12 months, the budget conversation is simply "this service is free and we should instrument it properly and keep using it."

How should I handle the fact that geocoding is one of several address-quality tools we use?

Attribute the outcome honestly. If you have an address-normalisation layer upstream and the geocoder downstream, the combined system produces the result — do not attribute 100% of the harm reduction to the geocoder alone. A clean attribution model might be: normalisation reduces Y by a fraction, geocoding reduces the remainder by a fraction, and the total harm reduction is the sum. In practice, most teams find that geocoding at capture is the single highest-leverage intervention and normalisation is complementary rather than competitive.

The engineering team wants to evaluate the API before committing. What is the fastest way to do that?

Sign up for the free tier — no credit card, 3,000 calls per day — and run your last month's address backlog through the geocoder over a few days. Compare the confidence score distribution against your current failure rate. That empirical test is more persuasive in a budget meeting than any benchmark or case study, because it uses your own data. The benchmarking methodology for doing this rigorously is covered in Benchmarking Geocoding APIs — Honest Numbers.

What is the right way to present the DIY build cost without underselling it?

Use loaded cost — not salary, but salary plus employer contributions, office overhead, management overhead, and opportunity cost (what else could that engineer have built in those eight weeks?). Use a senior engineer rate, not a junior one, because geocoding infrastructure requires understanding of address normalisation, Unicode handling, international address formats, and distributed retry patterns — not a graduate project. And include the ongoing cost explicitly: a self-hosted geocoder that is not actively maintained will drift, and the cost of a coverage incident at 2am on a Monday is not zero.

---

Related Articles

• Cutting Failed Deliveries with Clean Geocoded Addresses — the logistics case in detail
• The Real Cost of Running Your Own Geocoder — full DIY build and operate cost model
• Benchmarking Geocoding APIs — Honest Numbers — how to run a credible evaluation before you commit
• Caching Geocoding Results — 90% Cost Reduction — how to reduce effective per-record cost with a warm cache
• Observability for Geocoding Pipelines — the three metrics that make a budget review easy

---

*I.A. / CSV2GEO Creator*