[$250] Show 'Scanning' date and sort scanning receipts to top of expenses list

[MelvinBot]

When a user scans a receipt from the expenses page, the newly scanning expense gets a default date of "00:00:00 UTC today", which causes it to appear buried beneath other expenses created later that day. Users expect the scanning receipt to appear at the top of the list so they can easily track it.

Proposed Solution

Show "Scanning" instead of the date for scanning receipts, and sort them to the top of the expenses list. No backend changes needed — the display and sort are purely frontend concerns.

1. Show "Scanning" instead of the date

There's already a precedent — the merchant column does exactly this at TransactionItemRow/index.tsx:159-161:

if (isScanning(transactionItem) && shouldShowMerchant) {
    merchant = translate('iou.receiptStatusTitle');
}

Apply the same pattern for the date column at the two DateCell call sites:

• Wide layout: TransactionItemRow/index.tsx:326 — pass translate('iou.receiptStatusTitle') instead of createdAt when isScanning(transactionItem) is true
• Narrow layout: TransactionItemRow/index.tsx:736 — same change

DateCell.tsx would need a small tweak to skip date formatting when the value isn't a real date (or accept a displayText override prop).

2. Sort scanning receipts to top

Add scanning-priority logic in the two sort locations, before the normal compareValues call:

• Search/expenses list: SearchUIUtils.ts (getSortedTransactionData) — inside the .sort() callback, check isScanning(a) / isScanning(b) first. If one is scanning and the other isn't, return the scanning one first (regardless of sort direction).
• Report transaction list: MoneyRequestReportTransactionList.tsx:286 — same wrapper logic around compareValues.

3. No backend changes needed

The created date stays as today's date (no fake future dates). isScanning already detects the scanning state from receipt.state, and once SmartScan completes, isScanning returns false and the expense reverts to normal date display + sort position automatically.

---

Parent issue: https://github.com/Expensify/Expensify/issues/630432

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022052481085379087969
• Upwork Job ID: 2052481085379087969
• Last Price Increase: 2026-05-07

[melvin-bot]

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

[melvin-bot]

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

[trasnake87]

Proposal

Newly scanned receipts get a default created date of 00:00:00 UTC today, so any expense the user adds afterward (e.g. a manual cash expense at 14:32) sorts above the scanning receipt by date — burying it. The fix is purely client-side: render Scanning… in place of the date cell and pin scanning rows to the top of the list independent of sort direction.

Root cause

This is a two-part display + sort bug. Both parts share the same root signal — isScanning(transaction) from src/libs/TransactionUtils/index.ts:1432-1444:

// src/libs/TransactionUtils/index.ts:1432
function isScanning(transaction: OnyxEntry<Transaction>): boolean {
    if (!isReceiptBeingScanned(transaction)) {
        return false;
    }
    if (hasValidModifiedAmount(transaction)) {
        return false;
    }
    return isPartialTransaction(transaction) && hasReceipt(transaction);
}

1 — Date column shows the (wrong) UTC-midnight date. The merchant column already special-cases scanning at src/components/TransactionItemRow/index.tsx:155-166:

// src/components/TransactionItemRow/index.tsx:155
function getMerchantName(transactionItem, translate) {
    const shouldShowMerchant = transactionItem.shouldShowMerchant ?? true;
    let merchant = transactionItem?.formattedMerchant ?? getMerchant(transactionItem);
    if (isScanning(transactionItem) && shouldShowMerchant) {
        merchant = translate('iou.receiptStatusTitle');
    }
    ...
}

…but the date column does not. Both DateCell call sites pass the raw createdAt unconditionally — wide layout at src/components/TransactionItemRow/index.tsx:321-333 and narrow layout at src/components/TransactionItemRow/index.tsx:765-771:

// src/components/TransactionItemRow/index.tsx:327 (wide)
<DateCell
    date={createdAt}
    showTooltip={shouldShowTooltip}
    isLargeScreenWidth={!shouldUseNarrowLayout}
/>

// src/components/TransactionItemRow/index.tsx:766 (narrow)
<DateCell
    date={createdAt}
    showTooltip={shouldShowTooltip}
    isLargeScreenWidth={false}
    suffixText={categoryForDisplay}
