[Due for payment 2026-07-08] [$250] Duplicate resolver - don't show the "Choose if transaction is reimbursable" step if one of the expenses is a managed card transaction

[trjExpensify]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: v9.4.18-2
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack: No
Email or phone of affected tester (no customers): In thread
Logs: Logs
Issue reported by: @mgrumbles
Slack conversation (hyperlinked to channel name): #expensify-bugs

Action Performed:

1. Create a workspace
2. Connect a company card feed
3. Import some transactions
4. Add a cash expense for one of the transactions
5. Click "Resolve duplicates" on the expense
6. Go through the steps and observe "Choose if transaction is reimbursable" is shown as a step

Expected Result:

We should not show that step if one of the selected transactions is a managed card transaction. The card transaction should always be non-reimbursable.

Actual Result:

The user was shown that step > selected reimbursable > and now has a corp card transaction stuck as reimbursable: true with no recourse to fix it in the product.

Workaround:

None in-product, so we have to spend engineering time to fix it via a CQ.

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022070456902260469869
• Upwork Job ID: 2070456902260469869
• Last Price Increase: 2026-06-26

Issue Owner

Current Issue Owner: @abzokhattab

[MelvinBot]

Proposal

What is the root cause of that problem?

The duplicate resolver decides which review steps to show by comparing field values across the duplicate set in compareDuplicateTransactionFields. For reimbursable, it falls into the generic branch — if the values differ across transactions it adds reimbursable to the change map, which becomes a visible step:

src/libs/TransactionUtils/index.ts:2610-2613

This comparison has no awareness of card transactions. When a manually-added cash expense (reimbursable: true) is a duplicate of a managed company-card transaction (reimbursable: false), the values differ, so the “Choose if transaction is reimbursable” step is shown. The user can pick reimbursable, and that value is persisted on the merged transaction via buildMergeDuplicatesParams → leaving a corporate-card transaction stuck as reimbursable: true with no in-product way to correct it. Company-card transactions must always be non-reimbursable.

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

In compareDuplicateTransactionFields, add a dedicated branch for reimbursable (alongside the existing merchant/taxCode/category/tag special-cases) that checks whether any transaction in the set is a managed card transaction using the existing isManagedCardTransaction util:

• If transactions.some(isManagedCardTransaction) → set keep.reimbursable = false and do not add it to change.
• Otherwise → keep the current behavior (equal → keep, differ → change).

This is sufficient because:

• Object.keys(change) is exactly the list of steps shown, so dropping reimbursable from change removes the step everywhere (ReviewReimbursable.tsx, navigation, confirmation all recompute the same result).
• keep.reimbursable = false is seeded into the REVIEW_DUPLICATES Onyx state in getReviewNavigationRoute (...comparisonResult.keep), and the merge then reads reviewDuplicates?.reimbursable ?? false → the merged transaction correctly stays non-reimbursable.

Evidence trace

1. Step list = Object.keys(compareResult.change), recomputed per screen — e.g. ReviewReimbursable.tsx.
2. reimbursable added to change only when values differ: index.ts:2610-2613.
3. Card detector: isManagedCardTransaction index.ts:1349 (already exported, returns !!transaction?.managedCard).
4. keep → Onyx seed: TransactionPreviewUtils.ts:80-89.
5. Final persisted value: buildMergeDuplicatesParams index.ts:2660 → reimbursable: reviewDuplicates?.reimbursable ?? false.

Alternative considered & rejected: Hiding only the toggle UI in ReviewReimbursable.tsx would still leave reimbursable in change, so the step would still appear in the flow and the value would remain user-driven. Gating at the comparison source is the single correct fix point.

One caveat to verify: this relies on transaction.managedCard being populated on the imported card transaction client-side. Given the repro connects a company-card feed, that should hold, but it's worth confirming during implementation.

What alternative solutions did you explore? (Optional)

Use the narrower isCorporateCardTransaction (managed + liabilityType RESTRICT) instead of isManagedCardTransaction. The issue describes “managed card,” and any centrally-managed card must be non-reimbursable, so the broader isManagedCardTransaction is the better match.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94679) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

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

