The TEP process explained: translate, edit, proofread in modern workflows
The TEP translation process was built for human first drafts. How to redraw translate, edit and proofread now that AI writes the first version.
Most translation quotes still break the work into three lines: translate, edit, proofread. It reads like a tidy pipeline, and for two decades it described reality well enough. The TEP translation process came out of a world where the first draft was typed by a human working segment by segment, and every stage after that existed to catch a specific class of human mistake. That world is mostly gone. We work with agencies and freelancers who still bill in TEP stages but whose first draft now comes out of a model. The stage boundaries stayed where they were. The errors moved.
What the tep translation process actually means
The three letters hide more disagreement than most quotes admit. Translate is the least contested: one linguist produces a complete first rendering of the source. Edit is where the confusion starts. In the way the term was used by agencies for years, editing meant a bilingual pass by a second linguist who reads source and target side by side and fixes meaning, terminology, and register. Proofreading meant a monolingual pass over the target alone, checking that it reads like something written in that language, with correct typography and no leftover formatting damage.
Those two stages get collapsed constantly. A client asks for "editing and proofreading" and means "check it twice." A freelancer quotes "proofreading" and delivers a bilingual revision at a lower rate. ISO 17100 draws the line more sharply than most commercial practice does: a revision by a second person, comparing source against target, is a required step for a conforming service, while monolingual review by a domain specialist and a final proofread are described as additional services. The standard's vocabulary and the market's vocabulary do not match, which is why so many disputes over a delivered file turn out to be disputes over which stage was paid for.
We bring this up because the stage you name determines the error you get back. A bilingual reviser is looking for mistranslation. A monolingual proofreader cannot look for mistranslation, because they have no source text to compare against. Asking for a proofread and expecting meaning errors to surface is a category mistake, and it gets made on real projects every week.
What changes when the first draft comes from a machine
The old stage split was tuned to the way human first drafts fail. A tired translator working through forty pages produces visible symptoms: a sentence that trails off, a term guessed differently on page nine than on page thirty, a bracketed note left in the target, a skipped line. Those failures announce themselves. A reviser spots the ragged edge and knows where to look.
AI drafts fail quietly. They are fluent and confident, and they stay confident when they are wrong. The sentence that drops a negation reads exactly as smoothly as the one that keeps it. The clause that reverses an obligation reads as naturally as the correct version. A long document can carry the same source term rendered three ways across different sections, with each rendering defensible on its own. Numbers come through intact most of the time, which is exactly what makes the occasional transposed figure dangerous: the reviser stops checking.
This inverts the value of the two review stages. The bilingual pass becomes more load-bearing than it was, because it is now the only stage that can catch anything. And the monolingual proofread, which used to function as a second safety net, loses most of its diagnostic power. A proofreader with no source cannot tell that a well-formed German sentence says the opposite of the English one. Fluency hides error rather than signalling its absence.
We have watched teams discover this the hard way. The usual sequence is that AI pre-translation gets introduced to cut the translate stage, the edit stage is kept at its old scope and price, and the first complaint that comes back from a client is a meaning error in a passage nobody flagged because nothing about it looked wrong.
Rebuilding the edit stage around machine error types
If the edit stage is now the main line of defence, it needs a different definition than "read it against the source and fix what is wrong." That instruction was fine when errors were visible. Against a fluent draft, it produces a reader who confirms rather than checks.
What works better is a bilingual pass with an explicit list of the failure modes this kind of draft produces. The list is short and boring, which is the point: negations and modal verbs in anything contractual, numbers and units, dates, proper nouns, defined terms, cross-references, and the alignment of lists and tables against the source. A reviser working from that list reads differently. They are hunting specific things rather than forming a general impression, and general impressions are precisely what a fluent draft manipulates.
Two practical points about scope. First, consistency checking is not a reading task at all. Pulling every instance of a term into a two-column table and scanning it takes minutes and catches what a sequential read cannot, because the two inconsistent renderings may be eighty pages apart. Second, full bilingual reading of every segment is expensive, and some teams sample instead: a complete read of the first portion of the document to calibrate how this particular draft is failing, then targeted checks across the rest. Sampling works when the document is homogeneous, like a product catalogue or a set of similar case reports. It does not apply to contracts, regulatory submissions, or anything where a single clause can carry the whole risk. In those, every clause gets read, and if the budget does not allow that, the honest move is to say so in the quote rather than to call a sample an edit.
If you are deciding how deep the pass should go, the light versus full post-editing distinction is the useful frame. MTPE gets sold as discounted editing, which is where the trouble starts. It is a different stage with a different target quality, and it should be priced and described as one.
Two stage splits that worked
Advice about stages is easy to agree with and hard to apply. Two shapes we have seen hold up in practice:
A 40-page supplier agreement, English into German
A small agency ran AI pre-translation on the whole file, then assigned a full bilingual edit to a legal translator at close to the old editing rate, with no sampling. The edit found two things that mattered: one clause where a negative obligation had come through as a positive one, and eleven places where a defined term had lost its capitalisation and so stopped being a defined term. Neither would have been visible to a monolingual reader. The proofread stage afterwards found no meaning issues at all, which is the expected outcome, and did fix a table of contents that disagreed with the headings in the body and a numbering sequence that had restarted in the middle of the document. Three stages, each catching what it was designed to catch, and the price shifted from the translate line to the edit line rather than disappearing.
A quarterly report workbook, 1,400 cells across nine sheets
XLSX workbook translation breaks the TEP shape more than any other format we deal with. The freelancer here did not read the file sequentially, because a spreadsheet has no reading order. The edit stage was a sort: export source and target into two columns, sort by source, and look at every group where one source string had more than one target. That surfaced four header labels translated inconsistently between sheets, which would have made the pivot tables disagree with each other. The proofread stage was done in the rendered workbook rather than in the bilingual table, and it was almost entirely about truncation: German labels that no longer fitted their column, two date cells that had taken on a different format, and a chart legend that overflowed its box. None of that is visible in a bilingual view, and most teams skip it.
What the proofread stage should catch now
The monolingual pass still earns its place, but not as a second meaning check. Its job is everything that only becomes visible once the text is sitting in the delivery format. Register drift, where a document starts formal and ends conversational because different sections were drafted under different context. Headings that disagree with the table of contents. Numbering, hyphenation, quotation marks, and whatever the target language does with spacing around punctuation. Truncation in PPTX presentation translation, where a text box sized for English copy will not hold the same sentence in Russian or German. Images with embedded text that nobody extracted.
The practical rule we push for: the proofread happens on the delivery file, in the format the client will open, not on a bilingual table or a preview. Obvious, and skipped constantly, because reviewing a table is faster and feels like the same job. It is not the same job. A large share of the complaints we hear about after delivery are layout problems that five minutes in the actual DOCX or PPTX would have caught.
One limitation worth stating. A proofreader who does not read the source language cannot be held responsible for meaning, and should not be asked to sign off on it. If your workflow has no bilingual stage, adding a proofread does not fix that. It produces a file that reads well and may still be wrong, which is worse than an obviously rough one, because nothing warns the client to check.
When TEP is more process than the job needs
TEP assumes the deliverable is publication quality. A lot of translation work is not. An internal memo that three people will read once, a supplier email, a batch of support tickets being scanned for a pattern: these need the meaning to be right and nothing else. Selling three stages on that content is padding, and experienced buyers recognise it.
The opposite case is also real. Regulated content, clinical documentation, and anything that will be filed with an authority often needs more than three stages: a subject-matter review by a specialist who is not a linguist, a back-translation, or an in-country check. TEP was never a ceiling or a floor. It is one shape that happened to fit one era of the work well.
What we would push back on is the middle case, where a team keeps the three-stage label because clients recognise it while quietly draining the content out of the stages. The label then does active harm, because the client believes a bilingual revision happened. If your edit stage has become a spellcheck and a skim, it is more defensible to sell two honest stages than three nominal ones.
For a fuller picture of how these stages fit alongside automated checks and QA frameworks like MQM, our guide to translation quality assurance covers the measurement side in more detail than this piece does.
If the translate stage is where AI sits in your workflow, the preparation around it matters as much as the review after it. SnapIntel handles DOCX, XLSX, and PPTX files as structured translation projects: domain analysis, glossary, and translation prompt are prepared and approved before translation starts, and the outputs are a translated file in its original format, a neutral source and target XLSX export you can take into any CAT tool, and a QA report with a quality rating. That gives the edit stage something to work from rather than a bare target file. You can see how the flow works at snapintel.io.
Where to start with your own stage split
Do this with your last three delivered projects, not with a template. For each one, write down the errors that were actually found and at which stage, and the errors the client found after delivery. Then ask, for every stage you billed, which column it contributed to.
Most teams who run this exercise find the same two things. The edit stage is catching less than it used to, because it was defined for a kind of draft that no longer arrives. And the proofread stage is being skipped on the delivery format, so layout problems are reaching clients. Those are both fixable in an afternoon: give the reviser a written list of machine failure modes to hunt rather than an instruction to read carefully, and move the final pass into the file the client will open.
Keep the three-stage structure if it still describes what you do. Rename it if it does not. What matters is that the bilingual comparison survives the rewrite, under whatever name. A fluent draft gives a monolingual reader nothing to notice, so that pass is the only one left that can tell a smooth file from a wrong one.