[$250] New expenses added to already submitted (outstanding) report

[m-natarajan]

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.33-5
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
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: @marianaabussamra
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Create an expense as employee in a workspace configured with delay submission
2. Wait for the expense to submit
3. While in the Outstanding status, waiting for their approver to approve the report, create new expenses in same workspace

Expected Result:

Since the report was submitted, it should include only expenses incurred up to that date. New expenses should be added to a new/existing Draft report

Actual Result:

New expenses are currently being added to the Outstanding report

Workaround:

Unknown

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

The screenshots for the issue are in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @nyomanjyotisa

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022032136862851117575
• Upwork Job ID: 2032136862851117575
• Last Price Increase: 2026-03-12

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[MelvinBot]

Proposal

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

When a workspace has delay submission enabled, after a report is auto-submitted and enters the "Outstanding" (Processing) status, new expenses created by the employee are incorrectly added to the already-submitted Outstanding report instead of being placed into a new Draft report.

What is the root cause of that problem?

The root cause is in canAddOrDeleteTransactions() at src/libs/ReportUtils.ts:2818-2819. This function explicitly allows adding transactions to Processing (Outstanding) expense reports when isAwaitingFirstLevelApproval() returns true:

if (isProcessingReport(moneyRequestReport) && isExpenseReport(moneyRequestReport)) {
    return isAwaitingFirstLevelApproval(moneyRequestReport);
}

When the backend's harvesting job auto-submits a report via delay submission, the report transitions to stateNum=SUBMITTED, statusNum=SUBMITTED (Outstanding/Processing). The report's managerID is set to the first-level approver. Since isAwaitingFirstLevelApproval() checks whether managerID === submitsToAccountID, it returns true for these auto-submitted reports.

The full chain:

1. chatReport.iouReportID still points to the now-submitted report
2. shouldCreateNewMoneyRequestReport() (src/libs/ReportUtils.ts:11060-11063) checks !canAddTransaction(existingIOUReport) — since canAddTransaction returns true for the Outstanding report, this condition is false
3. No new report is created, and the expense is added to the Outstanding report

A secondary contributing factor: when the backend auto-submits a report, chatReport.iouReportID may not be cleared to null. The client-side submitReport function (src/libs/actions/IOU/index.ts:10866) does set iouReportID: null, but for backend-triggered auto-submit (delay submission), this client-side code doesn't run.

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

The fix should be in canAddOrDeleteTransactions() or shouldCreateNewMoneyRequestReport() in src/libs/ReportUtils.ts. The approach should differentiate between:

• Instant submit policies: Adding to a Processing report at first-level approval may be intentional (the report was auto-submitted immediately, and the user might want to continue adding expenses)
• Delay submission policies: A report that was auto-submitted by the backend harvesting job should be considered "frozen" — new expenses should go to a new Draft report

In shouldCreateNewMoneyRequestReport(), add a check: if the existing report is in Processing state AND the policy uses delay submission (isDelayedSubmissionEnabled(policy) from PolicyUtils.ts:839), force creation of a new report regardless of canAddTransaction.

Additionally, the backend auto-submit path should ideally send an Onyx update that clears chatReport.iouReportID to null, similar to what the client-side submitReport does. This would be a backend change in the harvesting job.

What alternative solutions did you explore? (Optional)

1. Modify canAddOrDeleteTransactions directly: Add a policy check so it returns false for Processing reports when the policy uses delay submission. Downside: this function is used in many places (including UI for showing/hiding buttons), and changing its behavior could have broader side effects.

2. Clear iouReportID on the backend only: Ensure the backend sends iouReportID: null when auto-submitting. This would fix the pointer issue but wouldn't fix the case where existingIOUReport is explicitly passed (e.g., from the move-expenses flow).

3. Modify shouldCreateNewMoneyRequestReport only (recommended): This is the most targeted fix since it only affects the decision of whether to create a new report during expense creation, without changing the broader canAddTransaction behavior that affects other parts of the app.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[shivang-goliyan]

Proposal

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

When a workspace uses delay submission (weekly, monthly, etc.), the backend harvesting job auto-submits the report and it enters Processing/Outstanding status. If the employee then creates new expenses in that workspace, those expenses get added to the already-submitted report instead of going into a new Draft report.

What is the root cause of that problem?

The issue is in canAddTransaction() at src/libs/ReportUtils.ts (line 2837). When a new expense is created, the chain goes: getMoneyRequestInformation() → shouldCreateNewMoneyRequestReport() (line 11063) → !canAddTransaction(existingReport). This calls into canAddOrDeleteTransactions() at line 2818-2819, which returns isAwaitingFirstLevelApproval(report) for any Processing expense report — returning true because managerID === submitsToAccountID.

The problem is this check was written for instant-submit policies, where adding to a Processing report is intentional. For delay-submission policies, once the harvesting job submits the report, the reporting period is over and the report should be frozen. The code doesn't distinguish between these two cases.

A secondary factor: the backend harvesting path doesn't clear chatReport.iouReportID the way client-side submitReport() does at IOU/index.ts:10866, so the client still points at the now-frozen report. But even fixing that alone wouldn't help — canAddTransaction would still say "yes, add to it."

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

Add a delay-submission guard in canAddTransaction() after line 2848, before the existing isInstantSubmitEnabled block at line 2850:

if (isProcessingReport(moneyRequestReport) && isExpenseReport(moneyRequestReport) && isDelayedSubmissionEnabled(policy)) {
    return false;
}

policy is already fetched at line 2844. We'd add isDelayedSubmissionEnabled to the PolicyUtils import at line 151. This follows the exact same pattern as the isInstantSubmitEnabled(policy) && isSubmitAndClose(policy) guard at lines 2850-2857 — a policy-aware check in canAddTransaction that blocks additions under specific submission configurations.

This propagates cleanly: shouldCreateNewMoneyRequestReport returns true via !canAddTransaction(), a new Draft report gets created, and UI buttons relying on canAddTransaction correctly hide for the Outstanding report. canDeleteTransaction is unaffected since it calls canAddOrDeleteTransactions directly, bypassing canAddTransaction — so users can still delete/move expenses from the frozen report.

A regression test should be added to tests/unit/ReportUtilsTest.ts (around line 7163) for the delay-submission + Processing report scenario, since no existing test covers this path.

What alternative solutions did you explore? (Optional)

Fixing in shouldCreateNewMoneyRequestReport alone (adding a delay-submission check there) would handle the "which report" decision but wouldn't update UI — add-expense buttons would still show on the Outstanding report, and the move-expenses flow (IOURequestEditReportCommon.tsx:136) would still allow moving transactions into a frozen report.

Fixing in canAddOrDeleteTransactions would be too broad — it would also block deleting transactions from Processing reports under delay submission, which users should still be able to do.

Fixing in isAwaitingFirstLevelApproval is risky since it's used in 6+ places for approval badge visibility, report action display, and workflow routing.