Multilingual vendors occupy the most complex position in the localization supply chain. They sit between enterprise clients with sophisticated demands and a fragmented network of specialized vendors and freelancers. Their business model depends on optimizing this middle ground – and that optimization challenge shapes every technology decision they make.
In the previous articles, I examined why enterprises can’t rely on a single TMS despite owning one, and how the gaps get filled with spreadsheets and workarounds. For MLVs, the situation is both similar and different. They face the same multi-system reality, but their central system isn’t a TMS – it’s a business management system. And their challenges aren’t about escaping lock-in but about managing complexity at scale.
The Economics of Being in the Middle
Understanding MLV technology choices requires understanding MLV economics. Unlike enterprises, who can save money by translating less or using more automation, MLVs only make money on what clients actually order. Their margin is the difference between what clients pay and what vendors charge.
This creates relentless pressure to optimize. Every project is an optimization problem: which vendor offers the best combination of quality, price, and availability for this specific content type, language pair, turnaround time, and volume? Get it right consistently, and you build a profitable business. Get it wrong, and margins evaporate.
The complexity compounds quickly. A typical MLV might work with hundreds of vendors across dozens of language pairs. Each vendor has different rates – often varying by content type, with premiums for rush work and discounts for volume. Some vendors excel at technical content; others at marketing. Some deliver flawlessly but slowly; others are fast but need more review. Some are available this week; others are booked solid.
Multiply these variables across thousands of projects per year, and you understand why vendor assignment consumes 30-50% of active project management time. This isn’t inefficiency – it’s the core value MLVs provide. But it’s also why technology matters so much.
The BMS as Central Nervous System
For MLVs, the business management system is the hub. This is where projects live, where vendor relationships are tracked, where profitability is calculated, where capacity is managed. Systems like Plunet, XTRF, or Protemos – or increasingly, custom-built solutions – serve as the operational backbone.
Why do so many large MLVs build their own systems? Because commercial BMSes, despite their sophistication, often can’t capture the granularity needed for true optimization. Vendor quality management in off-the-shelf tools tends to be rudimentary – a rating field, maybe some notes. But real quality management means tracking error types, severity distributions, trends over time, performance by content domain. It means connecting quality outcomes to assignment decisions in ways that improve over time.
Similarly, automatic vendor assignment in commercial tools often uses simple rules: round-robin allocation, first-come-first-serve offers, basic availability matching. These approaches treat vendors as interchangeable units when they’re actually differentiated assets. The MLV that can automatically route a pharmaceutical clinical trial to the vendor with regulatory expertise, appropriate certifications, and competitive rates for that specific language pair gains real advantage.
Building custom systems is expensive and risky. But for MLVs at scale, the alternative – accepting the limitations of generic tools – can be more expensive in lost optimization opportunities.
The Project Ingestion Problem
Before you can optimize vendor assignment, you need projects in your system. For MLVs, this ‘project ingestion’ challenge is surprisingly complex.
Work arrives from multiple channels. Some clients send emails with attachments. Others submit through a client portal. Some have integrated their TMS to push projects automatically. A few use APIs for programmatic submission. Enterprise clients might require you to work within their TMS, pulling work from their system rather than receiving it into yours.
Each channel has different characteristics. Email submissions need manual processing – someone has to parse the request, create the project, attach the files. Portal submissions are more structured but still require validation and often manual enrichment. TMS integrations can be highly automated but require ongoing maintenance as client systems evolve. API connections offer the cleanest automation but demand technical investment from both sides.
The heterogeneity is unavoidable. Clients have their own systems and processes; MLVs can influence but not control how work arrives. So MLVs need infrastructure that normalizes diverse inputs into a consistent internal format – what we might call a project ingestion layer.
Some MLVs build this into their BMS. Others create separate middleware. A few have built their own APIs that wrap multiple backend systems, presenting clients with a unified interface regardless of internal complexity. The approach varies, but the need is universal: transform chaotic input into structured data your systems can optimize.
Where TMSes Fit (And Where They Don't)
MLVs need translation management capabilities, but their relationship with TMSes differs fundamentally from enterprises. An enterprise picks one TMS and builds around it. An MLV might work with a dozen different TMSes depending on client requirements.
Consider the scenarios. Client A owns Phrase and requires all work to happen there. Client B uses memoQ and insists on their environment. Client C has no TMS and expects the MLV to provide one. Client D sends files via email and doesn’t care how they’re processed internally.
This means MLVs need TMS expertise across multiple platforms – not just one. They need processes that work regardless of which TMS a particular project uses. And they need their BMS to integrate with various TMSes, tracking work that might be distributed across several systems simultaneously.
For work where the MLV controls the environment, many still rely on desktop tools like Trados Studio or memoQ Translator Pro. These tools lack the workflow automation of server-based TMSes but offer flexibility and vendor familiarity. The trade-off makes sense when projects are diverse and vendor preferences vary.
Some MLVs – particularly those that have grown through acquisition – end up with multiple TMSes internally. One division uses XTM; another uses Memsource (now Phrase TMS); a third has a legacy memoQ server. Consolidation is perpetually planned but never quite achieved, because each system has users who know it well and workflows optimized for it.
The Accounting Connection
Every MLV needs to invoice clients and pay vendors. This sounds simple until you examine the data flow required.
Project completion in the BMS should trigger client invoicing. But invoicing requires more than project data – it needs customer master data, payment terms, tax handling, currency conversion, and compliance with various invoicing regulations. Most BMSes handle basic invoicing; few handle the full complexity of international B2B transactions.
Similarly, vendor payment requires matching completed work to purchase orders, validating rates, handling currency, managing payment schedules, and feeding data to accounts payable. The BMS knows what work was done; the accounting system knows how to pay for it. Connecting these requires either tight integration or manual reconciliation.
The entity matching problem is often underestimated. Your BMS might identify a client as ‘Acme Corp’ while your accounting system knows them as ‘ACME Corporation Ltd’ with a different customer ID. Your vendor ‘Maria Garcia’ in the BMS is ‘Garcia Translation Services’ in accounts payable. Maintaining these mappings – and catching when they drift – requires ongoing attention.
The MLVs that have solved this well treat it as core infrastructure, not an afterthought. They invest in clean data models, robust integration, and automated reconciliation. Those that haven’t solved it spend significant staff time on manual data entry and error correction.
The Client Portal Dilemma
Clients expect self-service capabilities: submitting requests, tracking progress, accessing completed work, reviewing invoices. This drives MLVs to offer client portals – but the implementation choices create interesting trade-offs.
Option one: use your BMS’s built-in portal. Plunet, XTRF, and similar systems offer client-facing interfaces. The advantage is tight integration with project data. The disadvantage is that these portals are often designed from an operational perspective rather than a client experience perspective. They expose BMS concepts that clients find confusing.
Option two: use a TMS’s client portal. If you’re using Phrase or XTM for production, their portals can serve clients directly. This works well when the TMS handles most workflow, but creates gaps when work spans multiple systems or requires BMS data that the TMS doesn’t have.
Option three: build a custom portal. This offers maximum control over client experience but requires development investment and ongoing maintenance. The portal becomes another system to integrate with your BMS, TMS, and accounting tools.
Some MLVs combine approaches – a custom front-end that pulls data from multiple backend systems, presenting a unified view even when the underlying infrastructure is fragmented. This is architecturally elegant but operationally complex.
Vendor Portals and Downstream Effects
Just as clients expect portals, vendors expect ways to receive work, accept or decline assignments, deliver completed files, and track payments. MLVs provide vendor portals for these functions.
But here’s where MLV optimization creates downstream problems. Remember that vendor assignment is where MLVs add value – routing work to the right vendor at the right price. The mechanisms for this routing (job offers, acceptance workflows, automatic assignment) all happen through vendor portals.
From the MLV’s perspective, a vendor portal that handles job offers, tracks responses, and manages delivery is a powerful tool. From the vendor’s perspective – especially SLVs working with multiple MLVs – each portal is another system to monitor, another login to manage, another interface to learn.
The MLV optimizes its own operations by pushing complexity downstream. First-come-first-serve job offers mean vendors must monitor portals constantly or miss opportunities. Automated assignment means vendors receive work they might not want. Portal-based delivery means vendors perform the same job in multiple systems – once in the TMS where the actual translation happens, again in the BMS portal to record completion.
This isn’t malicious; it’s structural. MLVs are optimizing for their constraints and competitive pressures. But the downstream effects accumulate. We’ll examine this more in the next article on SLVs and freelancers.
Why Custom Systems Proliferate
Looking at this landscape, you might wonder why MLVs don’t simply buy comprehensive solutions. The answer lies in the competitive dynamics of the industry.
If everyone uses the same tools with the same capabilities, competitive advantage shifts entirely to scale and relationships. The MLV that can build better vendor matching algorithms, tighter integrations, faster project ingestion, or more insightful analytics gains edge. Technology becomes a differentiator.
This explains why the largest MLVs almost universally run custom or heavily customized systems. TransPerfect, RWS, Lionbridge – none of them use off-the-shelf BMSes in standard configurations. They’ve built proprietary infrastructure that encodes their operational knowledge and enables capabilities their competitors can’t easily replicate.
Mid-sized MLVs face a harder choice. Custom development is expensive and risky. But accepting the limitations of standard tools means competing without technological differentiation. Many end up in a middle ground – commercial BMS platforms with significant customization, surrounded by satellite systems and integrations that address specific gaps.
The result is an industry where no two MLVs have quite the same technology stack, even when they use the same named products. The systems might share a foundation, but the customizations, integrations, and workarounds make each implementation unique.
The Integration Imperative
What ties this all together – or fails to – is integration. The BMS needs to connect to TMSes for production. TMSes need to connect to client systems for direct workflows. Client portals need to reflect BMS data. Vendor portals need to trigger TMS access. Accounting needs data from everywhere.
Every connection is a potential failure point and a maintenance burden. APIs change. Systems upgrade on different schedules. Data models evolve. What worked last year breaks this year.
MLVs respond in various ways. Some minimize integrations, accepting manual work to reduce complexity. Some build robust middleware layers that absorb change. Some partner with integration specialists. Some suffer through constant firefighting.
The integration challenge is where many MLVs feel the pain most acutely. They’ve invested in good systems for individual functions – capable BMS, solid TMS, functional accounting – but the connections between systems consume disproportionate attention and resources.
The View from the Middle
MLVs occupy a structurally complex position. They must be sophisticated enough to serve enterprise clients with high expectations. They must be efficient enough to maintain margins despite competitive pricing pressure. They must be flexible enough to work with whatever systems clients require. And they must manage a diverse vendor network that expects clear communication and reliable payment.
No single system addresses all these needs. The BMS handles operations but not translation production. TMSes handle translation but not business management. Accounting handles finance but not operations. Client portals handle submission but not production. Vendor portals handle assignment but create downstream burden.
The most successful MLVs treat this multi-system reality not as a problem to solve but as an environment to master. They invest in integration capabilities. They build processes that span systems gracefully. They measure what matters across boundaries. And increasingly, they look for ways to reduce the downstream burden their operations place on vendors – recognizing that supply chain efficiency benefits everyone.
In the final article of this series, we’ll examine how all of this looks from the other end of the supply chain – from SLVs and freelancers who must navigate the systems their clients choose.
Coming in this series
Part 4 SLVs and Freelancers – The Downstream Impact
Istvan Lengyel
Founder & CEO, BeLazy
