[$250] Per Diem expense receipt icon not displayed

[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: 9.3.54-0
Reproducible in staging?: Yes, but not reproducible with Use Staging Server Off
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-16749/folder/13176674/53829876/1313414640
Email or phone of affected tester (no customers): applausetester+abr2dg@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Web
App Component: Other

Action Performed:

1. Create a per diem expense in the workspace chat
2. Open the expense report
3. Click Receipt and check the icon

Expected Result:

Per Diem expense receipt icon should displayed

Actual Result:

Per Diem expense receipt icon is not showing

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @FitseTLT

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022041774297409889091
• Upwork Job ID: 2041774297409889091
• Last Price Increase: 2026-04-08

[MelvinBot]

Proposal

What is the root cause of that problem?

The isPerDiemRequest() function in TransactionUtils/index.ts:253-263 uses Object.hasOwn(transaction, 'iouRequestType') to check whether to use the client-only iouRequestType field. This check returns true if the key exists on the object — even if its value is null or undefined. After the transaction syncs with the server, if the server response includes iouRequestType with a falsy value (e.g., null), the function short-circuits and returns false without ever reaching the reliable fallback check (comment.type === 'customUnit' && comment.customUnit.name === 'Per Diem International').

This causes isPerDiemRequest() to return false post-sync, which means EReceiptThumbnail doesn't render the CalendarSolid icon, and ReceiptImage doesn't route the transaction through the per diem rendering path.

The same Object.hasOwn pattern exists in isDistanceRequest, isScanRequest, isTimeRequest, and other type-detection functions at lines 145, 161, 190, 200, 210, 226, 241, 267, 367 — all potentially affected by the same issue.

A secondary contributing factor: hasEReceipt is set optimistically (PerDiem.ts:419) but could also be overwritten by the server response, causing the transaction to lose its eReceipt status entirely.

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

In isPerDiemRequest() (and the other request-type functions), change the guard from checking key existence to checking key value:

// Before
if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
    return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.PER_DIEM;
}

// After
if (transaction?.iouRequestType) {
    return transaction.iouRequestType === CONST.IOU.REQUEST_TYPE.PER_DIEM;
}

This ensures that when iouRequestType is null/undefined after server sync, the function falls through to the server-side field check (comment.type + comment.customUnit.name) which is the authoritative source of truth for persisted transactions.

Apply the same fix to all the other Object.hasOwn(transaction, 'iouRequestType') call sites in TransactionUtils.

What alternative solutions did you explore? (Optional)

An alternative would be to explicitly delete the iouRequestType key from the transaction in the successData callback, ensuring it doesn't persist after server sync. However, this is more fragile since Pusher updates could re-introduce the field. The proposed fix makes the detection logic robust regardless of what the server returns.

Investigation details

Rendering chain for per diem receipt icon:

1. MoneyRequestReceiptView → checks hasReceipt() (which includes hasEReceipt) → renders ReportActionItemImage
2. ReportActionItemImage:144 → isEReceipt = !hasReceiptSource(transaction) && hasEReceipt(transaction) → sets propsObj.isPerDiemRequest at line 180
3. ReceiptImage:191-214 → routes isEReceipt && isPerDiemRequest to EReceiptThumbnail
4. EReceiptThumbnail:112-119 → renders CalendarSolid icon only when internal isPerDiemRequest() check returns true

Why staging-only: The staging server likely includes iouRequestType in its transaction response (possibly as part of a newer backend version), while production does not. When the staging response merges into Onyx with a falsy iouRequestType value, Object.hasOwn returns true but the value comparison fails.

Affected call sites: Lines 145, 161, 190, 200, 210, 226, 241, 255, 267, 367 in TransactionUtils/index.ts

---

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

[melvin-bot]

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

[Abdullahtmk]

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

When a user creates a per diem expense in the workspace chat and then opens the expense report to check the receipt, the per diem expense receipt icon is not displayed, even though it should show a receipt indicator.

What is the root cause of that problem?

