[$250] Rates - Incorrect currency symbol in change log message after updating rate amount.

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.2-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92186
Email or phone of affected tester (no customers): applausetester+ib0005@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Other

Action Performed:

Prerequisite: Use an Expensifail account.
Prerequisite 2: Account has a workspace with distance rates enabled.
Prerequisite 3: Workspace currency is different to USD (In this issue: ARS)

1. Open the staging.new.expensify.com website.
2. Navigate to "Workspaces" > Workspace > "Distance Rates"
3. Click on "Add Rate" and create a new rate with 1,3 ARS amount per mile.
4. Navigate to #Admins room of the same workspace and open thread created with distance rate creation.
5. Note that a "Added (Name) rate of ARS 1,30/Mile" message is visible.
6. Return to "Workspaces" > "Distance Rates"
7. Open the just created rate and update amount to 1,40 ARS.
8. Return to thread conversation.
9. Note that a "Changed the rate of the distance rate "Name" to AR$1,40 (previously AR$1,30" message is visible, showing the currency symbol as AR$ instead of ARS.

Expected Result:

After editing the amount of a distance rate, change log message created on thread, should display the correct currency symbol.

Actual Result:

Incorrect currency symbol is displayed on change log message after editing a distance rate amount. Message shows a "AR$" symbol instead of "ARS" symbol.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7176422_1781056109025.Rates_Log_7.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7176422

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022064562852131538207
• Upwork Job ID: 2064562852131538207
• Last Price Increase: 2026-06-24

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/7dfb532e1aeee54ab3990add6fbfb64c4ffb7cba867ba456dc1faac896c74f72

[MelvinBot]

Issue Analysis

Root Cause: The "Added rate" and "Changed rate" change-log messages format the currency from two different sources, so they disagree on symbol vs. ISO code:

• Add rate message is formatted client-side by App. ReportActionsUtils.ts:3171 takes the raw rate + currency from originalMessage and runs them through convertAmountToDisplayString, which uses Intl currency formatting → renders the ISO code: ARS 1,30.
• Update rate message is not re-formatted by App. ReportActionsUtils.ts:3204-3205 passes the backend-provided newValue / oldValue strings verbatim into the message. Those strings are already formatted by the backend with the currency symbol → AR$1,40.

The update path receives only the pre-formatted display string (the UPDATE_CUSTOM_UNIT_RATE originalMessage has no raw rate/currency fields, unlike the add path), so the AR$ symbol is produced server-side, before it ever reaches App.

⚠️ This fix requires a change outside the Expensify/App repo. The mismatched AR$ string is generated by the backend when it builds the UPDATE_CUSTOM_UNIT_RATE policy change log. App is faithfully rendering what it's sent. A separate internal investigation by an engineer with backend (Auth/Web-Expensify) access is needed.

Recommended Fix (backend): Make the rate-update change log consistent with the add change log — either format the rate value using the ISO currency code (matching convertAmountToDisplayString), or include the raw rate amount + currency in the UPDATE_CUSTOM_UNIT_RATE originalMessage so App can format it client-side the same way it does for adds.

Investigation details

Message templates (both in en.ts):

• Add: workspaceActions.addCustomUnitRateWithAmount → added "{rateName}" rate of {rateValue}
• Update: workspaceActions.updatedCustomUnitRate → changed the rate of the {customUnitName} {updatedField} "{name}" to "{newValue}" (previously "{oldValue}")

Why it's backend, not App:

• getWorkspaceCustomUnitRateAddedMessage reads rate + currency and formats locally.
• getWorkspaceCustomUnitRateUpdatedMessage only has newValue/oldValue (typed as string) — already-formatted display strings. There is no raw amount/currency to re-format from.
• App/src/libs/actions/Policy/DistanceRate.ts does not construct these values optimistically, confirming they arrive from the API response.

Alternative considered: Changing the add message to also show AR$ would make them consistent but contradicts the issue's Expected Result (the ISO code ARS is the desired output), so the update path is the one to fix.

Confidence: High — code evidence pinpoints both formatting paths and the divergence point.

---

