[Due for payment 2026-07-03] [$250] [Due for payment 2026-07-01] [Due for payment 2026-06-30] Expense - "This field is required", seen twice if trying to submit expense without 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.17-0
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: #94134
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Money Requests

Action Performed:

1. Open the staging.new.expensify.com website.
2. Click on FAB > "Create Expense"
3. Click on "Create Expense" without adding an amount.
4. Note that "This field is required" error, appears below amount field and also at the bottom of RHP.

Expected Result:

After trying to submit an expense without amount, the "This field is required" error should only appear below the missing field.

Actual Result:

After trying to submit an expense without amount, "This field is required" error appears below "Amount" field and also at the bottom of RHP.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188099_1782172277391.Required.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022070032016717629478
• Upwork Job ID: 2070032016717629478
• Last Price Increase: 2026-06-25
• Automatic offers:
• thelullabyy | Reviewer | 111824734

[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/c5997aa7f0be5ab6259af5094b6e6b0ddcff03c67551ff72d17149f44801b05e

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #94134

[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]

Issue Analysis

Root Cause: A single formError state (common.error.fieldRequired) is rendered in two independent places on empty-amount submit, and the footer path is missing the inline-duplicate suppression that already exists for other fields.

1. Inline (below the Amount field) — AmountField.tsx:96-104 sets amountFieldErrorText from formError === 'common.error.fieldRequired' and renders it on the input via errorText.
2. Footer (bottom of the RHP) — ConfirmationFooterContent.tsx:147-153 renders a FormHelpMessage from errorMessage, which is computed in useFormErrorManagement.ts:220-236.

computeErrorMessage() already returns undefined for violations.missingAttendees and iou.error.invalidTaxAmount "because the field surfaces it inline" — but it has no equivalent guard for common.error.fieldRequired / common.error.invalidAmount, even though the Amount field (and Date field) now surface those inline in the new manual flow. So both fire → the error shows twice.

This surfaced because PR #94134 (feat: remove isNewManualExpenseFlowEnabled beta flag) enabled the new manual-entry flow where the amount/date are inline required fields with their own inline error text — the inline surface is new; the footer FormHelpMessage predates it.

Recommended Fix: In computeErrorMessage() (useFormErrorManagement.ts:227-235), add a guard mirroring the existing missingAttendees/invalidTaxAmount suppressions, so the manual-flow errors that are already shown inline aren't repeated in the footer:

// The amount/date fields surface these required/invalid errors inline in the manual flow, so skip the footer.
if (
    transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.MANUAL &&
    (formError === 'common.error.fieldRequired' || formError === 'common.error.invalidAmount')
) {
    return undefined;
}

transaction is already a hook param and CONST is already imported, so no new props are needed. This keeps the field-level error (the desired UX per the issue's Expected Result) and removes the duplicate footer message.

Investigation details & data flow

On empty-amount submit (manual expense):

1. useConfirmationValidation.ts:173-175 → MANUAL && !isAmountSet returns {errorKey: 'common.error.fieldRequired'}.
2. The confirm handler sets this single formError state.
3. formError flows two ways:
   • → AmountField inline errorText → error site 1 (below field).
   • → useFormErrorManagement errorMessage → ConfirmationFooterContent FormHelpMessage → error site 2 (footer).

Why the guard covers all manual cases: the only manual-flow producers of these keys are amount-required (!isAmountSet, shown by AmountField), invalid-amount (shown by AmountField via shouldShowAmountInvalidError), and date-required (isCreatedMissing at useConfirmationValidation.ts:188-190, shown inline by the Date field). Each has an inline surface, so suppressing them at the footer never leaves the user without feedback. Non-manual flows (scan/distance/per diem/split) are unaffected by the iouRequestType === MANUAL check and keep their footer message.

Confidence: High — both render sites and the validation source were confirmed by reading the code at the referenced lines; the suppression pattern already exists in the same function for two other fields.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[trjExpensify]

I was trying to check this out on prod. The closest I can get in that flow is merchant, which we handle like so:

... because with amount you need to enter an amount to dismiss or save an edit on the BNP.

So we could follow merchant and put "Please enter a valid amount" like we do there in the footer, instead of doubling up on the message. That said, what happens if both merchant and amount are missing? It seems better if we just put these in-line the Merchant and Amount form fields only instead and drop that footer one completely. What do you think, @puneetlath?