What Has to Survive the Translation of an Official Document
Nobody reads a translated birth certificate for pleasure. Somebody reads it to check it — against the original, against a database, against a form they have to fill in. That reader does not care whether the prose flows. They care whether the certificate number matches, whether the surname is transliterated the way the passport transliterates it, and whether the thing has a seal.
This is the checklist we use, item by item, with what actually goes wrong when each one is missed. It comes from the field definitions of sixteen document templates and from the losses we caught while measuring them — not from a standards document.
The rule that generates the rest of the list
If a human or a system will compare it to something else, it has to survive verbatim.
That single test sorts everything. A description of a building can be reworded. A cadastral number cannot, because someone will paste it into a registry search. A sentence about who issued a passport can be rephrased. The subdivision code cannot, because it is checked digit by digit.
Everything below is an application of that rule to a category of value that keeps getting lost.
1. Registry codes and identifiers
Tax numbers, company registration numbers, cadastral numbers, insurance numbers, certificate series and numbers. These are the highest-stakes values in the document and the easiest to lose, because they look like noise to anything optimising for readable text.
Three specific failures we have measured:
Digits dropped from a run of them. On a customs declaration we tracked 28 source numbers through a full translation. Twenty-six came out unchanged. Of the other two, one was a deliberately reformatted date and one was a genuine loss — a second company registration code, in a field the target form had no box for.
Codes silently merged. A shipper line reading (91330206MAD62XJF0Y)(33029600GQ) contains two codes, not one long one. If your extraction schema has one field, you will keep the first and lose the second, and the output will look complete.
A code that is not the code you think. An extract from the register of individual entrepreneurs carries a 15-digit OGRNIP; a company extract carries a 13-digit OGRN. They are different registries with a similar-looking identifier. A field labelled "registration number" invites the wrong one.
2. Transliteration of names
A name is not translated, it is transliterated — and the only correct transliteration is the one already printed on the person's other documents, usually the international passport.
The failure here is subtle and expensive: the translation is internally consistent and externally wrong. Every page says "Timoshchenko"; the passport says "Timoschenko"; the visa application is rejected. Nothing in the translated document looks wrong. It only looks wrong next to the other document, which is exactly where it will be looked at.
Practical rule: transliteration is an input, not an output. Ask for the passport spelling, do not derive it. Where you must derive it, say which standard you used, in the document.
3. Form serials, numbers and the blank itself
Certificates are printed on numbered blanks. The series and number — I-ВС № 695914 on a Russian civil-registry certificate — identify the physical piece of paper. They are what makes it a document rather than a statement about one.
Two things go wrong. The obvious one is dropping them. The subtle one is copying them from somewhere else, which sounds impossible until you see it: we found four of our own extraction prompts teaching a model what a certificate number looks like by showing a plausible one, and the model returned the example instead of the value on the page. A form serial that is present, well-formatted and wrong is worse than one that is missing, because nothing flags it.
If you use examples in prompts, make them show the shape — I-АА № NNNNNN — never a value.
4. Seal and stamp text
A seal is not decoration; it names the authority and often carries a registration number or tax ID. In a certified translation it is normally rendered in brackets: [Seal: ...].
Two rules earned the hard way:
- Transcribe the seal, don't summarise it. "Official seal" is not a translation of a seal that names a specific registry office.
- The seal belongs to the document, not to the template. We audited our own sixteen forms for values left behind from whichever document each was traced from. Fifteen were clean. One — a notarised travel consent — printed a named notary and their tax number in the seal block on every consent it produced, regardless of who had actually certified the document. The working placeholders sat unused two paragraphs below.
That last one is the failure mode this whole article exists to warn about: a wrong value that is plausible, consistent and invisible from the output side.
5. Marks on the back and in the margins
Registration stamps, apostille notes, "issued in duplicate", corrections with an official's initials, and the pencil marks nobody thinks are part of the document. They are part of the document.
The practical problem is that back sides get skipped at the scanning stage, not the translation stage. If your process accepts a single-sided scan of a two-sided document, the loss happened before anyone translated anything. Ask for both sides; check page counts against what the document claims about itself.
6. Electronic signature certificates and their validity dates
An electronically issued extract carries signature blocks: the certifying authority, a certificate serial, and a validity period. On a Russian cadastre extract these are long hexadecimal strings with dates.
They are boring, they are long, and they are the part a receiving authority checks to decide whether the electronic document is genuine. Treat them as identifiers under rule 1: verbatim, both of them, with their dates. A certificate serial that lost four characters in the middle is not "mostly right".
7. Terms that must not be translated — and terms that must
Some things stay in the source script deliberately. Some must not. The distinction is not a style preference; it decides whether the reader can act on the document.
| Value | Treatment |
|---|---|
| Personal names | Transliterated, matching the passport |
| Registry codes, serials, certificate numbers | Verbatim |
| Authority names | Translated, with the original in brackets where it identifies a specific office |
| Document type labels | Translated |
| Insurance and identity document labels | Translated — this is where we found a real gap |
That last row is a defect we shipped and fixed. Our English output of a Russian cadastre extract carried the Cyrillic words for "SNILS" and "Passport" untranslated in the middle of otherwise-English text. Not a mistranslation — an omission of translation, which is harder to spot, because the surrounding text reads fine.
The general form of the check: scan the finished target text for characters from the source script. Anything found is either a deliberate decision you can defend or a value that fell through. Both outcomes are useful; the point is that neither should be a surprise.
8. The document must remain the document
Finally, the structural item that contains all the others: the translation has to be laid out so it can be compared box to box with the original. A perfect list of correct values in the wrong order is not a usable certified translation, because the person checking it is not reading — they are matching.
For a scan, that means filling a form built for that document type. For a file with real structure, it means replacing text in place and leaving the structure alone.
Key Takeaways
- The test for "must survive verbatim" is whether someone will compare it to something else. Codes, serials and certificate numbers pass that test; descriptive sentences do not.
- Transliteration is an input. Take the spelling from the passport rather than deriving it, or you will be internally consistent and externally rejected.
- A wrong-but-plausible value is worse than a missing one. Prompt examples that show a value, and templates that kept a value from the document they were traced from, both produce exactly that.
- Seal text, back-side marks and signature certificates are content, not decoration, and the last of these is what a receiving authority uses to judge the document genuine.
- Check the finished translation for leftover source-script characters. Every hit is either a defensible decision or a gap, and you want to know which.
FAQ
What is usually lost in a certified document translation?
In our own measurements, the losses cluster in three places: values with no field in the target form, second instances of a repeated identifier (two company codes where the schema declared one), and labels left untranslated inside otherwise-translated text. Plain mistranslation of prose is rarely the problem.
Should personal names be translated or transliterated?
Transliterated, and specifically to match the spelling already used in the person's international passport. A translation that transliterates correctly by a standard but differently from the passport will still be rejected, because the two documents have to agree.
Does the text of a seal have to be translated?
Yes, and transcribed rather than summarised — the seal names the issuing authority and often carries a registration number. Standard practice is to render it in brackets, marked as a seal, with the number preserved verbatim.
How do you check that numbers survived a translation?
Compare maximal runs of digits between source and target, not tokens — punctuation attached to a number makes a token comparison report false losses. Handle dates separately, since they are legitimately reformatted. The output is a count you can act on, not a similarity score.
What about the back of the document?
It is part of the document, and it is usually lost at scanning rather than translation. Require both sides, and cross-check the page count against any statement the document makes about its own length.
Conclusion
None of this list is exotic. Every item is the kind of thing an experienced translator of official documents already knows to watch. What changes when the work is automated is that the failures become silent and uniform: a template that drops a field drops it every time, and a prompt that teaches a model a plausible certificate number teaches it to every document.
So the checklist stops being a habit and has to become a measurement — a numeric-integrity comparison, a source-script sweep, an audit of what the forms themselves are printing.
If you translate certificates, declarations or registry extracts and want to see field-level extraction checked against a schema rather than a vibe, try KTTC.
