Caught at the gate
A reviewer reads one flagged segment. Minutes, before anything ships.
Translation cost
Your invoice is not your cost.
Spend reports show you rates and volumes. They don't show how much of that volume you had already paid to translate once — or how many of your own team's hours went into fixing what arrived.
The problem
What a spend report can tell you
Cost per word, by vendorVolume invoiced, by marketWhich suppliers are expensiveWhere the budget went
That's a complete picture of the transaction and a poor picture of the cost.
What isn't in it: how much of the volume you paid for was content already translated and approved somewhere else in the organisation. How much reviewer time went to content that didn't need reviewing. And the hours your own people spent correcting delivered files — which land in marketing or engineering capacity, not in the translation budget, and so appear in no report at all.
The pattern is consistent enough that teams describe it the same way: the file comes back, someone internally fixes the terminology, and nobody counts it.
The loop
The cost of a defect is set by when you find it
Software organisations price bugs this way as a matter of routine. Translation has the same curve and almost nobody manages it.
Caught internally after delivery
Someone has to notice — often a local market contact rather than whoever commissioned it. Then diagnose whether it's translation, source or layout. Then reopen a closed, invoiced project, where "error" versus "preferential change" is a commercial argument, because rework is unpaid work for the supplier.
Caught after publication
All of the above, plus re-export and re-upload across every market sharing the asset, and a release that slipped. None of it lands in the translation budget.
And in a language nobody internally reads
You can't diagnose it. You send it back and accept the fix on trust — which is how the same loop runs a second time. Layout is the exception: target text runs longer than source, the design stops fitting, and that fix is usually billed as DTP rather than translation. One quality failure, two invoices, one delay.
Where are your translation costs really coming from?
Our research reveals the hidden workflow costs driving translation spend — and where companies lose time, consistency and budget as content scales.
Why it persists
Why consolidation stops working
Bringing vendors together is the right instinct and it does produce a saving. It produces it once.
Rate is a one-time lever
A consolidated rate is negotiated, banked, and becomes the new baseline. There's nothing left to compress next cycle without changing supplier quality.
Volume is the recurring one — and nobody negotiates it
What drives spend year on year isn't what you pay per word, it's how many words you pay for.
The reuse discount is calculated by the party being paid
Leverage discounts are applied at rates the supplier sets, against a memory the supplier holds. You receive a discount on a saving you generated, on terms you can't audit.
And it resets
Change vendor, or lose the translator who learned your product, and the accumulated consistency starts over — because it was never in your possession.
The pivot
Volume is only a cost driver because of how you're priced
Under a per-word contract, every word you publish costs money, permanently. Content growth is a budget event. Reuse becomes a negotiation, because it reduces the supplier's revenue — that isn't bad faith, it's arithmetic.
Our plans include volume rather than metering it. OnePlatform covers 500,000 words a month with unlimited users. OneEnterprise is unlimited. Publishing more stops being the thing that moves the number.
It also makes iteration free. Re-running corrected source through an agency is a new purchase order, so teams patch instead of reprocessing. On an included-volume plan there's no reason not to run it again properly.
So if volume isn't metered, why does reuse still matter? Because reuse was never really about machine cost. It's about how much human attention each release demands — and human attention is the only thing left that scales.
What we build instead
Reduce the attention each release needs, not the rate you pay for it
Approved terminology and translation memory sit in your tenant, not a supplier's, and are applied while content is generated rather than credited afterwards — so repeated content never enters the review queue in the first place.
Review is routed by score
Review is routed by score
Every segment is scored against its source. Specialist time goes to what fell below threshold, not evenly across the file.
Specialist time goes to what fell below threshold.
Measurement
What procurement can actually measure
Centralisation is usually justified on rate. These are the numbers that show whether the operation improved.
Share of volume that was new
The figure most organisations can't currently produce. It sets review demand, not the bill.
Reuse rate by market
Where reuse is low, either the content really is new or the assets aren't reaching the work.
Review hours per 1,000 words
Falling means routing is working. Flat means review is still spread evenly.
Rework cycles per release
How often work comes back, and the internal hours it consumes. The cost that never appeared in a spend report.
Cost per market per release
Forecastable once the four above are known.
Rate per word
The least informative of these — it's the number that stops moving first.
Delivery
Why this has to be infrastructure
Coordination is a cost, and most of it comes from work being handed between systems by people. A gate that sits in the path the content already travels removes the handoff rather than managing it.
API
Releases trigger translation and gate on score. No project request, no queue.
MCP Server
Agents retrieve approved terminology at generation time, so content is produced inside the rules.
Automation platforms
Your team composes the flow in a tool they already run.
Self-service
For teams and one-off requests that don't need integration.
Pricing
The plans are published. The enterprise number isn't a mystery either.
Standard use is priced on the page. Multi-market operations are modelled individually — bring your volumes, markets and vendor mix and we'll work through it.
Business outcomes
Buy the work that's new. Stop buying the rest.
Content growth stops being a budget event
Volume is included rather than metered, so publishing into more markets doesn't move the line item.
Review cost follows risk
Specialist hours land where the score says they're needed.
Defects surface before they're expensive
Findings arrive pre-publication, so the fix is a reviewer's minute rather than a reopened project, a DTP invoice and a slipped release.
The curve starts where you already are
Bring the memories and published translations you already own. Everything after that accumulates in your tenant rather than a supplier's.
Management scenarios
Where centralised translation creates value
Multiple vendors across markets
One operating standard instead of parallel negotiations.
Global procurement
Demand and reuse visible before consolidation decisions are made.
Mergers and acquisitions
Bring separate language assets into one tenant rather than one contract.
Recurring product updates
The highest-reuse content, and the largest re-buy risk.
Growing content operations
More markets without proportionally more coordination.
Regulated content
Standardised terminology and review, auditable per market.
Turn fragmented spend into an operation you can forecast
Own the language assets, stop paying by the word for content you already have, and see the cost that never reached a report.
FAQ
Questions about centralizing translation operations
Do we need to replace every local translation vendor?
No, and it's usually the wrong first move. The lever isn't who does the work — it's where the terminology and memory live. Vendors and in-market reviewers can keep working inside a tenant you own, which means their output accumulates on your side rather than theirs. Supplier decisions get easier afterwards, because switching no longer costs you the accumulated language.
Can markets keep their own reviewers and language specialists?
Yes, and there's no per-seat reason not to. From OnePlatform upward users are unlimited, so adding the person in-market who actually knows the product is a permissions decision rather than a budget one.
How can we identify duplicate translation spend?
By measuring what share of each release was genuinely new content rather than content already translated somewhere in the organisation. Most spend reports can't produce that figure because volume is recorded per invoice, not per segment. Once reuse is measured centrally, duplication shows up as the gap between words commissioned and words that were actually new.
What happens to the translations we've already paid for?
They come with you. Existing translation memories and termbases import directly, and where you don't have those — which is most organisations, because vendors hold them — the translations you've already published can be aligned into candidate memory. That doesn't require anyone's cooperation, since published content is already yours. Candidates aren't authority, though: your people confirm what's correct, and only then is it enforced.
Who pays when a translation has to be redone?
With a supplier it's a negotiation, because rework is unpaid work for them and the line between an error and a preferential change is genuinely arguable. The more useful question is how often it happens. When every segment is scored before delivery, defects surface as findings you act on rather than disputes you open — and because volume is included rather than metered, reprocessing corrected content doesn't generate a new charge.
Can we start with one region or business unit?
Yes, and it's the normal path. A single market or content type establishes the reuse and review baselines that make the case for the rest. The assets built during a pilot stay usable when scope expands.
What should management measure after centralization?
Share of volume that was new, reuse rate by market, review hours per thousand words, internal correction hours, and cost per market per release. Rate per word is the least informative of these, because it's the number that stops moving first.
Can centralization slow down local teams?
It does when centralisation means routing every request through a central queue. It doesn't when what's centralised is the terminology and memory rather than the workflow — markets keep their own delivery path through API, automation platforms or self-service, working against shared assets.