When resolving duplicate transactions where one of the duplicates is a centrally managed card transaction (Expensify Card or Company Card) and another is a cash expense, the resolver shows the "Choose if transaction is reimbursable" step. If the user selects "Yes", the merged result is a managed card transaction stuck at reimbursable: true, which is an invalid state with no in-product way to correct it. Managed card transactions must always be non-reimbursable, so that step should never appear when any duplicate is a managed card transaction.

What is the root cause of that problem?

The duplicate resolver builds its list of review steps from the change object returned by compareDuplicateTransactionFields in src/libs/TransactionUtils/index.ts. For each field in fieldsToCompare (which includes reimbursable: ['reimbursable']), the function checks whether the value is identical across all transactions. If they match it stores the value in keep (no step), and if they differ it calls processChanges, which writes the field into change and thereby turns it into a review step:

App/src/libs/TransactionUtils/index.ts

Lines 2610 to 2614 in 76bc375

	} else if (areAllFieldsEqualForKey) {
	keep[fieldName] = firstTransaction?.[keys[0]] ?? firstTransaction?.[keys[1]];
	} else {
	processChanges(fieldName, transactions, keys);
	}

A cash expense is reimbursable: true while a managed card transaction is reimbursable: false. Because the two values differ, areAllFieldsEqualForKey is false, so reimbursable lands in change and the step is rendered. getReviewNavigationRoute routes into the reimbursable page whenever comparisonResult.change.reimbursable exists, and every Review* page derives its step list from Object.keys(compareResult.change) — so there is no guard anywhere that suppresses the step for card transactions.

The downstream consequence is the actual data corruption. When the user picks "Yes", setReviewDuplicatesKey({reimbursable: true}) is stored, and on confirm buildMergeDuplicatesParams reads it straight through with reimbursable: reviewDuplicates?.reimbursable ?? false, so the merge request writes reimbursable: true onto a managed card transaction:

App/src/libs/TransactionUtils/index.ts

Lines 2659 to 2660 in 76bc375

	billable: reviewDuplicates?.billable ?? false,
	reimbursable: reviewDuplicates?.reimbursable ?? false,

So the root cause is that compareDuplicateTransactionFields treats reimbursable as a freely-editable field even when one of the duplicates is a managed card transaction, where the value is not actually a user choice — it is constrained to false.

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

Special-case reimbursable inside the field loop of compareDuplicateTransactionFields so that when any transaction being compared is a managed card transaction, we force the value into keep as false and never add it to change. The codebase already has the exact predicate — isManagedCardTransaction (returns !!transaction?.managedCard, covers both Expensify and Company cards). Add a branch alongside the existing taxCode/category/tag cases:

} else if (fieldName === 'reimbursable') {
    if (transactions.some((item) => isManagedCardTransaction(item))) {
        keep[fieldName] = false; // managed card transactions are always non-reimbursable
    } else if (areAllFieldsEqualForKey) {
        keep[fieldName] = firstTransaction?.reimbursable;
    } else {
        processChanges(fieldName, transactions, keys);
    }
}

The change object never receives a reimbursable key when a managed card is present, so the step disappears in all three consumers (getReviewNavigationRoute, useReviewDuplicatesNavigation, and ReviewReimbursable) without touching their logic. Putting false into keep flows through setReviewDuplicatesKey({...comparisonResult.keep, ...}), so buildMergeDuplicatesParams resolves reimbursable to false and the merged transaction stays non-reimbursable. When no managed card is involved, the existing equal/different behavior is preserved exactly. transactions here is already the result of removeSettledAndApprovedTransactions, so we only inspect the transactions that actually participate in the merge.

Behavior across every duplicate combination:

Duplicate set	some(isManagedCardTransaction)	Result
managed card + cash	true	keep.reimbursable = false, no step (the bug)
managed card + managed card	true	keep.reimbursable = false (already non-reimbursable; also self-heals a corrupt true)
cash + cash	false	existing equal/processChanges logic, step shown when values differ (no regression)
managed card + cash + cash (3-way)	true	keep.reimbursable = false

I used isManagedCardTransaction rather than a broader card check on purpose: isFromCreditCardImport also matches personal-card / CSV imports that can legitimately be reimbursable, and isCorporateCardTransaction is narrower than needed (managed and liabilityType: RESTRICT). Any managed card must be non-reimbursable regardless of liability type, so isManagedCardTransaction (managedCard) is the precise predicate.

