Verbatim transcription writes down everything a speaker says, including fillers like "uh" and "um", false starts, repetitions and word fragments. Clean verbatim removes those disfluencies but keeps the speaker's own words. Intelligent verbatim often goes one step further and edits grammar and phrasing so the transcript reads like written text.
Most explanations of these styles are written for people who will read the transcript: lawyers, researchers, podcasters. When the transcript is training data or a test reference for a speech model, the question changes. The model learns from every token you keep, and it is scored against every token you keep. The style is a modeling decision, not a readability preference.
The short answer: transcribe conversational audio in tagged true verbatim, keep that as your master copy, and derive cleaner versions with a script when you need them.
Verbatim vs. clean verbatim vs. intelligent verbatim
The names aren't standardized. True verbatim is also called full or strict verbatim. Rev describes its clean verbatim as "lightly edited for easy readability": it removes stutters, fillers such as "um" and "like", false starts, unintentional repetition and interjections from other speakers such as "uh huh".
Intelligent verbatim is the loosest term. Many vendors use it as another name for clean verbatim; Verbit's page on it says its transcripts are "also known as Clean Verbatim". Others reserve it for a more edited style that also fixes grammar. This guide uses the three-way split below, but judge any vendor by its written rules, not by the name of the style.
| True verbatim | Clean verbatim | Intelligent verbatim | |
|---|---|---|---|
| Fillers (uh, um) | Kept | Removed | Removed |
| False starts, repetitions | Kept | Removed | Removed |
| Word fragments, stutters | Kept and marked | Removed | Removed |
| Backchannels (mm-hmm) | Kept as short turns | Usually removed | Removed |
| Laughter, coughs, noise | Tagged | Usually dropped | Dropped |
| Grammar and wording | As spoken | As spoken | Lightly corrected |
| Fit for speech AI | Training data and test references | Derived text for NLP and summaries | Not for training or scoring |
One utterance, three transcripts
Here is an example turn from a customer call. Speaker A is moving an appointment and uses one Spanish word. Speaker B says "mm-hmm" while A is still talking. The verbatim version uses the tag convention described further down.
TRUE VERBATIM (tagged)
A 0.00-6.10 So um I I wanted to I want to move my
appointment to uh Tue- Tuesday the
fourteenth at like two thirty [laugh]
because my <lang:es>abuela</lang:es>
is ((visiting))
B 3.10-3.45 mm-hmm
CLEAN VERBATIM
A So I want to move my appointment to Tuesday the
fourteenth at two thirty because my abuela is
visiting.
INTELLIGENT VERBATIM
A I want to move my appointment to Tuesday the 14th
at 2:30 because my abuela is visiting.
Clean verbatim removed eight words (um, uh, like, the fragment "Tue-", the repeated "I" and the false start "I wanted to"), plus the laugh, the language tag, the uncertainty mark and B's backchannel. Intelligent verbatim also dropped "So" and rewrote the spoken numbers as digits. A reader loses nothing. A model loses the information that those sounds are in the audio, and anyone scoring a model against these three transcripts gets three different answers.
Why the transcription style changes your WER
Word error rate is (S + D + I) / N: substitutions, deletions and insertions, divided by the number of words in the reference. Our word error rate guide walks through the formula. The point here is simpler: the reference transcript decides what counts as an error, so its convention decides the score.
To see how much, take two model outputs for the turn above. One writes what was said, fillers and all, and misses only the fragment "Tue-". The other writes the clean version. Neither gets a single content word wrong. Scored on speaker A's words, after lowercasing and removing punctuation and tag marks:
| Model output | vs. true verbatim (27 words) | vs. clean verbatim (19 words) | vs. intelligent verbatim (17 words) |
|---|---|---|---|
| Verbatim-style output | 3.7% | 36.8% | 64.7% |
| Clean-style output | 29.6% | 0.0% | 23.5% |
The same output moves from 0% to almost 30% depending only on the reference it is compared with. Even the two readable styles disagree by 23.5%, mostly because one writes "fourteenth" and "two thirty" and the other "14th" and "2:30".
Normalizing text before scoring helps, but less than you might expect. The English text normalizer in OpenAI's Whisper repository deletes six filler spellings (hmm, mm, mhm, mmm, uh and um). Apply that to both sides of the example and the clean-style output still scores 24.0% against the verbatim reference, because the repetition, the false start, the fragment and "like" are real words.
The same normalizer also deletes any text in square brackets, angle brackets or parentheses. That removes [laugh] and the language tags as intended, but it also deletes the best guess inside ((visiting)). Run the full normalizer on the raw tagged reference and the clean-style output scores 30.4%, slightly worse than the 29.6% without it: "visiting" vanishes from the reference, so the model's correct "visiting" counts as an insertion.
NIST's sclite scoring tool handles disfluencies more precisely. A reference word in parentheses, such as (um), is marked optional, and with the -D option, errors involving optional words are counted as correct, so a model is penalized neither for writing "um" nor for leaving it out.
The -F option counts a fragment, a word that begins or ends with a hyphen, as correct when the system's word matches it up to the hyphen, so a reference Tue- matches an output "Tuesday". Both options only work if the reference marked fillers and fragments consistently in the first place.
The rule that follows: keep evaluation references in tagged verbatim, and derive the scoring copy from them with a script that drops event tags, marks fillers and fragments as optional and leaves out segments with unclear speech. Fix one normalizer, and report the convention, the optional tokens and the normalizer with every number. A WER quoted without its transcription convention can't be compared with anything.
Which style for ASR training, TTS and evaluation
| Use | Style | Why |
|---|---|---|
| ASR training on conversational speech | Tagged true verbatim | Fillers and restarts are in the audio; text that skips them teaches the model to skip audible speech |
| ASR test references | Tagged true verbatim, fillers and fragments marked optional | Lets you score any output style fairly |
| TTS training | Text that matches the audio exactly | The model learns which sounds belong to which text; an untranscribed "um" becomes an alignment error |
| Conversational TTS | Verbatim with fillers and laughter kept as tokens | A voice can only say "um" on cue if "um" is in its training text |
| Summaries, analytics, search | Clean verbatim, derived by script | Readable text without a second transcription pass |
| Published transcripts and notes | Intelligent verbatim | Written for people, not models |
The strongest argument for verbatim is that the conversion only works in one direction. A script can drop fillers, fragments and event tags from a verbatim master in seconds, and repetitions and false starts too if the guideline gives them a mark; without one, those need a light editing pass. Nothing can add any of them back to a clean transcript except a person listening to the audio again.
If your product should output clean text, you can still train on verbatim and clean the output, or train on a clean version derived from the master. Either way, you keep the option.
TTS has the strictest requirement of all: the text must match the audio exactly, which is why our guide to TTS datasets treats transcript exactness as non-negotiable. For a read-speech voice, that means checking each recording against its script word for word. For a conversational voice, it means verbatim. A clean verbatim transcript of spontaneous speech is wrong for TTS, because it describes a recording that doesn't exist.
A tag convention for speech data
The exact symbols matter less than three properties: a closed set, one spelling per sound, and markup a script can parse without guessing. This is one workable convention, the one used in the example above.
| Phenomenon | Mark | Example | Training and scoring |
|---|---|---|---|
| Filled pause | Closed spelling list | uh um mm |
Keep for training; optional in references |
| Backchannel | Its own short segment | mm-hmm |
Keep; it is real speech from that speaker |
| Word fragment | Trailing hyphen | Tue- |
Keep or map to one token; optional in references |
| Repetition, false start | Write every word; add a restart mark if clean text must come from a script | I I wanted to I want to |
Keep; the model hears these words |
| Non-speech event | Closed set in square brackets | [laugh] [cough] [noise] |
Map to special tokens or strip; never score |
| Unclear speech | Double parentheses, best guess inside | ((visiting)) (( )) |
Exclude from test sets; flag for review |
| Overlap | Separate timed segment per speaker | B 3.10-3.45 mm-hmm |
Timestamps show the overlap |
| Code-switching | Language span tag, original script | <lang:es>abuela</lang:es> |
Never translate the switched word |
| Numbers | Words as spoken | two thirty fourteenth |
Digits come from a separate normalization step |
| Acronyms | As pronounced | I B M NASA |
Space the letters when they are spelled out |
Two rows cause most of the trouble. Overlap is far easier on dual-channel recordings, where each speaker is transcribed on their own channel with their own timestamps, so the overlap shows up in the timing instead of needing a tag. Code-switching needs its own decisions about script and spelling for each language pair, and an inconsistent choice makes WER on mixed-language speech unreliable; our article on code-switching in speech recognition explains why models trip on it.
Transcription guidelines: a checklist of what to define
A transcription guideline is the document that makes fifty annotators write the same transcript for the same audio. Verbatim transcription guidelines need the most detail, because verbatim forces a decision on every sound. Copy this list into the first page of yours, and ask any vendor to answer every line in writing before production starts.
| # | Decision | What to write down | Done |
|---|---|---|---|
| 1 | Style | True verbatim, clean or edited, and what the transcripts are for | |
| 2 | Fillers | The closed list of filler spellings, per language | |
| 3 | Fragments and false starts | The fragment mark, and whether restarts get any mark | |
| 4 | Non-speech events | The closed tag set and when each tag applies | |
| 5 | Unclear speech | The mark, whether to guess, and how sure a guess must be | |
| 6 | Overlap and backchannels | Segment rules per speaker or per channel | |
| 7 | Code-switching | Language tags, script and spelling for each language pair | |
| 8 | Numbers, dates, currency | Spoken form or digits, with examples | |
| 9 | Names, acronyms, domain terms | A spelling list, and how to write spelled-out letters | |
| 10 | Casing and punctuation | Whether to use them, and how a segment ends | |
| 11 | Segmentation and timestamps | Maximum segment length, boundary rules, word or segment level | |
| 12 | Speaker labels | Naming scheme and how to label unknown speakers | |
| 13 | Dialect and non-standard forms | Standard spelling or as pronounced | |
| 14 | Output format | File format, fields, encoding, and one example file | |
| 15 | QA and acceptance | Review sample, WER or agreement threshold, rework trigger | |
| 16 | Versioning | Version number and change log, recorded with every delivery |
Every rule should come with one audio example and its correct transcript. Then pilot it: have two transcribers label the same few hours independently, compare the results, and tighten the rules wherever they disagree. As our overview of audio annotation puts it, low agreement usually means the guideline is ambiguous, not that the annotators are bad.
Getting transcripts that follow your guideline
Whoever produces your transcripts, ask for three things before the first batch: the written guideline, a sample transcribed under it, and the QA threshold each batch must pass.
At SpeechData.ai we work the same way. If you already have recordings, our audio annotation services transcribe them with native-speaker annotators under a guideline agreed before production, covering casing, numbers, disfluencies, overlap, unknown speakers and domain terms. If you need new audio, our custom speech data collection records it to spec and transcribes it in your convention, verbatim or clean, with disfluency, overlap and code-switch tagging as required.
Whichever route you take, keep the verbatim master. From tagged verbatim, clean text is one script away. From clean text, verbatim is a full re-listen away.
