Expense is added to existing report and a new report is created when expense rule is applied

[lanitochka17]

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.11-17
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #80915
Email or phone of affected tester (no customers): sdjnoisdjoisjdso@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.1 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to Account > Expense rules.
3. Click New rule.
4. Click Merchant > enter Apple > Save.
5. Click Add to a report named > enter any name > Save.
6. Toggle on "Create report if necessary".
7. Click Save rule.
8. Go to workspace chat.
9. Create an empty report.
10. Open FAB > Create expense > Manual.
11. Submit a manual expense with Apple as merchant to workspace chat.

Expected Result:

Expense will be added to a new report with the name indicated in expense rule in Step 7.

Actual Result:

Expense is added to the empty report created in Step 9.
Another report with the name in expense rule is created.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7063115_1769888270439.26.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @luacmartins

[melvin-bot]

Triggered auto assignment to @trjExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

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

[annaweber830]

Proposal

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

When a personal expense rule is configured to “Add to a report named …” (with “Create report if necessary”), creating an expense from an existing/open report can incorrectly attach the expense to that currently-open report, while also creating the rule-target report. We should ensure the expense is created in the rule-target report instead of the currently-open report.

What is the root cause of that problem?

In the money request creation flow we pick the chatReport (and therefore the downstream IOU/expense report context) from the currently open/parent report early, without checking whether a matching personal expense rule intends to redirect the expense into a specific report name.

App/src/libs/actions/IOU/index.ts

Lines 3134 to 3177 in 9618ba6

	const isPolicyExpenseChat = participant.isPolicyExpenseChat;
	// STEP 1: Get existing chat report OR build a new optimistic one
	let isNewChatReport = false;
	let chatReport = !isEmptyObject(parentChatReport) && parentChatReport?.reportID ? parentChatReport : null;
	// If the participant is not a policy expense chat, we need to ensure the chatReport matches the participant.
	// This can happen when submit frequency is disabled and the user selects a different participant on the confirm page.
	// We verify that the chatReport participants match the expected participants. If it's a workspace chat or
	// the participants don't match, we'll find/create the correct 1:1 DM chat report.
	// We also check if the chatReport itself is a Policy Expense Chat to avoid incorrectly validating Policy Expense Chats.
	// We also skip validation for self-DM reports since they use accountID 0 for the participant (representing the report itself).
	// We also skip validation for group chats and deprecated group DMs since they can have more than 2 participants.
	if (chatReport && !isPolicyExpenseChat && !isPolicyExpenseChatReportUtil(chatReport) && !isSelfDM(chatReport) && !isGroupChat(chatReport) && !isDeprecatedGroupDM(chatReport)) {
	const parentChatReportParticipants = Object.keys(chatReport.participants ?? {}).map(Number);
	const expectedParticipants = [payerAccountID, payeeAccountID].sort();
	const sortedParentChatReportParticipants = parentChatReportParticipants.sort();
	const participantsMatch =
	expectedParticipants.length === sortedParentChatReportParticipants.length && expectedParticipants.every((id, index) => id === sortedParentChatReportParticipants.at(index));
	if (!participantsMatch) {
	chatReport = null;
	}
	}
	// If this is a policyExpenseChat, the chatReport must exist and we can get it from Onyx.
	// report is null if the flow is initiated from the global create menu. However, participant always stores the reportID if it exists, which is the case for policyExpenseChats
	if (!chatReport && isPolicyExpenseChat) {
	chatReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${participant.reportID}`] ?? null;
	}
	if (!chatReport) {
	chatReport = getChatByParticipants([payerAccountID, payeeAccountID]) ?? null;
	}
	// If we still don't have a report, it likely doesn't exist and we need to build an optimistic one
	if (!chatReport) {
	isNewChatReport = true;
	chatReport = buildOptimisticChatReport({
	participantList: [payerAccountID, payeeAccountID],
	optimisticReportID: optimisticChatReportID,
	});
	}

Because chatReport is selected based on the currently open/parent report (or the default participant-derived chat), the money request is created and sent with that chatReportID/iouReportID pairing. Separately, the server can still apply the personal expense rule and create the configured “report named …” (because “Create report if necessary” is enabled), resulting in the observed behavior: the expense ends up attached to the current report while a second, rule-target report is created.

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

We should apply personal expense rule routing (the report + createReport fields from ONYXKEYS.NVP_EXPENSE_RULES) before we finalize which chatReport to use in the money request flow. If a rule matches the transaction merchant and specifies a report name, we should prefer that report as the chatReport (when we have a policy/workspace context), so the expense is created in the rule-target report and we don’t create the money request in the currently-open report.

App/src/libs/actions/IOU/index.ts

Lines 3136 to 3177 in 9618ba6

	// STEP 1: Get existing chat report OR build a new optimistic one
	let isNewChatReport = false;
	let chatReport = !isEmptyObject(parentChatReport) && parentChatReport?.reportID ? parentChatReport : null;
	// If the participant is not a policy expense chat, we need to ensure the chatReport matches the participant.
	// This can happen when submit frequency is disabled and the user selects a different participant on the confirm page.
	// We verify that the chatReport participants match the expected participants. If it's a workspace chat or
	// the participants don't match, we'll find/create the correct 1:1 DM chat report.
	// We also check if the chatReport itself is a Policy Expense Chat to avoid incorrectly validating Policy Expense Chats.
	// We also skip validation for self-DM reports since they use accountID 0 for the participant (representing the report itself).
	// We also skip validation for group chats and deprecated group DMs since they can have more than 2 participants.
	if (chatReport && !isPolicyExpenseChat && !isPolicyExpenseChatReportUtil(chatReport) && !isSelfDM(chatReport) && !isGroupChat(chatReport) && !isDeprecatedGroupDM(chatReport)) {
	const parentChatReportParticipants = Object.keys(chatReport.participants ?? {}).map(Number);
	const expectedParticipants = [payerAccountID, payeeAccountID].sort();
	const sortedParentChatReportParticipants = parentChatReportParticipants.sort();
	const participantsMatch =
	expectedParticipants.length === sortedParentChatReportParticipants.length && expectedParticipants.every((id, index) => id === sortedParentChatReportParticipants.at(index));
	if (!participantsMatch) {
	chatReport = null;
	}
	}
	// If this is a policyExpenseChat, the chatReport must exist and we can get it from Onyx.
	// report is null if the flow is initiated from the global create menu. However, participant always stores the reportID if it exists, which is the case for policyExpenseChats
	if (!chatReport && isPolicyExpenseChat) {
	chatReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${participant.reportID}`] ?? null;
	}
	if (!chatReport) {
	chatReport = getChatByParticipants([payerAccountID, payeeAccountID]) ?? null;
	}
	// If we still don't have a report, it likely doesn't exist and we need to build an optimistic one
	if (!chatReport) {
	isNewChatReport = true;
	chatReport = buildOptimisticChatReport({
	participantList: [payerAccountID, payeeAccountID],
	optimisticReportID: optimisticChatReportID,
	});
	}