Next Steps: This needs a backend engineer with Auth/Web-Expensify access to align the UPDATE_CUSTOM_UNIT_RATE change-log currency formatting. Reply with @MelvinBot <feedback> to refine this analysis.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ChavdaSachin (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022064562852131538207

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a workspace's distance rate amount is edited on a non-USD workspace (e.g. ARS), the change-log message posted to the #Admins thread renders the currency as the locale symbol "AR$" instead of the ISO code "ARS" — e.g. Changed the rate of the distance rate "Name" to AR$1,40 (previously AR$1,30). The expected message uses "ARS" to match the sibling "Added rate" message (Added "Name" rate of ARS 1,30/Mile). Reproduces on Web and Android.

What is the root cause of that problem?

In src/libs/ReportActionsUtils.ts:3204-3206, getWorkspaceCustomUnitRateUpdatedMessage passes the server-supplied pre-formatted oldValue/newValue strings straight into translate('workspaceActions.updatedCustomUnitRate', …). Those strings come from the backend already formatted with the locale currency symbol ("AR$"), so the client never re-formats them. The sibling ADD branch at src/libs/ReportActionsUtils.ts:3169-3184 avoids the bug because it client-formats via convertAmountToDisplayString(rate, currency), which emits the ISO code ("ARS"). The bug surfaced once PR #92186 introduced the new amount-aware "added rate" copy that uses convertAmountToDisplayString, making the inconsistency visible between the ADD and UPDATE log entries.

What changes do you think we should make in order to solve the problem?

1. In src/libs/ReportActionsUtils.ts:3194-3206 (getWorkspaceCustomUnitRateUpdatedMessage), when updatedField === RATE_CHANGELOG_UPDATED_FIELD.RATE, re-derive the displayed amount instead of trusting oldValue/newValue strings. Read the workspace outputCurrency from the policy associated with the report (via getReport/getPolicy) and parse the numeric portion out of oldValue/newValue (strip the leading currency token, keep digits and the locale decimal separator), then format with convertAmountToDisplayString(amountInCents, currency) — the same helper the ADD branch uses at line 3171. This mirrors the working analog and guarantees the ISO-code rendering.
2. If the backend already includes numeric rate/currency (or oldRate/newRate) on the UPDATE_CUSTOM_UNIT_RATE originalMessage, prefer those fields directly and skip the string parse; extend OriginalMessage's rate-change shape in src/types/onyx/OriginalMessage.ts (around lines 583-589) to surface them so TypeScript catches the access.
3. Keep the en.ts / other-language copy strings unchanged — the bug is the value being interpolated, not the template. Verify the same code path renders correctly on Android/Web (single shared file, no .native/.web twin needed).
4. Add a defensive fallback: if parsing fails or outputCurrency is unavailable, fall back to the existing oldValue/newValue strings so the message still renders rather than going blank.

What alternative solutions did you explore? (Optional)

Backend fix (send ISO code instead of locale symbol in the change-log payload) — rejected because external contributions are frontend-only, and the ADD path already standardized on client-side formatting, so symmetry argues for fixing UPDATE the same way. A pure string-replace of "AR$" → "ARS" was rejected as locale-fragile (won't generalize to other currencies whose locale symbol differs from the ISO code).

[lorretheboy]

Proposal

What is the root cause of that problem?

The "added rate" and "changed rate" change-log messages build their amount string from two different sources, so they use two different currency symbols for the same currency.

The add message is formatted on the client from the raw numeric rate + currency via convertAmountToDisplayString, which uses Intl (style: 'currency') and renders ARS as the ISO-style symbol ARS:

App/src/libs/ReportActionsUtils.ts

Lines 3169 to 3171 in 7c91855

	if (rateName && rate !== undefined && currency && unit) {
	const unitLabel = unit === CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES ? translate('common.mile') : translate('common.kilometer');
	const formattedRate = `${convertAmountToDisplayString(rate, currency)}/${unitLabel}`;

App/src/libs/CurrencyUtils.ts

Lines 205 to 213 in 7c91855

	function convertAmountToDisplayString(amount = 0, currency: string = CONST.CURRENCY.USD): string {
	const convertedAmount = amount / 100.0;
	return format(IntlStore.getCurrentLocale(), convertedAmount, {
	style: 'currency',
	currency: sanitizeCurrencyCode(currency),
	minimumFractionDigits: CONST.MIN_TAX_RATE_DECIMAL_PLACES,
	maximumFractionDigits: CONST.MAX_TAX_RATE_DECIMAL_PLACES,
	});
	}

The update message, by contrast, renders newValue/oldValue exactly as the server pre-formatted them — the server builds those strings from the Expensify currency-list symbol (where ARS = AR$), and the client prints them verbatim:

App/src/libs/ReportActionsUtils.ts

Lines 3204 to 3206 in 7c91855

	if (customUnitName && customUnitRateName && updatedField === RATE_CHANGELOG_UPDATED_FIELD.RATE && typeof oldValue === 'string' && typeof newValue === 'string') {
	return translate('workspaceActions.updatedCustomUnitRate', customUnitName, customUnitRateName, updatedField, newValue, oldValue);
	}

App/src/languages/en.ts

Lines 7678 to 7679 in 7c91855

	updatedCustomUnitRate: (customUnitName: string, customUnitRateName: string, updatedField: string, newValue: string, oldValue: string) =>
	`changed the rate of the ${customUnitName} ${updatedField} "${customUnitRateName}" to "${newValue}" (previously "${oldValue}")`,

So the chain is: the rate-update original message carries only pre-formatted strings (no raw amount/currency) → the client can't reformat and prints the server's AR$-based string → it disagrees with the add message, which the client formats itself as ARS.

What changes do you think we should make in order to solve the problem?

Make the update message format the amount the same way the add message does, instead of trusting the server's pre-formatted string. Concretely, the UPDATE_CUSTOM_UNIT_RATE original message should carry the raw rate (cents) and currency like the add action already does:

App/src/libs/ReportActionsUtils.ts

Lines 3166 to 3171 in 7c91855

	const {customUnitName, rateName, rate, currency, unit, startDate, endDate} =
	getOriginalMessage(action as ReportAction<typeof CONST.REPORT.ACTIONS.TYPE.POLICY_CHANGE_LOG.ADD_CUSTOM_UNIT_RATE>) ?? {};
	if (rateName && rate !== undefined && currency && unit) {
	const unitLabel = unit === CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES ? translate('common.mile') : translate('common.kilometer');
	const formattedRate = `${convertAmountToDisplayString(rate, currency)}/${unitLabel}`;

Then, in the RATE branch, format newValue/oldValue through convertAmountToDisplayString(rate, currency) before passing them into the updatedCustomUnitRate translation, so both messages converge on the same client-side formatter and show ARS consistently:

App/src/libs/ReportActionsUtils.ts

Lines 3204 to 3206 in 7c91855

	if (customUnitName && customUnitRateName && updatedField === RATE_CHANGELOG_UPDATED_FIELD.RATE && typeof oldValue === 'string' && typeof newValue === 'string') {
	return translate('workspaceActions.updatedCustomUnitRate', customUnitName, customUnitRateName, updatedField, newValue, oldValue);
	}

This is the single convergence point — every distance-rate change-log message would then format currency through the same path. (Including the raw amount/currency on the update action is a small backend addition mirroring what the add action already sends.)

What alternative solutions did you explore? (Optional)

Keep using the server strings but normalize the symbol on the client by swapping the currency-list symbol for the Intl symbol via getLocalizedCurrencySymbol. This avoids a backend change but is fragile (string surgery on an already-formatted, locale-dependent value) and won't fix decimal/grouping differences — so aligning both messages on convertAmountToDisplayString is preferable.

[mukhrr]

Proposal

What is the root cause of that problem?

The rate update changelog path is the only amount-based policy changelog path here that trusts already-formatted strings from the action payload.

For distance rate creation, the action includes raw rate, currency, and unit, and the frontend formats the display value with convertAmountToDisplayString(rate, currency):

App/src/libs/ReportActionsUtils.ts

Lines 3165 to 3184 in 7c91855

	function getWorkspaceCustomUnitRateAddedMessage(translate: LocalizedTranslate, action: ReportAction): string {
	const {customUnitName, rateName, rate, currency, unit, startDate, endDate} =
	getOriginalMessage(action as ReportAction<typeof CONST.REPORT.ACTIONS.TYPE.POLICY_CHANGE_LOG.ADD_CUSTOM_UNIT_RATE>) ?? {};
	if (rateName && rate !== undefined && currency && unit) {
	const unitLabel = unit === CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES ? translate('common.mile') : translate('common.kilometer');
	const formattedRate = `${convertAmountToDisplayString(rate, currency)}/${unitLabel}`;
	const formattedStartDate = startDate ? DateUtils.formatToReadableString(startDate) : undefined;
	const formattedEndDate = endDate ? DateUtils.formatToReadableString(endDate) : undefined;
	if (formattedStartDate && formattedEndDate) {
	return translate('workspaceActions.addCustomUnitRateWithAmountAndDates', rateName, formattedRate, formattedStartDate, formattedEndDate);
	}
	if (formattedStartDate) {
	return translate('workspaceActions.addCustomUnitRateWithAmountAndStartDate', rateName, formattedRate, formattedStartDate);
	}
	if (formattedEndDate) {
	return translate('workspaceActions.addCustomUnitRateWithAmountAndEndDate', rateName, formattedRate, formattedEndDate);
	}
	return translate('workspaceActions.addCustomUnitRateWithAmount', rateName, formattedRate);

For distance rate updates, the action only uses oldValue and newValue strings, then inserts those strings directly into the translated message:

App/src/libs/ReportActionsUtils.ts

Lines 3194 to 3206 in 7c91855

	function getWorkspaceCustomUnitRateUpdatedMessage(translate: LocalizedTranslate, action: ReportAction): string {
	const {customUnitName, customUnitRateName, updatedField, oldValue, newValue, newTaxPercentage, oldTaxPercentage, newStartDate, newEndDate, oldStartDate, oldEndDate} =
	getOriginalMessage(action as ReportAction<typeof CONST.REPORT.ACTIONS.TYPE.POLICY_CHANGE_LOG.UPDATE_CUSTOM_UNIT_RATE>) ?? {};
	const {RATE_CHANGELOG_UPDATED_FIELD} = CONST.CUSTOM_UNITS;
	if (customUnitName && updatedField === RATE_CHANGELOG_UPDATED_FIELD.NAME && typeof oldValue === 'string' && typeof newValue === 'string') {
	return translate('workspaceActions.updatedCustomUnitRateName', customUnitName, oldValue, newValue);
	}
	if (customUnitName && customUnitRateName && updatedField === RATE_CHANGELOG_UPDATED_FIELD.RATE && typeof oldValue === 'string' && typeof newValue === 'string') {
	return translate('workspaceActions.updatedCustomUnitRate', customUnitName, customUnitRateName, updatedField, newValue, oldValue);
	}

That means if the backend sends AR$1,40, the UI cannot normalize it to match the add-rate message style. Similar changelog handlers avoid this by receiving raw numeric values plus currency and formatting in ReportActionsUtils, for example max expense amount and time rate updates:

App/src/libs/ReportActionsUtils.ts

Lines 3702 to 3723 in 7c91855

	function getPolicyChangeLogMaxExpenseAmountNoReceiptMessage(translate: LocalizedTranslate, action: ReportAction): string {
	const {oldMaxExpenseAmountNoReceipt, newMaxExpenseAmountNoReceipt, currency} =
	getOriginalMessage(action as ReportAction<typeof CONST.REPORT.ACTIONS.TYPE.POLICY_CHANGE_LOG.UPDATE_MAX_EXPENSE_AMOUNT_NO_RECEIPT>) ?? {};
	if (typeof oldMaxExpenseAmountNoReceipt === 'number' && typeof newMaxExpenseAmountNoReceipt === 'number') {
	const oldIsDisabled = oldMaxExpenseAmountNoReceipt === CONST.DISABLED_MAX_EXPENSE_VALUE;
	const newIsDisabled = newMaxExpenseAmountNoReceipt === CONST.DISABLED_MAX_EXPENSE_VALUE;
	const oldValue = oldIsDisabled ? '' : convertToDisplayString(oldMaxExpenseAmountNoReceipt, currency);
	const newValue = newIsDisabled ? '' : convertToDisplayString(newMaxExpenseAmountNoReceipt, currency);
	if (oldIsDisabled && !newIsDisabled) {
	return translate('workspaceActions.setReceiptRequiredAmount', newValue);
	}
	if (!oldIsDisabled && newIsDisabled) {
	return translate('workspaceActions.removedReceiptRequiredAmount', oldValue);
	}
	return translate('workspaceActions.changedReceiptRequiredAmount', oldValue, newValue);
	}
	return getReportActionText(action);

App/src/libs/ReportActionsUtils.ts

Lines 4158 to 4166 in 7c91855

	function getUpdatedTimeRateMessage(translate: LocalizedTranslate, reportAction: OnyxEntry<ReportAction>) {
	const {newRate, oldRate, currency} = getOriginalMessage(reportAction as ReportAction<typeof CONST.REPORT.ACTIONS.TYPE.POLICY_CHANGE_LOG.UPDATE_TIME_RATE>) ?? {};
	const newRateText = newRate !== undefined ? convertToDisplayString(convertToBackendAmount(newRate), currency) : undefined;
	const oldRateText = oldRate !== undefined ? convertToDisplayString(convertToBackendAmount(oldRate), currency) : undefined;
	if (newRate !== undefined && oldRate !== undefined) {
	return translate('workspaceActions.updatedTimeRate', newRateText, oldRateText);
	}

Git history also points to this helper as the intended frontend localization layer. PR 91391 added another getWorkspaceCustomUnitRateUpdatedMessage() branch for distance-rate renames so the UI would not fall back to raw server text:

#91391

But that PR left the existing updatedField === 'rate' branch unchanged, so rate updates still pass through server-formatted strings.

What changes do you think we should make in order to solve the problem?

Send raw values for distance rate update actions, and make the frontend prefer them when available.

Backend/API payload should include oldRate, newRate, and currency for POLICYCHANGELOG_UPDATE_CUSTOM_UNIT_RATE when updatedField === 'rate'. Then update the frontend formatter with a backward-compatible fallback:

diff --git a/src/types/onyx/OriginalMessage.ts b/src/types/onyx/OriginalMessage.ts
@@
     /** Rate amount in cents for the custom unit rate */
     rate?: number;
+
+    /** Previous rate amount in cents for custom unit rate updates */
+    oldRate?: number;
+
+    /** New rate amount in cents for custom unit rate updates */
+    newRate?: number;

diff --git a/src/libs/ReportActionsUtils.ts b/src/libs/ReportActionsUtils.ts
@@
-    const {customUnitName, customUnitRateName, updatedField, oldValue, newValue, ...} =
+    const {customUnitName, customUnitRateName, updatedField, oldValue, newValue, oldRate, newRate, currency, ...} =
         getOriginalMessage(...) ?? {};
@@
+    if (customUnitName && customUnitRateName && updatedField === RATE_CHANGELOG_UPDATED_FIELD.RATE && typeof oldRate === 'number' && typeof newRate === 'number' && currency) {
+        return translate(
+            'workspaceActions.updatedCustomUnitRate',
+            customUnitName,
+            customUnitRateName,
+            updatedField,
+            convertAmountToDisplayString(newRate, currency),
+            convertAmountToDisplayString(oldRate, currency),
+        );
+    }
+
     if (customUnitName && customUnitRateName && updatedField === RATE_CHANGELOG_UPDATED_FIELD.RATE && typeof oldValue === 'string' && typeof newValue === 'string') {
         return translate('workspaceActions.updatedCustomUnitRate', customUnitName, customUnitRateName, updatedField, newValue, oldValue);
     }

This avoids regression because existing/cached actions without the new fields still use the current oldValue/newValue branch. The new logic only affects rate updates that provide raw numeric rate data, and it matches the existing add-rate and other amount changelog formatting patterns.

Add or update tests for getWorkspaceCustomUnitRateUpdatedMessage() to cover:

1. New payload with oldRate, newRate, currency: 'ARS' formats through convertAmountToDisplayString.
2. Legacy payload with only oldValue/newValue still renders unchanged.
3. Rename, enabled, tax, and date-range branches still use their existing fields and are not affected.

What alternative solutions did you explore? (Optional)

We could parse AR$1,40 on the frontend and replace the symbol, but that is fragile across locales, spacing, separators, and currencies with overlapping symbols. Passing raw amount and currency follows the existing changelog pattern and avoids special-casing ARS.