[HOLD] [$250] Odometer - Manually entered start/end readings no longer shown in merchant line when reopening a mileage expense

[melvin-bot]

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.4.34-14

Reproducible in staging?: Needs reproduction

Reproducible in production?: Needs reproduction

Which of our officially supported platforms is this occurring on?

• Android: Standalone
• Device: Google Pixel
• OS: Android
• App version: 9.4.34-14

Action Performed:

1. Create an odometer mileage expense, manually entering a start and end odometer reading.
2. Save the expense.
3. Reopen / view the expense and look at the merchant line.

Expected Result:

The merchant line should display the manually entered start and end odometer readings, e.g.:
43.00 mi @ $0.00/mi (odometer start: ..., odometer end: ...)

Actual Result:

The merchant line only shows the calculated mileage and rate (e.g. 43.00 mi @ $0.00/mi). The manually entered start/end odometer readings are no longer displayed when reopening the expense, even though they were saved.

Additionally, the customer noted that the starting odometer is once again auto-populating from the previous expense's ending reading. This had reportedly stopped, then started working again — suggesting related churn in the reading persistence/re-hydration logic.

The customer reports this display behavior changed around July 9 with no action on their end, and is asking whether this is an intentional change or a regression. This appears to be an unintended regression.

Workaround:

Unknown / none confirmed.

Platforms:

• Android: Standalone

Screenshots/Videos

Customer provided before/after screenshots (previous behavior showing readings vs. current behavior missing them) — to be attached.

Notes / Context

• Customer-reported via Concierge. First noticed around July 9, 2026.
• Possibly related to recent odometer work in this window: Enhance odometer reading handling by introducing a baseline compariso… #95039 (Jul 2), [Payment due @DylanDylann] [Odometer] Show discard changes modal when switching tabs #94899 (Jun 29), [Odometer] Enable split expenses #90772. Distinct from Odometer - Merchant start & end reading disappear after splitting, reappears after editing #91770 (split-specific) and [Due for payment 2026-07-13] [$250 - payment 9th July] Distance - Odometer readings are auto cleared after switching tab despite saving for later #94961 (tab-switch clearing), which were reviewed and ruled out as matches.

---

Reported in Slack.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022078285505844588401
• Upwork Job ID: 2078285505844588401
• Last Price Increase: 2026-07-18

[jalynmsc]

There are shared screenshots showing the previous vs. current behavior, and are asking whether this is an intentional UI change or a regression.

[melvin-bot]

📣 @jalynmsc! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[trasnake87]

Proposal

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

When an odometer mileage expense is created with manually entered start/end readings and then re-opened, the merchant line drops the readings — it shows 43.00 mi @ $0.00/mi instead of 43.00 mi @ $0.00/mi (odometer start: …, odometer end: …), even though the readings are still saved on the transaction.

What is the root cause of that problem?

The readings-bearing merchant string (… (odometer start: …, odometer end: …)) is generated server-side — there is no frontend code that builds it. The regression is that the frontend now overwrites that server merchant with a locally-computed, readings-less one.

Re-opening an odometer expense lands on the odometer step, which re-saves via updateMoneyRequestDistance (the ending reading is also being auto-populated again, so hasChanges is true — src/pages/iou/request/step/IOURequestStepDistanceOdometer.tsx:402-430). That routes into getUpdatedTransaction, whose distance branch recomputes the merchant with getDistanceMerchant:

// src/libs/TransactionUtils/index.ts:843-867 (distance branch)
const updatedMerchant = DistanceRequestUtils.getDistanceMerchant(true, distanceInMeters, unit, rate, …);
…
updatedTransaction.modifiedMerchant = updatedMerchant;   // <- readings dropped

getDistanceMerchant (src/libs/DistanceRequestUtils.ts:256-279) only ever returns "<distance> @ <rate>" — it has no concept of odometer readings. That value is written to modifiedMerchant, and getMerchant prefers modifiedMerchant over merchant:

// src/libs/TransactionUtils/index.ts:1125-1127
function getMerchant(transaction) {
    return transaction?.modifiedMerchant ? transaction.modifiedMerchant : (transaction?.merchant ?? '');
}

So the readings-less modifiedMerchant masks the server merchant that carries the readings. Critically, merchant is not sent to the server on an odometer edit — dataToIncludeInParams only forwards keys present in transactionChanges ({distance, odometerStart, odometerEnd}), which excludes merchant (src/libs/actions/IOU/UpdateMoneyRequest.ts:1636). The server therefore regenerates the correct readings-bearing merchant on its own; the client just never displays it because its own optimistic modifiedMerchant sticks. The identical clobber exists in the rate branch at src/libs/TransactionUtils/index.ts:747-762.

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

For odometer transactions, stop overwriting modifiedMerchant with the readings-less getDistanceMerchant output. The merchant is regenerated server-side (and not sent in the params), so preserving the existing readings-bearing merchant keeps the readings visible optimistically and after sync.

