[$250] Expense - Error shows up when submitting unreported card expense to user

[izarutskaya]

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.60-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: https://github.com/Expensify/Expensify/issues/555083
Email or phone of affected tester (no customers): undefined
Issue reported by: Applause Internal Team
Device used: macOS Tahoe 26.1 - Chrome

Action Performed:

Precondition:

• User has added Wells Fargo card feed and assigned themselves Plaid Credit Card 3333.
• There is at least one imported card transaction.

1. Go to staging.expensify.com
2. Go to workspace chat.
3. Open the expense report with card expenses.
4. Click More > Delete > Delete.
5. Go to self DM.
6. Open the unreported card expense.
7. Click on the report header > Submit it to someone.
8. Enter email and select the user.
9. Click Create expense.

Expected Result:

User should not be able to select user when submitting unreported card expense.

Actual Result:

User is able to select user when submitting unreported card expense.
As a result, error shows up after attempting to submit unreported card expense to the user.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7110895_1774284433757.12.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022046165790441189471
• Upwork Job ID: 2046165790441189471
• Last Price Increase: 2026-05-04

Issue Owner

Current Issue Owner: @paulnjs

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Submit it to someone" button in ReportDetailsPage.tsx is gated only on isTrackExpenseReport && !isDeletedParentAction (line 450), with no check for whether the transaction is a managed card transaction. When a card expense becomes unreported in self DM (after its expense report is deleted), its parent report action type is TRACK, so isTrackExpenseReportNew returns true and the submit/categorize/share buttons appear — even though card transactions cannot be submitted to individual users.

The iouTransaction object (which contains the managedCard flag) is already fetched at line 314, but it's never consulted before showing these actions.

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

Add a isManagedCardTransaction(iouTransaction) check to the condition at ReportDetailsPage.tsx:450 so the submit/categorize/share buttons are hidden for managed card transactions:

if (isTrackExpenseReport && !isDeletedParentAction && !isManagedCardTransaction(iouTransaction))

isManagedCardTransaction already exists in TransactionUtils (line 1357) and checks !!transaction?.managedCard, which covers both Expensify Card and Company Card (Wells Fargo, etc.) transactions.

What alternative solutions did you explore? (Optional)

1. Blocking at the participant selector level — The selector already sets includeP2P: false for corporate card transactions, but this only hides individual users from the list; the user still enters the submit flow unnecessarily. Better to prevent the flow entirely.
2. Blocking at whisper creation (TrackExpense.ts:1119) — Could also skip creating the ACTIONABLE_TRACK_EXPENSE_WHISPER for card transactions, but this is a secondary entry point. The ReportDetailsPage fix is the primary one since that's where the user triggers the action in this bug's reproduction steps.

---

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

[MobileMage]

Proposal

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

When a user opens an unreported card expense (e.g., a Wells Fargo Plaid personal card transaction) and taps "Submit it to someone" from the report header, the participant selector incorrectly allows selecting a personal user (P2P). Submitting then fails with a server error because card expenses cannot be submitted directly to another user.

What is the root cause of that problem?

The isCorporateCardTransaction helper (used to determine whether to hide P2P options in the participant selector) is too narrow — it only returns true for managed-card transactions that explicitly have liabilityType === RESTRICT:

App/src/libs/TransactionUtils/index.ts

Lines 290 to 292 in 6871452

	function isCorporateCardTransaction(transaction: OnyxEntry<Transaction>): boolean {
	return isManagedCardTransaction(transaction) && transaction?.comment?.liabilityType === CONST.TRANSACTION.LIABILITY_TYPE.RESTRICT;
	}

Personal card feed transactions imported via Plaid (Wells Fargo, etc.) have a cardNumber or bank field set but do not necessarily have managedCard populated, so isManagedCardTransaction returns false and therefore isCorporateCardTransaction also returns false. Because of this, IOURequestStepParticipants passes isCorporateCardTransaction={false} to MoneyRequestParticipantsSelector, which in turn sets includeP2P: true — exposing individual users as valid targets even for card transactions that cannot be submitted to a person.

The broader utility isFromCreditCardImport already handles this correctly: it covers managed cards, Plaid-imported cards (cardNumber), and bank-connected cards (bank) but excludes CSV-upload transactions.

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

In IOURequestStepParticipants, replace the isCorporateCardTransaction check with isFromCreditCardImport when the action is SUBMIT. Card expenses of any kind cannot be submitted to a personal user, so P2P options should be hidden for any imported card transaction during the SUBMIT flow.

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

Lines 133 to 135 in 6871452

	const isPerDiem = isPerDiemRequest(initialTransaction);
	const isTime = isTimeRequestUtil(initialTransaction);
	const isCorporateCard = isCorporateCardTransaction(initialTransaction);

-import {getRequestType, hasRoute, isCorporateCardTransaction, isDistanceRequest, isPerDiemRequest, isTimeRequest as isTimeRequestUtil} from '@libs/TransactionUtils';
+import {getRequestType, hasRoute, isCorporateCardTransaction, isDistanceRequest, isFromCreditCardImport, isPerDiemRequest, isTimeRequest as isTimeRequestUtil} from '@libs/TransactionUtils';

// inside the component:
-    const isCorporateCard = isCorporateCardTransaction(initialTransaction);
+    const isCorporateCard = action === CONST.IOU.ACTION.SUBMIT
+        ? isFromCreditCardImport(initialTransaction)
+        : isCorporateCardTransaction(initialTransaction);

This means that when navigating to the participant selector via the "Submit it to someone" action, all imported card transactions (personal or corporate) hide P2P options and only show workspace chats as valid destinations, which is the correct and expected behavior. For the normal expense creation flow (action === CREATE), the existing narrower check is preserved so that only restricted corporate cards suppress P2P, leaving personal card flow unchanged.

What alternative solutions did you explore? (Optional)

N/A

[melvin-bot]

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

[twilight2294]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

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

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

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