/>

DateCell itself blindly formats whatever string it gets via DateUtils.formatWithUTCTimeZone (src/components/Search/SearchList/ListItem/DateCell.tsx:14-27), so passing the translated label without a code change would print "Invalid date".

2 — Sort by created puts scanning rows below same-day rows. Two sorters compare created directly, so a 00:00:00 UTC scanning row loses to any expense created later in the day:

• src/libs/SearchUIUtils.ts:3618-3756 — getSortedTransactionData. The fall-through path at src/libs/SearchUIUtils.ts:3738-3756 handles the DATE column and ranks rows purely by created via compareValues, with no scanning-priority bypass.
• src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx:288-292 — same comparator in one line:

// src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx:288
const sortedTransactions: TransactionWithOptionalHighlight[] = useMemo(() => {
    return [...transactions].sort((a, b) =>
        compareValues(getTransactionSortValue(a, sortBy, report, policy), getTransactionSortValue(b, sortBy, report, policy), sortOrder, sortBy, localeCompare, true),
    );
}, [sortBy, sortOrder, transactions, localeCompare, report, policy]);

Proposed fix

1 — Make DateCell accept a display override. Add an optional displayText prop that bypasses the formatWithUTCTimeZone call. This keeps every other call site untouched:

// src/components/Search/SearchList/ListItem/DateCell.tsx
type DateCellProps = {
    date: string;
    showTooltip: boolean;
    isLargeScreenWidth: boolean;
    suffixText?: string;
    displayText?: string;
};

function DateCell({date, showTooltip, isLargeScreenWidth, suffixText, displayText}: DateCellProps) {
    const styles = useThemeStyles();

    const formattedDate =
        displayText ??
        DateUtils.formatWithUTCTimeZone(date, DateUtils.doesDateBelongToAPastYear(date) ? CONST.DATE.MONTH_DAY_YEAR_ABBR_FORMAT : CONST.DATE.MONTH_DAY_ABBR_FORMAT);
    const finalText = suffixText ? `${formattedDate} • ${suffixText}` : formattedDate;

    return (
        <TextWithTooltip
            text={finalText}
            shouldShowTooltip={showTooltip}
            style={[styles.lineHeightLarge, styles.pre, styles.justifyContentCenter, isLargeScreenWidth ? undefined : styles.mutedNormalTextLabel, !!suffixText && styles.flexShrink1]}
        />
    );
}

2 — Pass the override at both TransactionItemRow call sites. Compute the value once next to the existing createdAt/merchant logic so it stays cheap:

// src/components/TransactionItemRow/index.tsx (near line 212)
const createdAt = getTransactionCreated(transactionItem);
const isTransactionScanning = isScanning(transactionItem);
const dateDisplayText = isTransactionScanning ? translate('iou.receiptStatusTitle') : undefined;

// src/components/TransactionItemRow/index.tsx:327 (wide layout)
<DateCell
    date={createdAt}
    showTooltip={shouldShowTooltip}
    isLargeScreenWidth={!shouldUseNarrowLayout}
    displayText={dateDisplayText}
/>

// src/components/TransactionItemRow/index.tsx:766 (narrow layout)
<DateCell
    date={createdAt}
    showTooltip={shouldShowTooltip}
    isLargeScreenWidth={false}
    suffixText={categoryForDisplay}
    displayText={dateDisplayText}
/>

'iou.receiptStatusTitle' already resolves to Scanning… (src/languages/en.ts:1329) and is the same key the merchant column uses, so the two cells stay visually consistent.

3 — Pin scanning rows to the top of the list, regardless of sort direction. Add a small comparator wrapper that short-circuits when exactly one row is scanning. Apply it at both sort sites.

// src/libs/SearchUIUtils.ts (new helper near getSortedTransactionData)
function compareScanningPriority<T extends {receipt?: Transaction['receipt']; cardName?: string}>(a: T, b: T): number {
    const aScanning = isScanning(a as OnyxEntry<Transaction>);
    const bScanning = isScanning(b as OnyxEntry<Transaction>);
    if (aScanning === bScanning) {
        return 0;
    }
    return aScanning ? -1 : 1;
}

