text normalization turns written forms such as numbers, dates, prices, times, abbreviations, and identifiers into the words a text to speech (tts) model should say. it happens before speech generation. the normalizer decides that ₹2,400 means "two thousand four hundred rupees" rather than a string of symbols and digits.

how does text normalization work?

written text often uses forms that people do not say aloud. we write 18:45, but say "six forty-five pm." we write 25%, but say "twenty-five percent." text normalization converts those written forms into spoken words near the start of a tts pipeline.

a normalizer usually has to make three decisions:

1. find the written form. it detects a number, date, amount, time, abbreviation, or identifier that may need to be expanded.

2. work out its role. the same digits can represent a quantity, year, phone number, account number, or one-time password.

3. write the spoken form. it converts the input into words that the pronunciation and speech-generation stages can process.

context is the difficult part. 2026 may mean the year "twenty twenty-six" or the quantity "two thousand twenty-six." 0071 may be an identifier that must keep both leading zeros. a normalizer needs either enough context to choose correctly or a clear instruction from the application.

text normalization example

rumik silk normalizes text before synthesis. numbers used as quantities are written normally. identifiers that must be spoken one character at a time go inside double quotes.

a voice agent could send this line to rumik silk:

Your OTP is "4820". Rs 2,45,600 was debited on 09/03/2025.

Your OTP is "4820". Rs 2,45,600 was debited on 09/03/2025.

silk speaks the otp one digit at a time, reads the amount in lakhs, and expands the date. the application does not need to replace every digit with words before sending the request.

the quotation marks carry meaning here. without them, a sequence such as 482093 looks like a quantity. silk cannot know from the digits alone that the caller needs an otp read one number at a time.

text normalization vs inverse text normalization

text normalization and inverse text normalization move in opposite directions.

text normalization prepares written text for a voice model. inverse text normalization formats recognized speech for a screen, transcript, or stored record. the two processes may handle the same date or amount, but they start from different forms and serve different parts of a speech system.

pronunciation is another step. normalization decides that 25% should become "twenty-five percent." pronunciation decides how the sounds in those words are produced. fixing the spoken form does not guarantee that every name or borrowed word will be pronounced correctly.

why does text normalization matter for voice agents?

voice agents read values created during a live conversation. appointment dates, refund amounts, account endings, order numbers, and otps may change on every call. writing each possible value out by hand is not practical.

the error can also change the information the caller receives. reading 6042 as "six thousand forty-two" is wrong when the line says "your card ending 6042." dropping the zeros in an otp can make the code unusable. reading an indian amount in the wrong number system can make a payment or balance harder to understand.

before shipping a call flow, test the forms the voice agent will receive from real systems:

• amounts with indian comma placement

• dates with numeric separators

• times in 12-hour and 24-hour formats

• decimals and percentages

• otps and pins with leading zeros

• phone, account, card, and tracking numbers

normalization runs by default in rumik silk. you can set "normalization": false when the text is already written exactly as it should be spoken. once it is turned off, the application takes responsibility for preparing every amount, date, and identifier in the line.