// STEP 1: Get existing chat report OR build a new optimistic one
let isNewChatReport = false;
let chatReport = !isEmptyObject(parentChatReport) && parentChatReport?.reportID ? parentChatReport : null;

// If a personal expense rule matches this merchant and specifies a report name,
// prefer creating the expense in that report (instead of the currently-open report).
//
// Notes:
// - Match should be case-insensitive and mirror the backend "contains" behavior.
// - This should be limited to flows where a policy/workspace context exists (policyID is known).
const matchingExpenseRule = findMatchingExpenseRuleForMerchant(merchant);
const targetReportName = matchingExpenseRule?.report?.trim();
const policyID = chatReport?.policyID;

if (policyID && targetReportName) {
    const normalizedTargetReportName = targetReportName.toLowerCase();
    const existingTargetReport = Object.values(allReports ?? {}).find(
        (report) => report?.policyID === policyID && (report?.reportName ?? '').toLowerCase() === normalizedTargetReportName,
    );

    if (existingTargetReport) {
        chatReport = existingTargetReport;
    } else if (matchingExpenseRule?.createReport) {
        const optimisticTargetRoom = buildOptimisticChatReport({
            participantList: [userAccountID],
            reportName: targetReportName,
            chatType: CONST.REPORT.CHAT_TYPE.POLICY_ROOM,
            policyID,
        });

        Report.addPolicyReport(optimisticTargetRoom);
        chatReport = optimisticTargetRoom;
    }
}

function findMatchingExpenseRuleForMerchant(expenseRules: ExpenseRule[], merchant?: string): ExpenseRule | undefined {
    const normalizedMerchant = (merchant ?? '').trim().toLowerCase();
    if (!normalizedMerchant) {
        return undefined;
    }

    return expenseRules.find((rule) => {
        const merchantToMatch = (rule?.merchantToMatch ?? '').trim().toLowerCase();
        if (!merchantToMatch) {
            return false;
        }

        // Match should be case-insensitive and mirror "contains" behavior.
        return normalizedMerchant.includes(merchantToMatch);
    });
}

Implementation notes:

• Add an Onyx subscription in src/libs/actions/IOU/index.ts for ONYXKEYS.NVP_EXPENSE_RULES (similar to the other top-level Onyx.connect(...) subscriptions already in that file), so findMatchingExpenseRuleForMerchant() can inspect the latest rules.
• findMatchingExpenseRuleForMerchant() should return the first rule whose merchantToMatch is a case-insensitive substring of the transaction merchant (and should safely handle missing/empty merchant strings).
• When createReport is enabled, use the existing optimistic workspace room creation flow (e.g. Report.addPolicyReport(...)) to avoid waiting on the network before routing the expense, and to keep the UI consistent with other room creation flows.

What alternative solutions did you explore? (Optional)

• Wait for the server response, detect that a rule-target report was created, and then “move” the optimistic money request from the originally selected report into the rule-target report. This is more complex (requires reconciliation of optimistic Onyx data + report actions across two reports) and risks temporary duplication/flicker.
• Disable optimistic creation when a matching expense rule is present (create the expense only after the server chooses the correct report). This avoids duplication, but would noticeably degrade the UX for a common money request flow.

[trjExpensify]

@JS00001 @situchan are you guys handling this?

[JS00001]

Yep, should be a part of rules