[Due for payment 2026-01-21] [Due for payment 2026-01-20] [$250] Invoice-Wrong recipient when selecting an email address after selecting an Invoice room

[mitarachim]

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: v9.2.21-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: Found when working on #71648
Email or phone of affected tester (no customers): agexptest+pr0110@gmail.com
Issue reported by: Applause Internal Team
Device used: Windows 11/ Chrome, Samsung S23FE/ Android 15, iPhone 13 Mini/ iOS 18.5
App Component: Other

Action Performed:

Preconditions: Have a workspace with the Invoices feature enabled.
Have at least one Invoice room.

1. Go to staging.new.expensify.com
2. Open FAB > Send invoice
3. Enter amount > Next
4. Select an Invoice room from Recents
5. In the "To" field, click on the right caret icon
6. Enter an email address that is not included in any Invoice room with the current user
   7 Send the invoice

Expected Result:

The app creates the invoice thread in a new Invoice room with the email address entered in step 6.

Actual Result:

The app creates the invoice thread in the Invoice room selected in step 4.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6962289_1759354745008.Wrong_recipient.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021973664764145064677
• Upwork Job ID: 1973664764145064677
• Last Price Increase: 2025-12-25
• Automatic offers:
• cretadn22 | Contributor | 109964626

Issue Owner

Current Issue Owner: @dylanexpensify

[melvin-bot]