In getUpdatedTransaction (src/libs/TransactionUtils/index.ts), guard both merchant assignments with isOdometerDistanceRequest(transaction) (already used at line 412/730 in this file):

// distance branch, lines 860-868
const isOdometer = isOdometerDistanceRequest(transaction);
if (useFallback) {
    updatedTransaction.modifiedAmount = Math.round(previousAmount * (distanceInMeters / previousDistanceInMeters));
    if (!isOdometer) {
        updatedTransaction.modifiedMerchant = updatedMerchant;
    }
} else {
    updatedTransaction.modifiedAmount = amount;
    if (!isOdometer) {
        updatedTransaction.modifiedMerchant = updatedMerchant;
    }
    updatedTransaction.modifiedCurrency = updatedCurrency;
}

Apply the same !isOdometer guard to updatedTransaction.modifiedMerchant = updatedMerchant; in the rate branch (line 761). Amount/currency still update optimistically; only the merchant is left to the server, which owns the readings format. pendingFields.merchant is already flagged UPDATE (line 912), so the field renders as pending until the server response lands.

What alternative solutions did you explore? (Optional)

Replicating the backend format on the frontend (a new iou.odometerMerchant translation appended inside getDistanceMerchant). Rejected: it duplicates server-owned formatting, risks locale/format drift causing the merchant to flicker when the server response replaces it, and the server already produces the correct string — the only defect is the client masking it.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-18 01:24:03 UTC.

Proposal

What is the root cause of that problem?

The readings are not being lost. The odometer edit screen sends the recalculated distance together with odometerStart and odometerEnd, but the optimistic transaction update also rebuilds modifiedMerchant with the generic distance formatter.

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

Lines 398 to 429 in 4bafe13

	// Update existing transaction
	const previousDistance = transaction?.comment?.customUnit?.quantity;
	const previousStart = transaction?.comment?.odometerStart;
	const previousEnd = transaction?.comment?.odometerEnd;
	const hasChanges = previousDistance !== calculatedDistance || previousStart !== start || previousEnd !== end;
	if (hasChanges) {
	// Update distance (which will also update amount and merchant)
	updateMoneyRequestDistance({
	transaction,
	transactionThreadReport: report,
	parentReport,
	iouReportOwnerLogin,
	distance: calculatedDistance,
	odometerStart: start,
	odometerEnd: end,
	// Not required for odometer distance request
	transactionBackup: undefined,
	policy,
	distanceOriginalPolicy,
	policyTagList: policyTags,
	policyCategories,
	currentUserAccountIDParam,
	currentUserEmailParam,
	isASAPSubmitBetaEnabled: false,
	parentReportNextStep,
	recentWaypoints,
	delegateAccountID,
	reportPolicyTags,
	isTrackIntentUser,
	personalPolicyOutputCurrency: personalPolicy?.outputCurrency,
	});

App/src/libs/TransactionUtils/index.ts

Lines 839 to 877 in 4bafe13

	const distanceInMeters = getDistanceInMeters(updatedTransaction, unit);
	let amount = DistanceRequestUtils.getDistanceRequestAmount(distanceInMeters, unit, rate ?? 0);
	amount = isFromExpenseReport || isUnReportedExpense ? -amount : amount;
	const updatedCurrency = updatedMileageRate.currency ?? CONST.CURRENCY.USD;
	const updatedMerchant = DistanceRequestUtils.getDistanceMerchant(
	true,
	distanceInMeters,
	unit,
	rate,
	updatedCurrency,
	translateLocal,
	(digit) => toLocaleDigit(IntlStore.getCurrentLocale(), digit),
	getCurrencySymbol,
	isManualDistanceRequest(transaction),
	);
	// No locally resolvable rate (e.g. track expense without policy loaded) → scale the previous
	// amount by the distance ratio so the optimistic value isn't 0. `modifiedAmount` is `""` for
	// unedited transactions, so coerce via Number() and fall through to `amount`.
	const previousAmount = Number(transaction?.modifiedAmount) || transaction?.amount || 0;
	const useFallback = !rate && !!previousDistanceInMeters && !!previousAmount && !!distanceInMeters;
	if (useFallback) {
	updatedTransaction.modifiedAmount = Math.round(previousAmount * (distanceInMeters / previousDistanceInMeters));
	updatedTransaction.modifiedMerchant = updatedMerchant;
	// Leave currency alone — without a resolvable rate we don't know the target currency.
	} else {
	updatedTransaction.modifiedAmount = amount;
	updatedTransaction.modifiedMerchant = updatedMerchant;
	updatedTransaction.modifiedCurrency = updatedCurrency;
	}
	}
	if (Object.hasOwn(transactionChanges, 'odometerStart') && typeof transactionChanges.odometerStart === 'number') {
	lodashSet(updatedTransaction, 'comment.odometerStart', transactionChanges.odometerStart);
	}
	if (Object.hasOwn(transactionChanges, 'odometerEnd') && typeof transactionChanges.odometerEnd === 'number') {
	lodashSet(updatedTransaction, 'comment.odometerEnd', transactionChanges.odometerEnd);
	}