The receipt icon display logic likely checks for a transaction's receipt or receipt state, but per diem expenses may not have a receipt object or may have a different receipt state indicator than regular expenses. The receipt icon rendering component skips displaying the icon when it cannot find the expected receipt data structure for per diem transactions.

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

Locate the receipt icon display component (likely in src/components/AttachmentPreview.tsx or receipt-related files) and update the logic to handle per diem expenses:

// Before: Only shows icon for transactions with receipt object
const hasReceipt = transaction?.receipt?.source;

// After: Show icon for either regular receipts OR per diem transactions
const isPDMExpense = transaction?.isPolicyExpense && transaction?.receipt?.receiptObject?.receiptType === 'per_diem';
const hasReceipt = transaction?.receipt?.source || isPDMExpense;

if (hasReceipt) {
    return <ReceiptIcon />;
}

Alternatively, if the per diem receipt icon is handled separately, ensure the per diem expense creation flow (likely in src/libs/actions/IOU.ts) sets the appropriate receipt indicator flag that the display logic checks for.

What alternative solutions did you explore? (Optional)

• Add special per diem receipt type: If per diem already has a distinct receipt type, ensure it's being set during creation
• Update receipt display conditions: Check for policy expense type in addition to receipt existence

Why this works: Routes the per diem receipt display through the same icon rendering logic as regular expenses, ensuring visual consistency.

[yuvrajangadsingh]

Proposal

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

After creating a per diem expense on staging, the receipt calendar icon is missing. The per diem eReceipt thumbnail doesn't render, leaving a blank receipt area.

What is the root cause of that problem?

The isPerDiemRequest() function in src/libs/TransactionUtils/index.ts:252-262 guards on Object.hasOwn(transaction, 'iouRequestType') before checking the value. When the staging server returns the transaction with iouRequestType set to a falsy value (null or empty string), Object.hasOwn returns true, the value comparison against CONST.IOU.REQUEST_TYPE.PER_DIEM fails, and the function returns false. It never reaches the reliable server-side fallback at line 259-261 that checks comment.type === 'customUnit' && comment.customUnit.name.

This breaks the rendering chain at multiple points:

1. Main receipt view (src/components/ReportActionItem/ReportActionItemImage.tsx:178): propsObj.isPerDiemRequest is set to false, so ReceiptImage at src/components/ReceiptImage/index.tsx:201 never takes the isEReceipt && isPerDiemRequest branch, and EReceiptThumbnail (which renders the CalendarSolid icon at src/components/EReceiptThumbnail.tsx:112-119) is never mounted.

2. Attachment view (src/components/Attachments/AttachmentView/index.tsx:204): isPerDiemRequest(transaction) returns false, so PerDiemEReceipt is skipped entirely.

3. Receipt cell in search (src/components/TransactionItemRow/DataCells/ReceiptCell.tsx:40): isPerDiem evaluates to false.

4. Receipt preview on hover (src/components/TransactionItemRow/ReceiptPreview/index.tsx:38): isPerDiemEReceipt evaluates to false.

This explains the staging-only behavior: production doesn't return iouRequestType in the server response, so Object.hasOwn is false and the fallback check runs correctly. Staging includes the field with a falsy value, short-circuiting the logic.

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

In src/libs/TransactionUtils/index.ts, change the guard in isPerDiemRequest (and all sibling functions using the same pattern) from checking key existence to checking value truthiness:

// Before (line 254)
if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
    return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.PER_DIEM;
}

// After
if (transaction?.iouRequestType) {
    return transaction.iouRequestType === CONST.IOU.REQUEST_TYPE.PER_DIEM;
}

Apply the same change to all functions with the identical Object.hasOwn(transaction, 'iouRequestType') pattern:

• isDistanceRequest (line 144)
• isDistanceTypeRequest (line 160)
• isMapDistanceRequest (line 189)
• isGPSDistanceRequest (line 199)
• isManualDistanceRequest (line 209)
• isOdometerDistanceRequest (line 225)
• isScanRequest (line 240)
• isPerDiemRequest (line 254)
• isTimeRequest (line 266)

When iouRequestType is null/undefined after server sync, the function falls through to the server-side field check, which is the authoritative source of truth for persisted transactions.