Then wrap the date-column fall-through at src/libs/SearchUIUtils.ts:3738-3756:

// src/libs/SearchUIUtils.ts:3738
return data.sort((a, b) => {
    const scanningOrder = compareScanningPriority(a, b);
    if (scanningOrder !== 0) {
        return scanningOrder;
    }

    const aValue = getTransactionSortValue(a, sortingProperty);
    const bValue = getTransactionSortValue(b, sortingProperty);

    const primaryComparison = compareValues(aValue, bValue, sortOrder, sortingProperty, localeCompare);
    if (primaryComparison !== 0) {
        return primaryComparison;
    }

    const createdComparison = compareValues(a.created, b.created, sortOrder, 'created', localeCompare);
    if (createdComparison !== 0) {
        return createdComparison;
    }
    return compareValues(a.transactionID, b.transactionID, sortOrder, 'transactionID', localeCompare);
});

And the in-report sort at src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx:288-292:

// src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx:288
const sortedTransactions: TransactionWithOptionalHighlight[] = useMemo(() => {
    return [...transactions].sort((a, b) => {
        const scanningOrder = compareScanningPriority(a, b);
        if (scanningOrder !== 0) {
            return scanningOrder;
        }
        return compareValues(getTransactionSortValue(a, sortBy, report, policy), getTransactionSortValue(b, sortBy, report, policy), sortOrder, sortBy, localeCompare, true);
    });
}, [sortBy, sortOrder, transactions, localeCompare, report, policy]);

compareScanningPriority is exported from SearchUIUtils.ts and imported in the report list — both files already import other helpers from there (compareValues, getColumnsToShow at src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx:62).

Why this approach

The display half mirrors a precedent already in this exact file: the merchant column at src/components/TransactionItemRow/index.tsx:160-162 swaps getMerchant for translate('iou.receiptStatusTitle') under the same isScanning predicate, so reusing the predicate and translation key keeps the two columns in lockstep — when SmartScan finishes, both revert to real values automatically because isScanning flips off.

Adding a displayText override on DateCell is preferable to type-laundering the date prop (passing 'Scanning…' as a string would silently flow through to DateUtils.formatWithUTCTimeZone and any other consumers that grow up around the prop). It also avoids a parallel "scanning?" branch in every caller — only the one place that actually wants this behavior opts in.

For the sort, a dedicated priority-comparator that short-circuits before compareValues (rather than mutating the created value or injecting a synthetic high date) keeps the existing tie-breaker chain intact and works identically for ASC and DESC, which matches the issue's expectation that scanning rows always show first. Mutating created was rejected because it would also affect every downstream consumer that reads transaction.created (date grouping headers, year suffix logic in src/libs/TransactionUtils/shouldShowTransactionYear.ts, server payload echoes), and would silently misorder a scanning row against a real future-dated expense once SmartScan completes.

[wildan-m]

Proposal

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

When a receipt is being SmartScanned from the expenses page, the new transaction's created timestamp defaults to today's date at 00:00:00 UTC. Two problems follow:

1. The Date column shows that midnight stamp as a real date, even though no real receipt date is known yet — so the cell is misleading.
2. With sort = Date / DESC, the midnight stamp is the earliest timestamp of today, so the in-progress scan is buried under every other expense created later that day. Users expect a freshly scanned receipt to be visible at the top so they can track its scan progress.

The expected behavior is: while a receipt is scanning, the Date column should show "Scanning…" (matching the existing Merchant column treatment for scans), and the row should be pinned to the top of the list regardless of which column or direction the user has sorted by.

What is the root cause of that problem?

There are two independent gaps, both downstream of Transaction.created being set to today-at-midnight for in-progress scans (this happens server-side; the client only reads it).

Gap 1 — display. The Merchant column already special-cases scanning in TransactionItemRow:

App/src/components/TransactionItemRow/index.tsx

