[Due for payment 2026-04-14] [$250] Expense - Create new report bypasses restricted action page

[nlemma]

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.50-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #85619
Email or phone of affected tester (no customers): applausetester+ap28@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11
App Component: Other

Action Performed:

• User has at least 2 reports with Per diem expenses in a workspace chat
• User has at least 2 workspaces with per diem enabled
• User has at least 1 workspace with Time feature enabled
• Create a Per Diem expense before applying restriction
• Run:
  Onyx.merge('sharedNVP_private_billingGracePeriodEnd_[accountID]', {value: 1});

1. Open staging.newexpensify.com
2. Navigate to a workspace chat
3. Open the existing Per Diem expense
4. Click on "Move expense"
5. Click on "New report"

Expected Result:

User is redirected to the restricted action page.

Actual Result:

A new report is created instead of showing the restricted action page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7115036_1774639310801.Grabando__536.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022037613276148698186
• Upwork Job ID: 2037613276148698186
• Last Price Increase: 2026-03-27

[MelvinBot]

Proposal

What is the root cause of that problem?

In both IOURequestEditReport.tsx and IOURequestStepReport.tsx, the createReport function has a Per Diem early return that calls handleCreateReport() directly without checking shouldRestrictUserBillableActions().

In IOURequestEditReport.tsx:140-157:

const createReport = () => {
    if (hasPerDiemTransactions) {
        handleCreateReport(); // ← skips restriction check
        return;
    }
    // ... restriction check only reached for non-Per-Diem ...
    if (policyForMovingExpensesID && shouldRestrictUserBillableActions(...)) {
        Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(policyForMovingExpensesID));
        return;
    }
    handleCreateReport();
};

The identical pattern exists in IOURequestStepReport.tsx:261-279 with isPerDiemTransaction instead of hasPerDiemTransactions.

When the expense is a Per Diem, the function returns early on the first condition (line 141/262), so the shouldRestrictUserBillableActions() check on line 152/274 is never reached. This allows Per Diem expenses to be moved to a new report even when the workspace billing grace period restriction is active.

Other flows correctly check restrictions for all expense types — e.g., selecting an existing report in IOURequestEditReportCommon.tsx:228, the FAB create flow in useCreateReportAction.tsx:128-146, and the search bulk-move in SearchTransactionsChangeReport.tsx:140.

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

Add the shouldRestrictUserBillableActions check before the Per Diem early return in both files:

1. IOURequestEditReport.tsx — In the createReport function, add the billing restriction check before the hasPerDiemTransactions early return. Use selectedReport?.policyID as the policy ID (since that's the policy the Per Diem expense belongs to, matching how createReportForPolicy uses selectedReportPolicy for Per Diem at line 122).

2. IOURequestStepReport.tsx — Same change: add the billing restriction check before the isPerDiemTransaction early return. Use perDiemOriginalPolicy?.id as the policy ID (since that's the Per Diem's originating policy, matching how createReportForPolicy uses it at line 249).

What alternative solutions did you explore? (Optional)

An alternative would be to move the restriction check into IOURequestEditReportCommon's handleCreateReport callback so it's applied universally before any createReport call. However, that would change the existing flow for non-Per-Diem expenses and is a larger refactor. The minimal fix of adding the check to the Per Diem early-return paths mirrors the existing pattern and is less risky.

---

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 - @dukenv0307 (External)

[melvin-bot]

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

[trasnake87]

Proposal

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

When a user with an expired billing grace period clicks "Move expense" → "New report" on a Per Diem expense, a new report is created instead of showing the restricted action page.

What is the root cause of that problem?

The real gap is in handleCreateReport inside the shared component IOURequestEditReportCommon.tsx. This is the onPress handler for the "Create report" MenuItem rendered at line 256. It validates Per Diem compatibility but never checks shouldRestrictUserBillableActions. Compare with its sibling handleSelectReport at line 228 which does check restrictions before allowing an existing report to be selected. Both the IOURequestEditReport and IOURequestStepReport pages delegate to this shared component, so fixing it here covers every caller in one place.

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

Add the shouldRestrictUserBillableActions guard to handleCreateReport in IOURequestEditReportCommon.tsx, mirroring what handleSelectReport already does. The component already imports the function (line 21) and subscribes to the required Onyx keys (lines 74–75), so the fix is just adding the check:

const handleCreateReport = useCallback(() => {
    if (policyForMovingExpenses?.id && shouldRestrictUserBillableActions(policyForMovingExpenses.id, userBillingGraceEndPeriods, undefined, ownerBillingGraceEndPeriod)) {
        Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(policyForMovingExpenses.id));
        return;
    }
    if (!validatePerDiemMove(policyForMovingExpenses?.id)) {
        return;
    }
    createReport?.();
}, [validatePerDiemMove, policyForMovingExpenses?.id, createReport, userBillingGraceEndPeriods, ownerBillingGraceEndPeriod]);

This single-file fix is safe because it's the same guard already used two functions above in handleSelectReport, using the same Onyx data already subscribed to, and the server validates billing status on the backend anyway.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[abbasifaizan70]

Proposal

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

When a user moves an existing Per Diem expense and selects New report, billing restriction is not enforced in this flow.

