Most engineering leads optimize obsessively for recognition accuracy and treat text formatting as a post-processing afterthought. In production across French, German, and Spanish, that assumption accumulates technical debt fast. Spoken numbers, dates, and currencies in these languages do not share formatting rules with English, and they do not share rules with each other. This article breaks down the specific ITN mechanics for each language (vigesimal parsing for French, unit-before-tens reversal for German, and gender-agreement mapping for Spanish), and covers how WFST and hybrid architectures handle them at the pipeline level.
Impact of normalization on output precision
Transcript cleanup and normalization
Standard text normalization (TN) converts written text into its spoken equivalent, transforming "€150" into "cent cinquante euros" for text-to-speech (TTS) systems. Inverse Text Normalization (ITN) is the reverse: it takes the spoken-form output of an Automatic Speech Recognition (ASR) model and converts it into the written form a downstream system expects.
NVIDIA's NeMo documentation confirms that ITN converts ASR model output into its written form to improve text readability, and that labeled training data for ITN is scarce and difficult to collect since spoken-form text rarely appears on the web. These constraints compound in multilingual pipelines: each language introduces distinct grammar rules, inflection patterns, and significant linguistic knowledge requirements that a single shared ruleset cannot cover.
ITN is not a cosmetic step. The same NVIDIA NeMo documentation confirms that ITN improves readability and also boosts downstream task performance for neural machine translation and named entity recognition, since these tasks use written text during training. Pass unnormalized output to your NER pipeline and the entity tagger trained on written dates and currency symbols will fail to fire on "le vingt et un avril deux mille vingt-six."
Identifying common pipeline bottlenecks
Common failure modes in ITN pipelines include latency overhead during rule evaluation, regex execution limits on edge-case inputs, and tokenization mismatches where the output token format does not match the schema expected by downstream models. Choosing the right ITN architecture determines which of those you accept as trade-offs:
| Architecture |
Relative latency |
Accuracy on standard domains |
Accuracy on out-of-vocabulary |
Maintenance overhead |
| WFST (rule-based) |
Typically low, though scales with grammar complexity |
High (rule-governed) |
Low (requires manual rules) |
High (linguistic expertise) |
| Transformer-based |
Typically higher overhead, with known challenges for real-time and resource-constrained deployments |
Very high (contextual) |
High (generalizes well) |
Low (requires training data) |
| Hybrid (tagger + WFST) |
Implementation-dependent, competitive with WFST when the seq2seq component is scoped to tagged spans only |
Very high |
Very high |
Varies (depends on implementation) |
Research on the hybrid ITN approach demonstrates that a Transformer-based tagger combined with category-specific WFSTs applied only to tagged spans retains WFST's customizability while reducing the transducer's size. The computationally intensive seq2seq component runs only on tagged spans, keeping overall latency competitive with pure WFST while preserving contextual accuracy on ambiguous inputs.
Optimizing transcripts for final display
Raw transcripts need to pass two standards: human readability and machine parseability. These sometimes conflict. A date written "21. April 2026" reads naturally in German but needs consistent ISO formatting for a database insert. Match your business requirements to the right normalization architecture:
| Business requirement |
Latency constraint |
Domain complexity |
Recommended approach |
| High-volume contact center QA |
Sub-second acceptable |
Standard (dates, currencies) |
Hybrid (tagger + WFST) or optimized WFST |
| Real-time voice agents |
Sub-800ms at p95 |
Low |
Pure WFST (rule-governed) |
| Specialized medical or legal |
Batch processing acceptable |
High (domain jargon) |
Hybrid with custom rule overrides |
Standardizing transcripts for European locales
Standardizing unformatted STT output
The contrast between raw and normalized output illustrates why ITN belongs inside or immediately after the ASR engine. The following illustrative example shows what a German-language business call transcript looks like before and after ITN is applied:
```json
// Raw STT output
{
"text": "wir haben am einundzwanzigsten april zweitausendsechsundzwanzig dreitausendfünfhundert euro bezahlt"
}
// Normalized STT output (ITN applied)
{
"text": "Wir haben am 21. April 2026 3.500 € bezahlt"
}
```
A downstream CRM field expecting a date in DD.MM.YYYY format or a currency parser looking for a numeric value with a thousands separator will fail on the raw form, and the failure is silent. The record inserts without error, with a null date field and a string where a float should be.
Language rules for text normalization
French, German, and Spanish each operate on different number-formation logic, date conventions, decimal and thousands separators, and currency symbol placement. A single ITN ruleset cannot cover all three without producing systematic errors in at least two of them. Treating European languages as a monolithic block is where most in-house pipelines first fail, because the English heuristic (numeric tokens, decimal point, currency symbol prefix) applies cleanly to none of them.
Pipeline placement for STT accuracy
When ITN runs inside the ASR pipeline rather than as a downstream microservice, the audio-to-LLM pipeline receives normalized tokens that match the training distribution of the entity extraction model. Post-processing ITN applied after LLM tokenization cannot retroactively fix mismatches already encoded in the model's attention context.
French normalization logic for speech recognition
Automating French digit normalization
French uses a vigesimal (base-20) counting system for numbers in the 70 to 99 range, which no English-centric ITN pipeline handles correctly without explicit language-specific rules:
- 70 = "soixante-dix" (sixty-ten)
- 80 = "quatre-vingts" (four-twenties)
- 90 = "quatre-vingt-dix" (four-twenty-ten)
- 97 = "quatre-vingt-dix-sept" (four-twenty-ten-seven)
The ITN engine must parse a five-token string and output a single integer. The edge cases compound quickly: "quatre-vingts" takes an "s" when standing alone but drops it in compound forms like "quatre-vingt-un." Similarly, "deux cents" takes an "s" for 200 but not for 201 ("deux cent un"). These are not regex-catchable patterns because they require a full finite-state grammar. A production pipeline serving French-speaking Europe also needs to handle "septante" (70) and "nonante" (90) used in Belgian and Swiss French, mapping all regional variants to the same integer output.
Parsing French date and time strings
French date formatting follows DD/MM/YYYY, and time expressions use the 24-hour form in formal registers ("quatorze heures trente" to "14h30" or "14:30"). An ITN engine must detect that "le vingt et un avril" is a date fragment, reconstruct the ordinal, and format it as "21 avril" before appending the year from context.
Formatting rules for currency and units
French currency formatting places the Euro symbol after the number, separated by a non-breaking space: "150 €" not "€150." This is the reverse of common English convention and will break any downstream currency parser that assumes the symbol precedes the amount. A properly configured French ITN rule maps "cent cinquante euros" to "150 €" with the correct symbol position and casing.
Handling non-standard French inputs
Abbreviations introduce a second class of normalization challenge. Spoken letter sequences like "esse enne cé ef" should map to "SNCF" and "monsieur" to "M." in formal text. French postal codes require mapping spoken number words to five-digit strings: "soixante-quinze mille" to "75000." These are deterministic rules, but they require explicit coverage in the grammar. An LLM prompt asked to normalize French text post-hoc will hallucinate on edge cases, and there is no reliable way to detect failures without a verification layer that adds latency you did not budget for.
German normalization: handling dates and currency
Automating German digit normalization
German reverses the digit order for compound numbers relative to English: "einundzwanzig" is literally "one-and-twenty," with the units digit stated before the tens. The ITN parser must detect the "und" connector, extract the operands, reverse their semantic order, and output "21." For numbers above 100, the pattern nests: "dreihunderteinundzwanzig" requires a three-layer decomposition to produce "321."
Standardizing German date and time formats
German ordinal numbers in dates take a trailing period after the numeral: "der einundzwanzigste April" becomes "21. April." The grammar must also handle time expressions with non-standard tokens: "viertel nach acht" maps to "8:15" depending on context, and "halb neun" maps to "8:30," meaning half-before-nine rather than the English additive logic of half-past-eight.
German currency and abbreviation rules
German currency uses a period as the thousands separator and a comma as the decimal separator, the reverse of English convention: "3.500,50 €". An ITN engine that inherits English decimal logic will invert these, producing "3,500.50" that fails German locale number parsing. The practical consequence: a financial transcript feeding a reporting dashboard will silently corrupt every currency figure if the normalization layer does not carry German-specific number format rules.
Managing German compound word splitting
German compound nouns like "Kraftfahrzeug-Haftpflichtversicherung" (motor vehicle liability insurance) present a distinct challenge: the ITN engine must decide whether to split or preserve the compound based on downstream context. In a key data extraction pipeline, an incorrectly split compound noun produces two unknown tokens instead of one recognized entity. There is no universal rule for German compound splitting, only context-dependent heuristics, which is why our custom vocabulary support lets you inject domain-specific compound noun mappings without maintaining the full grammar.
Handling Spanish data variants in speech pipelines
Mapping Spanish digits and quantities
Spanish introduces gender agreement for compound numbers in the hundreds range. "Doscientos libros" (200 books, masculine) and "doscientas páginas" (200 pages, feminine) both map to "200," but the ITN engine must recognize both gendered forms as valid inputs for the same integer output. Only numbers ending in "-cientos" carry this gender distinction, covering 200, 300, 400, 500, 600, 700, 800, and 900. A pipeline that handles only the masculine form will fail on roughly half of feminine-noun contexts.
Normalizing Spanish date and time
Spanish date formatting uses the long form "veintiuno de abril de dos mil veintiséis" mapping to "21 de abril de 2026," maintaining the "de" prepositions in the written output rather than converting to a numeric slash format. Time expressions like "las tres y media" map to "3:30" or "15:30" depending on context disambiguation. The ITN engine must also handle colloquial forms like "las tres menos cuarto" (quarter-to-three = "2:45").
Handling currency and token variations
Spanish-speaking markets span significantly different currency contexts. European Spanish uses "1.500,50 €" with a period as the thousands separator and a comma as the decimal separator. Decimal conventions vary across Latin American markets: countries including Mexico, Peru, and Panama follow the US convention with a comma as the thousands separator and a period for decimals, while other markets reverse this. A production Spanish ITN ruleset needs a locale parameter to select the correct currency symbol and separator convention, otherwise the same input string produces output that is wrong for a significant portion of your user base.
Why in-house normalization pipelines fail
Why custom logic creates technical debt
The engineering lead who decides to build ITN in-house for a single language typically scopes it as a two-week sprint. In practice, covering core happy paths routinely extends well beyond that initial estimate. Handling production edge cases often extends that to a full quarter. The hidden cost is not the initial build but the compounding maintenance as new edge cases arrive with every new customer segment.
The following TCO comparison uses illustrative relative cost ratios to frame the asymmetry:
| Cost component |
Build (in-house custom pipeline) |
Buy (managed API with built-in ITN) |
| Initial engineering |
Higher (linguistic rules, pipeline integration) |
Lower (API integration) |
| Compute and infrastructure |
Higher (GPU or CPU hosting for custom models) |
Lower (bundled in per-hour pricing) |
| Maintenance and updates |
Significantly higher (fixing edge cases, new locales) |
Lower (managed by vendor) |
| Total cost of ownership |
Significantly higher |
Lower |
Teams that move off self-hosted infrastructure report saving 20% or more in DevOps effort. That figure does not account for the linguistic expertise required to maintain ITN grammars across five European locales, which is a separate cost center most engineering teams have never explicitly budgeted.
Solving linguistic edge case complexity
The most insidious failure mode in ITN pipelines is the silent normalization error. A single unnormalized date field on a CRM insert succeeds at the database layer, stores a null, and surfaces three months later as a data quality issue in a quarterly report. By that point, the team has no way to identify which transcripts contained the malformed dates without a full audit.
Domain-specific jargon compounds this. Medical, legal, and financial terminology introduces out-of-vocabulary tokens that generic ITN rules map incorrectly or skip. A custom rule override layer on top of a managed service is a reasonable middle path: it preserves the maintained baseline while allowing your team to inject domain-specific term mappings without owning the full grammar, which is what our custom vocabulary support is designed for.
Top normalization frameworks compared
For teams evaluating open-source ITN frameworks, NVIDIA NeMo provides a WFST and Transformer hybrid implementation with language-specific grammar files. For TN (written-to-spoken), NeMo's context-aware implementation generates multiple tagged written-form candidates via FSTs and uses a language model to rescore them, but this rescoring step applies to TN only. NeMo's own ITN implementation uses a pure WFST pipeline (classify/verbalize) rather than a tagger. A related hybrid tagger-plus-WFST approach, described in the research below, offers an alternative architecture for the same problem. The hybrid ITN research shows that splitting the process into tagging and transduction phases keeps latency competitive while retaining contextual accuracy on ambiguous inputs.
For teams who need to inspect, extend, or self-host the normalization layer before committing to a managed integration, Gladia's open-source normalization library is purpose-built for the French, German, and Spanish rules covered in this article: vigesimal parsing for French, unit-before-tens reversal for German, and gender-agreement mapping for Spanish. It ships with language-specific grammar files rather than a shared ruleset, so you can audit the exact logic that powers the production pipeline or fork it to add domain-specific term mappings before integrating with the managed API.
Automating entity parsing for EU languages
Normalization logic for FR, DE, and ES
The language-specific ITN rules covered in this article, vigesimal parsing for French, unit-before-tens reversal for German, gender-agreement mapping for Spanish, and the correct locale-specific decimal and thousands separators for each, follow a deterministic rule design.
The rules are auditable: each normalization decision can be traced to a specific grammar path, which matters for compliance-sensitive deployments where an audit requires explaining why a specific output was produced.
Standardizing multilingual output formats
When a speaker switches languages mid-conversation, the ITN engine must switch normalization rules at the language boundary, not at the session level. A bilingual French-English sales call might reference "vingt euros" in a French-language segment and "$20" in an English segment within the same call. Applying French ITN rules to the English segment or English rules to the French segment produces formatting errors in both directions.
End-to-end multilingual models that detect language changes natively remove the routing layer entirely. Code-switching detection passes language tokens to the ITN layer at the point of the language change, allowing the correct normalization ruleset to activate per segment rather than per session. For code-switching in ITN pipelines, the architectural requirement is a language token at each segment boundary that the normalization layer can consume. Solaria-1 handles true mid-conversation code-switching across 100+ supported languages for real-time and async workflows. For European business audio specifically, Solaria-3 offers higher accuracy on real-world conversational audio compared to Solaria-1's broader multilingual approach.
Integrating normalization for STT accuracy
When ITN runs inside the ASR pipeline rather than as a downstream microservice, Named Entity Recognition accuracy improves because the entity tagger receives tokens that match its training distribution. A date tagger trained on "21 April 2026" will not fire on "einundzwanzigsten april zweitausendsechsundzwanzig." The improvement in NER precision directly reduces the hallucination rate across audio intelligence outputs downstream: LLM summarization, CRM population, and sentiment scoring.
Solaria-3 achieves 6.4% WER on the Earnings22 financial call benchmark, the only model under 7% in that test, ahead of AssemblyAI, ElevenLabs, Deepgram, Mistral, and Speechmatics, on real-world accented English financial audio.
Addressing edge cases in normalization pipelines
Quantifying normalization effects on WER
WER calculations are sensitive to normalization consistency between reference and hypothesis transcripts. If your reference transcript is normalized (contains "21 April 2026") but your hypothesis is raw (contains "einundzwanzigsten april zweitausendsechsundzwanzig"), the WER calculation will count multiple substitution and deletion errors for what is semantically a correct recognition. Consistent normalization between reference and hypothesis is a precondition for meaningful WER measurement on multilingual datasets.
Disabling normalization for raw output
There are legitimate use cases where you want raw ASR output without ITN applied: training downstream acoustic models where training data should match the raw model output distribution, linguistic research requiring spoken-form text, and debugging pipelines where you need to isolate normalization errors from recognition errors. Managed STT services typically support disabling ITN via configuration parameters, giving you control over which pipeline stage applies normalization. This matters for teams building evaluation harnesses who need raw output to compute reference-matched WER metrics.
Start with €50 in free credits, test our models on your own conversational audio, and evaluate based on the entities that matter most to your operation before committing to an architecture that will be difficult to unwind six months into production.
FAQs
What is the difference between text normalization and inverse text normalization?
Text normalization (TN) converts written text to spoken form (for example, "€150" to "cent cinquante euros") for TTS systems. Inverse text normalization (ITN) does the reverse, converting spoken ASR output into written form (for example, "cent cinquante euros" to "150 €") to make transcripts usable by downstream databases, LLMs, and NER models.
Why does French ITN require special handling compared to English?
French uses a vigesimal (base-20) counting system for numbers 70 to 99, so "quatre-vingt-dix-sept" (four-twenty-ten-seven) must parse to "97." English number formation is additive and decimal throughout, so English-centric ITN rules cannot cover these multi-token constructs without dedicated French grammar files.
Can I use an LLM to handle normalization post-transcription?
LLM-based post-processing introduces three production risks: latency per normalization pass depending on model size, cost that compounds at high call volumes since each normalization requires a full inference, and hallucination on edge cases where the LLM invents plausible-looking but incorrect formats. Deterministic WFST or hybrid architectures produce verifiable, auditable outputs without those failure modes.
Does Gladia handle inverse text normalization automatically?
Yes. We apply inverse text normalization automatically as part of the transcription pipeline for all supported languages, including the French, German, and Spanish rules covered in this article. You receive normalized output by default — dates, currencies, and numbers formatted for downstream systems — without additional configuration.
Is Gladia's normalization library available to inspect or self-host?
Yes. Our normalization library is open-source and covers the language-specific rules for French, German, and Spanish discussed in this article — vigesimal parsing, unit-before-tens reversal, gender-agreement mapping, and locale-specific decimal and thousands separators. It's useful for teams who want to audit the grammar logic, extend it for their domain, or self-host the normalization layer before integrating with the managed API.
Does Gladia support real-time speaker diarization?
No. Speaker diarization is powered by pyannoteAI's Precision-2 model and is only available in asynchronous (batch) workflows.
What is the cost of Gladia's asynchronous transcription?
Asynchronous transcription starts at $0.61 per hour on the Starter plan and goes as low as $0.20 per hour on the Growth plan, with diarization, translation, NER, sentiment analysis, and summarization all included in the base rate on Starter and Growth.
Is customer data used to train Gladia's models?
On the Starter plan, customer data can be used for model training by default. On Growth and Enterprise plans, customer data is never used for model training and no opt-out action is required.
How does normalization affect WER calculations on multilingual benchmarks?
WER calculations require consistent normalization between reference and hypothesis transcripts. If the reference is normalized and the hypothesis is raw, WER is artificially inflated. If the hypothesis is normalized and the reference is raw, WER is artificially deflated. Matching the normalization state across both inputs is a precondition for meaningful multilingual WER measurement.
Key terms glossary
Inverse Text Normalization (ITN): The process of converting spoken-form ASR output (for example, "one hundred dollars") into written-form text (for example, "$100") to make transcripts usable by downstream databases, LLMs, and NER models.
Weighted Finite-State Transducer (WFST): A rule-based graph architecture used for low-latency text normalization, where weights encode probabilities or costs for different normalization paths. Modern WFST implementations often incorporate non-deterministic variants to handle context-dependent ambiguities.
Word Error Rate (WER): The standard ASR accuracy metric, calculated as the number of substitutions, deletions, and insertions divided by the total words in the reference transcript. Normalization consistency between reference and hypothesis is a precondition for meaningful WER measurement.
Vigesimal counting: A base-20 number system used in standard French for numbers 70-99, where "quatre-vingts" (four-twenties) represents 80. Regional variants in Belgian and Swiss French include "septante" (70) and "nonante" (90). "Huitante" (80) appears in some Swiss French varieties but is not standard in Belgian French, and "octante" is archaic even in Switzerland.
Code-switching: Mid-conversation language changes where a speaker alternates between two or more languages within the same session, requiring the ITN engine to switch normalization rulesets at the language boundary rather than applying a single session-level ruleset.
Out-of-vocabulary (OOV): Tokens not present in a model's training vocabulary, including rare words, names, newly coined terms, and domain-specific terminology in medical, legal, or financial contexts, which generic ITN rules cannot normalize correctly without custom rule overrides.
