Number Formatting
Currency, percentages and numbers that read the same in every answer and chart. IBM.
A business user should see $1,234,567.89 or 12.5%, not 1234567.886 or 0.125. Users set a format on a column once, such as currency in US dollars or a percentage with one decimal place, and IBM watsonx BI applies it to written answers and to charts. We built formatting across both, including values the system calculates while answering a question.
Node.js · TypeScript · Java · LLMs · Prompt engineering
Why it matters
Unformatted numbers are hard to read and easy to misread: is 0.25 a quarter of something, or 0.25 dollars? For one prospective customer, missing currency and percentage formatting was a blocker to adopting the product.
The problems
- Calculated values have no format. A question like “profit margin by region” produces columns that exist only in that answer. Nobody has set a format for them.
- Percentages come in two forms. 0.25 and 25 can both mean 25%. Formatting the wrong one shows 2,500% or 0.25%.
- Mixed currencies. Revenue in US dollars minus costs in euros is a number, but not a meaningful one.
- Answers and charts must agree. The same value written in an answer and shown in a chart should look the same.
The solution
One format, used everywhere
Formats set in the data catalog are converted once, during enrichment, into the dataset’s shared description that every service reads. A single shared formatting module turns a value and its format into text, and both written answers and charts use it. When a column has no format, the answer writer is told not to invent one, so a plain number never gains a dollar sign.
Inferring formats for calculated values
After a query runs, numeric result columns that are not in the dataset are recognised as calculated. A model reads the SQL and the formats of the columns each value was calculated from, and decides the format:
| Calculation | Format | Why |
|---|---|---|
| revenue − cost, both in USD | currency, USD | the result keeps the monetary unit |
| (this year − last year) / last year | percentage, as a fraction | a relative change |
| same, multiplied by 100 | percentage, already scaled | the ×100 shows the scale |
| median of price | same as price | a percentile of a price is a price |
| revenue in USD − cost in EUR | none, flagged | the calculation is not meaningful |
The model may only answer for the calculated columns of that query, in a fixed structure, and must return no format when it is unsure. A missing format is better than a wrong one.
Warning about mixed currencies, only when it matters
Showing revenue in dollars next to costs in euros is fine. Subtracting them is not. A separate check reads the question first, then the SQL, and decides whether the answer actually combines different currencies. Only then does the answer get a short note explaining that the comparison is not meaningful. Questions that merely list both values get no warning, even when the query contains extra columns.
Results
Answers and charts show currency, percentages and numbers in the format users set, including for values calculated on the fly. It removed an adoption blocker for a prospective customer.