Expense - Report field shows "None" when submitting track expense to employer.

[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.43-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: #96136
Email or phone of affected tester (no customers): applausetester+ib0024@applause.expensifail.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:

Prerequisite: Use an expensifail account.
Prerequisite 2: Account has Self DM and a workspace.

1. Open the staging.new.expensify.com website.
2. Create a manual expense and submit it to Self DM.
3. Click on "Submit to my employer"
4. On confirm page, scroll down to "Report" field.
5. Note that "None" is visible instead of "New Report"

Expected Result:

While submitting a track expense to employer, report field should show "New Report" in it.

Actual Result:

While submitting a track expense to employer, report field shows "None" instead of "New Report" in it.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7214963

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

[melvin-bot]

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

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

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #96136 - "[Submit] Fix regressions from the "Submit to my employer" flow (#94319)" by @abzokhattab (Medium confidence)
Related Issues: #94319 (original "Submit to my employer" feature, already on production)

Recommendation: ROLL FORWARD (targeted fix)

The "None" text is a cosmetic label in the beta-gated SUBMIT_2026 "Submit to my employer" flow. #96136 is the only PR in this deploy that touches that flow, but it bundles six other regression fixes (Unexpected error, infinite skeleton, rate validation, per diem guard), so reverting would reintroduce worse bugs. A one-line conditional fix in ReportField.tsx is far safer than a revert.

Assigned: @abzokhattab (PR author), @iwiznia, @garrettmknight, @hungvu193 (approving reviewers) from #96136
Labels: No changes. Kept DeployBlockerCash (App deploy blocker — this is a frontend fix). DeployBlocker was not present.

📋 Detailed Analysis

Evidence

• The bug reproduces only on staging, not production, and is gated behind the SUBMIT_2026 beta. The feature itself ([Submit] Update "Submit to someone" to two options to allow for Submit workspace creation #94319) shipped to production earlier and is not in this deploy, so the regression must come from a PR in the current StagingDeployCash (9.4.43).
• Scanning every PR in the 9.4.43 checklist, [Submit] Fix regressions from the "Submit to my employer" flow (#94319) #96136 is the only PR that touches the "Submit to my employer" confirmation path. It modifies src/pages/iou/request/step/IOURequestStepConfirmation.tsx, src/hooks/usePolicyForTransaction.ts, src/libs/ReportUtils.ts (getPolicyName), and src/libs/actions/IOU/TrackExpense.ts — all specific to this flow.
• The BrowserStack regression field / melvin auto-assignment pointing at [Submit] Fix regressions from the "Submit to my employer" flow (#94319) #96136 is consistent with this: it is a genuinely relevant attribution, not a false one.
• Fix Submit plan welcome modal: navigate to existing Submit workspace and remove double bottom safe-area padding #96459 also touches Submit-plan code (SubmitPlanWelcomeModal, useAutoCreateSubmitWorkspace) but does not touch the confirmation Report field or the transaction's report context, so it is not the cause.

Verification

• The "Report" field is rendered by src/components/MoneyRequestConfirmationList/sections/ReportField.tsx.
• Line 74: const isUnreported = transactionReportID === CONST.REPORT.UNREPORTED_REPORT_ID; (UNREPORTED_REPORT_ID === '0', src/CONST/index.ts:1457).
• Lines 110-116, the name resolution:

  const reportName = (() => {
      const name = deprecatedGetReportName(selectedReport, reportAttributes);
      if (!name) {
          return isUnreported ? translate('common.none') : translate('iou.newReport');
      }
      return name;
  })();

  When no report name resolves, it shows "None" if the transaction is unreported and "New report" otherwise.
• ReportField.tsx itself is NOT modified by [Submit] Fix regressions from the "Submit to my employer" flow (#94319) #96136 (last meaningful change was a batch merge on 2026-07-21, unrelated to this deploy). Its logic is correct and unchanged — the field faithfully reports the state of the transaction it is handed.

Root Cause

A tracked expense in the self-DM is unreported (transaction.reportID === '0'). When the user taps "Submit to my employer", the confirmation page opens against that same tracked transaction, whose reportID is still '0'. ReportField therefore computes isUnreported === true, and because the destination is a freshly-created draft workspace whose draft report has no resolvable name yet, deprecatedGetReportName(...) returns empty, so the field falls into the isUnreported ? 'None' branch and renders "None" instead of "New report".

The destination in the "Submit to my employer" flow is a brand-new (draft) report, so the field should render "New report". The report/policy-resolution plumbing for this flow was reworked in #96136 (draft-policy fallback in usePolicyForTransaction, draft-participant policy forwarding in IOURequestStepConfirmation, and the getReportOrDraftReport(... , {}, ...) change that deliberately skips the REPORT_DRAFT fallback for the pre-insert check). That last change in particular means the draft destination report is intentionally not treated as a loaded/renderable report in parts of this flow, which is consistent with ReportField failing to see a named destination report and falling back to the unreported "None" branch.

Suggested targeted fix

In src/components/MoneyRequestConfirmationList/sections/ReportField.tsx, the empty-name fallback should not treat the destination as unreported when the flow is moving a tracked expense into a (draft) workspace. When the confirmation is for the "Submit to my employer" destination (a new draft report), the fallback should resolve to iou.newReport rather than common.none. This is a one-line conditional change and does not require reverting the six fixes in #96136.