[Due for payment 2026-09-15] [$250] Outstanding report can be selected on confirm page, but expense is created in another report

[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.99-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92230
Email or phone of affected tester (no customers): sdoidjosjnijdsoj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
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. Create an expense and click Submit on the expense preview. Rename this report to A.
4. Create an empty report. Rename this report to B.
5. Click + > Create expense > Manual.
6. Enter amount > Next.
7. On confirm page, click Report.
8. Select the outstanding report A from Step 3.
9. Click Create expense.

Expected Result:

The new expense will be created in the selected outstanding report (report A)

Actual Result:

The new expense is not created in the selected outstanding report. It is created in the draft report (report B) from Step 4.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7171609_1780583207113.11.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022062549125297439759
• Upwork Job ID: 2062549125297439759
• Last Price Increase: 2026-08-20

Issue Owner

Current Issue Owner: @mallenexpensify

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

[MelvinBot]

Proposal

Posted by MelvinBot 🤖 — automated root-cause analysis (confidence: medium-high). The full mechanism is traced in code; the one runtime assumption is called out at the end.

What is the root cause of that problem?

The report picker on the confirm page offers submitted/outstanding reports as selectable options, but the submit path silently discards the selection when the chosen report is already submitted — and then falls back to the workspace chat's most-recently-created report (Report B).

Step by step:

1. Selecting Report A on the confirm page correctly writes it to transaction.reportID via setTransactionReport (useReportSelectionActions.ts:181-188).
2. At submit time, resolveReportForMoneyRequest re-validates the picked report with isReportOutstanding(..., allowSubmitted=false). Report A is SUBMITTED, so this returns false, the selection is dropped, and the function returns undefined.
3. With no report, the create builder falls back to chatReport.iouReportID (MoneyRequestBuilder.ts:1318-1327).
4. That pointer is Report B, because creating Report B in step 4 of the repro overwrote the chat's iouReportID to the newest report (Report/index.ts:4047-4051).

The core inconsistency: the picker lists SUBMITTED reports (built with allowSubmitted=true), but the submit resolver rejects them (allowSubmitted=false). So the UI lets you pick a report the create flow refuses to honor, and it quietly routes the expense elsewhere instead of using your choice.

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

Make the submit path honor the user's explicit report selection. Concretely, in resolveReportForMoneyRequest: when transaction.reportID points at a report the user explicitly picked (i.e. it's a real expense report in the available list and passes canAddTransaction), return that report instead of undefined — even if it's SUBMITTED. This stops the fallback to chatReport.iouReportID and creates the expense in the selected report.

The picker and the resolver must use the same outstanding-report criteria. If a SUBMITTED report genuinely can't receive new expenses for a given policy, it should not appear in the picker in the first place; if it can be selected, the resolver must respect it.

Investigation details & evidence

Selection write (correct): useReportSelectionActions.ts:181-188 writes transaction.reportID = A. Note the participant's reportID stays pointed at the workspace chat (L109-117), which is by design.

Resolver drops the pick: IOUUtils.ts:490-514 — canUseTransactionReport = !(isProcessingReport(transactionReport) && !policy?.harvesting?.enabled) && isReportOutstanding(transactionReport, ..., false). For a SUBMITTED Report A with delayed submission off, this is false; since transaction.reportID !== routeReport.reportID (route report is the chat), it returns undefined.

isReportOutstanding strictness: ReportUtils.ts:11567-11595 — allowSubmitted=false excludes anything stateNum >= SUBMITTED.

Fallback to chat's iouReportID: MoneyRequestBuilder.ts:1318-1327. The confirm flow passes no existingIOUReport and report=undefined (useExpenseSubmission.ts:331,383-385, TrackExpense.ts:1654-1656), so it falls through to chatReport.iouReportID.

Why that pointer is Report B: Report/index.ts:4047-4051 overwrites the parent chat's iouReportID to the new report on every createNewReport. The design rule is documented at ReportWorkflow.ts:760-766 ("the report created later will become the iouReportID of the chat report").

