Pre-delivery translation file checklist: how to send files without loose ends
A step-by-step pre-delivery translation file checklist for agencies: file counts, QA sign-off, formatting verification, and what to include in the delivery package.
The average translation project doesn't fail at the translation stage. It fails at delivery. A pre-delivery translation file checklist sounds administrative, but the projects that end up generating client complaints and revision rounds are usually the ones where delivery was treated as a non-event: zip the folder, attach to email, send. We've watched solid translations come back from clients for reasons that had nothing to do with translation quality — wrong file version, broken formatting, a header left in source language, a file missing from the zip. Every one of those returns was preventable. This is the checklist we run before anything goes out the door.
Why delivery errors keep happening even in good workflows
Most delivery mistakes don't come from poor translation. They come from assumptions made during the handoff — the gap between "translation done" and "files sent."
The most familiar pattern: a project finishes under pressure. The translator submits the final file. The PM already has an email draft open. The folder looks full. Send. What nobody checked: the final exported file still shows tracked changes because the translator forgot to accept all revisions before saving. Or the corrected version is named "file3_final_FINAL_v2.docx" and lives in a subfolder, while the original export sits in the root of the delivery folder. The root file goes out.
Neither of those is a quality failure. Both are handoff failures.
A second pattern shows up in multi-language projects. Four languages finish on time; one has a two-hour delay. Under deadline pressure, the four go out with a note that the fifth is coming. The client takes the four files, forwards them internally, and forgets the fifth is outstanding. Two weeks later, a complaint arrives. Nobody missed a translation. They just missed a file.
Both scenarios are predictable. The fix is a delivery check that runs the same way every time, not one that runs "when there's time."
File completeness: the 60-second count that saves hours
Before opening any translated file, count. The project brief specifies how many files the client ordered. Your delivery folder should have that exact number of translated outputs, plus any agreed supplementary files. Do this first, before anything else. It takes one minute and catches more errors than the next three steps combined.
Beyond the count, verify:
Every source file has a corresponding translated output with a recognizable filename. If the source was "employee-handbook-EN.docx," the delivery file should not be named "translation_output_v3.docx" unless that naming convention was agreed in the brief.
No stale files are in the delivery folder. Exports, backups, and draft versions accumulate in translation project folders quickly. Before packaging, clear everything except the final output files. If you need to keep intermediate versions for internal records, move them to a separate archive folder before zipping.
Multi-language projects need a per-language count. If the brief calls for translations into German, French, and Polish, verify each language pair separately. Don't assume that because the German delivery looks complete, the French one does too.
Additional deliverables are present. Some projects include a neutral XLSX export for TM import, a QA report, or an updated glossary. If any of these were agreed with the client, check for them before packaging.
This sounds basic, and it is. But we've seen projects where the PM had done a thorough QA review and still sent the wrong file because they were checking quality instead of checking completeness. Both matter. They're separate checks.
Linguistic sign-off at the delivery stage
Full QA should have already run before you reach this stage. The delivery check's role is to confirm that QA happened and that its outputs are complete, not to re-run the entire process from scratch.
At delivery, confirm:
The QA tool was applied to the final version of each file, not an earlier draft. This matters more than it sounds. Translators sometimes correct errors after the QA run, which means the final file hasn't actually been checked. If your workflow allows post-QA edits, the delivery check should verify the QA timestamp against the file's last modification time.
All critical errors flagged in the QA report have been resolved. "Resolved" can mean fixed, or it can mean documented as a client-accepted exception. Either is acceptable; unreviewed critical flags sitting in a report nobody looked at are not.
Untranslated segments are intentional. Proper nouns, product names, and legal citations sometimes correctly stay in the source language. But a segment that was simply missed looks identical in the file. A quick scroll for obvious gaps — particularly at the beginning and end of a document, where time-pressure errors tend to cluster — takes two minutes.
Numbers, dates, and currency formats match the target locale. A legal document translated into German with US-format dates (MM/DD/YYYY) is wrong even if every word is correct.
One structural point worth making: the person running the delivery check should not be the same person who did the main linguistic review. Familiarity hides things. Even a brief second-pair-of-eyes pass on the first and last 10% of each file catches errors that the reviewer missed precisely because they knew what the text was supposed to say.
Formatting and file integrity
Once the linguistic layer passes, the check moves to what the client sees when they open the file.
For DOCX deliverables, the first thing to check is whether the document opens without tracked changes visible. Translators who work in review mode can forget to accept all revisions before saving. A client opening a file and seeing revision markup is jarring at best; for legal or regulatory documents, it can raise compliance questions that have nothing to do with translation quality.
Check that styles and structure are intact. Tables shouldn't have collapsed, heading levels should be consistent with the original, and page breaks shouldn't be interrupting flow in unexpected places. A translation that expands content volume (some languages run 20–30% longer than English) can push headings into awkward positions. A quick scroll through the document catches these.
Watch for introduced fonts. When translators work on machines with different font sets, translated files sometimes contain substituted fonts that only become visible when the client opens the document on their end. Sticking to the font set from the original template, or normalizing fonts as part of the export process, prevents this.
Check that headers, footers, and text boxes have been handled. These areas are frequently missed, especially in automated pipelines. Footer copyright notices, running headers, and sidebar text boxes need to be translated if they contain translatable content — and they often do.
For XLSX deliverables: confirm formulas are preserved, the file opens without unexpected protected-sheet warnings, and number formats are localized correctly for the target country.
For all file types: if the final file is notably smaller than the source file, something may have been dropped during export. File size isn't a definitive check, but an unusually small output is worth a second look before it goes to the client.
Matching deliverables to the brief
File completeness asks whether you have everything. Brief matching asks whether what you have is right for this specific client.
Two clients receiving the same source document can have different delivery requirements. One may require British English; the other American English. A spell checker set to the wrong locale makes both wrong — and the error shows up as word choices rather than obvious mistakes, so it's easy to miss on casual review.
One client may have an approved glossary with specific terminology choices. If compliance with that glossary was part of the service agreement, a spot-check of high-frequency terms belongs in the delivery check. We run a find-and-replace scan for the top 10 glossary terms per project; it takes about five minutes and has caught terminology drift in client-sensitive documents more than once.
One client may expect the translation returned in a specific template. Another may just want a clean file. Delivering a heavily styled agency template to a client who expected a plain document is not a translation failure, but it is a brief failure — and the client won't distinguish between the two.
All of this requires that the brief was captured correctly at project intake. If the brief says "translate to French" without specifying region, glossary, format, or style requirements, the delivery check has nothing to verify against. The fix is upstream: a brief template that captures enough information to make verification meaningful.
What to include beyond the translated files
Client expectations around translation deliverables have expanded. The translated document is still the main event, but what surrounds it matters — both for client confidence and for practical usability on their end.
A QA summary is worth including on every project, even a short one. Not because clients always read it, but because it signals that a process ran. A brief note describing what QA tool was used, how many errors were flagged, and what was corrected takes five minutes to write and has saved us multiple "are you sure this was reviewed?" conversations. For clients who've had bad experiences with translation quality in the past, it provides direct reassurance. Building a QA summary into your standard delivery package is one of the lower-effort ways to differentiate on process — and our translation quality assurance guide covers how to structure that layer into a repeatable workflow.
If new terms came up during the project and were added to the working glossary, the updated glossary file should be in the delivery package. Keeping terminology work internal is a missed opportunity to build client trust. An updated glossary also protects the next project: the client comes back to you with their established terminology rather than starting from scratch with someone else.
When something in the brief couldn't be met exactly, document it before the client notices. If a segment was intentionally left in the source language, if a formatting element couldn't be preserved, if a terminology decision required interpretation rather than a direct equivalent — a delivery note that says so is more professional than an explanation three days after the client opens the file. The goal is that the client should never discover something on their own that you already knew about.
Making the checklist stick
A delivery checklist that only runs "when there's time" won't run consistently. The problem is that delivery pressure is highest exactly when time feels shortest — that's when skipping the check seems most reasonable.
What actually works: make it a physical artifact. A checklist that lives only in someone's head is a habit, not a process. Habits don't transfer when the person who holds them goes on leave or hands a project to a colleague. A shared sign-off form that must be completed before files go out is harder to skip, and it makes the check visible to the rest of the team.
Allocating time in the project timeline matters equally. If QA has 30 minutes budgeted and delivery verification has zero, you've already decided delivery verification is optional. Add the time explicitly — 20 to 30 minutes depending on project complexity — and treat it as a fixed cost.
The last habit, and the one that compounds: log delivery failures and use them to improve the checklist. When an error gets through — and eventually one will — trace it back to the step that would have caught it. Add that step. The checklist gets more reliable over time because it's calibrated against your actual failures rather than a generic template. For agencies running high volumes, a weekly five-minute review of how many projects had a documented delivery check gives you a direct read on delivery risk. We cover how to build these habits at team scale in our piece on standardizing quality control across a translation agency.
One thing we've learned from maintaining this process over time: the checklist rarely gets shorter. Almost every addition traces back to an error that got through. That's not a sign the checklist is growing too long — it's a sign it's working.
Run the pre-delivery translation file checklist in this order: count files against the brief, open and scroll each translated output, confirm QA ran on the final version (not an earlier draft), verify that delivery format and terminology match the brief, assemble the package with any supplementary materials, and document exceptions before the email goes out. If this process takes longer than it should, the problem is almost never the checklist itself — it's that the project brief didn't capture enough information to make verification fast. Fix the intake form, and the check becomes a five-minute task instead of an hour-long hunt.