[$250] Expense - Inconsistent expense type shown during scan – “Receipt” in chat, “Cash” in IOU report

[jponikarchuk]

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.3.20-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #80003
Email or phone of affected tester (no customers): dreamnitethedragon+msiw@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redminote 10S Android 13
App Component: Money Requests

Action Performed:

1. Launch app
2. Open 1:1 chat
3. Create 2 scan expense with camera image
4. While scanning note the preview in 1:1 chat and IOU report page

Expected Result:

While expense is scanning, 1:1 chat preview must show "cash" in preview in all sections.

Actual Result:

While expense is scanning, 1:1 chat preview shows "Receipt" but in IOU report page "cash" is shown.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022029615192196932495
• Upwork Job ID: 2029615192196932495
• Last Price Increase: 2026-03-05

[Eskalifer1]

Proposal

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

Expense - Inconsistent expense type shown during scan – “Receipt” in chat, “Cash” in IOU report

What is the root cause of that problem?

There is a mismatch in getTransactionPreviewTextAndTranslationPaths: for scanning transactions it overrides the already-derived expense type label and forces common.receipt.
Root cause:

App/src/libs/TransactionPreviewUtils.ts

Lines 289 to 297 in b14d99a

	let previewHeaderText: TranslationPathOrText[] = [{translationPath: getExpenseTypeTranslationKey(getTransactionType(transaction))}];
	if (isDistanceRequest(transaction)) {
	if (RBRMessage === undefined && isUnreportedAndHasInvalidDistanceRateTransaction(transaction, policy)) {
	RBRMessage = {translationPath: 'violations.customUnitOutOfPolicy'};
	}
	} else if (isTransactionScanning) {
	previewHeaderText = [{translationPath: 'common.receipt'}];
	} else if (isBillSplit) {

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

Keep the expense type derived from getExpenseTypeTranslationKey(getTransactionType(transaction)) even when the transaction is scanning, instead of replacing it with receipt.

Code to update:

App/src/libs/TransactionPreviewUtils.ts

Lines 295 to 297 in b14d99a

	} else if (isTransactionScanning) {
	previewHeaderText = [{translationPath: 'common.receipt'}];
	} else if (isBillSplit) {

} else if (isTransactionScanning) {
    previewHeaderText = [{translationPath: getExpenseTypeTranslationKey(getTransactionType(transaction)) || 'common.receipt'}];
} else if (isBillSplit) {

What alternative solutions did you explore? (Optional)

Remove the isTransactionScanning override block entirely so previewHeaderText always uses the default initialization from line 289.

This also fixes the issue, but is slightly less explicit than keeping the scanning branch and setting the same expense-type translation directly.

[melvin-bot]

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

[MelvinBot]

Proposal

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

When a scan expense is being processed, the 1:1 chat preview shows "Receipt" while the IOU report page shows "Cash" for the same transaction. The expense type label should be consistent across both views.

What is the root cause of that problem?

Two different code paths render the expense type label with different scanning-state handling:

1. Chat preview path (src/libs/TransactionPreviewUtils.ts:302-309): The function getTransactionPreviewTextAndTranslationPaths correctly initializes previewHeaderText using getExpenseTypeTranslationKey(getTransactionType(transaction)) (which resolves to 'iou.cash' = "Cash" for a scanned receipt). However, at line 308-309, when isTransactionScanning is true, it overrides this to 'common.receipt' = "Receipt":

   // Line 302 - correct default
   let previewHeaderText = [{translationPath: getExpenseTypeTranslationKey(getTransactionType(transaction))}];
   // Lines 304-309 - scanning override replaces 'Cash' with 'Receipt'
   if (isDistanceRequest(transaction)) {
       ...
   } else if (isTransactionScanning) {
       previewHeaderText = [{translationPath: 'common.receipt'}];  // BUG
   }

2. IOU report table path (src/components/TransactionItemRow/DataCells/TypeCell.tsx:42-45): TypeCell calls getExpenseTypeTranslationKey(getTransactionType(transaction)) directly with no scanning override, so it correctly shows "Cash".

The getTransactionType function (src/libs/TransactionUtils/index.ts:337-364) classifies a scanned receipt (no card, not distance) as CASH, and getExpenseTypeTranslationKey maps that to 'iou.cash' = "Cash". The scanning override in TransactionPreviewUtils.ts is the sole cause of the inconsistency.

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

In src/libs/TransactionPreviewUtils.ts, update the scanning branch (line 309) to preserve the actual expense type instead of hardcoding 'common.receipt':

Change the scanning branch from using 'common.receipt' to using getExpenseTypeTranslationKey(getTransactionType(transaction)), with 'common.receipt' as a fallback. This ensures the chat preview label matches the IOU report page for all expense types (Cash, Card, etc.) during scanning.

What alternative solutions did you explore? (Optional)

Alternative: Remove the scanning branch entirely. Since line 302 already initializes previewHeaderText with the correct expense type, the isTransactionScanning branch could be removed so it falls through to the default. This also works but is slightly less explicit about the scanning case.

Note: MoneyRequestReportPreviewContent.tsx:371 also hardcodes 'common.receipt' for scanning transactions in multi-expense report previews. That may warrant a similar fix but is a separate concern from the 1:1 chat preview inconsistency reported here.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.