Not a regression from PR #92230: that PR only refactored how ReportField reads its data (prop-drill → selector); the press handler and setTransactionReport path are unchanged, and the bug reproduces in production (which doesn't yet have #92230). #92230 is just where QA caught it.

One runtime assumption: the analysis assumes policy.harvesting.enabled (delayed submission) is off, which is the default and matches the repro. If delayed submission were on, resolveReportForMoneyRequest would return Report A and the bug would not trigger via this path.

Possibly related issues

• [Due for payment 2026-06-02] When there are open reports, Confirm page shows wrong report, double confirm page opens #90677 — "When there are open reports, Confirm page shows wrong report" (same iouReportID / report-resolution subsystem).
• [$250] New expenses added to already submitted (outstanding) report #85113 — "New expenses added to already submitted (outstanding) report".
• [Due for payment 2026-06-24] [$250] Admin unable to add unreported credit card transactions to a cardholder's existing report in NewDot without opening the report first #92519 — "Unable to add unreported credit card transactions to an existing report".

---

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

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-08-04 08:39:16 UTC.

Proposal

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

On the confirmation page the user explicitly selects the outstanding report A in the Report field, but the expense is created in the empty report B instead of A.

What is the root cause of that problem?

The report picker and the report resolver use two different predicates to answer the same question — "can this report receive the expense?" — and they disagree by exactly one guard.

The picker (both the Report field and the selection page) offers a report when isReportOutstanding(report, policyID, rnvp, /* allowSubmitted */ false) is true:

• ReportField.tsx#L80 and #L84
• IOURequestEditReportCommon.tsx#L136 with isEditing = false in the create flow (DynamicIOURequestStepReport.tsx#L71)