That formatter only produces the distance and rate. It has no odometer-reading inputs, so the optimistic value becomes 43.00 mi @ $0.00/mi.

App/src/libs/DistanceRequestUtils.ts

Lines 256 to 279 in 4bafe13

	function getDistanceMerchant(
	hasRoute: boolean,
	distanceInMeters: number,
	unit: Unit | undefined,
	rate: number | undefined,
	currency: string,
	translate: LocaleContextProps['translate'],
	toLocaleDigit: LocaleContextProps['toLocaleDigit'],
	getCurrencySymbol: CurrencyListActionsContextType['getCurrencySymbol'],
	isZeroDistanceAllowed?: boolean,
	): string {
	if (!hasRoute || !rate) {
	return translate('iou.fieldPending');
	}
	if (!distanceInMeters && !isZeroDistanceAllowed) {
	return '';
	}
	const distanceInUnits = getDistanceForDisplay(hasRoute, distanceInMeters, unit, rate, translate, true, isZeroDistanceAllowed);
	const ratePerUnit = getFormattedRateValue(unit, rate, currency, translate, toLocaleDigit, getCurrencySymbol, undefined, true);
	return `${distanceInUnits} ${CONST.DISTANCE_MERCHANT_SEPARATOR} ${ratePerUnit}`;
	}

The update request itself includes only fields that the caller changed, so this odometer edit sends the distance and readings but not the locally recomputed merchant. The server can therefore regenerate the authoritative merchant containing the readings, but getMerchant() continues to prefer the client's readings-less modifiedMerchant over merchant, masking the server value after the response.

App/src/libs/actions/IOU/UpdateMoneyRequest.ts

Lines 1619 to 1648 in 4bafe13

	const updatedTransaction: OnyxEntry<OnyxTypes.Transaction> = transaction
	? getUpdatedTransaction({
	transaction,
	transactionChanges: transactionChangesForOptimisticMerge,
	isFromExpenseReport,
	isSplitTransaction,
	policy,
	personalPolicyOutputCurrency,
	})
	: undefined;
	const transactionDetails = getTransactionDetails(updatedTransaction, undefined, undefined, allowNegative);
	if (transactionDetails?.waypoints) {
	transactionDetails.waypoints = stringifyWaypointsForAPI(transactionDetails.waypoints as WaypointCollection);
	}
	const dataToIncludeInParams: Partial<TransactionDetails> = Object.fromEntries(Object.entries(transactionDetails ?? {}).filter(([key]) => key in transactionChanges));
	// Preserve the caller's full-precision distance so the server doesn't fire `increasedDistance`
	// when the rounded display value drifts above the exact route distance.
	if ('distance' in transactionChanges && typeof transactionChanges.distance === 'number') {
	dataToIncludeInParams.distance = transactionChanges.distance;
	}
	const apiParams: UpdateMoneyRequestParams = {
	...dataToIncludeInParams,
	reportID: iouReport?.reportID,
	transactionID,
	};

App/src/libs/TransactionUtils/index.ts

Lines 1122 to 1127 in 4bafe13

	/**
	* Return the merchant field from the transaction, return the modifiedMerchant if present.
	*/
	function getMerchant(transaction: OnyxInputOrEntry<Transaction>): string {
	return transaction?.modifiedMerchant ? transaction.modifiedMerchant : (transaction?.merchant ?? '');
	}

The same clobber can happen when changing an odometer expense's rate because that branch also writes a generic modifiedMerchant.

App/src/libs/TransactionUtils/index.ts

Lines 736 to 763 in 4bafe13

	if (!isFetchingWaypointsFromServer(transaction)) {
	// When the waypoints are being fetched from the server, we have no information about the distance, and cannot recalculate the updated amount.
	// Otherwise, recalculate the fields based on the new rate.
	const updatedMileageRate = DistanceRequestUtils.getRate({transaction: updatedTransaction, policy, useTransactionDistanceUnit: false, personalPolicyOutputCurrency});
	const {unit, rate} = updatedMileageRate;
	const distanceInMeters = getDistanceInMeters(updatedTransaction, unit);
	const amount = DistanceRequestUtils.getDistanceRequestAmount(distanceInMeters, unit, rate ?? 0);
	const updatedAmount = isFromExpenseReport || isUnReportedExpense ? -amount : amount;
	const updatedCurrency = updatedMileageRate.currency ?? CONST.CURRENCY.USD;
	const updatedMerchant = DistanceRequestUtils.getDistanceMerchant(
	true,
	distanceInMeters,
	unit,
	rate,
	updatedCurrency,
	translateLocal,
	(digit) => toLocaleDigit(IntlStore.getCurrentLocale(), digit),
	getCurrencySymbol,
	isManualDistanceRequest(transaction),
	);
	updatedTransaction.amount = updatedAmount;
	updatedTransaction.modifiedAmount = updatedAmount;
	updatedTransaction.modifiedMerchant = updatedMerchant;
	updatedTransaction.modifiedCurrency = updatedCurrency;
	}

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