Triggered auto assignment to @dylanexpensify (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.

[nyomanjyotisa]

Proposal

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

Invoice-Wrong recipient when selecting an email address after selecting an Invoice room

What is the root cause of that problem?

Invoice room selection logic prioritizes a pre-selected report over checking if the current transaction participants have changed

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

Lines 869 to 884 in f3984ef

	if (iouType === CONST.IOU.TYPE.INVOICE) {
	const invoiceChatReport = !isEmptyObject(report) && report?.reportID ? report : existingInvoiceReport;
	sendInvoice(
	currentUserPersonalDetails.accountID,
	transaction,
	invoiceChatReport,
	currentTransactionReceiptFile,
	policy,
	policyTags,
	policyCategories,
	undefined,
	undefined,
	policyRecentlyUsedCategories,
	);
	return;
	}

• report is the invoice room selected from recents
• existingInvoiceReport is determined by the useParticipantsInvoiceReport hook based on current transaction participants

The issue occurs because when a user selects an invoice room and then changes the email address, the transaction participants are updated but it still uses the originally selected report instead of checking if it matches the new recipient

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

We can check if the selected report matches the current transaction participants before using it

                const doesReportMatchCurrentReceiver = report?.invoiceReceiver && 'accountID' in report.invoiceReceiver && report.invoiceReceiver.accountID === receiverAccountID;

                // Or check for policyID as well

                const doesReportMatchCurrentReceiver =
                    report?.invoiceReceiver &&
                    (('accountID' in report.invoiceReceiver && report.invoiceReceiver.accountID === receiverAccountID) ||
                        ('policyID' in report.invoiceReceiver &&
                            receiverParticipant &&
                            'policyID' in receiverParticipant &&
                            report.invoiceReceiver.policyID === receiverParticipant.policyID)) &&
                    report.invoiceReceiver.type === receiverType;

Then use it here

                const invoiceChatReport = doesReportMatchCurrentReceiver && report?.reportID ? report : existingInvoiceReport;

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

Line 870 in f3984ef

const invoiceChatReport = !isEmptyObject(report) && report?.reportID ? report : existingInvoiceReport;

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None

What alternative solutions did you explore? (Optional)

None

[lorretheboy]

Proposal

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

Wrong recipient when selecting an email address after selecting an Invoice room

What is the root cause of that problem?

The existingInvoiceReport is calculated by useParticipantsInvoiceReport based on current transaction participants (recipient B)

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

Line 177 in 7a21602

const existingInvoiceReport = useParticipantsInvoiceReport(receiverAccountID, receiverType, senderWorkspaceID);

But the original report from route parameter (for recipient A)

When no existing invoice report exists for the new recipient B, the logic fell back to the original report for recipient A

So instead of creating a new report, the code fell back to the stale original report --> This caused the invoice to be created in the wrong room

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

For useParticipantsInvoiceReport, we need the correct receiverID based on receiver type to calculate existingInvoiceReport in useParticipantsInvoiceReport

    let receiverID: string | number | undefined = receiverAccountID;
    if (receiverType === CONST.REPORT.INVOICE_RECEIVER_TYPE.BUSINESS && receiverParticipant && 'policyID' in receiverParticipant) {
        receiverID = receiverParticipant.policyID;
    }

    const existingInvoiceReport = useParticipantsInvoiceReport(receiverID, receiverType, senderWorkspaceID);

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

Line 177 in 7a21602

const existingInvoiceReport = useParticipantsInvoiceReport(receiverAccountID, receiverType, senderWorkspaceID);

Update here to fallback to existingInvoiceReport if exists

    const invoiceChatReport = existingInvoiceReport;

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

Line 865 in 7a21602

const invoiceChatReport = !isEmptyObject(report) && report?.reportID ? report : existingInvoiceReport;

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[melvin-bot]

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

[melvin-bot]

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

[huult]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @huult 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.

[ShridharGoel]

Proposal

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

Invoice drafts created from the FAB could not be addressed to a new recipient if the user previously picked an existing invoice room. Entering a new email in the confirmation step still re-used the earlier room, so the invoice was sent to the wrong conversation.

What is the root cause of that problem?

The confirmation step and the invoicing action both prioritized an existing invoice room whenever a report was available on the route. In getSendInvoiceInformation, the receiver was picked only when a participant had a persisted accountID, otherwise the logic fell back to the existing room

App/src/libs/actions/IOU.ts

Lines 3204 to 3218 in b76a740

	const receiverParticipant: Participant | InvoiceReceiver | undefined = participants?.find((participant) => participant?.accountID) ?? invoiceChatReport?.invoiceReceiver;
	const receiverAccountID = receiverParticipant && 'accountID' in receiverParticipant && receiverParticipant.accountID ? receiverParticipant.accountID : CONST.DEFAULT_NUMBER_ID;
	let receiver = getPersonalDetailsForAccountID(receiverAccountID);
	let optimisticPersonalDetailListAction = {};
	// STEP 1: Get existing chat report OR build a new optimistic one
	let isNewChatReport = false;
	let chatReport = !isEmptyObject(invoiceChatReport) && invoiceChatReport?.reportID ? invoiceChatReport : null;
	if (!chatReport) {
	isNewChatReport = true;
	chatReport = buildOptimisticChatReport({
	participantList: [receiverAccountID, currentUserAccountID],
	chatType: CONST.REPORT.CHAT_TYPE.INVOICE,
	policyID: senderWorkspaceID,
	});

Similarly, the confirmation page derived the receiver directly from report?.invoiceReceiver when no accountID was present, ignoring a newly entered login

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

Lines 174 to 179 in b76a740

	const receiverParticipant: Participant | InvoiceReceiver | undefined = transaction?.participants?.find((participant) => participant?.accountID) ?? report?.invoiceReceiver;
	const receiverAccountID = receiverParticipant && 'accountID' in receiverParticipant && receiverParticipant.accountID ? receiverParticipant.accountID : CONST.DEFAULT_NUMBER_ID;
	const receiverType = getReceiverType(receiverParticipant);
	const senderWorkspaceID = transaction?.participants?.find((participant) => participant?.isSender)?.policyID;
	const existingInvoiceReport = useParticipantsInvoiceReport(receiverAccountID, receiverType, senderWorkspaceID);

As a result the old room stayed selected even after typing a different email.

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

Update both the confirmation screen and the invoicing action to prefer the participant supplied by the current transaction (including those identified only by login) and only reuse the existing invoice room when that participant truly represents the same room.

// src/pages/iou/request/step/IOURequestStepConfirmation.tsx
const receiverParticipantFromTransaction = transaction?.participants?.find(
    (participant) => !participant?.isSender && (!!participant?.accountID || !!participant?.login),
);
const receiverParticipant: Participant | InvoiceReceiver | undefined = receiverParticipantFromTransaction ?? report?.invoiceReceiver;

// src/libs/actions/IOU.ts
const receiverParticipantFromTransaction = participants?.find(
    (participant) => !participant?.isSender && (!!participant?.accountID || !!participant?.login),
);
const shouldUseExistingInvoiceChat = !receiverParticipantFromTransaction || !!receiverParticipantFromTransaction.reportID;
const invoiceChatReportToUse = shouldUseExistingInvoiceChat ? invoiceChatReport : undefined;
const receiverParticipantFromReport = invoiceChatReportToUse?.invoiceReceiver;
const receiverParticipant: Participant | InvoiceReceiver | undefined = receiverParticipantFromTransaction ?? receiverParticipantFromReport;
...
const parameters: SendInvoiceParams = {
    ...,
    ...(receiverInvoiceRoomID ? {receiverInvoiceRoomID} : {receiverEmail: receiver.login ?? ''}),
};

These updates ensure a new invoice room is generated when the user types an email that does not yet belong to an existing room, while still preserving the previous behavior when the selected participant already references a room.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

• Unit test for the confirmation step selector ensuring it returns the new participant when present and only falls back to report?.invoiceReceiver when transaction data lacks a receiver.