With allowSubmitted = false, isReportOutstanding still accepts a submitted report when canAddTransaction(iouReport, false, false) is true, which for a processing expense report reduces to isAwaitingFirstLevelApproval. Report A from step 3 is exactly that: submitted, owned by the current user, still awaiting first-level approval — so it is listed, and selecting it writes reportID: A into the draft transaction (useReportSelectionActions.ts#L148 / #L195).

The resolver, used at submit time (IOURequestStepConfirmation.tsx#L186-L195), adds one guard on top of the picker's rule — IOUUtils.ts#L565:

const canUseTransactionReport = !(isProcessingReport(transactionReport) && !policy?.harvesting?.enabled) && isReportOutstanding(transactionReport, policy?.id, undefined, false);

A is processing and the workspace has scheduled submit off (harvesting.enabled is false/absent), so canUseTransactionReport is false; routeReport exists, so shouldUseTransactionReport is false; the picked report differs from the route report, so the resolver returns undefined.

undefined then silently degrades into "whatever report the workspace chat currently points at": moneyRequestReportID becomes '' (useExpenseSubmission.ts#L240, TrackExpense.ts#L1697), and getMoneyRequestInformation falls back to chatReport.iouReportID — the most recently created report on that workspace chat, i.e. the empty report B from step 4. That is the reported symptom.

So the harvesting term is the whole bug: it is the only condition that rejects a report the picker itself offered, and it keys the decision on a policy setting (harvesting.enabled, which is also undefined whenever the policy isn't fully loaded) instead of on whether the report can actually take a transaction. It was added in 17647a0 with the comment "if the report was submitted and delayed submission is on, then we should use an initial report", i.e. the implemented polarity doesn't even match the stated intent.

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

In src/libs/IOUUtils.ts#L565, make the resolver use exactly the picker's predicate — nothing more, nothing less:

-    const canUseTransactionReport = !(isProcessingReport(transactionReport) && !policy?.harvesting?.enabled) && isReportOutstanding(transactionReport, policy?.id, undefined, false);
+    const canUseTransactionReport = isReportOutstanding(transactionReport, policy?.id, undefined, false);

(and drop the now-unused isProcessingReport import in IOUUtils.ts).

Now the explicitly picked report A is usable, requestMoneyIOUActions receives report = A, moneyRequestReportID = A.reportID, and the expense is created in A.

Why this exact scope, addressing each risk raised in this comment:

1. Nothing is loosened beyond the picker. allowSubmitted stays false, so isReportOutstanding still enforces the policy-ID match, isForwardedReport, archived-report and stateNum/statusNum bounds, and routes submitted reports through canAddTransaction.
2. The outer canAddTransaction gate must go — it isn't just redundant, it re-creates the same class of bug. The submitted branch of isReportOutstanding is allowSubmitted || isProcessingReport(activeReport) || canAddTransaction(iouReport, false, false). Adding an outer canAddTransaction would make the resolver stricter than the picker in the isProcessingReport(activeReport) case (creating an expense while the active route report is itself processing): the picker would offer the report and the resolver would drop it — this bug again, in a different configuration.
3. The creation layer keeps its own guard. Even with the resolver returning A, getMoneyRequestInformation re-checks the destination via shouldCreateNewMoneyRequestReport → !canAddTransaction(existingIOUReport) (call site). A report that genuinely cannot accept transactions still gets a fresh optimistic report — the fix cannot write an expense into an approved/settled/closed report.
4. No new return shape. The resolver already returns expense reports on this branch (for open outstanding picks); only the accepted set widens to the submitted-but-addable reports the picker already lists, so downstream consumers are unaffected.
5. Same one-line fix also covers the share-sheet flow, which uses the same helper: SubmitDetailsPage.tsx#L264.

Tests (I ran these locally against main at 78342c60f29):

• Added a unit test in tests/unit/IOUUtilsTest.ts: a submitted report owned by the current user on a group policy, awaiting first-level approval, with a different routeReport and harvesting: {enabled: false} → the resolver must return that report. It fails before the change (Expected "500", received undefined) and passes after it.
• Regression test in the same block: for a submitted report that is not addable (not the submitter / approved / reimbursed / forwarded), the resolver must still return undefined — verified passing with the fix.
• The existing returns undefined when the picked report is processing and policy harvesting is disabled test keeps passing (its fixture report isn't addable, so isReportOutstanding rejects it on its own) — worth renaming to reflect what it actually asserts. The whole IOUUtilsTest suite passes (103/103).
• Manual: the repro steps → expense created in A; plus regressions on a scheduled-submit-enabled workspace, an open outstanding report, "New report", "Unreported", and the create-from-chat flow.

What alternative solutions did you explore? (Optional)

• Keep the guard and only flip the polarity (isProcessingReport(transactionReport) && policy?.harvesting?.enabled): it fixes this repro, but the picker/resolver mismatch simply moves to workspaces with scheduled submit on — the exact same bug there. A report the user explicitly picked shouldn't be discarded based on a harvesting setting; whether it can take the expense is what canAddTransaction already answers.
• Filter submitted reports out of the picker instead: this also makes the two consistent, but it removes a legitimate destination (A can accept the expense) and contradicts the Expected Result of this issue.
• Fix the chatReport.iouReportID fallback in getMoneyRequestInformation: by that point the user's selection is already lost (moneyRequestReportID is ''), so it is the wrong layer; it would also change the destination for every flow that legitimately relies on that fallback.
• Pass reportNameValuePairs into the resolver's isReportOutstanding call for literal parity with the picker: the current undefined falls back to the module-level collection and is equivalent today; happy to thread it through if preferred.

[kamronbek04]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-08-03 20:08:57 UTC.

Proposal

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

When creating an expense from global create and explicitly picking an outstanding report A (which is already submitted) in the confirm page's Report field, the expense is not created in A. It lands in the empty report B that was created just before, so the explicit pick is silently ignored.

What is the root cause of that problem?

The confirm page resolves its destination report with resolveReportForMoneyRequest. Picking A correctly writes transaction.reportID = A.reportID, but the resolver drops it because of the extra processing-guard on the canUseTransactionReport line:

const canUseTransactionReport = !(isProcessingReport(transactionReport) && !policy?.harvesting?.enabled) && isReportOutstanding(transactionReport, policy?.id, undefined, false);

With A submitted and harvesting off, !(isProcessingReport(A) && !false) = false, so canUseTransactionReport is false — even though isReportOutstanding(A, …, false) on the same line already returned true (A is a submitter-owned, first-level-approval report that canAddTransaction admits). shouldUseTransactionReport is then false, the picked report differs from the route report (the workspace chat), so the resolver returns undefined. Downstream, getMoneyRequestInformation falls back to chatReport.iouReportID, which is the most-recently-created report B.

The deeper problem is a picker/resolver mismatch. The confirm-page Report picker offers A using exactly isReportOutstanding(report, policyID, rnvp, allowSubmitted = false) (useOutstandingReports(..., isEditing = false)). The resolver then re-decides usability with a different rule — the extra isProcessingReport && !harvesting override — and throws away the report the picker just offered. That override, keyed on policy.harvesting.enabled, is something the picker never consults.

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

Make the resolver decide usability with the same predicate the picker uses — nothing looser, nothing extra. In src/libs/IOUUtils.ts#L565:

const canUseTransactionReport = isReportOutstanding(transactionReport, policy?.id, undefined, false);

isProcessingReport becomes unused in this file, so drop it from the import.

Why this is the right gate and stays regression-free:

• allowSubmitted stays false — the resolver keeps the picker's exact strictness. A submitted report is only admitted through isReportOutstanding's internal canAddTransaction branch, so a non-addable submitted report (approved/closed, instant-submit-and-close, not the submitter) is still rejected and falls through to a new optimistic report — unchanged from today.
• isReportOutstanding is the whole gate, not a redundant partner to canAddTransaction — it already enforces the policy match, isExpenseReport, not-archived, not-forwarded, and the state/status bounds, and internally consults canAddTransaction for the submitted case. Gating on canAddTransaction in addition would double-check the addable branch while dropping those other bounds, so isReportOutstanding(…, false) alone is both sufficient and complete.
• The removed term was the actual bug — it's the only clause that disagreed with the picker, and it's what discarded an already-offered, addable report when harvesting is off.

With this, picking the submitted-but-addable A makes canUseTransactionReport true, shouldUseTransactionReport true, and the resolver returns A — so the expense is created in A.

What specific scenarios should we cover in automated tests to prevent regressions?

Unit tests on resolveReportForMoneyRequest:

• transactionReport = submitted, submitter-owned, first-level-approval report on a group policy without harvesting; routeReport = the workspace chat; transaction.reportID = the submitted report's ID → resolver returns the submitted report (the repro; would return undefined today).
• transactionReport = a non-addable submitted report (approved/closed, or not the submitter) → resolver returns undefined (guards against the picker/resolver gate drifting looser).
• transactionReport = an open outstanding report → still returned (no regression to the pre-existing pass case).
• transaction.reportID === UNREPORTED_REPORT_ID → still returns undefined (Remove-from-report intent preserved).

What alternative solutions did you explore? (Optional)

• Return transactionReport directly in the isTransactionReportDifferentFromRoute branch (my earlier version). This honors the pick but bypasses the outstanding/addable gate, so a stale or non-addable transaction.reportID would be routed there anyway. Gating on the picker's own isReportOutstanding(…, false) is the safer fix and is why I switched to it.
• Drop allowSubmitted and call isReportOutstanding(transactionReport, policy?.id) (default true). This is looser than the picker — allowSubmitted = true admits any submitted report regardless of canAddTransaction, so a non-addable submitted report could become a usable destination. Keeping allowSubmitted = false avoids that.
• Only flip the !policy?.harvesting?.enabled typo (&& policy?.harvesting?.enabled). This also fixes the repro, but it keeps a harvesting-keyed branch the picker never uses, so the picker/resolver mismatch stays latent for the harvesting-on case. Mirroring the picker's single predicate removes the divergence at the source.

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022062549125297439759

[github-actions]

⚠️ @dilshodmackbook-sketch Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.