In getUpdatedTransaction, detect odometer distance requests and do not replace modifiedMerchant with the generic getDistanceMerchant() result in either the distance-change or rate-change branch. Keep the existing optimistic amount, currency, distance, and reading updates. This lets getMerchant() fall back to the server-owned merchant value that already contains the odometer suffix instead of duplicating that formatting in the client.

Apply this to both branches so editing the readings/distance and editing the mileage rate behave consistently. If the transaction can enter the update with a stale odometer modifiedMerchant, clear that optimistic override as part of the same odometer-specific update so existing affected transactions also fall back to merchant.

Test coverage: extend the getUpdatedTransaction unit cases to verify that odometer distance and rate edits preserve/fall back to the server merchant while still updating amount, currency, distance, and both readings; retain assertions that map/manual distance edits continue to generate modifiedMerchant. Add an update-action test confirming the API params contain distance, odometerStart, and odometerEnd but not merchant, plus a UI regression test for reopening an odometer expense after the response arrives.

App/tests/unit/TransactionUtilsTest.ts

Lines 400 to 630 in 4bafe13

	describe('getUpdatedTransaction', () => {
	it('should return updated category and tax when updating category with a category tax rules', () => {
	// Given a policy with tax expense rules associated with a category
	const category = 'Advertising';
	const taxCode = 'id_TAX_RATE_1';
	const fakePolicy: Policy = {
	...createRandomPolicy(0),
	taxRates: CONST.DEFAULT_TAX,
	rules: {expenseRules: createCategoryTaxExpenseRules(category, taxCode)},
	};
	const transaction = generateTransaction();
	// When updating the transaction category to the category associated with the rule
	const updatedTransaction = TransactionUtils.getUpdatedTransaction({
	transaction,
	isFromExpenseReport: true,
	policy: fakePolicy,
	transactionChanges: {category},
	personalPolicyOutputCurrency: undefined,
	});
	// Then the updated transaction should contain the tax from the matched rule
	expect(updatedTransaction.category).toBe(category);
	expect(updatedTransaction.taxCode).toBe(taxCode);
	expect(updatedTransaction.taxAmount).toBe(5);
	expect(updatedTransaction.taxValue).toBe('5%');
	});
	it('should update transaction when distance is changed', () => {
	// Given: a policy with a mileage rate
	const fakePolicy: Policy = {
	...createRandomPolicy(0),
	customUnits: {
	distance: {
	name: CONST.CUSTOM_UNITS.NAME_DISTANCE,
	customUnitID: 'distance',
	rates: {
	default: {
	customUnitRateID: '1',
	currency: CONST.CURRENCY.USD,
	rate: 1, // 1 USD per mile
	},
	},
	attributes: {
	unit: CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES,
	},
	},
	},
	};
	const transaction = generateTransaction({
	comment: {
	customUnit: {
	distanceUnit: CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES,
	quantity: 10, // original distance
	},
	},
	currency: CONST.CURRENCY.USD,
	});
	const newDistance = 20; // change distance to 20 miles
	// When: updating the transaction with a new distance
	const updatedTransaction = TransactionUtils.getUpdatedTransaction({
	transaction,
	isFromExpenseReport: false,
	policy: fakePolicy,
	transactionChanges: {distance: newDistance},
	personalPolicyOutputCurrency: undefined,
	});
	// Then: quantity should be updated
	expect(updatedTransaction.comment?.customUnit?.quantity).toBe(newDistance);
	// And: amount should be recalculated (20 miles × 1 USD = 20)
	expect(updatedTransaction.modifiedAmount).toBe(20);
	// And: merchant should be updated with mileage description
	expect(updatedTransaction.modifiedMerchant).toContain('20');
	// And: currency should be set from policy mileage rate
	expect(updatedTransaction.modifiedCurrency).toBe(CONST.CURRENCY.USD);
	// And: pending fields should mark distance-related updates
	expect(updatedTransaction.pendingFields).toMatchObject({
	quantity: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	amount: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	merchant: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	});
	});
	it('threads personalPolicyOutputCurrency into the recalculated rate for a P2P distance expense with no policy', async () => {
	// A P2P distance expense (FAKE_P2P_ID) has no policy rate, so the mileage currency comes from the
	// resolved personal-policy currency that getUpdatedTransaction forwards to getRate. getRateForP2P only
	// returns that resolved currency when the default P2P rate is loaded, so seed it here.
	await Onyx.merge(ONYXKEYS.DEFAULT_P2P_MILEAGE_RATE, {rate: 30, unit: CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES});
	await waitForBatchedUpdates();
	try {
	// transaction.currency is deliberately USD so a passing result proves the EUR came from
	// personalPolicyOutputCurrency, not from the transaction itself.
	const transaction = generateTransaction({
	currency: CONST.CURRENCY.USD,
	comment: {
	customUnit: {
	customUnitRateID: CONST.CUSTOM_UNITS.FAKE_P2P_ID,
	distanceUnit: CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES,
	quantity: 10,
	},
	},
	});
	const updatedTransaction = TransactionUtils.getUpdatedTransaction({
	transaction,
	isFromExpenseReport: false,
	policy: undefined,
	transactionChanges: {distance: 20},
	personalPolicyOutputCurrency: 'EUR',
	});
	// Currency + merchant follow the threaded personal currency (EUR), and amount = 20 mi × 30¢ = 600.
	// (The merchant shows the "EUR" code rather than the € glyph because the currency list isn't loaded in this unit test.)
	expect(updatedTransaction.modifiedCurrency).toBe('EUR');
	expect(updatedTransaction.modifiedMerchant).toContain('EUR');
	expect(updatedTransaction.modifiedMerchant).toContain('0.30');
	expect(updatedTransaction.modifiedAmount).toBe(600);
	} finally {
	await Onyx.merge(ONYXKEYS.DEFAULT_P2P_MILEAGE_RATE, null);
	await waitForBatchedUpdates();
	}
	});
	it('uses the resolved personal-policy currency (not transaction.currency) when recalculating a P2P expense from edited waypoints', async () => {
	// Regression: the waypoint/route branch used to format the merchant with transaction.currency and never set
	// modifiedCurrency, so a P2P expense whose personal currency differs from transaction.currency would show a
	// rate in the old currency for an amount computed in the new one (visible offline / before the server responds).
	await Onyx.merge(ONYXKEYS.DEFAULT_P2P_MILEAGE_RATE, {rate: 30, unit: CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES});
	await waitForBatchedUpdates();
	try {
	const transaction = generateTransaction({
	currency: CONST.CURRENCY.USD,
	comment: {
	customUnit: {
	customUnitRateID: CONST.CUSTOM_UNITS.FAKE_P2P_ID,
	distanceUnit: CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES,
	quantity: 10,
	},
	waypoints: {waypoint0: {address: 'Old A'}, waypoint1: {address: 'Old B'}},
	},
	});
	// 32186.88 m ≈ 20 mi; at the EUR P2P rate of 30¢ the amount is 600.
	const updatedTransaction = TransactionUtils.getUpdatedTransaction({
	transaction,
	isFromExpenseReport: false,
	policy: undefined,
	transactionChanges: {
	waypoints: {waypoint0: {address: 'New A'}, waypoint1: {address: 'New B'}},
	routes: {
	route0: {
	distance: 32186.88,
	geometry: {
	coordinates: [
	[0, 0],
	[1, 1],
	],
	},
	},
	},
	},
	personalPolicyOutputCurrency: 'EUR',
	});
	// Merchant currency and modifiedCurrency both follow the EUR personal-policy rate, not the USD transaction currency.
	expect(updatedTransaction.modifiedCurrency).toBe('EUR');
	expect(updatedTransaction.modifiedMerchant).toContain('EUR');
	expect(updatedTransaction.modifiedMerchant).toContain('0.30');
	expect(updatedTransaction.modifiedAmount).toBe(600);
	} finally {
	await Onyx.merge(ONYXKEYS.DEFAULT_P2P_MILEAGE_RATE, null);
	await waitForBatchedUpdates();
	}
	});
	it('should negate modifiedAmount when isFromExpenseReport is true', () => {
	const transaction = generateTransaction();
	const newAmount = 500;
	const updatedTransaction = TransactionUtils.getUpdatedTransaction({
	transaction,
	isFromExpenseReport: true,
	transactionChanges: {amount: newAmount},
	personalPolicyOutputCurrency: undefined,
	});
	expect(updatedTransaction.modifiedAmount).toBe(-newAmount);
	});
	it('should not negate modifiedAmount when isFromExpenseReport is false', () => {
	const transaction = generateTransaction();
	const newAmount = 500;
	const updatedTransaction = TransactionUtils.getUpdatedTransaction({
	transaction,
	isFromExpenseReport: false,
	transactionChanges: {amount: newAmount},
	personalPolicyOutputCurrency: undefined,
	});
	expect(updatedTransaction.modifiedAmount).toBe(newAmount);
	});
	it('should update taxValue when taxValue and taxCode are both in transactionChanges', () => {
	const transaction = generateTransaction();
	const updatedTransaction = TransactionUtils.getUpdatedTransaction({
	transaction,
	isFromExpenseReport: true,
	transactionChanges: {taxCode: 'id_TAX_RATE_1', taxAmount: 50, taxValue: '5%'},
	personalPolicyOutputCurrency: undefined,
	});
	expect(updatedTransaction.taxValue).toBe('5%');
	expect(updatedTransaction.taxCode).toBe('id_TAX_RATE_1');
	expect(updatedTransaction.taxAmount).toBe(-50);
	});
	it('should not update taxValue when taxCode is not in transactionChanges', () => {
	const transaction = generateTransaction({taxValue: '10%'});
	const updatedTransaction = TransactionUtils.getUpdatedTransaction({

What alternative solutions did you explore? (Optional)

I considered extending getDistanceMerchant() to append localized odometer readings and threading them through every odometer-capable call site. That would make the optimistic text look correct, but it would duplicate server-owned formatting, introduce localization/format-drift risk, and still require every future recomputation path to remember the extra metadata. Preventing the client override fixes the precedence bug at its source.

[melvin-bot]

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

[melvin-bot]

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

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The merchant line for odometer mileage expenses is built from the transaction's comment.customUnit data. When reopening an expense, the odometer start/end readings stored in comment.customUnit are not being included in the merchant string displayed on the expense details screen. I suspect the utility function that formats the merchant/description line for distance requests is not reading customUnit.attributes.startOdometer / endOdometer fields when constructing the display string after the transaction is rehydrated from Onyx.

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

In src/libs/ReportUtils.ts (or wherever the mileage merchant string is assembled — likely getTransactionMerchant or a similar helper), I'd ensure the odometer readings are appended when they exist on the transaction's custom unit:

- let merchantString = `${distanceInUnits} @ ${ratePerUnit}`;
+ let merchantString = `${distanceInUnits} @ ${ratePerUnit}`;
+ const startOdometer = transaction?.comment?.customUnit?.attributes?.startOdometer;
+ const endOdometer = transaction?.comment?.customUnit?.attributes?.endOdometer;
+ if (startOdometer !== undefined && endOdometer !== undefined) {
+     merchantString += ` (odometer start: ${startOdometer}, odometer end: ${endOdometer})`;
+ }
  return merchantString;

This ensures that when a saved odometer transaction is reopened, the readings previously stored in comment.customUnit.attributes are surfaced in the merchant line just as they were at creation time.

What alternative solutions did you explore?

I also considered that the readings might be getting dropped during the Onyx write (i.e., not persisted at all), but since the customer confirms the values were saved and the regression appeared around a specific date tied to recent odometer PRs (#95039, #94899), it's more likely a display/formatting regression rather than a persistence issue.

[aswin-s]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-18 01:15:44 UTC.

Proposal

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

When an odometer mileage expense with manually entered start/end readings is saved and then reopened, the merchant line displays only 43.00 mi @ $0.00/mi instead of 43.00 mi @ $0.00/mi (odometer start: …, odometer end: …). The odometer readings are still persisted on the transaction; the server generates the readings-bearing merchant string correctly. The regression is that the client optimistically overwrites it with a readings-less string on reopen.

What is the root cause of that problem?

Server owns the odometer merchant format. For odometer expenses, the client never generates the readings-bearing suffix — buildDistanceAmountAndMerchant (handleMoneyRequestStepDistanceNavigation.ts:110-145) returns {merchant: translate('iou.fieldPending')} for non-manual-distance (odometer case, since isManualDistance === false). useExpenseSubmission.ts:440 likewise only calls getDistanceMerchant when isManualDistanceRequest(item) is true. The server processes odometerStart/odometerEnd and stores the readings-bearing merchant in transaction.merchant.

The regression clobber. getMerchant (TransactionUtils/index.ts:1125) prefers modifiedMerchant over merchant. getUpdatedTransaction (TransactionUtils/index.ts:604-919) has two branches that set modifiedMerchant to the output of getDistanceMerchant (which has no odometer params and never includes a suffix):

• distance branch (~line 860): fires whenever transactionChanges.distance is present — always true when IOURequestStepDistanceOdometer.tsx:406 calls updateMoneyRequestDistance({distance, odometerStart, odometerEnd, …}).
• customUnitRateID branch (~line 761): fires when the rate is changed and the transaction is not an odometer request — already uses isOdometerDistanceRequest elsewhere in the same block (line ~730) but NOT on the modifiedMerchant assignment.

Why the regression surfaced around July 9. IOURequestStepDistanceOdometer.tsx:402 computes hasChanges = previousDistance !== calculatedDistance || previousStart !== start || previousEnd !== end. The auto-population of odometerStart from the previous expense's ending reading (a separate bug re-introduced around this date, noted in the issue) makes previousStart !== start true on reopen, so hasChanges=true and updateMoneyRequestDistance fires. The distance branch of getUpdatedTransaction then sets modifiedMerchant = getDistanceMerchant(…) — a readings-less string — which getMerchant returns in preference to the server's merchant. The net effect: the readings-bearing transaction.merchant from the server is permanently masked.

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

The fix belongs in getUpdatedTransaction (src/libs/TransactionUtils/index.ts), not in getDistanceMerchant. For odometer transactions, the server owns the merchant string; modifiedMerchant should not be set so getMerchant falls through to the server-generated merchant.

1. Guard the distance branch (~lines 863–868):

// distance branch of getUpdatedTransaction
const isOdometer = isOdometerDistanceRequest(transaction);
if (useFallback) {
    updatedTransaction.modifiedAmount = Math.round(previousAmount * (distanceInMeters / previousDistanceInMeters));
    if (!isOdometer) {
        updatedTransaction.modifiedMerchant = updatedMerchant;
    }
} else {
    updatedTransaction.modifiedAmount = amount;
    if (!isOdometer) {
        updatedTransaction.modifiedMerchant = updatedMerchant;
    }
    updatedTransaction.modifiedCurrency = updatedCurrency;
}

Amount and currency still update optimistically; only the merchant assignment is guarded so the server's readings-bearing string is preserved.

2. Guard the customUnitRateID branch (~lines 761–762):

The same isOdometerDistanceRequest guard that already appears at line ~730 in this block (for the distance-unit conversion) must also protect the updatedTransaction.modifiedMerchant = updatedMerchant assignment at the end of this branch:

if (!isOdometerDistanceRequest(transaction)) {
    updatedTransaction.modifiedMerchant = updatedMerchant;
}

3. Verify pendingFields.merchant.

Confirm that pendingFields.merchant continues to be set to UPDATE when distance changes (already done at line ~905: ...(Object.hasOwn(transactionChanges, 'distance') && { … merchant: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE })). This ensures the merchant field renders as pending while awaiting the server response — no change needed here, just verify.

No changes are needed to getDistanceMerchant, handleMoneyRequestStepDistanceNavigation, useExpenseSubmission, or other call sites.

What alternative solutions did you explore?

A. Extend getDistanceMerchant with optional odometerStart/odometerEnd params (posted proposal + competitor @KJ21-ENG approach). Rejected. This duplicates the server-side readings format in the client. The server already generates the correct format; adding a parallel client format risks format drift (different localization, different field names, different ordering). It also requires touching 11 call sites unnecessarily. The root cause is not that getDistanceMerchant lacks odometer params — it is that getUpdatedTransaction clobbers a merchant the server already owns.

B. Fix the auto-population regression separately. The auto-population of odometerStart (noted in the issue as a related regression) being fixed would reduce the frequency of hasChanges=true on reopen, but even a deliberate user edit of odometer readings would still call updateMoneyRequestDistance({distance, …}) and trigger the same clobber. The getUpdatedTransaction guard is necessary regardless and is the complete fix.

[aswin-s]

Proposal

Updated

[lorretheboy]

Proposal

What is the root cause of that problem?

For an odometer expense the readings are stored on the transaction (comment.odometerStart / comment.odometerEnd)

App/src/types/onyx/Transaction.ts

Lines 140 to 144 in 4bafe13

	/** Odometer start reading for distance expenses */
	odometerStart?: number;
	/** Odometer end reading for distance expenses */
	odometerEnd?: number;

but the merchant string the app builds and persists is produced only by getDistanceMerchant, which emits "<distance> <separator> <rate>" and never includes the readings:

App/src/libs/DistanceRequestUtils.ts

Lines 256 to 279 in 4bafe13

	function getDistanceMerchant(
	hasRoute: boolean,
	distanceInMeters: number,
	unit: Unit | undefined,
	rate: number | undefined,
	currency: string,
	translate: LocaleContextProps['translate'],
	toLocaleDigit: LocaleContextProps['toLocaleDigit'],
	getCurrencySymbol: CurrencyListActionsContextType['getCurrencySymbol'],
	isZeroDistanceAllowed?: boolean,
	): string {
	if (!hasRoute || !rate) {
	return translate('iou.fieldPending');
	}
	if (!distanceInMeters && !isZeroDistanceAllowed) {
	return '';
	}
	const distanceInUnits = getDistanceForDisplay(hasRoute, distanceInMeters, unit, rate, translate, true, isZeroDistanceAllowed);
	const ratePerUnit = getFormattedRateValue(unit, rate, currency, translate, toLocaleDigit, getCurrencySymbol, undefined, true);
	return `${distanceInUnits} ${CONST.DISTANCE_MERCHANT_SEPARATOR} ${ratePerUnit}`;
	}

Every odometer path routes the merchant through that one suffix‑less builder — the confirmation controller,

App/src/components/MoneyRequestConfirmationList/DistanceRequestController.tsx

Lines 230 to 241 in 4bafe13

	const distanceMerchant = DistanceRequestUtils.getDistanceMerchant(
	hasRoute,
	distance,
	unit,
	rate ?? 0,
	currency ?? CONST.CURRENCY.USD,
	translate,
	toLocaleDigit,
	getCurrencySymbol,
	isManualDistanceRequest,
	);
	setMoneyRequestMerchant(transactionID, distanceMerchant, true);

the skip‑confirmation submit path,

App/src/pages/iou/request/step/IOURequestStepDistance/handleMoneyRequestStepDistanceNavigation.ts

Lines 133 to 141 in 4bafe13

	const merchant = DistanceRequestUtils.getDistanceMerchant(
	true,
	distanceInMeters,
	unit,
	mileageRate?.rate ?? 0,
	mileageRate?.currency ?? transaction?.currency ?? CONST.CURRENCY.USD,
	translate,
	(digit) => toLocaleDigit(IntlStore.getCurrentLocale(), digit),
	getCurrencySymbol,

and the optimistic edit path in getUpdatedTransaction (which recomputes modifiedMerchant from getDistanceMerchant while writing the readings to the comment right below):

App/src/libs/TransactionUtils/index.ts

Lines 843 to 877 in 4bafe13

	const updatedMerchant = DistanceRequestUtils.getDistanceMerchant(
	true,
	distanceInMeters,
	unit,
	rate,
	updatedCurrency,
	translateLocal,
	(digit) => toLocaleDigit(IntlStore.getCurrentLocale(), digit),
	getCurrencySymbol,
	isManualDistanceRequest(transaction),
	);
	// No locally resolvable rate (e.g. track expense without policy loaded) → scale the previous
	// amount by the distance ratio so the optimistic value isn't 0. `modifiedAmount` is `""` for
	// unedited transactions, so coerce via Number() and fall through to `amount`.
	const previousAmount = Number(transaction?.modifiedAmount) || transaction?.amount || 0;
	const useFallback = !rate && !!previousDistanceInMeters && !!previousAmount && !!distanceInMeters;
	if (useFallback) {
	updatedTransaction.modifiedAmount = Math.round(previousAmount * (distanceInMeters / previousDistanceInMeters));
	updatedTransaction.modifiedMerchant = updatedMerchant;
	// Leave currency alone — without a resolvable rate we don't know the target currency.
	} else {
	updatedTransaction.modifiedAmount = amount;
	updatedTransaction.modifiedMerchant = updatedMerchant;
	updatedTransaction.modifiedCurrency = updatedCurrency;
	}
	}
	if (Object.hasOwn(transactionChanges, 'odometerStart') && typeof transactionChanges.odometerStart === 'number') {
	lodashSet(updatedTransaction, 'comment.odometerStart', transactionChanges.odometerStart);
	}
	if (Object.hasOwn(transactionChanges, 'odometerEnd') && typeof transactionChanges.odometerEnd === 'number') {
	lodashSet(updatedTransaction, 'comment.odometerEnd', transactionChanges.odometerEnd);
	}

So the merchant that gets shown on the transaction never carries the entered readings. The chain is: readings saved to the comment → merchant built by getDistanceMerchant with no reading info → merchant line shows 43.00 mi @ $0.00/mi only. (The "start auto‑populating from the previous expense's end" is the backend default that kicks in whenever a start reading isn't present, so it resurfaces alongside the same regression.)

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

Make getDistanceMerchant the single place that appends the readings: give it optional odometerStart / odometerEnd params and, when they're present, append a readings segment (behind a new translation, e.g. distance.odometer.readingsSuffix) to the returned string:

App/src/libs/DistanceRequestUtils.ts

Lines 256 to 279 in 4bafe13

	function getDistanceMerchant(
	hasRoute: boolean,
	distanceInMeters: number,
	unit: Unit | undefined,
	rate: number | undefined,
	currency: string,
	translate: LocaleContextProps['translate'],
	toLocaleDigit: LocaleContextProps['toLocaleDigit'],
	getCurrencySymbol: CurrencyListActionsContextType['getCurrencySymbol'],
	isZeroDistanceAllowed?: boolean,
	): string {
	if (!hasRoute || !rate) {
	return translate('iou.fieldPending');
	}
	if (!distanceInMeters && !isZeroDistanceAllowed) {
	return '';
	}
	const distanceInUnits = getDistanceForDisplay(hasRoute, distanceInMeters, unit, rate, translate, true, isZeroDistanceAllowed);
	const ratePerUnit = getFormattedRateValue(unit, rate, currency, translate, toLocaleDigit, getCurrencySymbol, undefined, true);
	return `${distanceInUnits} ${CONST.DISTANCE_MERCHANT_SEPARATOR} ${ratePerUnit}`;
	}

Then pass the readings from the three call sites that already have them — DistanceRequestController, handleMoneyRequestStepDistanceNavigation, and the distance branch of getUpdatedTransaction — so the optimistic and persisted merchant line matches what's stored in the comment. Fixing the shared builder keeps create, skip‑confirmation, and edit consistent.

What alternative solutions did you explore? (Optional)

If the readings are expected to be rendered by the backend‑generated merchant, the regression is instead that they aren't reaching the server. In that case verify the readings survive the confirmation gate odometerStart: isOdometerDistanceRequest ? transaction.comment?.odometerStart : undefined and the typeof … === 'number' guard on the edit path, since either dropping the value would explain both the missing merchant suffix and the returning auto‑populate.

App/src/pages/iou/request/step/confirmation/useExpenseSubmission.ts

Lines 823 to 824 in 4bafe13

	odometerStart: isOdometerDistanceRequest ? transaction.comment?.odometerStart : undefined,
	odometerEnd: isOdometerDistanceRequest ? transaction.comment?.odometerEnd : undefined,