I verified this against a real managed company-card transaction duplicated with a cash expense: the pair is {reimbursable: true, managedCard: false} (cash) and {reimbursable: false, managedCard: true} (card), isManagedCardTransaction returns true for the card, and with the guard the reimbursable step is dropped and the outgoing MergeDuplicates request carries reimbursable: false instead of true.

compareDuplicateTransactionFields is pure and unit-testable: managed card + cash with differing reimbursable should yield keep.reimbursable === false with no reimbursable key in change, while cash + cash with differing reimbursable should still surface the step.

What alternative solutions did you explore? (Optional)

Clamp reimbursable to false only at the write boundary in buildMergeDuplicatesParams. That fixes the corrupted data but still displays the misleading reimbursable step, which the issue explicitly asks us to remove — so handling it at the comparison source is the correct fix. A page/navigation-layer guard was also rejected: the step list is regenerated from change keys independently on each Review* page, so it would leave change.reimbursable populated and the merge could still persist a reimbursable card transaction. The comparison-sou

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The duplicate resolver decides which review steps to show by diffing the candidate transactions field-by-field in compareDuplicateTransactionFields. reimbursable is one of those fields:

App/src/libs/TransactionUtils/index.ts

Lines 2492 to 2500 in b396890

	const fieldsToCompare: FieldsToCompare = {
	merchant: ['modifiedMerchant', 'merchant'],
	category: ['category'],
	tag: ['tag'],
	description: ['comment'],
	taxCode: ['taxCode'],
	billable: ['billable'],
	reimbursable: ['reimbursable'],
	};

It has no dedicated handler, so it falls into the generic branch — if the values are not all equal it is pushed into change via processChanges:

App/src/libs/TransactionUtils/index.ts

Lines 2610 to 2614 in b396890

	} else if (areAllFieldsEqualForKey) {
	keep[fieldName] = firstTransaction?.[keys[0]] ?? firstTransaction?.[keys[1]];
	} else {
	processChanges(fieldName, transactions, keys);
	}

A managed card transaction is always reimbursable: false, while the manually-added cash expense is reimbursable: true. The two values differ, so change.reimbursable is populated, and getReviewNavigationRoute consequently routes the user into the reimbursable step:

App/src/libs/TransactionPreviewUtils.ts

Lines 109 to 111 in b396890

	if (comparisonResult.change.reimbursable) {
	return ROUTES.TRANSACTION_DUPLICATE_REVIEW_REIMBURSABLE_PAGE.getRoute(threadReportID, backTo);
	}

App/src/pages/TransactionDuplicate/Review.tsx

Line 191 in b396890

getReviewNavigationRoute(

If the user then selects "Yes", keep.reimbursable becomes true and the merged transaction is built non-reimbursable-blind from that key:

App/src/libs/TransactionUtils/index.ts

Line 2660 in b396890

reimbursable: reviewDuplicates?.reimbursable ?? false,

So: card txn reimbursable:false + cash txn reimbursable:true → values differ → change.reimbursable set → reimbursable step shown → user can pick "Yes" → the corp card transaction is merged as reimbursable: true with no in-product way to undo it.

This is not platform-specific (the report just happens to be MacOS Chrome) — it is plain comparison logic, so it reproduces everywhere, and it reproduces in production because the step has always been unguarded. The confirmation page re-derives the same compareResult from this exact function (Confirmation.tsx), so the central comparison is the single convergence point for the step decision, the step page, and the final merge.

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

Give reimbursable its own branch in compareDuplicateTransactionFields (right beside the existing billable/generic handling at L2610-L2614). When any transaction in the set is a managed card transaction, force-keep false and never add it to change:

} else if (fieldName === 'reimbursable') {
    if (transactions.some(isManagedCardTransaction)) {
        keep[fieldName] = false;
    } else if (areAllFieldsEqualForKey) {
        keep[fieldName] = firstTransaction?.[keys[0]];
    } else {
        processChanges(fieldName, transactions, keys);
    }
}

isManagedCardTransaction is the existing canonical helper, already defined in this same file, so it is in scope with no new import:

App/src/libs/TransactionUtils/index.ts

