Expense - Amount field is 0.00 by default

[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.3.88-1
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #87920
Email or phone of affected tester (no customers): sdjsodnjiodsjsoinj1@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Run Onyx.merge('betas', ['newManualExpenseFlow']); in console.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Click + > Create expense > Manual.

Expected Result:

Amount field will be empty by default.

Actual Result:

Amount field is 0.00 by default.
User will need to clear the input to enter amount.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7165461_1779985662192.17.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7165461

[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/0dcd8d627aa0a82115b3dfe8f22ca7f4d180d9c8502f6d3df71b6cfd736d62f8

[melvin-bot]

@puneetlath recently merged #87920, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @MonilBhavsar (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

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

In the new manual expense flow (newManualExpenseFlow beta), starting a manual expense from a workspace chat composer (+ → Create expense → Manual) renders the inline Amount field pre-filled with 0.00 instead of leaving it empty. The user must clear the input before they can type a real amount.

The behavior was introduced by PR #87920 (merged 2026-05-13), which refactored the manual expense flow to render the confirmation page inline and added an "empty by default" rule for the amount field. The rule fires off the wrong state and gets locked in by the input component.

What is the root cause of that problem?

Two-part race that locks "0.00" into the visible input.

Part 1 — empty-amount predicate flips false → true after first render. In AmountField.tsx:115-116 the field is empty only when:

const shouldShowEmptyAmount =
    isNewManualExpenseFlowEnabled &&
    !transactionSlice?.isAmountSet &&
    transactionSlice?.iouRequestType === CONST.IOU.REQUEST_TYPE.MANUAL;
const transactionAmount = shouldShowEmptyAmount ? '' : convertToFrontendAmountAsString(amount, decimals);

When the user picks + → Create expense from the workspace chat composer (AttachmentPickerWithMenuItems.tsx:239), startMoneyRequest(SUBMIT, reportID, draftTransactionIDs) clears the optimistic draft and navigates to IOURequestStartPage. With the beta on, the Manual tab renders IOURequestStepConfirmation directly (IOURequestStartPage.tsx:248-256). The transaction's iouRequestType is set to MANUAL later, asynchronously, by useResetIOUType's useFocusEffect calling initMoneyRequest (useResetIOUType.ts:89-105).

On the first render(s), transactionSlice?.iouRequestType is undefined, so shouldShowEmptyAmount === false and transactionAmount = convertToFrontendAmountAsString(0, 2) = "0.00".

Part 2 — NumberWithSymbolForm ignores subsequent value prop changes. NumberWithSymbolForm.tsx:210 seeds internal state from the prop exactly once:

const [currentNumber, setCurrentNumber] = useState(typeof number === 'string' ? number : '');

There is no useEffect that syncs currentNumber when the value prop later changes. Once Onyx writes iouRequestType: MANUAL and AmountField re-renders with transactionAmount = '', the rendered TextInput value={formattedNumber} (line 493) is derived from the now-stale currentNumber = "0.00", so the field stays at 0.00.

The FAB flow (ExpenseMenuItem.tsx:34) hits the same logic and is also at risk; the workspace-chat path is the one Applause caught.

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

Fix Part 1 at the source so the input never renders 0.00 on first paint. The predicate currently treats "iouRequestType not yet MANUAL" as "show the formatted amount," but for the new manual flow it should treat the absence of a user-set amount as empty regardless of whether iouRequestType has been populated yet.

In AmountField.tsx:115, relax the guard to no longer require iouRequestType === MANUAL — the field is only mounted in the new manual flow branch when isNewManualExpenseFlowEnabled && !isAmountFieldDisabled (lines 276 onward), and isAmountFieldDisabled already excludes distance/time. The scan flow programmatically sets the amount and toggles isAmountSet, so !isAmountSet is sufficient:

const shouldShowEmptyAmount = isNewManualExpenseFlowEnabled && !transactionSlice?.isAmountSet;

This also matches the comment on lines 111-114 which describes the intent as "amount field starts empty… until the user explicitly sets an amount."

As a defense-in-depth, also fix Part 2 by adding a useEffect in NumberWithSymbolForm that syncs currentNumber when the value prop changes and the input is not focused (avoid clobbering the user's typing). That prevents this same class of bug from recurring elsewhere.

What alternative solutions did you explore? (Optional)

• Synchronously initialize the draft. Call initMoneyRequest before navigating in startMoneyRequest so iouRequestType: MANUAL is on the draft before AmountField mounts. More invasive and risks breaking the existing tab-driven useResetIOUType flow that depends on transitioning from "no type" to a chosen type.
• Guard the AmountField render until transaction?.iouRequestType is set. Hides the issue but introduces a visible loading flash and doesn't address the NumberWithSymbolForm desync.
• Revert PR Feat: Manual expense flow UI refactor - r3 #87920. Heaviest option; the PR delivered the entire UI refactor, so a revert is disproportionate to a focused predicate fix.

Likely related open issues from a quick scan

• #90681 — "Unable to submit expense with 0.00 to self DM when created from FAB" (same PR, related amount-validation logic)
• #90648 — "Confirm page loads infinitely after switching from Scan to Manual tab" (same PR)
• #90652 — "Manual tab shows scan confirm page after uploading receipt on Scan and returning to Manual" (same PR)

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92005) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.