Terminology control means a specific term always comes out the same way, every time, across every document — and that certain terms never get translated at all. In legal and financial work this is not a style preference. A defined term that drifts between clauses breaks the contract's internal logic, and an accounting line item that renders three different ways across a set of statements is a reconciliation problem before it is a language problem. Most translation tools offer a glossary field. Far fewer enforce it, and fewer still tell you when they couldn't.
This guide covers what a real terminology implementation looks like underneath, how the standards work, and the four tests that separate a vendor with genuine term control from one with a glossary upload button.
The Three Jobs a Glossary Actually Does
People say "glossary" for three different mechanisms that fail in three different ways.
Term substitution. A source term maps to a required target term. Board of Directors must render as Conseil d'administration, never Comité de direction. This is the job most tools mean when they advertise glossary support.
Do-not-translate. Some strings must pass through untouched: party names, product designations, ticker symbols, statute citations, defined terms already capitalised in the agreement, standard references like EN ISO 13849-1. Treating these as translatable prose is the most damaging single failure mode, because the output looks fluent and is wrong.
Forbidden terms. A term must never appear. Firms that have settled litigation over a word choice, or that operate under a regulator's naming conventions, need a blocklist as much as an allowlist.
A tool that does the first and not the second two will still produce documents that fail review. Ask which of the three are supported before asking how many entries a glossary holds.
Why Defined Terms Are the Hard Case in Contracts
Contracts build a private dictionary in their own opening pages. "Affiliate," "Material Adverse Effect," "Permitted Encumbrance" — each is defined once, capitalised throughout, and carries the meaning the drafters assigned rather than the ordinary one. The whole instrument depends on that consistency holding.
Translation breaks it in two ways. Either the defined term is translated inconsistently across clauses, so the reader can no longer tell which occurrences point at the definition. Or it is translated correctly but variably — a translator using a natural synonym in clause 14 that they did not use in clause 3 — which is worse, because it reads well and still severs the link.
The mechanism that prevents this is not a better model. It is a term base populated from the definitions section before translation begins, with each defined term locked. This is a well-understood problem in contract translation workflows, and it is the reason a glossary has to be per-document, not only per-account. Every agreement brings its own dictionary.
The Standards That Make Term Bases Portable
Two specifications matter here, and asking about them is a fast way to tell a real implementation from a text field in a settings page.
TBX — ISO 30042 — is the interchange format for term bases. A term entry in TBX is not a row with two columns; it carries part of speech, usage context, definition, status (preferred, admitted, deprecated) and provenance. That structure is what lets a firm's terminology survive a change of vendor, and what lets deprecated mean something enforceable rather than advisory.
XLIFF 2.1 is the bitext format that carries translatable content between systems. Its inline-markup model is what allows a term to be flagged and protected inside a segment while the surrounding text is translated — and what allows formatting tags to survive that process.
If a vendor cannot import TBX and cannot explain how terms are protected at the segment level, the glossary is almost certainly a post-hoc find-and-replace. That distinction matters, because find-and-replace has no concept of inflection: it will produce the nominative form of a German term in a genitive position and leave a sentence that is grammatically broken in a way no reviewer expects to have to check.
What Happens on a Conflict
This is the question that separates implementations, and almost nobody publishes the answer.
A term base says shall render as X. The model, given the surrounding sentence, wants Y. Three things can happen: the glossary wins silently, the model wins silently, or the system flags the conflict. Only the third is acceptable in regulated work, and only the third gives you an audit trail.
Conflicts are not rare edge cases. They cluster predictably: where a glossary term needs inflection the entry doesn't cover; where the same source term is a defined term in one section and ordinary language in another; where two glossary entries overlap; where the required target term does not grammatically fit the construction the source sentence forces. A financial statement using provision in both its accounting sense and its ordinary sense inside one paragraph will trigger this on every run.
The practical requirement is a report: which terms were enforced, which were overridden, and where. Without it, "glossary support" is a claim that cannot be verified after the fact — which is exactly when you need to verify it.
Financial Statements: Consistency Across a Set, Not a File
Financial translation has a constraint legal work mostly doesn't: the unit of consistency is the reporting set, not the document. The balance sheet, income statement, cash flow statement and notes all reference the same line items, and a reader reconciles across them. If accrued liabilities renders one way in the balance sheet and another in note 12, the statements no longer tie out to a reader working in the target language, even though every number is correct.
This gets harder across reporting periods. A term rendered one way in the FY2025 annual report and differently in FY2026 makes year-on-year comparison unreliable and invites an auditor's question. Terminology in finance is therefore a longitudinal asset — it has to persist across documents and across years, which means it belongs in a maintained term base rather than being rebuilt per engagement.
The same logic governs scientific and technical terminology standards, where a term set is maintained against a published nomenclature rather than reinvented per document.
How to Test a Vendor's Terminology Support
Four tests, each of which takes under an hour and any of which a weak implementation fails.
Import a real TBX file. Not a two-column CSV — an actual term base with status fields and context notes. If the importer flattens it to source/target pairs, the structure isn't being used.
Send a document where a glossary term needs inflection. German, Polish, Russian or Finnish will do it. Check whether the output is grammatical or whether the nominative form has been dropped into an oblique case.
Create a deliberate conflict. Put a term in the glossary that the sentence context fights, and see whether you get a flag, a silent override, or a broken sentence.
Ask for the enforcement report. Terms applied, terms overridden, location of each. If it doesn't exist, you cannot audit the output, and neither can the reviewer who signs it off.
Run the same four tests on a document that also has real formatting — a contract with numbered clauses and a table, or a statement with footnotes. Terminology and layout are handled by different parts of a pipeline, and a system that does one well can still destroy the other.
Where Terminology Ends and Review Begins
Terminology control makes output consistent. It does not make it correct. A term base populated with the wrong preferred term will enforce that error perfectly across ten thousand pages, which is a genuinely worse outcome than inconsistency, because it looks deliberate.
That is why the standards separate the two. ISO 18587 sets the requirements for full post-editing of machine translation output — the human step that catches an enforced-but-wrong term. Note that ISO 17100, the translation-services standard people more often cite, explicitly excludes machine-translation post-editing from its scope. Any vendor claiming ISO 17100 certification for AI translation output has misread the standard, and it is worth knowing that before a procurement conversation rather than during one.
The practical division: the term base carries decisions already made and validated. Review is where new decisions get made. Keeping those separate is what stops a glossary becoming a place where mistakes go to be replicated.
Sources and Further Reading
ISO 18587 — requirements for post-editing of machine translation output
ISO 17100 — translation services requirements (note the MTPE exclusion)
MQM — the open framework for analytic translation quality evaluation
Data privacy compliant translation software — practitioners in r/machinetranslation working through the same vendor-evaluation questions
Related Reading
Last reviewed 24 August 2026 by the Bluente document engineering team, who build and test the terminology-enforcement and format-preservation pipeline described here. We revise these guides when the underlying standards change.
Lock your terminology once and hold it across every document. Bluente enforces term bases and do-not-translate lists across 120+ languages while keeping tables, clause numbering and footnotes intact. Try BluTranslate free.