Lines 156 to 167 in ca84a2c

	function getMerchantName(transactionItem: TransactionWithOptionalSearchFields, translate: (key: TranslationPaths) => string) {
	const shouldShowMerchant = transactionItem.shouldShowMerchant ?? true;
	let merchant = transactionItem?.formattedMerchant ?? getMerchant(transactionItem);
	if (isScanning(transactionItem) && shouldShowMerchant) {
	merchant = translate('iou.receiptStatusTitle');
	}
	const merchantName = StringUtils.getFirstLine(merchant);
	return merchantName !== CONST.TRANSACTION.PARTIAL_TRANSACTION_MERCHANT && merchantName !== CONST.TRANSACTION.DEFAULT_MERCHANT ? merchantName : '';
	}

But the Date column has no equivalent branch. The two DateCell call sites (wide layout and narrow layout) pass createdAt straight through:

App/src/components/TransactionItemRow/index.tsx

Lines 323 to 335 in ca84a2c

	case CONST.SEARCH.TABLE_COLUMNS.DATE:
	return (
	<View
	key={column}
	style={[StyleUtils.getReportTableColumnStyles(CONST.SEARCH.TABLE_COLUMNS.DATE, {isDateColumnWide})]}
	>
	<DateCell
	date={createdAt}
	showTooltip={shouldShowTooltip}
	isLargeScreenWidth={!shouldUseNarrowLayout}
	/>
	</View>
	);

App/src/components/TransactionItemRow/index.tsx

Lines 770 to 775 in ca84a2c

	<DateCell
	date={createdAt}
	showTooltip={shouldShowTooltip}
	isLargeScreenWidth={false}
	suffixText={categoryForDisplay}
	/>

And DateCell itself has no escape hatch — it always runs the input through DateUtils.formatWithUTCTimeZone, so it can't render a non-date string:

App/src/components/Search/SearchList/ListItem/DateCell.tsx

Lines 14 to 27 in ca84a2c

	function DateCell({date, showTooltip, isLargeScreenWidth, suffixText}: DateCellProps) {
	const styles = useThemeStyles();
	const formattedDate = DateUtils.formatWithUTCTimeZone(date, DateUtils.doesDateBelongToAPastYear(date) ? CONST.DATE.MONTH_DAY_YEAR_ABBR_FORMAT : CONST.DATE.MONTH_DAY_ABBR_FORMAT);
	const displayText = suffixText ? `${formattedDate} • ${suffixText}` : formattedDate;
	return (
	<TextWithTooltip
	text={displayText}
	shouldShowTooltip={showTooltip}
	style={[styles.lineHeightLarge, styles.pre, styles.justifyContentCenter, isLargeScreenWidth ? undefined : styles.mutedNormalTextLabel, !!suffixText && styles.flexShrink1]}
	/>
	);
	}

Gap 2 — sort. Both transaction-list sort sites compare the raw created value with compareValues and have no concept of scanning priority:

App/src/libs/SearchUIUtils.ts

Lines 3759 to 3777 in ca84a2c

	return data.sort((a, b) => {
	const aValue = getTransactionSortValue(a, sortingProperty);
	const bValue = getTransactionSortValue(b, sortingProperty);
	const primaryComparison = compareValues(aValue, bValue, sortOrder, sortingProperty, localeCompare);
	if (primaryComparison !== 0) {
	return primaryComparison;
	}
	// If we have a tie in the primary comparison, we add a tie breaker on date and/or transactionID as a last resort to make the sort deterministic
	const createdComparison = compareValues(a.created, b.created, sortOrder, 'created', localeCompare);
	if (createdComparison !== 0) {
	return createdComparison;
	}
	return compareValues(a.transactionID, b.transactionID, sortOrder, 'transactionID', localeCompare);
	});

App/src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx

Lines 296 to 316 in ca84a2c

	const sortedTransactions: TransactionWithOptionalHighlight[] = useMemo(() => {
	return [...transactions].sort((a, b) => {
	// When on default sort (Date/ASC), prioritize RBR-flagged transactions
	if (isDefaultSort && allTransactionViolations) {
	const rbrComparison = compareByRBR(
	a,
	b,
	allTransactionViolations,
	currentUserDetails?.login ?? '',
	currentUserDetails?.accountID ?? CONST.DEFAULT_NUMBER_ID,
	report,
	policy,
	reportActionsMap,
	);
	if (rbrComparison !== 0) {
	return rbrComparison;
	}
	}
	return compareValues(getTransactionSortValue(a, sortBy, report, policy), getTransactionSortValue(b, sortBy, report, policy), sortOrder, sortBy, localeCompare, true);
	});
	}, [sortBy, sortOrder, transactions, localeCompare, report, policy, isDefaultSort, allTransactionViolations, currentUserDetails?.login, currentUserDetails?.accountID, reportActionsMap]);