What alternative solutions did you explore? (Optional)

Could strip the iouRequestType key in successData callbacks after server sync. But that's fragile since Pusher updates can re-add it. The value-check fix makes detection logic robust regardless of what the server sends back.

[marufsharifi]

Proposal

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

Per diem expenses should show the per diem receipt icon when the user opens the receipt from the expense report, but after the transaction syncs, the icon is not shown.

What is the root cause of that problem?

The root cause is in isPerDiemRequest() in src/libs/TransactionUtils/index.ts

App/src/libs/TransactionUtils/index.ts

Lines 253 to 262 in d1dbbcb

	function isPerDiemRequest(transaction: OnyxEntry<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.PER_DIEM;
	}
	// This is the case for transaction objects once they have been saved to the server
	const type = transaction?.comment?.type;
	const customUnitName = transaction?.comment?.customUnit?.name;
	return type === CONST.TRANSACTION.TYPE.CUSTOM_UNIT && customUnitName === CONST.CUSTOM_UNITS.NAME_PER_DIEM_INTERNATIONAL;

Today it does this:

• It first checks Object.hasOwn(transaction, 'iouRequestType')
• If that key exists, it returns only based on transaction.iouRequestType === CONST.IOU.REQUEST_TYPE.PER_DIEM
• It never falls back to the persisted server-side check (comment.type === CUSTOM_UNIT and comment.customUnit.name === 'Per Diem International')

That is incorrect because iouRequestType is an optimistic/client-side field. After sync, the transaction can still contain the iouRequestType key with a nullish value, so this branch returns false too early even though the persisted transaction data still clearly identifies the transaction as per diem.

That incorrect classification then flows into the receipt rendering path, so the UI stops treating the transaction as a per diem receipt and the icon disappears.

The same key-existence pattern is also used in the sibling request-type helpers in the same file:
src/libs/TransactionUtils/index.ts

App/src/libs/TransactionUtils/index.ts

Lines 145 to 268 in d1dbbcb

	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return (
	transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE ||
	transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_MAP ||
	transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_ODOMETER ||
	transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_GPS ||
	transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_MANUAL
	);
	}
	// This is the case for transaction objects once they have been saved to the server
	return hasDistanceCustomUnit(transaction);
	}
	function isDistanceTypeRequest(transaction: OnyxEntry<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE;
	}
	// This is the case for transaction objects once they have been saved to the server
	return hasDistanceCustomUnit(transaction);
	}
	/**
	* todo: Currently there is no way to tell server map transaction object from
	* server GPS transaction object, this will be discussed and updated later.
	* To fix this temporarily we set keyForList of GPS waypoints to 'gps_start' and 'gps_end'
	* and use that to determine if it's a GPS or Map transaction. This should be changed before
	* the first GPS release.
	*/
	function hasGPSWaypoints(transaction: OnyxEntry<Transaction>) {
	const waypoints = transaction?.comment?.waypoints;
	if (!waypoints) {
	return false;
	}
	const waypoint = Object.values(waypoints).at(0);
	return !!waypoint?.keyForList?.startsWith('gps');
	}
	function isMapDistanceRequest(transaction: OnyxEntry<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_MAP;
	}
	// This is the case for transaction objects once they have been saved to the server
	return hasDistanceCustomUnit(transaction) && !hasGPSWaypoints(transaction);
	}
	function isGPSDistanceRequest(transaction: OnyxEntry<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_GPS;
	}
	// This is the case for transaction objects once they have been saved to the server
	return hasGPSWaypoints(transaction);
	}
	function isManualDistanceRequest(transaction: OnyxEntry<Transaction>, isUpdatedMergeTransaction = false): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType') && !isUpdatedMergeTransaction) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_MANUAL;
	}
	// This is the case for transaction objects once they have been saved to the server
	// Exclude odometer requests which also have no waypoints but have odometer readings
	return (
	hasDistanceCustomUnit(transaction) &&
	isEmptyObject(transaction?.comment?.waypoints) &&
	transaction?.comment?.odometerStart === undefined &&
	transaction?.comment?.odometerEnd === undefined
	);
	}
	function isOdometerDistanceRequest(transaction: OnyxEntry<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_ODOMETER;
	}
	// This is the case for transaction objects once they have been saved to the server
	// Odometer requests have odometerStart and odometerEnd in comment, and no waypoints
	return (
	hasDistanceCustomUnit(transaction) &&
	isEmptyObject(transaction?.comment?.waypoints) &&
	(transaction?.comment?.odometerStart !== undefined || transaction?.comment?.odometerEnd !== undefined)
	);
	}
	function isScanRequest(transaction: OnyxEntry<Transaction> | Partial<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.SCAN;
	}
	// Distance requests can have a receipt source (for the map), so we need to exclude them
	if (hasDistanceCustomUnit(transaction)) {
	return false;
	}
	return !!transaction?.receipt?.source && transaction?.amount === 0;
	}
	function isPerDiemRequest(transaction: OnyxEntry<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.PER_DIEM;
	}
	// This is the case for transaction objects once they have been saved to the server
	const type = transaction?.comment?.type;
	const customUnitName = transaction?.comment?.customUnit?.name;
	return type === CONST.TRANSACTION.TYPE.CUSTOM_UNIT && customUnitName === CONST.CUSTOM_UNITS.NAME_PER_DIEM_INTERNATIONAL;
	}
	function isTimeRequest(transaction: OnyxEntry<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.TIME;

src/libs/TransactionUtils/index.ts

App/src/libs/TransactionUtils/index.ts

Lines 367 to 369 in d1dbbcb

	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction.iouRequestType === CONST.IOU.REQUEST_TYPE.MANUAL;
	}

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

