You’ve just received a 40,000-word translation back from your provider. It looks fine at first glance - no obvious gibberish, the formatting survived. But how do you know it’s actually good? That the terminology is consistent across all 40,000 words? That the translator didn’t quietly skip two paragraphs on page 37? That a number in a dosage table didn’t flip from 0.5 mg to 5 mg?
You don’t - unless there’s a structured quality assurance process behind the translation. And that’s exactly what the TEP model is: a multi-step quality framework that the translation industry has used for decades to catch errors before they reach the client.
This article walks through each stage of TEP, explains when you need to go beyond it, covers the automated QA tools that supplement human review, and introduces the MQM error framework that lets you actually measure translation quality instead of guessing.
What Is TEP and Why It’s the Industry Default¶
TEP stands for Translation, Editing, Proofreading - three sequential stages where different people review the same text. The concept is simple: the more qualified eyes that see a text, the fewer errors survive to the final delivery.
The model isn’t new. Variations of it have existed since professional translation became an industry. But it got formalized when ISO 17100:2015 was published - the international standard for translation services. ISO 17100 doesn’t use the exact acronym “TEP,” but it mandates the same process: a qualified translator produces the translation, and a different qualified reviser checks it against the source. That’s the minimum - what the industry calls the four-eye principle.
“The four-eye principle means that every translation must be reviewed by a second qualified linguist who compares the target text against the source. This is the minimum quality bar set by ISO 17100.” - Ciklopea
In practice, most professional agencies run all three stages. Some add a fourth or fifth. The key point: if someone’s delivering translations without at least T+E (translation plus editing), they’re cutting below the ISO 17100 floor - and you should know that before you sign the contract.
Let’s look at what happens at each stage.
Stage 1: Translation - The First Draft¶
The translation stage is where the source text becomes target text for the first time. It sounds obvious, but the quality of this first draft determines everything that follows. A sloppy first translation means the editor spends their time fixing basic errors instead of catching nuanced mistakes.
Who does it: A qualified translator who is a native speaker (or near-native) of the target language. For specialized content - legal contracts, medical device manuals, financial reports - the translator should also be a subject matter expert (SME) in that domain.
What they do:
- Translate the full source text into the target language
- Apply any client-provided style guides, glossaries, and reference materials
- Use CAT tools to maintain terminology consistency across segments
- Flag ambiguous source passages for the project manager or client
- Run basic in-tool QA (spell check, tag verification) before submitting
What they’re responsible for: Accuracy (does the translation say what the source says?), completeness (is everything translated?), and subject matter correctness (are the technical terms right?).
A common misconception: the translator’s job is to produce a perfect final text. It isn’t. Their job is to produce the best possible first version - knowing that a second pair of eyes will review it. This doesn’t mean they can be careless. It means the system doesn’t rely on a single person being perfect, because nobody is.
The translator’s qualifications matter a lot here. ISO 17100 requires at least one of: a translation degree, any degree plus two years of professional experience, or five years of professional experience with no degree. These aren’t arbitrary bars - they’re the minimum needed for someone to consistently produce translations that don’t need to be rewritten from scratch during editing.
Stage 2: Editing (Revision) - The Bilingual Check¶
This is the most critical quality gate in the entire TEP process. Editing - also called “revision” in ISO terminology - is where a second qualified linguist compares the translation against the original source text. Not a quick skim. A systematic, segment-by-segment bilingual comparison.
Who does it: A different translator from the one who produced the initial translation. They must have the same language pair qualifications and, ideally, subject matter expertise. The “different person” requirement is non-negotiable under ISO 17100 - you can’t translate and revise your own work.
What they check:
- Accuracy: Does the translation faithfully convey the meaning of the source?
- Terminology: Are domain-specific terms translated correctly and consistently?
- Completeness: Is anything missing - sentences, paragraphs, footnotes, table cells?
- Grammar and syntax: Is the target language correct?
- Style and register: Does the translation match the intended tone? A legal contract shouldn’t read like a blog post.
- Adherence to client specs: Does it follow the provided glossary, style guide, and formatting requirements?
“The question isn’t whether to revise a translation - the question is whether you can afford not to. Every translator, no matter how experienced, benefits from a second pair of qualified eyes.” - Lexika Translations
What it catches that self-review doesn’t: This is the key insight. Your brain auto-corrects your own errors. If you wrote “the patient should take 50mg” when the source said 500mg, you’ll read your own translation and see 500mg because that’s what you intended. A fresh pair of eyes sees what’s actually on the page.
The editor typically works in a CAT tool - either memoQ or Trados - where they can see source and target side by side, track changes, and leave comments for the project manager. Changes are logged, creating an audit trail that’s useful both for quality tracking and for giving feedback to the original translator.
Here’s a comparison of what translation vs editing focuses on:
| Aspect | Translation (Stage 1) | Editing/Revision (Stage 2) |
|---|---|---|
| Primary focus | Creating target text from source | Verifying target against source |
| Perspective | Monolingual (writing in target language) | Bilingual (comparing both languages) |
| Who performs it | Translator A | Translator B (different person) |
| Source text reference | Constant - working from source | Constant - comparing to source |
| Error types caught | N/A (creating, not catching) | Mistranslations, omissions, terminology errors |
| ISO 17100 status | Required | Required (minimum quality bar) |
| Typical time | 2,000-3,000 words/day | 4,000-6,000 words/day |
Stage 3: Proofreading - The Monolingual Polish¶
Proofreading is the final human review stage. Unlike editing, it’s monolingual - the proofreader reads only the target text, without referring to the source. They’re reading it the way the end user will read it.
Who does it: A native speaker of the target language. They don’t need to know the source language at all. What they need is an eye for detail and a strong sense of how natural, fluent text should read in their language.
What they check:
- Typos and spelling errors
- Grammar mistakes that slipped through editing
- Punctuation and formatting consistency
- Flow and readability - does the text sound natural, or does it read like a translation?
- Inconsistencies within the target text (e.g., switching between “email” and “e-mail”)
- Layout issues: orphaned lines, broken tables, wrong fonts after export
What it doesn’t check: Accuracy against the source text. That was the editor’s job. The proofreader trusts that the meaning is correct and focuses entirely on how the text reads in the target language.
This stage catches a different category of errors than editing. An editor comparing source and target might not notice that a sentence, while accurate, reads awkwardly in the target language. They’re focused on meaning fidelity. The proofreader, reading without the source text as a crutch, immediately spots the awkward phrasing.
Proofreading is technically optional under ISO 17100 - the standard mandates translation plus revision, but lists review and proofreading as additional steps. In practice, most agencies include it for published or client-facing content. For internal-use translations with tight deadlines, it’s sometimes skipped.
Beyond TEP: When Three Stages Aren’t Enough¶
TEP handles most translation projects well. But some content types carry enough risk - financial, legal, medical, regulatory - that three stages aren’t enough. Here’s what sits beyond TEP and when you need it.
Subject Matter Expert (SME) Review¶
An SME review brings in a domain specialist who may or may not be a translator. A cardiologist reviewing a translated clinical trial protocol. A patent attorney reviewing a translated patent application. An engineer reviewing a translated technical manual.
The SME isn’t checking language quality. They’re checking whether the content is technically correct. A translator might render a chemical compound name perfectly from a linguistic standpoint but get the nomenclature wrong from a chemistry standpoint. The SME catches that.
When you need it: medical/pharma content, patent translations, engineering specs, financial regulatory filings.
Back-Translation¶
Back-translation is exactly what it sounds like: you translate the target text back into the source language, then compare the back-translation to the original. If they match in meaning, the translation is accurate. If they diverge, something went wrong.
This sounds redundant - and it is, intentionally. Back-translation is the gold standard for high-stakes accuracy verification, especially in pharmaceutical and clinical trial contexts. The FDA and EMA often require back-translation for patient-facing materials like informed consent forms and patient information leaflets.
The catch: it roughly doubles your translation cost. You’re paying for two complete translations. That’s why it’s reserved for content where a translation error could cause direct harm - wrong dosage instructions, misleading consent forms, inaccurate labeling.
In-Country Review (ICR)¶
ICR puts the translated content in front of someone who lives in the target market and uses the product or service. For marketing content, this is often a local marketing team member. For software, it might be a local user or QA tester.
ICR catches what no translator can: cultural misfires, local market conventions, brand voice inconsistencies, and the subtle difference between “grammatically correct” and “how people actually talk here.” A translation from English to Latin American Spanish that passes TEP with flying colors might still sound off to someone in Mexico City because it uses Castilian conventions.
When you need it: marketing campaigns, UI/UX localization, anything where the text needs to feel native rather than just be correct.
Dual Independent Translation¶
For the highest-stakes content - safety-critical medical devices, aviation manuals, nuclear facility documentation - some organizations commission two independent translations from different translators, then have a third person compare them. Where the two translations agree, the text is considered verified. Where they disagree, the third person investigates.
This is expensive and slow, but for content where errors can be life-threatening, it provides a level of verification that TEP alone can’t match.
Automated QA Tools: What Machines Catch Better Than Humans¶
Human reviewers are great at catching meaning errors, style issues, and cultural misfires. They’re terrible at catching missing tags, inconsistent number formatting, and double spaces. That’s where automated QA tools come in.
Automated QA runs rule-based checks across your entire translation - every segment, every file - in seconds. Things that a human might miss on page 47 of an 80-page document, the tool flags instantly.
What Automated QA Checks¶
- Tag errors: Missing, extra, or incorrectly placed formatting tags (a huge deal in software localization and DTP)
- Number mismatches: Source says 1,500 but target says 15,000
- Untranslated segments: Segments where the translator left the source text unchanged
- Terminology violations: Using “contract” when the glossary says “agreement”
- Inconsistency: The same source term translated three different ways across the file
- Double spaces, extra punctuation, missing end punctuation
- Target same as source: Segments where translation is identical to source (might be correct, might be an oversight)
- Length violations: Target text significantly shorter or longer than source (possible omission or addition)
The Main Tools¶
Here’s how the most widely used QA tools compare:
| Tool | Type | Price | Best For |
|---|---|---|---|
| Xbench | Standalone desktop | Free (basic) / €99/yr (Pro) | Freelancers and small teams |
| Verifika | Standalone desktop | ~€100/yr | Agencies running batch QA |
| QA Distiller | Standalone desktop | ~€200-400 | High-volume agency QA |
| Built-in CAT QA | Part of CAT tool | Included | Quick in-editor checks |
Xbench is probably the most popular standalone QA tool. The basic version is free, and it handles the most common checks: terminology, consistency, tag verification, number matching. The Pro version ($99/year) adds batch QA across multiple files, custom checklists, and integration with major CAT tools. As one review noted, Xbench hits the sweet spot between power and accessibility for most translation workflows.
Verifika focuses on batch processing. You point it at a folder of bilingual files and it runs QA across everything. Useful when you’re managing 15 files across a large localization project and need to check consistency across all of them, not just within each file.
QA Distiller is the heavy-duty option. It’s built for agencies processing high volumes and supports more file formats and check types than most alternatives. The price is higher, but for agencies running QA on hundreds of projects per month, the time savings pay for it quickly.
Built-in CAT QA - both Trados and memoQ have built-in QA features. They’re convenient because they run inside the editor, but they’re generally less thorough than standalone tools. Most professional workflows use the built-in QA for quick checks during translation and a standalone tool for the final QA pass.
“Translation QA tools don’t replace human reviewers - they handle the mechanical checks that humans are bad at, freeing up the reviewer to focus on meaning and style.” - Nimdzi
The important thing: automated QA is a supplement, not a replacement. It catches formatting, consistency, and mechanical errors. It can’t tell you whether a sentence reads naturally, whether the tone is appropriate, or whether a legal term was translated correctly for the target jurisdiction.
MQM: How to Actually Measure Translation Quality¶
You’ve run TEP. You’ve run automated QA. The translation looks good to you. But how do you prove it’s good? How do you compare quality across different translators, languages, or projects? How do you tell a client “this translation scores 98.5 on our quality scale” instead of “it looks fine to us”?
That’s what MQM (Multidimensional Quality Metrics) was designed for.
MQM is a framework for categorizing and scoring translation errors. It was developed as part of the QT21 project, funded by the European Commission, and is now maintained as an open standard. If DQF (Dynamic Quality Framework) rings a bell - DQF was TAUS’s quality framework that has since been integrated into MQM, so you’ll sometimes see references to “MQM/DQF.”
How MQM Works¶
The framework defines a hierarchy of error categories:
Accuracy errors - the translation doesn’t say what the source says. - Mistranslation: meaning is wrong - Omission: something in the source is missing from the target - Addition: something in the target wasn’t in the source - Untranslated: source text left as-is in the target
Fluency errors - the target text has language quality problems regardless of the source. - Grammar - Spelling - Punctuation - Awkward phrasing / unnatural register
Terminology errors - wrong terms used, inconsistent terminology, terms that violate the glossary.
Style errors - violations of the style guide. Inconsistent tone, wrong formality level, text that doesn’t match the brand voice.
Locale convention errors - date formats (MM/DD vs DD/MM), number formatting (1,000 vs 1.000), currency symbols, measurement units, address formats.
Each error also gets a severity level:
| Severity | Definition | Typical Impact |
|---|---|---|
| Critical | Changes meaning in a way that could cause harm or major misunderstanding | Dosage error, legal liability, safety risk |
| Major | Noticeable error that affects usability but doesn’t cause harm | Wrong term in a contract clause, missing sentence |
| Minor | Small error that doesn’t affect understanding | Typo, extra space, minor formatting issue |
Scoring with MQM¶
The standard scoring model assigns penalty points: critical errors get the most points, minor errors the fewest. You then calculate a quality score based on total penalty points per word count. A typical passing threshold for professional translation is 1-2 penalty points per 1,000 words, but thresholds vary by client and content type.
Here’s why this matters practically: if you’re a translation buyer managing 10 language pairs across three agencies, MQM gives you an objective way to compare quality. Agency A scores 98.2 on your English-to-German medical translations. Agency B scores 94.7. That’s a data point you can act on - not just a vague feeling that “Agency A seems better.”
For agencies, adopting MQM means you can track translator performance over time. If a translator’s accuracy scores drop across three consecutive projects, you spot the pattern early and address it - through feedback, additional training, or reassignment.
When to Go Beyond Basic TEP¶
Not every project needs five stages of human review, automated QA, and MQM scoring. That would be overkill for a 500-word internal memo and appropriate for a pharmaceutical labeling project. Here’s a practical breakdown.
TEP only (T+E+P) works for: - General business content (emails, presentations, internal docs) - Marketing content with low regulatory risk - Content where speed matters more than perfection - Routine updates to previously translated materials
TEP + automated QA is the sweet spot for: - Software localization (tag errors can break the UI) - Technical documentation (number accuracy is critical) - Large-volume projects where manual QA alone would miss consistency issues - Any project using CAT tools with translation memory
TEP + automated QA + SME review for: - Medical and pharmaceutical content - Legal contracts and regulatory filings - Patent translations - Financial reporting for regulatory submissions
TEP + automated QA + back-translation for: - Clinical trial documentation (ICH-GCP requirement) - Patient-facing medical content (informed consent, PILs) - Content where regulatory bodies explicitly require it
TEP + automated QA + ICR for: - Global marketing campaigns - Product launches in new markets - UI/UX for consumer-facing software - Brand-sensitive content where “correct” isn’t enough - it needs to feel native
For anything involving MTPE workflows, the QA requirements shift slightly. Machine translation introduces different error patterns than human translation - more fluency issues, fewer omission errors, sometimes hallucinated content that sounds confident but is wrong. Your QA process should be tuned to catch MT-specific errors, not just traditional human translation mistakes.
Practical Tips for Implementing Multi-Step QA¶
If you’re building or improving a QA process - whether you’re an agency, a localization team, or a freelancer working with collaborators - here are the things that actually make a difference.
1. Define your QA process before the project starts, not after problems appear. Write down which stages apply, who’s responsible for each, and what the acceptance criteria are. This goes into the project brief alongside the deadline and word count.
2. Match QA intensity to content risk. A five-stage QA process for a blog post is a waste of resources. A two-stage process for patient-facing medical content is negligent. Categorize your content by risk level and assign QA tiers accordingly.
3. Run automated QA before human review, not after. If the editor spends 20 minutes catching tag errors that Xbench would have found in 5 seconds, you’ve wasted their time and attention. Let the machine handle mechanical checks first, then let the human focus on meaning and style.
4. Keep translator feedback loops short. When the editor finds recurring errors from a specific translator - say, consistently mistranslating a key term - that feedback needs to reach the translator quickly, not six months later in a quarterly review. Most CAT tools let you export tracked changes as a feedback report.
5. Use style guides and glossaries proactively, not retroactively. It’s much cheaper to give the translator a clear style guide upfront than to fix style inconsistencies during editing. Every hour spent on style guide creation saves five hours in revision.
6. Track quality metrics over time. Whether you use MQM or a simpler error categorization, log your QA findings. After 20 projects, patterns emerge: maybe your German translations consistently score lower on fluency, suggesting you need a different proofreader. Maybe accuracy errors cluster in pharmaceutical content, pointing to a terminology gap. You can’t improve what you don’t measure.
7. Don’t skip stages under deadline pressure. This is the most common failure mode. The deadline is tight, so you skip proofreading. Or the client wants it cheap, so you skip editing entirely. Then a critical error reaches the client, and the cost of fixing it - plus the reputational damage - far exceeds what you saved by cutting the stage. If you can’t afford proper QA, adjust the deadline or the scope, not the quality process.
FAQ¶
What does TEP stand for in translation?¶
TEP stands for Translation, Editing, and Proofreading. It’s the industry-standard three-stage quality assurance process where the translation is produced by one linguist, reviewed against the source text by a second linguist (editing), and then polished for readability by a third reviewer who reads only the target text (proofreading).
Is editing the same as proofreading in translation QA?¶
No - they’re fundamentally different stages. Editing (also called revision) is a bilingual process: the editor compares the translated text against the source to check accuracy, terminology, and completeness. Proofreading is monolingual: the proofreader reads only the target text to catch typos, grammar issues, and readability problems. Editing verifies meaning; proofreading polishes language.
Does ISO 17100 require all three stages of TEP?¶
Not exactly. ISO 17100 requires translation plus revision (editing) as the minimum - the four-eye principle. Proofreading is listed as an optional additional step. In practice, most professional agencies include proofreading for published content, but the standard’s mandatory minimum is T+E, not full TEP.
What translation errors does automated QA catch that humans miss?¶
Automated QA tools excel at catching mechanical errors across large volumes: mismatched numbers (source says 1,500, target says 15,000), missing or broken formatting tags, untranslated segments, terminology inconsistencies, double spaces, and cases where the same source term gets translated three different ways in the same document. These are the exact errors that human reviewers tend to overlook after hours of reading, especially on page 60 of a 70-page document.
When should you use back-translation instead of standard editing?¶
Back-translation is typically required for high-stakes medical and pharmaceutical content - clinical trial protocols, patient informed consent forms, and regulatory submissions. If a translation error could cause patient harm or regulatory non-compliance, back-translation provides an extra verification layer beyond standard editing. The FDA and EMA frequently require it for patient-facing materials. For general business or marketing content, standard TEP with editing is sufficient.
How does the MQM framework score translation quality?¶
MQM (Multidimensional Quality Metrics) assigns penalty points to each translation error based on its category (accuracy, fluency, terminology, style, locale conventions) and severity (critical, major, minor). Critical errors receive the highest penalty points, minor errors the lowest. The total penalty points are then divided by the word count to produce a quality score per thousand words. Most professional translation programs set a passing threshold of 1-2 penalty points per 1,000 words, though this varies by content type and client requirements.