So a scanning row's position is dictated entirely by the today-midnight timestamp. Under DESC date sort it lands at the bottom of today; under any other sort column it lands wherever its (often empty / placeholder) value ranks. There is no logic that says "if one of these is scanning, pin it to the top."

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

Two minimal changes — one for display, one for sort — both gated on the existing isScanning(transaction) predicate from TransactionUtils.

1) Display "Scanning…" in the Date column while scanning.

In DateCell.tsx, accept an optional override prop (call it displayTextOverride?: string). When provided, the cell renders that text directly via TextWithTooltip and skips the formatWithUTCTimeZone call entirely. This keeps DateCell's public API backward compatible — every existing call site continues to work unchanged because the new prop is optional.

In TransactionItemRow/index.tsx, at both the wide-layout call site (around line 329) and the narrow-layout call site (around line 770), compute the override once and pass it through:

• If isScanning(transactionItem) is true, pass displayTextOverride={translate('iou.receiptStatusTitle')} (this is the same 'Scanning…' string already used for the Merchant column at line 162, so we get visual consistency for free).
• Otherwise pass nothing — DateCell formats createdAt as today.

This mirrors the pattern the Merchant column has used for a long time, so reviewers and future contributors will recognize it immediately.

2) Pin scanning rows to the top in both sort sites.

The user-facing rule is: "scanning rows always come first, regardless of which column or direction is selected." That's a priority short-circuit applied before any column-based comparison runs.

Add a small helper (e.g. compareScanningPriority(a, b)) that returns:

• -1 if isScanning(a) and not isScanning(b) (a comes first)
• +1 if isScanning(b) and not isScanning(a)
• 0 otherwise (fall through to the existing comparison)

Crucially, the helper does not consult sortOrder — that's the whole point. Whether the user sorts ASC or DESC, by Date or by Amount or by Merchant, scanning rows float to the top.

Wire it into both sort sites:

• SearchUIUtils.ts getSortedTransactionData — call the helper at the top of every data.sort((a, b) => …) callback inside this function (the date-property branch around lines 3759-3777, plus the per-column branches above it). Returning the helper's result if non-zero short-circuits before compareValues runs. This handles the search/expenses list.
• MoneyRequestReportTransactionList.tsx — call the helper at the top of the sortedTransactions callback around lines 296-316, before the existing RBR-priority short-circuit and before compareValues. This handles the report-detail transaction list.

A single shared helper (placed in TransactionUtils, next to isScanning) keeps the rule in one place.

3) No backend or schema changes.

Transaction.created keeps its real value. isScanning already derives from receipt.state (SCANNING / SCANREADY):

App/src/libs/TransactionUtils/index.ts

Lines 1428 to 1445 in ca84a2c

	function isScanning(transaction: OnyxEntry<Transaction>): boolean {
	// Performance optimization: Check the receipt state first (cheapest check) before doing more expensive checks
	if (!isReceiptBeingScanned(transaction)) {
	return false;
	}
	// SmartScan can continue in the background, but a manual amount edit should stop the scanning UI state.
	if (hasValidModifiedAmount(transaction)) {
	return false;
	}
	return isPartialTransaction(transaction) && hasReceipt(transaction);
	}
	function isReceiptBeingScanned(transaction: OnyxInputOrEntry<Transaction>): boolean {
	return transaction?.receipt?.state === CONST.IOU.RECEIPT_STATE.SCAN_READY || transaction?.receipt?.state === CONST.IOU.RECEIPT_STATE.SCANNING;
	}