In src/libs/TransactionUtils/index.ts, we should stop treating the mere existence of iouRequestType as authoritative.

App/src/libs/TransactionUtils/index.ts

Lines 145 to 268 in d1dbbcb

	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return (
	transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE ||
	transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_MAP ||
	transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_ODOMETER ||
	transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_GPS ||
	transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_MANUAL
	);
	}
	// This is the case for transaction objects once they have been saved to the server
	return hasDistanceCustomUnit(transaction);
	}
	function isDistanceTypeRequest(transaction: OnyxEntry<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE;
	}
	// This is the case for transaction objects once they have been saved to the server
	return hasDistanceCustomUnit(transaction);
	}
	/**
	* todo: Currently there is no way to tell server map transaction object from
	* server GPS transaction object, this will be discussed and updated later.
	* To fix this temporarily we set keyForList of GPS waypoints to 'gps_start' and 'gps_end'
	* and use that to determine if it's a GPS or Map transaction. This should be changed before
	* the first GPS release.
	*/
	function hasGPSWaypoints(transaction: OnyxEntry<Transaction>) {
	const waypoints = transaction?.comment?.waypoints;
	if (!waypoints) {
	return false;
	}
	const waypoint = Object.values(waypoints).at(0);
	return !!waypoint?.keyForList?.startsWith('gps');
	}
	function isMapDistanceRequest(transaction: OnyxEntry<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_MAP;
	}
	// This is the case for transaction objects once they have been saved to the server
	return hasDistanceCustomUnit(transaction) && !hasGPSWaypoints(transaction);
	}
	function isGPSDistanceRequest(transaction: OnyxEntry<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_GPS;
	}
	// This is the case for transaction objects once they have been saved to the server
	return hasGPSWaypoints(transaction);
	}
	function isManualDistanceRequest(transaction: OnyxEntry<Transaction>, isUpdatedMergeTransaction = false): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType') && !isUpdatedMergeTransaction) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_MANUAL;
	}
	// This is the case for transaction objects once they have been saved to the server
	// Exclude odometer requests which also have no waypoints but have odometer readings
	return (
	hasDistanceCustomUnit(transaction) &&
	isEmptyObject(transaction?.comment?.waypoints) &&
	transaction?.comment?.odometerStart === undefined &&
	transaction?.comment?.odometerEnd === undefined
	);
	}
	function isOdometerDistanceRequest(transaction: OnyxEntry<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE_ODOMETER;
	}
	// This is the case for transaction objects once they have been saved to the server
	// Odometer requests have odometerStart and odometerEnd in comment, and no waypoints
	return (
	hasDistanceCustomUnit(transaction) &&
	isEmptyObject(transaction?.comment?.waypoints) &&
	(transaction?.comment?.odometerStart !== undefined || transaction?.comment?.odometerEnd !== undefined)
	);
	}
	function isScanRequest(transaction: OnyxEntry<Transaction> | Partial<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.SCAN;
	}
	// Distance requests can have a receipt source (for the map), so we need to exclude them
	if (hasDistanceCustomUnit(transaction)) {
	return false;
	}
	return !!transaction?.receipt?.source && transaction?.amount === 0;
	}
	function isPerDiemRequest(transaction: OnyxEntry<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.PER_DIEM;
	}
	// This is the case for transaction objects once they have been saved to the server
	const type = transaction?.comment?.type;
	const customUnitName = transaction?.comment?.customUnit?.name;
	return type === CONST.TRANSACTION.TYPE.CUSTOM_UNIT && customUnitName === CONST.CUSTOM_UNITS.NAME_PER_DIEM_INTERNATIONAL;
	}
	function isTimeRequest(transaction: OnyxEntry<Transaction>): boolean {
	// This is used during the expense creation flow before the transaction has been saved to the server
	if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
	return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.TIME;

Instead, we should only use the optimistic path when iouRequestType has a defined value. If it is null or undefined, we should fall back to the persisted transaction data.

Minimal diff:

diff --git a/src/libs/TransactionUtils/index.ts b/src/libs/TransactionUtils/index.ts
@@
 function hasDistanceCustomUnit(transaction: OnyxEntry<Transaction> | Partial<Transaction>): boolean {
     return transaction?.comment?.type === CONST.TRANSACTION.TYPE.CUSTOM_UNIT && transaction?.comment?.customUnit?.name === CONST.CUSTOM_UNITS.NAME_DISTANCE;
 }
+
+function hasOptimisticIOURequestType(transaction: OnyxEntry<Transaction> | Partial<Transaction>): transaction is (Transaction | Partial<Transaction>) & {iouRequestType: IOURequestType} {
+    return transaction?.iouRequestType !== undefined && transaction?.iouRequestType !== null;
+}
@@
 function isPerDiemRequest(transaction: OnyxEntry<Transaction>): boolean {
-    if (transaction && Object.hasOwn(transaction, 'iouRequestType')) {
-        return transaction?.iouRequestType === CONST.IOU.REQUEST_TYPE.PER_DIEM;
+    if (hasOptimisticIOURequestType(transaction)) {
+        return transaction.iouRequestType === CONST.IOU.REQUEST_TYPE.PER_DIEM;
     }

     const type = transaction?.comment?.type;
     const customUnitName = transaction?.comment?.customUnit?.name;
     return type === CONST.TRANSACTION.TYPE.CUSTOM_UNIT && customUnitName === CONST.CUSTOM_UNITS.NAME_PER_DIEM_INTERNATIONAL;
 }

The same replacement should be applied to the other helpers that use the same pattern in this file:

• isDistanceRequest
• isDistanceTypeRequest
• isMapDistanceRequest
• isGPSDistanceRequest
• isManualDistanceRequest
• isOdometerDistanceRequest
• isScanRequest
• isTimeRequest
• isManualRequest

This keeps the fix localized to the source of truth for transaction type detection, avoids touching receipt UI code, and prevents the same nullish iouRequestType bug from affecting adjacent request-type logic.

Video demo of fix:

per-diem-icon.webm

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)

I considered two alternatives:

1. Fix it in the receipt UI components.
   This is not the right place to fix it because the rendering code is already behaving correctly based on the transaction classification it receives. The bug starts earlier in TransactionUtils.

2. Delete or clean up iouRequestType after sync.
   This is more fragile because it depends on every merge/update path removing the field correctly. Fixing the detection logic is more robust because it works even if iouRequestType is present but nullish.