[$250] [Due for payment 2025-09-23] Receipt required violation shows `25.00` briefly

[m-natarajan]

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:
Reproducible in staging?: Needs Reproduction
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @truph01
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Create a new workspace
2. Go to More features Page -> Enabled Rule feature
3. Submit an expense with the amount over 25
4. Observe the expense preview

Expected Result:

Receipt required violation doesn’t show 25.00 briefly

Actual Result:

Receipt required violation shows 25.00 briefly

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Platforms Tested:

On which of our officially supported platforms was this issue tested:

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

Screenshots/Videos

Add any screenshot/video evidence

violations.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021970534826802914464
• Upwork Job ID: 1970534826802914464
• Last Price Increase: 2025-09-23
• Automatic offers:
• truph01 | Contributor | 108878825

[melvin-bot]

Triggered auto assignment to @garrettmknight (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[m-natarajan]

Proposal by @truph01

Proposal

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

Receipt required violation shows 25.00 briefly

What is the root cause of that problem?

When creating a new expense, we will check for Receipt required violation and we use the convertAmountToDisplayString function with minimumFractionDigits as 2 here

App/src/libs/Violations/ViolationsUtils.ts

Lines 382 to 392 in f574d5e

	newTransactionViolations.push({
	name: CONST.VIOLATIONS.RECEIPT_REQUIRED,
	data:
	shouldShowCategoryReceiptRequiredViolation || !policy.maxExpenseAmountNoReceipt
	? undefined
	: {
	formattedLimit: CurrencyUtils.convertAmountToDisplayString(policy.maxExpenseAmountNoReceipt, policy.outputCurrency),
	},
	type: CONST.VIOLATION_TYPES.VIOLATION,
	showInReview: true,
	});

App/src/libs/CurrencyUtils.ts

Lines 155 to 163 in f574d5e

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

Then when the Back End returns the data that update the violation in Onyx with no digits.

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

We should use convertToDisplayString function instead like the way we did in Rules Page

   data:
       shouldShowCategoryReceiptRequiredViolation || !policy.maxExpenseAmountNoReceipt
           ? undefined
           : {
                   formattedLimit: CurrencyUtils.convertToDisplayString(policy.maxExpenseAmountNoReceipt, policy.outputCurrency),
               },

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None

What alternative solutions did you explore? (Optional)

[lorretheboy]

Proposal

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

Receipt required violation shows 25.00 briefly

What is the root cause of that problem?

We use convertAmountToDisplayString to convert to display, however it has mimimum decimal places is 2 which doesn
t match with what BE returns

App/src/libs/Violations/ViolationsUtils.ts

Line 388 in c70a6c7

formattedLimit: CurrencyUtils.convertAmountToDisplayString(policy.maxExpenseAmountNoReceipt, policy.outputCurrency),

App/src/CONST/index.ts

Line 6307 in f6e4d35

MIN_TAX_RATE_DECIMAL_PLACES: 2,

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

We should update to use convertToDisplayString to match with what BE returns

App/src/libs/Violations/ViolationsUtils.ts

Line 388 in c70a6c7

formattedLimit: CurrencyUtils.convertAmountToDisplayString(policy.maxExpenseAmountNoReceipt, policy.outputCurrency),

Also, we have another issue that causes the unmatch between FE and BE is about the currency symbol. We should fix this as well otherwise the UI is still having a brief update

The FE is showing "AMD 25.25" while the backend returns "դր25.25" (using the Armenian Dram symbol)

To fix this, we should update convertToDisplayString to accept 1 more param shouldUseLocalCurrencySymbol = false

So if it is enable, then we should get local currency symbol by getCurrencySymbol to use

    if (shouldUseLocalCurrencySymbol) {
        const currencySymbol = getCurrencySymbol(currencyWithFallback);

        if (currencySymbol) {
            const formattedNumber = format(IntlStore.getCurrentLocale(), convertedAmount, {
                style: 'decimal',
                minimumFractionDigits: getCurrencyDecimals(currency),
                maximumFractionDigits: 2,
            });
            return `${currencySymbol}${formattedNumber}`;
        }
    }

App/src/libs/CurrencyUtils.ts

Line 108 in e091028

function convertToDisplayString(amountInCents = 0, currency: string = CONST.CURRENCY.USD): string {

Or we can update directly to format function here to support local currency, however, I think since it's a general-purpose number formatting utility that's used throughout the codebase for various formatting needs (not just currency) so we can consider to only update in convertToDisplayString function

App/src/libs/NumberFormatUtils/index.ts

Line 10 in 462de3a

function format(locale: Locale | undefined, number: number, options?: Intl.NumberFormatOptions): string {

Or if we have any util function for this purpose in codebase, we can re-use it. However, i couldn't find it so I propose to update existing func. If we really have that function, we could use it

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[muhammad-ali-abbasi]

Proposal

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

When a workspace has Rules enabled (e.g., a receipt threshold set), submitting an expense above that threshold causes the preview to briefly show 25.00 as the threshold—even if the actual saved threshold is different. This flash of the wrong value is confusing to users.

What is the root cause of that problem?

In short: the UI shows the violation message before the real policy data (like the correct threshold) is available. It falls back to a default $25.00, which flashes briefly before being updated with the real value.

Details:

• The logic that builds the “Receipt required” message uses a precomputed or fallback formattedLimit while the actual policy data is still loading.
• This happens because the data from Onyx hasn’t arrived yet during the initial render.
• The flicker occurs because the message is optimistically rendered with a default, then corrected once the real policy info loads.

Relevant code areas:

• src/libs/ReportUtils.ts – handles formatting violation messages (search for where formattedLimit is created or used).

• UI components displaying these messages, like:

  • src/pages/home/report/ReportActionItemPreview.tsx
  • Any Violation or Violations component used in expense previews or report rows.

Why this flash happens:
The violation message is shown before policy data is loaded. The fallback $25.00 is displayed, then replaced with the real threshold, causing a flash.

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

Goal: Avoid showing a wrong default value, while keeping the violation visible early. Keep the fix low-risk.

Proposed changes:

1. Don’t render the threshold unless it's actually available

   • In the message builder, include formattedLimit only if the real value is loaded (e.g., policy.maxExpenseAmountNoReceipt is defined).

   • Otherwise, render a simplified message like Receipt required or Receipt required — threshold loading.

   • Example:

     message = `Receipt required${formattedLimit ? ` over ${formattedLimit}` : ''}`

2. Defensively compute formattedLimit in ReportUtils

   • Only compute formattedLimit if the relevant policy field is present.
   • Don’t default to $25.00. If the policy isn’t ready, skip the amount.

3. (Optional) Show a neutral placeholder instead

   • If a message must appear before data loads, make it generic (Receipt required) or show a temporary status like …loading threshold.

4. Limit the fix to message rendering only

   • Don't touch the rules logic or server-side validation—this is just about improving client-side display timing.

5. Where to apply the fix

   • Update the message-creation logic in src/libs/ReportUtils.ts.
   • Ensure UI components don’t assume formattedLimit is always present.

6. Add a small defensive test

   • Make sure formattedLimit can be safely undefined and doesn’t break anything.

Example pseudo-change (do not paste as PR):

Before:

const formattedLimit = CurrencyUtils.convertToDisplayString(policy.maxExpenseAmountNoReceipt, policy.outputCurrency) || '$25.00';
message = `Receipt required over ${formattedLimit}`;

After:

let formattedLimit;
if (policy && typeof policy.maxExpenseAmountNoReceipt === 'number') {
    formattedLimit = CurrencyUtils.convertToDisplayString(policy.maxExpenseAmountNoReceipt, policy.outputCurrency);
}
message = `Receipt required${formattedLimit ? ` over ${formattedLimit}` : ''}`;

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Unit tests for the message builder

• No amount is shown if policy or policy.maxExpenseAmountNoReceipt is missing.
• Amount is shown correctly when present and valid.
• $0 value is handled correctly.
• Formatted string is used correctly when conversion is successful.

2. Component snapshot/rendering tests

• Component with violation.formattedLimit = undefined should show Receipt required (not $25.00).
• Component with violation.formattedLimit = '$40.00' should show over $40.00.

3. Integration / E2E scenario

• Simulate initial absence of policy in Onyx and ensure no $25.00 is shown.
• Inject policy and confirm the correct value replaces the placeholder.

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[melvin-bot]

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

[rojiphil]

Also, we have another issue that causes the unmatch between FE and BE is about the currency symbol.

The FE is showing "AMD 25.25" while the backend returns "դր25.25" (using the Armenian Dram symbol)

@lorretheboy Seems like another issue with another root cause but I was not able to reproduce this. Can you please share a video with the steps to reproduce?

[lorretheboy]

Hi @rojiphil, here is the recording for that issue. Please note, during testing, you should use currency that has local symbol such as AMD

Screen.Recording.2025-09-03.at.14.45.33.mov