Once SmartScan completes server-side and the receipt state transitions, isScanning returns false on the next Onyx update, and both the display branch and the sort short-circuit naturally fall through — the row reverts to its real date and its real chronological position with zero extra plumbing.

4) Tests.

• Unit-test the new sort helper directly (scanning vs non-scanning, scanning vs scanning, non-scanning vs non-scanning) — this is the highest-leverage test because it locks in the "regardless of sort direction" invariant.
• Snapshot or render-test TransactionItemRow with a scanning transaction to confirm the Date column renders "Scanning…" (we can use the same fixture pattern as the existing Merchant tests).
• Lightweight integration test on getSortedTransactionData to confirm a scanning row sorts to position 0 even when sortOrder = ASC and sortBy = AMOUNT.

What alternative solutions did you explore? (Optional)

A) Set a sentinel created timestamp (e.g. far-future date) for scanning transactions client-side so they naturally sort to the top under DESC.
Rejected. It corrupts the meaning of the created field, would have to be re-applied every time a scanning transaction round-trips through Onyx, only works for one sort direction (still wrong under ASC), and only fixes the Date sort — Amount/Merchant/etc. would still bury scanning rows. Adding a one-line priority short-circuit in the existing sort callbacks is strictly cleaner.

B) Render scanning transactions in a separate section above the main list.
Rejected as out of scope. It changes the list's structural model (sectioned vs flat), affects selection/checkbox behavior, virtualization, and all the existing column header/sort affordances. The reported behavior — "show 'Scanning' and float to top" — is achievable inside the existing flat list with two small, additive changes; a section split would be a much bigger redesign.

C) Conditionally hide the Date column entirely while scanning (render an empty cell).
Rejected. The cell would visually collapse and shift the row layout, and the user loses the explicit "Scanning…" affordance that already exists in the Merchant column. Showing the same 'Scanning…' string keeps the row visually balanced and consistent with the existing in-progress-scan treatment elsewhere in the row.

[oqildev]

Proposal

What is the root cause of that problem?

When a receipt is added via SmartScan, the transaction is created with created = "00:00:00 UTC today" (placeholder until OCR completes). The expense list/report sort uses that created value with no special-case for "still scanning," so freshly scanned receipts naturally land at the bottom of today's group instead of the top, and the date column renders the placeholder timestamp as if it were a real date.

The two hot spots:

1. The DateCell component formats created unconditionally — it has no awareness of scanning state:
   https://github.com/Expensify/App/blob/main/src/components/Search/SearchList/ListItem/DateCell.tsx#L14-L27

2. DateCell is rendered from TransactionItemRow in both layouts, but only createdAt is passed in — the isScanning(transactionItem) signal that already drives the merchant column (merchant = translate('iou.receiptStatusTitle')) is not forwarded:

• https://github.com/Expensify/App/blob/main/src/components/TransactionItemRow/index.tsx#L156-L167
• https://github.com/Expensify/App/blob/main/src/components/TransactionItemRow/index.tsx#L323-L335
• https://github.com/Expensify/App/blob/main/src/components/TransactionItemRow/index.tsx#L769-L775

3. The two sort paths treat scanning transactions like any other:

• Money request report view sort (already has an RBR-first tiebreaker; just needs a scanning-first one ahead of it):
  https://github.com/Expensify/App/blob/main/src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx#L285-L316
• Search results sort (the generic DATE branch falls through to plain compareValues on created):
  https://github.com/Expensify/App/blob/main/src/libs/SearchUIUtils.ts#L3759-L3777

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

1. Make DateCell show "Scanning" when the transaction is still being scanned, mirroring the merchant column convention:

- function DateCell({date, showTooltip, isLargeScreenWidth, suffixText}: DateCellProps) {
-     const styles = useThemeStyles();
-     const formattedDate = DateUtils.formatWithUTCTimeZone(date, DateUtils.doesDateBelongToAPastYear(date) ? CONST.DATE.MONTH_DAY_YEAR_ABBR_FORMAT : CONST.DATE.MONTH_DAY_ABBR_FORMAT);
-     const displayText = suffixText ? `${formattedDate} • ${suffixText}` : formattedDate;
+ function DateCell({date, showTooltip, isLargeScreenWidth, suffixText, isScanning}: DateCellProps) {
+     const styles = useThemeStyles();
+     const {translate} = useLocalize();
+     const formattedDate = isScanning
+         ? translate('iou.receiptStatusTitle')
+         : DateUtils.formatWithUTCTimeZone(date, DateUtils.doesDateBelongToAPastYear(date) ? CONST.DATE.MONTH_DAY_YEAR_ABBR_FORMAT : CONST.DATE.MONTH_DAY_ABBR_FORMAT);
+     const displayText = suffixText && !isScanning ? `${formattedDate} • ${suffixText}` : formattedDate;

Then in TransactionItemRow/index.tsx pass isScanning={isScanning(transactionItem)} to both <DateCell> call sites (large layout L329 and narrow layout L770). isScanning is already imported there (L50), so no extra wiring.

2. Pin scanning rows to the top of the list. In MoneyRequestReportTransactionList.tsx (L296–L316), add a scanning-first comparator that runs before the existing RBR/date logic:

  const sortedTransactions: TransactionWithOptionalHighlight[] = useMemo(() => {
      return [...transactions].sort((a, b) => {
+         const aScanning = isScanning(a);
+         const bScanning = isScanning(b);
+         if (aScanning !== bScanning) {
+             return aScanning ? -1 : 1;
+         }
          if (isDefaultSort && allTransactionViolations) {
              const rbrComparison = compareByRBR(...);
              if (rbrComparison !== 0) {
                  return rbrComparison;
              }
          }
          return compareValues(getTransactionSortValue(a, sortBy, report, policy), getTransactionSortValue(b, sortBy, report, policy), sortOrder, sortBy, localeCompare, true);
      });
  }, [...]);

The scanning short-circuit runs unconditionally (not just on default sort) so a user who clicks another column header still sees the scanning rows pinned on top — that matches the spirit of the request (find your fresh scan easily).

3. Apply the same scanning-first tiebreaker in SearchUIUtils.getSortedTransactionData (src/libs/SearchUIUtils.ts L3759–L3777) inside the generic sort branch, so the search/report views are consistent. One small helper (e.g. compareByScanning(a, b)) reused at both call sites keeps the logic in one place.

No backend/Onyx changes; relies on the existing isScanning(transaction) derivation from receipt state. The iou.receiptStatusTitle key ('Scanning…') is already localized, so no new translations needed.

What alternative solutions did you explore? (Optional)

• Backfill created with now() instead of 00:00:00 UTC so newly-scanned receipts naturally sort to today's top. Rejected — it lies about user intent (the actual receipt date comes from OCR and is usually not "now"), and it would re-shuffle once scanning completes, which is jarring. Keeping the placeholder and just overriding the display + sort is less invasive.
• Sort by pendingAction === ADD instead of isScanning. Rejected — that captures non-scan optimistic adds too (manual entries), which we don't want to mark as "Scanning."
• Push the "Scanning" label only when the merchant column is hidden. Rejected — the issue explicitly wants the date cell itself to read "Scanning," and hiding it conditionally just hides the problem on narrow layouts.

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

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

[Abdulloh0109]

Proposal

What is the root cause of that problem?

There are two distinct bugs — a display bug and a sorting bug — both rooted in the same missing isScanning check for the date field.

Display bug: In src/components/TransactionItemRow/index.tsx, the DateCell component is rendered at two sites for the created-date (DATE) column — the column-layout path at lines 329–334 and the narrow-layout path at lines 770–774 — both unconditionally passing createdAt (from getTransactionCreated) to DateCell. The codebase already has the correct pattern for this scenario: getMerchantName at lines 156–167 checks isScanning(transactionItem) and substitutes translate('iou.receiptStatusTitle') for the merchant string, and src/components/TransactionItemRow/DataCells/TotalCell.tsx:19–21 does the same inline before rendering amount text. The DATE column is the only display field that was never given this treatment.

Sorting bug: A scanning transaction's backend-assigned created value arrives as a date-only string (e.g., "2025-05-08" with no time component). When formatWithUTCTimeZone parses it, it resolves to UTC midnight that day. Lexicographically, "2025-05-08" sorts before "2025-05-08 14:35:00", so on the Search/Expenses page (default DATE/DESC sort), scanning receipts sink below same-day full-timestamp expenses. There are two independent sort paths that both lack a scanning-priority check:

1. getSortedTransactionData in src/libs/SearchUIUtils.ts — when sortBy === DATE, execution falls through to the generic comparator at line 3759, which calls getTransactionSortValue(a, 'date') returning transaction['date'] with no special scanning handling.
2. The sortedTransactions useMemo comparator in src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx lines 296–316 — calls getTransactionSortValue from ReportUtils.ts:13291 which returns getTransactionCreated(transaction), again the raw date string. This component already has an analogous priority mechanism — compareByRBR at lines 299–313 bumps violation-flagged transactions to the top under the default sort — but there is no equivalent for scanning transactions.

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

This is a frontend-only fix. isScanning in TransactionUtils/index.ts is already correct; no backend changes are needed. Four files are touched; no other files are modified.

1. src/components/Search/SearchList/ListItem/DateCell.tsx
Add an optional displayText?: string prop to the component type and the function signature. At the top of the function body, before computing formattedDate, return early with a TextWithTooltip rendering displayText (using the same style array) when displayText is present. This keeps DateCell general-purpose and reusable for SUBMITTED, APPROVED, POSTED, and EXPORTED columns, which must not receive this prop.

2. src/components/TransactionItemRow/index.tsx
isScanning is already imported at line 50 and translate is available from useLocalize at line 210. Add a derived constant const isTransactionScanning = isScanning(transactionItem) near where createdAt is computed at line 214. In the DATE column switch case (lines 323–335), pass displayText={translate('iou.receiptStatusTitle')} to DateCell when isTransactionScanning is true. Apply the same conditional at the narrow-layout render (lines 769–775). The SUBMITTED, APPROVED, POSTED, and EXPORTED DateCell renders are left untouched.

3. src/libs/SearchUIUtils.ts
Import isScanning from @libs/TransactionUtils. In getSortedTransactionData, add a special case branch for sortBy === CONST.SEARCH.TABLE_COLUMNS.DATE before the generic sortingProperty fallthrough (currently line 3666). Within that branch, sort the data such that any scanning transaction (where isScanning(a) is true) is placed before non-scanning ones, then fall back to the existing compareValues on date for items of the same scanning status. This ensures the behavior is confined to date-column sorting and does not affect user-selected sort columns such as MERCHANT, TOTAL, or CATEGORY.

4. src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx
Import isScanning from @libs/TransactionUtils. In the sortedTransactions comparator (lines 297–316), after the existing compareByRBR check (lines 299–313) and before the compareValues fallback at line 314, add a scanning-priority check guarded by isDefaultSort: if exactly one of a or b is scanning, return -1 or 1 to put the scanning transaction first. Guarding on isDefaultSort is intentional and mirrors the compareByRBR pattern — when the user has chosen a non-date sort column, the scanning override does not apply.

What alternative solutions did you explore? (Optional)

No prior proposals exist on this issue at the time of writing.

Rejected: modifying DateCell to accept isScanning directly. Coupling DateCell to the transaction's scanning concept would violate its role as a generic date display cell used for SUBMITTED, APPROVED, POSTED, and EXPORTED columns. A displayText override prop keeps the component agnostic.

Rejected: skipping DateCell when scanning and rendering null. Rendering nothing for the date of a scanning transaction leaves an empty column cell with no feedback. The merchant and total columns explicitly show "Scanning…" text for the same transaction state; the date column should be consistent.

Rejected: fixing only the display and not the sort. Even if "Scanning…" text is shown, the transaction can still be rendered below older expenses (in ASC order) or below same-day full-timestamp expenses (in DESC order) because the underlying date value remains a midnight-UTC date string. Both bugs need to be fixed together.

Rejected: applying scanning priority to all sort columns in getSortedTransactionData. If the user has explicitly chosen to sort by MERCHANT or TOTAL, forcing scanning transactions to the top overrides their intent. Limiting the priority to the DATE column sort (and isDefaultSort in the report view) is the correct scope.