Expected result: user is redirected to the restricted action page when billable actions are restricted.
Actual result: a new report is created instead of navigating to the restricted action page.

What is the root cause of that problem?

In IOURequestStepReport, createReport() returns early for Per Diem transactions by calling handleCreateReport() before checking shouldRestrictUserBillableActions().
The restriction check only runs in the non-Per-Diem branch, so Per Diem can bypass the restricted-action gate.

App/src/pages/iou/request/step/IOURequestStepReport.tsx

Lines 261 to 279 in 2eaa12f

	const createReport = () => {
	if (isPerDiemTransaction) {
	handleCreateReport();
	return;
	}
	if (!isPerDiemTransaction && !policyForMovingExpensesID && !shouldSelectPolicy) {
	return;
	}
	if (shouldSelectPolicy) {
	setSelectedTransactions([transactionID]);
	Navigation.navigate(ROUTES.NEW_REPORT_WORKSPACE_SELECTION.getRoute(true, backTo));
	return;
	}
	if (policyForMovingExpensesID && shouldRestrictUserBillableActions(policyForMovingExpensesID, userBillingGraceEndPeriods, undefined, ownerBillingGraceEndPeriod)) {
	Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(policyForMovingExpensesID));
	return;
	}
	handleCreateReport();
	};

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

App/src/pages/iou/request/step/IOURequestStepReport.tsx

Lines 261 to 279 in 2eaa12f

	const createReport = () => {
	if (isPerDiemTransaction) {
	handleCreateReport();
	return;
	}
	if (!isPerDiemTransaction && !policyForMovingExpensesID && !shouldSelectPolicy) {
	return;
	}
	if (shouldSelectPolicy) {
	setSelectedTransactions([transactionID]);
	Navigation.navigate(ROUTES.NEW_REPORT_WORKSPACE_SELECTION.getRoute(true, backTo));
	return;
	}
	if (policyForMovingExpensesID && shouldRestrictUserBillableActions(policyForMovingExpensesID, userBillingGraceEndPeriods, undefined, ownerBillingGraceEndPeriod)) {
	Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(policyForMovingExpensesID));
	return;
	}
	handleCreateReport();
	};

const createReport = () => {
    const policyIDForNewReport = isPerDiemTransaction ? (perDiemOriginalPolicy?.id ?? policyForMovingExpensesID) : policyForMovingExpensesID;
    if (policyIDForNewReport && shouldRestrictUserBillableActions(policyIDForNewReport, userBillingGraceEndPeriods, undefined, ownerBillingGraceEndPeriod)) {
        Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(policyIDForNewReport));
        return;
    }
    if (isPerDiemTransaction) {
        handleCreateReport();
        return;
    }
    if (!isPerDiemTransaction && !policyForMovingExpensesID && !shouldSelectPolicy) {
        return;
    }
    if (shouldSelectPolicy) {
        setSelectedTransactions([transactionID]);
        Navigation.navigate(ROUTES.NEW_REPORT_WORKSPACE_SELECTION.getRoute(true, backTo));
        return;
    }
    handleCreateReport();
};

[mgrom]

Proposal

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

When a user with an active billing restriction clicks "Move expense" -> "New report" on a Per Diem expense, a new report is created instead of redirecting to the restricted action page.

What is the root cause of that problem?

The root cause is in handleCreateReport inside the shared component IOURequestEditReportCommon.tsx (lines 240-245). This is the onPress handler for the "Create report" MenuItem. It validates Per Diem compatibility via validatePerDiemMove but never checks shouldRestrictUserBillableActions.

Compare with its sibling handleSelectReport at line 228 of the same file, which correctly checks restrictions before allowing an existing report to be selected. Both IOURequestEditReport and IOURequestStepReport delegate to this shared component by passing a createReport prop, so fixing it here covers all callers in one place.

The component already imports shouldRestrictUserBillableActions (line 21) and subscribes to the required Onyx keys ownerBillingGraceEndPeriod (line 75) and userBillingGraceEndPeriods (line 74), so no new dependencies are needed.

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

Add the shouldRestrictUserBillableActions guard to handleCreateReport in IOURequestEditReportCommon.tsx, mirroring what handleSelectReport already does:

const handleCreateReport = useCallback(() => {
    if (policyForMovingExpenses?.id && shouldRestrictUserBillableActions(policyForMovingExpenses.id, ownerBillingGraceEndPeriod, userBillingGraceEndPeriods)) {
        Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(policyForMovingExpenses.id));
        return;
    }
    if (!validatePerDiemMove(policyForMovingExpenses?.id)) {
        return;
    }
    createReport?.();
}, [validatePerDiemMove, policyForMovingExpenses?.id, ownerBillingGraceEndPeriod, userBillingGraceEndPeriods, createReport]);

Note on existing proposals: trasnake87 proposed the same file but used incorrect argument order for shouldRestrictUserBillableActions. The correct order (matching all other call sites in the codebase) is (policyID, ownerBillingGraceEndPeriod, userBillingGraceEndPeriods).

This single-file fix is minimal and safe because it uses the same guard and the same Onyx data already present in the component, and it makes handleCreateReport and handleSelectReport consistent with each other.

---

Contributor details
Your Expensify account email: marcin.grom@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~018534923336544eae