Lines 1346 to 1351 in b396890

	/**
	* Determine whether a transaction is made with a centrally managed card (Expensify or Company Card).
	*/
	function isManagedCardTransaction(transaction: OnyxEntry<Pick<Transaction, 'managedCard'>>): boolean {
	return !!transaction?.managedCard;
	}

Because change.reimbursable stays empty, getReviewNavigationRoute skips the reimbursable step, and because keep.reimbursable = false is persisted via setReviewDuplicatesKey, buildNewTransactionAfterReviewingDuplicates (L2660) merges the card transaction as non-reimbursable. One change fixes the step list, the step page, and the final merge. Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Guard the step only at the navigation layer in getReviewNavigationRoute (L109-L111) by checking the duplicates for a managed card. Rejected: that only hides the step — compareResult.change.reimbursable would still be set, Confirmation.tsx re-derives it independently, and keep.reimbursable would never be forced to false, so the merged transaction could still end up reimbursable. Fixing it inside compareDuplicateTransactionFields addresses the root cause at the single source all three consumers read from.

[aswin-s]

Proposal

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

When a user clicks "Resolve duplicates" on a cash expense that was matched with a managed card transaction, the duplicate review wizard shows a "Choose if transaction is reimbursable" step. This step should never be shown when any of the duplicates is a managed card transaction, because card transactions must always be non-reimbursable. Showing the step allows users to incorrectly mark the merged expense as reimbursable, leaving the corp card transaction stuck as reimbursable: true with no in-product fix.

What is the root cause of that problem?

In src/libs/TransactionPreviewUtils.ts at lines 109–111, getReviewNavigationRoute routes to the reimbursable review page whenever comparisonResult.change.reimbursable is truthy. That value is produced by compareDuplicateTransactionFields in src/libs/TransactionUtils/index.ts (around line 2506), where reimbursable is listed in fieldsToCompare unconditionally — it compares the raw reimbursable field across all transactions with no check for whether any transaction is a managed card transaction. When a managed card transaction (non-reimbursable) is paired with a cash expense (reimbursable), the values differ and the step is emitted, allowing the user to set an incorrect value.

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

1. src/libs/TransactionUtils/index.ts — compareDuplicateTransactionFields: Before processing the reimbursable field in the fieldsToCompare loop, check whether any transaction in the set is a managed card transaction (using the existing isManagedCardTransaction util). If one is, force reimbursable into keep as false and skip adding it to change, so the step is never surfaced.

2. src/libs/TransactionPreviewUtils.ts lines 109–111: No change needed to the routing logic itself — fixing the upstream compareDuplicateTransactionFields to never populate change.reimbursable when a managed card is involved is sufficient to prevent this branch from being reached.

3. src/libs/actions/IOU/Duplicate.ts — resolveDuplicates / mergeDuplicates: Verify (and if needed enforce) that when a managed card transaction is one of the duplicates, the resolved transaction always gets reimbursable: false regardless of what reviewDuplicates contains — as a safety net against any other path that might set reimbursable: true.

What alternative solutions did you explore? (Optional)

Alternatively, gate the reimbursable step in getReviewNavigationRoute directly by checking isManagedCardTransaction on the transaction set before evaluating comparisonResult.change.reimbursable, keeping the comparison logic unchanged.

[x-dev90]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-26 13:13:23 UTC.

Proposal

What is the root cause of that problem?

compareDuplicateTransactionFields() always includes reimbursable in the generic duplicate comparison list:

App/src/libs/TransactionUtils/index.ts

Lines 2492 to 2500 in 76bc375

	const fieldsToCompare: FieldsToCompare = {
	merchant: ['modifiedMerchant', 'merchant'],
	category: ['category'],
	tag: ['tag'],
	description: ['comment'],
	taxCode: ['taxCode'],
	billable: ['billable'],
	reimbursable: ['reimbursable'],
	};

When the selected transaction and its duplicates have different raw reimbursable values, the generic comparison path adds reimbursable to change:

App/src/libs/TransactionUtils/index.ts

Lines 2610 to 2614 in 76bc375

	} else if (areAllFieldsEqualForKey) {
	keep[fieldName] = firstTransaction?.[keys[0]] ?? firstTransaction?.[keys[1]];
	} else {
	processChanges(fieldName, transactions, keys);
	}

That change.reimbursable value drives the duplicate review flow. getReviewNavigationRoute() routes to the reimbursable review page whenever it exists:

App/src/libs/TransactionPreviewUtils.ts

Lines 80 to 110 in 76bc375

	const comparisonResult = compareDuplicateTransactionFields(policyTags, transaction, duplicates, transactionReport, transaction?.transactionID, policy, policyCategories);
	setReviewDuplicatesKey(
	{
	...comparisonResult.keep,
	duplicates: duplicates.map((duplicate) => duplicate?.transactionID).filter(Boolean) as string[],
	transactionID: transaction?.transactionID,
	reportID: transaction?.reportID,
	},
	true,
	);
	if (comparisonResult.change.merchant) {
	return ROUTES.TRANSACTION_DUPLICATE_REVIEW_MERCHANT_PAGE.getRoute(threadReportID, backTo);
	}
	if (comparisonResult.change.category) {
	return ROUTES.TRANSACTION_DUPLICATE_REVIEW_CATEGORY_PAGE.getRoute(threadReportID, backTo);
	}
	if (comparisonResult.change.tag) {
	return ROUTES.TRANSACTION_DUPLICATE_REVIEW_TAG_PAGE.getRoute(threadReportID, backTo);
	}
	if (comparisonResult.change.description) {
	return ROUTES.TRANSACTION_DUPLICATE_REVIEW_DESCRIPTION_PAGE.getRoute(threadReportID, backTo);
	}
	if (comparisonResult.change.taxCode) {
	return ROUTES.TRANSACTION_DUPLICATE_REVIEW_TAX_CODE_PAGE.getRoute(threadReportID, backTo);
	}
	if (comparisonResult.change.billable) {
	return ROUTES.TRANSACTION_DUPLICATE_REVIEW_BILLABLE_PAGE.getRoute(threadReportID, backTo);
	}
	if (comparisonResult.change.reimbursable) {
	return ROUTES.TRANSACTION_DUPLICATE_REVIEW_REIMBURSABLE_PAGE.getRoute(threadReportID, backTo);

This is valid for cash-only or non-managed-card duplicates, where reimbursable is a real user choice. It is invalid when any transaction in the duplicate set is a managed card transaction. Managed card transactions are centrally managed company/Expensify card transactions and must always remain non-reimbursable.

So the root cause is not the reimbursable review page itself. The problem is that the duplicate comparison source treats reimbursable as a freely reviewable field even when the duplicate set contains a managed card transaction, where reimbursable is constrained to false.

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

Fix this in compareDuplicateTransactionFields(), because this function is the shared source for:

• which duplicate review steps are shown;
• what values are written into ONYXKEYS.REVIEW_DUPLICATES;
• the step list used by the review screens and confirmation screen;
• the reviewed values later used by buildMergeDuplicatesParams().

After building the filtered transactions array:

const transactions = removeSettledAndApprovedTransactions([reviewingTransaction, ...(duplicates ?? [])]);

compute whether the duplicate set contains a managed card transaction:

const hasManagedCardTransaction = transactions.some(isManagedCardTransaction);

Then, inside the fieldsToCompare loop, before the generic equality/change branch handles reimbursable, force the managed-card invariant:

if (fieldName === 'reimbursable' && hasManagedCardTransaction) {
    keep[fieldName] = false;
    continue;
}

This should happen after removeSettledAndApprovedTransactions() so only the transactions that actually participate in duplicate review/merge affect the decision.

This fixes both sides of the bug:

• change.reimbursable is not populated, so getReviewNavigationRoute() skips TRANSACTION_DUPLICATE_REVIEW_REIMBURSABLE_PAGE.
• keep.reimbursable = false is written into ONYXKEYS.REVIEW_DUPLICATES, so confirmation and buildMergeDuplicatesParams() use the correct non-reimbursable value.

Do not solve this by hiding the UI step in TransactionPreviewUtils or ReviewReimbursable. That would only hide one consumer while leaving compareDuplicateTransactionFields() and reviewed Onyx state inconsistent.

Also do not use generic card-import checks such as isFromCreditCardImport(). The correct predicate is isManagedCardTransaction(), because personal card imports can still be reimbursable. The invariant applies only to centrally managed card transactions.

As an additional defensive hardening, we can clamp the preview transaction in buildNewTransactionAfterReviewingDuplicates() when the kept/result transaction itself is a managed card transaction:

const shouldForceNonReimbursable = isManagedCardTransaction(duplicatedTransaction);

return {
    ...duplicatedTransaction,
    ...restReviewDuplicateTransaction,
    ...(shouldForceNonReimbursable && {reimbursable: false}),
    modifiedMerchant: reviewDuplicateTransaction?.merchant,
    merchant: reviewDuplicateTransaction?.merchant,
    comment: {...reviewDuplicateTransaction?.comment, comment: reviewDuplicateTransaction?.description},
    ...(hasUpdatedTaxCode && {taxAmount, taxName: undefined, taxValue: undefined}),
};

This is only a safety rail for stale ONYXKEYS.REVIEW_DUPLICATES, old local state, or direct/stale navigation. The comparator remains the real fix because it has access to the full duplicate set. The builder clamp should not replace the comparator logic.

Tests to add

Add coverage for compareDuplicateTransactionFields():

• managed card + cash expense with different reimbursable values returns keep.reimbursable === false;
• the same case does not return change.reimbursable;
• cash-only duplicates with different reimbursable values still return change.reimbursable;
• personal card/imported-card transactions without managedCard are not treated as managed card transactions;
• settled/approved managed-card duplicates do not force the value if they are filtered out before comparison.

What alternative solutions did you explore? (Optional)

[lorretheboy]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[Abdulloh0109]

What is the root cause of that problem?

The "Choose if transaction is reimbursable" step is shown purely because the two duplicate transactions disagree on reimbursable, with no awareness that one of them is a centrally managed card transaction (which must always be non-reimbursable).

Every review-duplicates page derives its step list from the keys of the change object returned by compareDuplicateTransactionFields:

App/src/pages/TransactionDuplicate/ReviewReimbursable.tsx

Lines 38 to 41 in 76bc375

	const compareResult = compareDuplicateTransactionFields(policyTags ?? {}, transaction, allDuplicates, reviewDuplicatesReport, undefined, policy, policyCategories);
	const stepNames = Object.keys(compareResult.change ?? {}).map((key, index) => (index + 1).toString());
	const {currentScreenIndex, goBack, navigateToNextScreen} = useReviewDuplicatesNavigation(
	Object.keys(compareResult.change ?? {}),

Inside compareDuplicateTransactionFields, reimbursable is just another field in fieldsToCompare and falls into the generic comparison branch. The values are compared as raw fields via SafeString(item?.reimbursable), and if they aren't all equal the field gets pushed into change, which is what makes the step appear:

App/src/libs/TransactionUtils/index.ts

Lines 2492 to 2500 in 76bc375

	const fieldsToCompare: FieldsToCompare = {
	merchant: ['modifiedMerchant', 'merchant'],
	category: ['category'],
	tag: ['tag'],
	description: ['comment'],
	taxCode: ['taxCode'],
	billable: ['billable'],
	reimbursable: ['reimbursable'],
	};

App/src/libs/TransactionUtils/index.ts

Lines 2610 to 2613 in 76bc375

	} else if (areAllFieldsEqualForKey) {
	keep[fieldName] = firstTransaction?.[keys[0]] ?? firstTransaction?.[keys[1]];
	} else {
	processChanges(fieldName, transactions, keys);

A managed (corp) card transaction carries reimbursable: false, while the manually-added cash expense is reimbursable (reimbursable defaults to true — see getReimbursable). So their raw values differ → change.reimbursable is set → the step renders:

App/src/libs/TransactionUtils/index.ts

Lines 1195 to 1196 in 76bc375

	function getReimbursable(transaction: OnyxInputOrEntry<Transaction>): boolean {
	return transaction?.reimbursable ?? true;

The user then picks "reimbursable", that kept value flows straight into the merge request, and the card transaction is saved as reimbursable: true — an invalid state for a managed card with no in-product way to undo it:

App/src/libs/TransactionUtils/index.ts

Lines 2659 to 2660 in 76bc375

	billable: reviewDuplicates?.billable ?? false,
	reimbursable: reviewDuplicates?.reimbursable ?? false,

There's no special-casing anywhere in compareDuplicateTransactionFields for card transactions, even though the right detector already exists:

App/src/libs/TransactionUtils/index.ts

Lines 1346 to 1351 in 76bc375

	/**
	* Determine whether a transaction is made with a centrally managed card (Expensify or Company Card).
	*/
	function isManagedCardTransaction(transaction: OnyxEntry<Pick<Transaction, 'managedCard'>>): boolean {
	return !!transaction?.managedCard;
	}

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

Fix this in the data layer — compareDuplicateTransactionFields in src/libs/TransactionUtils/index.ts — since it's the single source of truth that both the step list and the kept values flow from.

Special-case reimbursable before it reaches the generic compare branch: if any of the transactions being compared is a managed card transaction (isManagedCardTransaction), force the kept value to non-reimbursable and never add it to change:

• if (transactions.some(isManagedCardTransaction)) { keep.reimbursable = false; continue; } (handle this inside a fieldName === 'reimbursable' case, before the generic else).

Because every Review* page builds stepNames from Object.keys(change), removing reimbursable from change automatically drops the step from the flow and the step counter — no changes needed in useReviewDuplicatesNavigation or CONST.REVIEW_DUPLICATES_ORDER. Putting it in keep as false guarantees the merged transaction stays non-reimbursable, which is the expected result (and is consistent with the reimbursable: reviewDuplicates?.reimbursable ?? false default already used when building the merge params).

Edge cases this touches:

• Card-vs-card duplicates: both are already non-reimbursable, so the step never showed — unchanged.
• Cash-vs-cash duplicates: no managed card, so the existing differ/equal logic still runs and the step shows when it should.

What alternative solutions did you explore? (Optional)

Use the broader isFromCreditCardImport detector instead of isManagedCardTransaction. Rejected: isFromCreditCardImport also returns true for personal cards imported via a bank connection, and those can legitimately be reimbursable. Only centrally managed cards (Expensify/Company cards) are guaranteed non-reimbursable, so isManagedCardTransaction is the precise condition.

Hide the step at the page/navigation layer instead of in the compare function. Rejected: the step list is regenerated from change keys independently on each of the seven Review* pages, and the merge consumes the kept values. Filtering at the page layer would mean touching every page and would still leave change.reimbursable populated, so the merge could keep a card transaction reimbursable. Fixing the source function fixes all consumers at once.

Force reimbursable: false only at merge/confirmation time. Rejected: that would still walk the user through a pointless step that visibly contradicts what's saved, whereas the maintainer explicitly asked to not show that step. Suppressing it at the compare layer matches the requested behavior and keeps the UI and the saved value consistent.

[mukhrr]

Proposal

What is the root cause of that problem?

The duplicate review flow compares reimbursable exactly like the other editable duplicate fields, but it does not apply the managed-card invariant before creating the review steps.

This started with the duplicate review fields work. PR #41093 added the review flow, and PR #42503 added reimbursable to the fields that can be reviewed. That implementation compares billable and reimbursable generically, with no managed-card exception.

Current code still does the same:

• compareDuplicateTransactionFields() always includes reimbursable in fieldsToCompare:

  App/src/libs/TransactionUtils/index.ts

  Lines 2492 to 2500 in 5c494a6

  	const fieldsToCompare: FieldsToCompare = {
  	merchant: ['modifiedMerchant', 'merchant'],
  	category: ['category'],
  	tag: ['tag'],
  	description: ['comment'],
  	taxCode: ['taxCode'],
  	billable: ['billable'],
  	reimbursable: ['reimbursable'],
  	};

• If values differ, the generic comparison adds it to change:

  App/src/libs/TransactionUtils/index.ts

  Lines 2546 to 2553 in 5c494a6

  	for (const fieldName in fieldsToCompare) {
  	if (Object.prototype.hasOwnProperty.call(fieldsToCompare, fieldName)) {
  	const keys = fieldsToCompare[fieldName];
  	const firstTransaction = transactions.at(0);
  	const isFirstTransactionCommentEmptyObject = typeof firstTransaction?.comment === 'object' && firstTransaction?.comment?.comment === '';
  	const areAllFieldsEqualForKey = areAllFieldsEqual(transactions, (item) => keys.map((key) => SafeString(item?.[key])).join('|'));
  	if (fieldName === 'description') {

• getReviewNavigationRoute() then opens the reimbursable review step whenever comparisonResult.change.reimbursable exists:

  App/src/libs/TransactionPreviewUtils.ts

  Lines 109 to 110 in 5c494a6

  	if (comparisonResult.change.reimbursable) {
  	return ROUTES.TRANSACTION_DUPLICATE_REVIEW_REIMBURSABLE_PAGE.getRoute(threadReportID, backTo);

That conflicts with the rest of the app. Similar managed-card cases already hide or block reimbursable editing:

• Expense details hides reimbursable for managed cards:

  App/src/components/ReportActionItem/MoneyRequestView.tsx

  Lines 464 to 468 in 5c494a6

  	const shouldShowReimbursable =
  	(isPolicyExpenseChat || (isExpenseUnreported && !!policy)) &&
  	(policy?.disabledFields?.reimbursable !== true || isCurrentTransactionReimbursableDifferentFromPolicyDefault) &&
  	!isManagedCardTransactionTransactionUtils(transaction) &&
  	!isInvoice;

• Expense creation footer hides reimbursable for managed cards:

  App/src/components/MoneyRequestConfirmationListFooter/hooks/useFooterDerivedFlags.ts

  Lines 91 to 92 in 5c494a6

  	const shouldShowReimbursable =
  	(isPolicyExpenseChat || isTrackExpense) && !!policy && policy?.disabledFields?.reimbursable !== true && !isManagedCardTransaction(transaction) && !isTypeInvoice;

• Search bulk reimbursable edit excludes managed cards:

  App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

  Lines 103 to 108 in 5c494a6

  	const areSelectedTransactionsReimbursable = selectedTransactionContexts.every(({transaction, report, transactionPolicy}) => {
  	// Unreported expenses have no policy yet but reimbursable is always applicable
  	if (!transaction.reportID || transaction.reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
  	return true;
  	}
  	return !isIOUReport(report) && !isInvoiceReport(report) && transactionPolicy?.disabledFields?.reimbursable === false && !isManagedCardTransaction(transaction);

Git history also confirms the intended distinction: PR #84596 changed reimbursable visibility from “any card import” to isManagedCardTransaction() so personal cards can still be reimbursable, while managed/company cards cannot.

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

Handle this in compareDuplicateTransactionFields(), because this function decides both which review steps are shown and what values are stored in reviewDuplicates.

Before iterating fields, detect whether any transaction in the duplicate set is managed card. When processing reimbursable, if any transaction is managed card, force keep.reimbursable = false and skip adding reimbursable to change.

Small diff sketch:

 const transactions = removeSettledAndApprovedTransactions([reviewingTransaction, ...(duplicates ?? [])]);
+const hasManagedCardTransaction = transactions.some(isManagedCardTransaction);

 ...
 for (const fieldName in fieldsToCompare) {
     if (Object.prototype.hasOwnProperty.call(fieldsToCompare, fieldName)) {
         const keys = fieldsToCompare[fieldName];
         const firstTransaction = transactions.at(0);
+
+        if (fieldName === 'reimbursable' && hasManagedCardTransaction) {
+            keep[fieldName] = false;
+            continue;
+        }

This avoids regression because:

• It is scoped only to duplicate review comparison.
• It still allows personal card imports to choose reimbursable, since it uses isManagedCardTransaction() and not isFromCreditCardImport(), matching PR Fix Reimbursable toggle hidden for personal card transactions #84596.
• It does not affect merchant/category/tag/tax/billable conflict review.
• It preserves the final merge payload, because buildMergeDuplicatesParams() already sends reviewDuplicates.reimbursable:

  App/src/libs/TransactionUtils/index.ts

  Lines 2659 to 2660 in 5c494a6

  	billable: reviewDuplicates?.billable ?? false,
  	reimbursable: reviewDuplicates?.reimbursable ?? false,

Add unit coverage for:

1. managed card + cash expense with different reimbursable values skips /duplicates/review/reimbursable;
2. the stored/kept reimbursable value is false;
3. two non-managed transactions with different reimbursable values still show the reimbursable review step.

What alternative solutions did you explore? (Optional)

We could skip the reimbursable page only in getReviewNavigationRoute(), but that only hides the UI. It would not guarantee reviewDuplicates.reimbursable is forced to false before buildMergeDuplicatesParams() builds the merge request. Handling it in compareDuplicateTransactionFields() fixes both the UI step list and the final data used by the merge.

[melvin-bot]

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