MQM vs. LISA QA model: which translation quality framework should you use?

Most translation teams don't choose a quality framework — they inherit one. A client sends a QA template, the TMS comes with built-in error categories, or the agency has been using the same spreadsheet since 2009. Eventually someone mentions MQM. Someone else defends LISA. Both sides have a point, and neither can fully explain why they use what they use.

The MQM translation quality model and the LISA QA framework both describe translation errors. But they approach the problem differently enough that picking the wrong one creates real friction: categories that don't fit the content, severity ratings that feel arbitrary, and QA reports that clients don't trust and translators can't act on. The actual differences (not just the summaries) are worth understanding.

What the LISA QA model was

LISA stands for the Localization Industry Standards Association, which developed this framework in the late 1990s and early 2000s. LISA dissolved in 2011, but its QA model outlived the organization by more than a decade. That says something about the framework: if it's been built into commercial tools for 25 years, it clearly solves a real problem.

The original LISA QA model evaluates translation against six main error categories:

Accuracy — does the translation convey what the source says?
Language — grammar, spelling, punctuation
Terminology — are approved terms used correctly?
Style — does the text match the client's style guide?
Country standards — dates, currencies, measurements
Inconsistency — does the same source phrase get translated the same way?

Each error receives a severity weight: critical, major, or minor. The total weighted error count is divided by the word count, and the result either passes or fails against a threshold. A typical threshold for MTPE projects might be 0.5 weighted errors per 100 words; for standard human translation, many agencies use 0.3 or lower.

This simplicity is genuinely useful. A reviewer with limited QA background can learn the framework in an hour and produce consistent reports by the second project. Freelancers understand it quickly. Clients can read the output without a glossary.

The limitation is also tied to that simplicity. LISA doesn't tell you why an accuracy error happened or what type of fluency problem you're dealing with. You know the translation failed a threshold; you don't get clear guidance on what to fix next time.

MQM translation quality model: how it works

MQM — Multidimensional Quality Metrics — was developed through European research initiatives starting around 2012, later refined through the Translation Automation User Society (TAUS) Dynamic Quality Framework. Unlike LISA, MQM was designed from the start to work with both human translation and machine translation evaluation, which is why it gained traction as MT and AI translation became mainstream.

The framework uses a hierarchical error typology. At the top level, error categories include Accuracy, Fluency, Terminology, Style, Locale Convention, and Design. Under each category, MQM defines specific subcategories. Under Accuracy alone, you'll find mistranslation, overtranslation, undertranslation, addition, omission, and untranslated content as separate error types. Under Fluency, subcategories distinguish grammar errors, register problems, spelling errors, and punctuation issues.

The structure does two things. First, it produces actionable data. If 60% of errors in a given language pair are undertranslations, you know to adjust the post-editing brief to emphasize completeness. If the dominant error type is inconsistent domain terminology, that points to a glossary problem — not a translator capability issue.

Second, MQM severity levels work like LISA (critical, major, minor) but with clearer definitions. A critical error is one that would block the content from being used: a safety warning mistranslated, a legal clause that changes meaning, a UI element that prevents the user from completing an action. A minor error is a stylistic deviation that doesn't affect meaning or usability. Explicit definitions reduce reviewer inconsistency, which is one of the biggest practical problems with any QA framework.

Error categories side by side: where the frameworks diverge

A concrete example makes the difference clearer. Suppose a translator renders "not to be taken with alcohol" as "to be taken without alcohol." The meaning is preserved, but the phrasing shifts.

Under LISA QA, this might be categorized as a Style error (minor) or an Accuracy error depending on the reviewer's judgment. The category captures that something changed, but not what specifically, or whether it matters for the use case.

Under MQM, you'd classify this as Accuracy > mistranslation or Fluency > awkward phrasing depending on whether you consider the meaning genuinely distorted or just oddly expressed. The distinction matters when you're analyzing error patterns across 50 documents. At that scale, knowing whether your accuracy problems are mistranslations, omissions, or added content tells you what to actually fix in your process.

A second example: a translator uses a competitor brand name where the style guide requires generic terms. Under LISA, it's a Terminology error. Under MQM, it's Terminology > wrong term. The added granularity seems marginal until you're comparing error profiles across three language pairs and trying to figure out whether the problem sits in the glossary, the post-editing brief, or the reviewers' calibration.

That's the actual trade-off. MQM gives you more usable information. LISA is faster to apply and easier to train reviewers on.

Severity levels and how they affect scoring

Both frameworks use three severity levels — critical, major, and minor — but the scoring logic differs.

