[Submit] Creating a new expense creates new report even when an existing draft report exists

[garrettmknight]

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:
Reproducible in staging?:
Reproducible in production?:
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by:
Slack conversation (hyperlinked to channel name):

Action Performed:

1. Sign up for an account
2. Add it to the Submit2026 beta
3. Switch to Classic
4. Navigate to expensify.com/pricing
5. Create a Submit workspace
6. Got to Spend > Create expense (or Global Create > Create expense)
7. Creates a new report in the Draft state
8. Create another expense from Spend or GC, select the Submit workspace

Expected Result:

The second expense should have landed on the existing Draft report

Actual Result:

The second expense created an additional Draft report when one already existed

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @hungvu193

[MelvinBot]

Proposal

What is the root cause of that problem?

canAddTransaction() gates whether an existing expense report can receive additional transactions. For Submit-type policy reports it always returns false, because the check at ReportUtils.ts:2789 requires the policy to satisfy isPaidGroupPolicy, which only returns true for TEAM or CORPORATE — Submit (POLICY.TYPE.SUBMIT) is excluded.

That false propagates into shouldCreateNewMoneyRequestReport(): once !canAddTransaction(existingIOUReport) is true, it returns true, which forces the expense builder at MoneyRequestBuilder.ts:1321-1345 to build a brand-new optimistic expense report instead of reusing the existing Draft.

Step-by-step evidence

1. 1st expense on the Submit workspace: there is no existing iouReport, so a new optimistic Open/Open Draft report is built and chatReport.iouReportID is written back at MoneyRequestBuilder.ts:548.
2. 2nd expense: STEP 1 at MoneyRequestBuilder.ts:1290-1296 finds the same policyExpenseChat. STEP 2 at MoneyRequestBuilder.ts:1315-1317 successfully reads the existing Draft via chatReport.iouReportID — so the lookup itself works.
3. ReportUtils.ts:11129-11148 then calls canAddTransaction(existingIOUReport).
4. Inside canAddTransaction, isExpenseReport = true, isCurrentUserSubmitter = true, but isPaidGroupPolicy(policy) = false (Submit isn't TEAM/CORPORATE), so it returns false.
5. shouldCreateNewMoneyRequestReport returns true, and MoneyRequestBuilder.ts:1329 takes the build-new-report branch.

Note: the helper isGroupPolicy() in PolicyUtils.ts already exists for exactly this case — its doc comment explicitly says "use this helper when Submit workspaces should be treated like paid workspaces." canAddTransaction simply wasn't updated when Submit2026 was introduced. There's also a pre-existing TODO comment at ReportUtils.ts:2786 acknowledging this function needs revisiting.

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

Replace the isPaidGroupPolicy(policy) check inside canAddTransaction() at ReportUtils.ts:2789 with isGroupPolicy(policy) (the PolicyUtils.ts variant), which already treats Submit and paid (Team/Corporate) workspaces uniformly. Add isGroupPolicy to the existing PolicyUtils import block at the top of ReportUtils.ts (aliased to avoid collision with the same-named string predicate in ReportUtils).

This is a one-line behavioral change plus a one-line import edit. It allows a Draft expense report on a Submit workspace to accept additional transactions, so the second (and Nth) expense lands on the existing Draft rather than spawning a duplicate.

What alternative solutions did you explore? (Optional)

Adding a Submit-specific branch (!isPaidGroupPolicy(policy) && !isSubmitPolicy(policy)) works too, but it's less idiomatic than reusing the helper that was purpose-built for this. A broader audit of other isPaidGroupPolicy-only checks (e.g., shouldBeManuallySubmitted) may surface adjacent Submit2026 regressions, but those are out of scope here.

Related issues found in a quick scan

• Expensify/App#91991 — [Submit] Unnecessary workspace selection on report creation. Same Submit2026 surface area, different symptom.

---

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