[Due for payment 2026-07-13] [$250] Expense - Distance expense can be created when date is removed

[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?: No
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): joisjdnosjdoijso@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:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Open FAB > Track distance > Manual.
4. Enter amount > Next.
5. Click X on Date field to remove the date.
6. Click Create expense.

Expected Result:

Error will show up on Date field. Expense will not be created until date is entered.

Actual Result:

Distance expense can be created when date is removed.
This issue also happens with Time expense and invoice.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188072_1782170669745.4.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022071549017445353510
• Upwork Job ID: 2071549017445353510
• Last Price Increase: 2026-06-29
• Automatic offers:
• thelullabyy | Reviewer | 111860156

[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/16799c79a3c0aabc18359ba19ecb4f0bfc9defdc0fcec0044e1ae8b7c032ea84

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

Proposal

What is the root cause of that problem?

The confirmation-step date validation only blocks creation for manual expenses. In useConfirmationValidation.ts:188 the "date is missing" guard is gated on iouRequestType === CONST.IOU.REQUEST_TYPE.MANUAL:

if (transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.MANUAL && isCreatedMissing(transaction)) {
    return {errorKey: 'common.error.fieldRequired'};
}

Distance and time expenses have different request types — distance / distance-manual and time (CONST REQUEST_TYPE) — so this guard is skipped and the expense is created with an empty date. Meanwhile the DateField is rendered as an inline, clearable DatePicker for all IOU types, so the user can remove the date on distance/time/invoice flows where nothing validates it.

This was newly exposed by PR #94134 (the flagged regression). That PR removed the isNewManualExpenseFlowEnabled beta, making the inline date field the default for everyone — but it kept the pre-existing MANUAL-only gate on the date check, so distance/time/invoice now show a removable date field with no matching validation. That's why it reproduces on staging but not production (where the beta was off).

Evidence chain

• isCreatedMissing returns true when created is empty: TransactionUtils/index.ts:547.
• The inline date error only surfaces when formError === 'common.error.fieldRequired' (DateField.tsx:60), which is exactly the error the validation skips for non-manual types.
• PR feat: remove isNewManualExpenseFlowEnabled beta flag #94134 diff for this file removed only the beta flag, leaving the MANUAL request-type condition intact.

Alternative considered: A race where created is cleared after validation — ruled out; the guard is simply never reached for non-MANUAL request types, which deterministically matches "distance, time, and invoice" all failing while plain manual works.

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

Broaden the date-missing guard so it applies wherever the date is shown as an inline required field — i.e. for distance and time requests (and invoice), not just MANUAL. Concretely, drop the iouRequestType === MANUAL restriction on the isCreatedMissing check at line 188 (or extend it to include the DISTANCE* and TIME request types) so a missing date returns common.error.fieldRequired for those flows too.

Care should be taken not to block scan flows where the date is populated server-side after SmartScan — that path is read-only rather than inline-editable, so keying the check off the inline-editable date field (not MANUAL only) is the safest scope.

What alternative solutions did you explore? (Optional)

Gate the check on whether the DateField is rendered inline/editable (!isReadOnly) rather than enumerating request types, so validation and UI stay in sync automatically.

---

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