In LISA-based systems, a single critical error typically fails the project regardless of the overall score. A critical error in a medical translation means the file needs revision before delivery, full stop. Major and minor errors accumulate toward the threshold.

MQM leaves more of this to the implementer. The framework provides definitions and weighting guidance, but organizations adapt thresholds to their content type and risk profile. A marketing campaign translation might tolerate more minor fluency errors than a pharmaceutical patient information leaflet. MQM's design explicitly supports this kind of configuration; LISA's simpler model doesn't distinguish between use cases as cleanly.

In practice, teams new to MQM often start with a simplified subset — sometimes called MQM-Core — that reduces the error typology to 10–15 categories rather than the full range of possible subcategories. The full MQM error inventory is a research tool; most production workflows use a customized profile that covers the error types they actually encounter. Starting with MQM-Core and adding subcategories as new error patterns emerge is a more sustainable path than trying to implement the full taxonomy from day one.

When to choose LISA (or a LISA-derived approach)

LISA or LISA-derived models make sense in a few specific situations.

When reviewer training time is limited, a new freelance reviewer can be briefed on LISA categories in one session. MQM requires more upfront investment in definitions and examples before reviewers produce consistent results.

When clients specifically require LISA — some enterprises, particularly in life sciences and manufacturing, have it written into supplier contracts — using a different framework creates reconciliation problems and reporting headaches even if your alternative produces better data.

When your TMS supports LISA natively and moving to MQM would require custom configuration or a dedicated QA tool on top. Not every project justifies that overhead.

None of these apply if you're evaluating AI or MT output regularly. For machine translation post-editing projects, LISA's coarser categories don't give you enough signal to improve the MT engine's output or tune post-editing instructions project by project. A reviewer who can only flag "Accuracy error" gives you less to work with than one who can note "consistent undertranslation of subordinate clauses in German-to-English pairs."

When MQM is the right fit

MQM is the better choice when error pattern data matters more than speed of execution.

For MT and AI-assisted translation workflows, MQM provides enough granularity to distinguish systematic errors from random ones. Systematic errors — the MT engine consistently undertranslates passive constructions in this language pair — are fixable at the process level. Random errors require different interventions. LISA can't make that distinction.

For regulated content in medical, legal, or pharmaceutical domains, MQM's precise critical error definitions make defensible QA reports easier to produce. When a regulatory body asks why a batch of patient information leaflets passed QA, you want a framework that maps errors to specific subcategories with documented severity rationale, not a spreadsheet that says "0 critical, 2 major, 5 minor" without further context.

For agencies building long-term client relationships, MQM-based reporting gives clients actionable feedback about their source content. If 40% of errors across a client's technical manual translations classify as "Accuracy > source issue," that's a conversation about pre-editing the source text — which benefits the client and reduces revision cycles for you.

We've also found that teams working with AI-generated outputs benefit from MQM's taxonomy. Patterns in AI output differ from human translation errors: consistent omissions in certain syntactic structures, overconfident handling of idioms, systematic issues with false cognates. LISA categories blur these patterns. MQM surfaces them, which is what lets you build a feedback loop between QA results and prompt or glossary adjustments.

If your AI translation workflow produces output you want to run through a structured review, SnapIntel generates QA reports alongside translated DOCX and XLSX files — a starting point for error analysis without building a QA pipeline from scratch.

Getting started with MQM without a full system overhaul

The most common reason teams avoid MQM is complexity. The full error typology can run to hundreds of subcategories. No production team uses all of it.

The practical way in: look at your last 20 projects and list the error types that actually appeared. Most teams find 80–90% of errors fall into 8–12 categories. Start there, not with the full taxonomy.

Write one concrete example of each severity level for your content type. A critical error in a pharmaceutical leaflet looks different from a critical error in a marketing campaign. Share those examples with your team after the first two projects and revise them — shared examples do more than abstract definitions, and the definitions improve when reviewers can push back with real cases.

Your existing tools can likely handle this. Xbench and Verifika both support custom error profiles; you don't need to change platforms. Our overview of translation QA tools covers which platforms have the flexibility for custom taxonomies.

Resist logging every possible subcategory in month one. Pick 10–12, run two projects, then add categories only when a new error pattern appears that doesn't fit what you have. This works better than deploying the full MQM taxonomy and watching reviewers ignore half of it.

The MQM translation quality model isn't a replacement for reviewer judgment — it's a structure that lets different people apply judgment consistently. That consistency is what makes QA data useful over time. Without it, each project's results tell you whether last week went well. With it, you're building something you can actually learn from.