[Due for payment 2026-09-07][$250] Expense Report- "Rate not valid for this workspace" error msg not appears

[applause-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.35-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
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/64947920/folder/13176670/47218012/1573556433?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11 Home/Chrome
App Component: Money Requests

Action Performed:

1. Open https://staging.new.expensify.com/
2. Create new account (Something else)
3. Navigate to Self DM
4. Track a distance expense
5. Open the created expense
6. Click on 'Report' fiield
7. Click on 'Upgrade'
8. Complete the flow
9. Click on 'Create report' button

Expected Result:

"Rate not valid for this workspace" error message appears automatically on the report

Actual Result:

"Rate not valid for this workspace" error message does not appear. The rate is changed into default rate automatically

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7209829_1784207073845.error_msg_is_not_displayed.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7209829

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077762505573967371
• Upwork Job ID: 2077762505573967371
• Last Price Increase: 2026-08-19

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/b75c3d7d855865c064e1cbfaa2929798db670479b9b9f118976738d2fcbdb1c8

[MelvinBot]

Issue Analysis

This looks like an outdated test expectation, not a product bug. The "actual" behavior — the distance rate silently switching to the new workspace's default rate with no error — is intended by design. When a Self DM (tracked) distance expense is moved into a workspace, the fake P2P rate is deliberately dropped and replaced with the new workspace's default IRS mileage rate, so there is a valid rate and no "Rate not valid for this workspace" error should appear.

Root Cause: The "Create report" flow routes through submitTrackedExpenseToPolicy in TrackExpense.ts. For a P2P transaction it explicitly strips the rate to undefined and then falls back to the newly created workspace's default rate:

• TrackExpense.ts:2622 — const mileageRate = isCustomUnitRateIDForP2P(transaction) ? undefined : customUnitRateID;
• TrackExpense.ts:2248 — customUnitRateID: isDistanceRequest ? (createdWorkspaceParams?.customUnitRateID ?? transactionParams.customUnitRateID) : undefined,

Because the transaction is given the workspace's valid default rate, no invalidRate error and no CUSTOM_UNIT_OUT_OF_POLICY violation is ever generated for this path. The "Rate not valid for this workspace" errors live on a different code path (the confirmation page controller), which this flow bypasses.

Recommended next step: Have BugZero/QA confirm the intended behavior with the feature owner. If auto-resetting to the workspace default is correct (it appears to be — it's the better UX than a hard error), the regression test case should be updated rather than the code changed.

Investigation details

Two separate "Rate not valid" surfaces exist — the test conflates them:

1. Confirmation-page error (iou.error.invalidRate, "Rate not valid for this workspace. Please select an available rate…") — set only by the DistanceRequestController effect when a distance transaction sits on the confirmation page.
2. Report-level violation (customUnitOutOfPolicy) — decided in MoneyRequestView.tsx:590-591, requiring either a backend CUSTOM_UNIT_OUT_OF_POLICY violation or isDistanceRequest && !rate.

The "Create report" flow (open expense → Report field → Upgrade → Create report) goes through neither. It calls submitTrackedExpenseToPolicy, where the P2P rate (_FAKE_P2P_ID_, via isCustomUnitRateIDForP2P) is stripped to undefined before any validation runs, then replaced with createdWorkspaceParams.customUnitRateID (the workspace default). So the backend receives a valid rate and never flags it.

The code comments at TrackExpense.ts:2245-2250 show this is deliberate handling, not an accidental gap.

Alternative explanation considered: that the validation is simply missing on this path (a real bug). Ruled out because the rate substitution is explicit and commented — the transaction is intentionally never left with an invalid rate on the move-to-workspace path, so there is nothing for a validator to flag.

Note: I could not confirm from git history whether the test expectation predates this design (the local App checkout is a shallow, depth-1 clone). The code itself is unambiguous that the reset is intentional.

Possibly related issues

• [Due for payment 2026-07-30] Submit workspace - Rate not valid error remains after selecting default rate #96200 — "Submit workspace - Rate not valid error remains after selecting default rate" — the inverse bug on the confirmation-page path; a genuine bug in the DistanceRequestController validation.
• [Exploratory] Expense-Rate not valid for workspace is shown briefly on submitting self dm expense to 1:1 #93643 — "[Exploratory] Rate not valid for workspace is shown briefly on submitting self dm expense to 1:1".

---

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

[aswin-s]

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

When a user tracks a distance expense in Self DM (which assigns the internal FAKE_P2P_ID rate) and then moves it to a newly-created workspace report via "Report → Upgrade → Create report", the expected CUSTOM_UNIT_OUT_OF_POLICY ("Rate not valid for this workspace") violation never surfaces on the report. Instead the rate is silently replaced with the workspace default, giving the user no indication that their original rate was invalid for the workspace.

---

What is the root cause of the bug?

The bug has one active layer (the primary cause) and one secondary path that is not reachable in the primary flow but is worth hardening.

Primary (Transaction.ts — auto-swap pre-empts violation):

In changeTransactionsReport (src/libs/actions/Transaction.ts:~1145–1250), before calling getViolationsOnyxData, the function detects that FAKE_P2P_ID is not a valid workspace rate and auto-swaps it:

// Transaction.ts — inside changeTransactionsReport, for each transaction
const currentRateID = transaction.comment?.customUnit?.customUnitRateID; // "fake_P2P_id"
const currentRate = getDistanceRateCustomUnitRate(policy, currentRateID);  // undefined — not in workspace
if (!currentRateID || !currentRate || currentRate.enabled === false) {
    const defaultRate = DistanceRequestUtils.getDefaultMileageRate(policy); // workspace default
    if (defaultRate?.customUnitRateID) {
        transactionForViolations = { ...transaction, comment: { ...transaction.comment,
            customUnit: { ...transaction.comment?.customUnit,
                customUnitRateID: defaultRate.customUnitRateID, // SWAPPED — no longer FAKE_P2P_ID
            },
        }};
    }
}
// Violations then computed on transactionForViolations (workspace default rate, NOT FAKE_P2P_ID)
const violationData = ViolationsUtils.getViolationsOnyxData({
    updatedTransaction: transactionForViolations,  // workspace default rate
    // isSelfDM not passed → undefined
});

getViolationsOnyxData sees the workspace default rate:

• isCustomUnitRateIDForP2P(transactionForViolations) → false (not FAKE_P2P_ID)
• getDistanceRateCustomUnitRate(policy, defaultRateID) → valid rate found
• CUSTOM_UNIT_OUT_OF_POLICY is cleared — violation never raised

Secondary (ViolationsUtils.ts:613–615 — secondary bypass for no-default-rate edge case):

If the workspace has no default rate, transactionForViolations still carries FAKE_P2P_ID. getViolationsOnyxData (called without isSelfDM) then hits:

// ViolationsUtils.ts:613–615
const isTransactionOnPolicyExpenseChat = updatedTransaction.participants?.some(
    (participant) => participant?.isPolicyExpenseChat
);
if (TransactionUtils.isCustomUnitRateIDForP2P(updatedTransaction) && !isTransactionOnPolicyExpenseChat) {
    newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY});
}

At move time, updatedTransaction.participants still reflects the Self DM context, so isPolicyExpenseChat is false → violation cleared even though a real policy was passed.

Why this guard exists and why it must be narrowed carefully:

The existing isTransactionOnPolicyExpenseChat guard serves a real purpose: a P2P distance expense created while a workspace policy is still in context (e.g. the new manual expense flow switching the recipient from a workspace to a person before the API distance response arrives) must not surface a spurious CUSTOM_UNIT_OUT_OF_POLICY violation. The current code clears the violation whenever FAKE_P2P_ID is present and participants do not include a policy expense chat, which is the correct behaviour for that scenario. Any secondary fix must preserve this protection.

Not active in this code path:
Lines 628–630 (else if (isSelfDM && isDistanceRequestForCustomUnit)) are dead code here — isSelfDM is not passed to getViolationsOnyxData from changeTransactionsReport (it defaults to undefined).

---

What changes do you think we should make?

Fix 1 — Transaction.ts (primary fix, src/libs/actions/Transaction.ts):

Gate the auto-swap so it never fires for P2P-rate transactions. FAKE_P2P_ID transactions need the violation raised — not a silent rate replacement:

// Before (line ~1150):
if (!currentRateID || !currentRate || currentRate.enabled === false) {
    const defaultRate = DistanceRequestUtils.getDefaultMileageRate(policy);
    if (defaultRate?.customUnitRateID) { /* swap */ }
}

// After:
if ((!currentRateID || !currentRate || currentRate.enabled === false)
    && !TransactionUtils.isCustomUnitRateIDForP2P(transaction)) {
    const defaultRate = DistanceRequestUtils.getDefaultMileageRate(policy);
    if (defaultRate?.customUnitRateID) { /* swap */ }
}

With this fix, FAKE_P2P_ID stays in transactionForViolations, and the violation checker will encounter it. This also means transactionIDToUpdatedCustomUnitRateID is not populated for P2P transactions, so the backend won't receive a stale rate-update instruction.

Fix 1 alone is sufficient for the primary flow (workspace has a default rate). Fix 2 below hardens the no-default-rate edge case without touching the participant-based guard that protects genuine P2P expenses.

Fix 2 — ViolationsUtils.ts (secondary fix, [src/libs/Violations/ViolationsUtils.ts:613](https://github.com/Expensify/App/blob/848dbf50b1a023cbe52d1336ca76836a02e285ac/src/libs/Violations/ViolationsUtils.ts#L613)–615):

The secondary bypass clears CUSTOM_UNIT_OUT_OF_POLICY whenever FAKE_P2P_ID is present and isPolicyExpenseChat is false. This is correct for genuine P2P expenses and must be preserved. The only scenario it fails to handle is the no-default-rate edge case from changeTransactionsReport, where the transaction was explicitly moved into a workspace report but participants have not yet been updated to reflect isPolicyExpenseChat.

Rather than replacing the participant guard (which would break genuine P2P protection), narrow it so the bypass only fires when no workspace policy is being evaluated. The policy parameter is already available at the call site:

// Before (line ~613):
const isTransactionOnPolicyExpenseChat = updatedTransaction.participants?.some(
    (participant) => participant?.isPolicyExpenseChat
);
if (TransactionUtils.isCustomUnitRateIDForP2P(updatedTransaction) && !isTransactionOnPolicyExpenseChat) {
    newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY});
}

// After:
const isTransactionOnPolicyExpenseChat = updatedTransaction.participants?.some(
    (participant) => participant?.isPolicyExpenseChat
);
// Only suppress the violation when there is no real workspace policy in scope.
// If a real policy is present, the transaction has been moved into a workspace context
// and FAKE_P2P_ID is invalid there — let the rate-lookup below raise the violation.
// Genuine P2P expenses are always called without a policy, so this guard continues to protect them.
const hasRealPolicy = !!policy && !!policy.id;
if (TransactionUtils.isCustomUnitRateIDForP2P(updatedTransaction)
    && !isTransactionOnPolicyExpenseChat
    && !hasRealPolicy) {
    newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY});
}
// Falls through to rate-lookup below, which finds no match for FAKE_P2P_ID
// → pushes CUSTOM_UNIT_OUT_OF_POLICY at line 633

This preserves the existing behaviour for all genuine P2P scenarios (no policy passed) while allowing the violation to surface when changeTransactionsReport calls getViolationsOnyxData with a real workspace policy.

Fix 3 — Regression test (tests/unit/ViolationsUtilsTest.ts):

Add a test: Self DM distance transaction with FAKE_P2P_ID rate, violations recomputed via getViolationsOnyxData with a real workspace policy (that has a valid default rate) → expect CUSTOM_UNIT_OUT_OF_POLICY to be present in the result.

Add a second test to guard against regression of the genuine P2P case: distance transaction with FAKE_P2P_ID, getViolationsOnyxData called without a policy (simulating P2P creation) → expect CUSTOM_UNIT_OUT_OF_POLICY to be absent from the result.

---

What alternative solutions did you explore?

• Fix ViolationsUtils only (without fixing Transaction.ts): Insufficient for the primary case — after the auto-swap, transactionForViolations no longer has FAKE_P2P_ID, so the ViolationsUtils change at line 614 is never reached. Both layers must be fixed.
• Remove the auto-swap entirely for all invalid rates: Too broad — the auto-swap is correct for expired or disabled workspace rates. The guard should be scoped specifically to isCustomUnitRateIDForP2P.
• Replace the isTransactionOnPolicyExpenseChat guard entirely with a policy-presence check: This would drop the protection the current code gives genuine P2P expenses created while a workspace policy is still in context. The narrower hasRealPolicy addition in Fix 2 achieves the same outcome without removing the existing guard.
• Raise the violation server-side only: The user sees the optimistic client state immediately after "Create report" — a server-only fix would create a confusing window where the report shows no violation.

[MobileMage]

Proposal

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

When a distance expense tracked in the Self DM is moved onto a newly upgraded workspace via the Report field's "Create report" button, the expected "Rate not valid for this workspace" violation never appears. Instead the expense's P2P distance rate is silently replaced with the workspace's default mileage rate and the amount is recalculated, so the user is never prompted that their rate wasn't valid for the workspace.

What is the root cause of that problem?

A tracked distance expense created in the Self DM carries the pseudo rate CONST.CUSTOM_UNITS.FAKE_P2P_ID in comment.customUnit.customUnitRateID. When the user picks "Create report" on the Report field, IOURequestStepReport creates the optimistic report and calls handleRegularReportSelection, which (since action is EDIT) calls changeTransactionsReport in src/libs/actions/Transaction.ts. Inside that action there is an auto-select block that runs for every distance expense moved to a group policy: it looks up the current rate on the destination policy and, if it's missing or disabled, silently swaps in the default rate:

App/src/libs/actions/Transaction.ts

Lines 1202 to 1206 in 11fc3a6

	if (isGroupPolicy(policy) && policy?.id && isDistanceRequest(transaction)) {
	const currentRateID = transaction.comment?.customUnit?.customUnitRateID;
	const currentRate = currentRateID ? getDistanceRateCustomUnitRate(policy, currentRateID) : undefined;
	if (!currentRateID || !currentRate || currentRate.enabled === false) {
	const defaultRate = DistanceRequestUtils.getDefaultMileageRate(policy);

Because FAKE_P2P_ID never exists on any workspace, getDistanceRateCustomUnitRate(policy, currentRateID) returns undefined for every tracked expense, so this branch always fires. It records the swap in transactionIDToUpdatedCustomUnitRateID (sent to the backend as an API param, so the server persists the default rate and never sees the invalid one), recalculates amount/modifiedMerchant/modifiedCurrency from the new rate, and — critically — builds transactionForViolations from the already-fixed transaction. The subsequent ViolationsUtils.getViolationsOnyxData({updatedTransaction: transactionForViolations, ...}) call then finds a valid enabled rate and rejects CUSTOM_UNIT_OUT_OF_POLICY instead of pushing it, so the violation appears neither optimistically nor from the server response. The rate simply changes, which is exactly the reported symptom.

This directly contradicts the documented behavior in the violation engine itself, which states that a track expense moved onto a workspace should keep FAKE_P2P_ID so the violation prompts the user to pick a workspace rate:

App/src/libs/Violations/ViolationsUtils.ts

Lines 610 to 614 in 11fc3a6

	// arrives). We must NOT clear it when the transaction is still bound to a policy expense chat, because a
	// track expense moved onto a workspace intentionally keeps FAKE_P2P_ID until the user picks a workspace
	// rate, and the violation is what prompts them to do so — so that case falls through to the rate check below.
	const isTransactionOnPolicyExpenseChat = updatedTransaction.participants?.some((participant) => participant?.isPolicyExpenseChat);
	if (TransactionUtils.isCustomUnitRateIDForP2P(updatedTransaction) && !isTransactionOnPolicyExpenseChat) {

The auto-select block (added in PR #88286 to handle rates that became invalid during a move) was written too broadly: it makes sense when the expense had a real workspace rate that is missing or disabled on the destination policy (workspace-to-workspace moves, disabled rates), but for the P2P pseudo rate it overrides the intended "show the violation and let the user choose" flow.

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

In changeTransactionsReport, gate the auto-select block so it never fires for the P2P pseudo rate — only a genuinely stale workspace rate should be auto-replaced. Using the existing isCustomUnitRateIDForP2P helper from TransactionUtils (already the canonical check for this rate):

const isP2PRate = isCustomUnitRateIDForP2P(transaction);
if (!isP2PRate && (!currentRateID || !currentRate || currentRate.enabled === false)) {

With the swap skipped, no transactionIDToUpdatedCustomUnitRateID entry is sent, so the backend sees the invalid rate on ChangeTransactionsReport and returns the customUnitOutOfPolicy violation as it did before the regression. To also surface it optimistically, the P2P-clearing guard in ViolationsUtils must fall through to the rate check, which it only does when updatedTransaction.participants contains a policy expense chat — and changeTransactionsReport never updates participants. So in the same block, when the P2P rate is kept on a group-policy move, mark the violation-calculation copy accordingly:

transactionForViolations = {...transaction, participants: [{...transaction.participants?.at(0), isPolicyExpenseChat: true, policyID: policy.id}]};

App/src/libs/actions/Transaction.ts

Lines 1292 to 1295 in 11fc3a6

	transactionForViolations = {
	...updatedTransaction,
	...optimisticValue,
	};

This is safe for the scenarios PR #88286 targeted: expenses moved between workspaces with a missing/disabled real rate still get the default rate auto-selected with recalculated amounts, and the transactionIDToUpdatedCustomUnitRateID API param still flows for them. Manually picking a rate afterwards goes through updateMoneyRequestDistanceRate, which recomputes violations optimistically and clears the flag, so the violation correctly disappears once the user resolves it.

What alternative solutions did you explore? (Optional)

We considered relaxing the P2P guard in ViolationsUtils.getViolationsOnyxData to flag FAKE_P2P_ID whenever the passed policy is a group policy regardless of participants, but that guard was added specifically to prevent spurious "Rate not valid" violations during genuine P2P expense creation while a workspace policy is still in context, and loosening it risks regressing that flow; fixing the move action itself, where the rate is actually being (wrongly) rewritten, is both narrower and matches the layer where the symptom is produced.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 14:30:52 UTC.

Proposal

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

When a distance expense tracked in the Self DM is moved onto a newly created workspace whose rate list doesn't contain the expense's rate, the Rate not valid for this workspace message never appears. Instead the rate is silently replaced with the workspace's default mileage rate and the amount is recalculated, so the user is never prompted to pick a valid rate.

What is the root cause of that problem?

changeTransactionsReport auto-selects the workspace's default rate whenever the moved distance expense's current rate isn't valid for the destination policy, and it does this before violations are computed:

App/src/libs/actions/Transaction.ts

Lines 1199 to 1208 in c88326a

	// Auto-select a valid default distance rate when moving to a workspace where the current rate is invalid,
	// and recalculate derived fields (amount, merchant, currency) to match the new rate.
	let transactionForViolations = transaction;
	if (isGroupPolicy(policy) && policy?.id && isDistanceRequest(transaction)) {
	const currentRateID = transaction.comment?.customUnit?.customUnitRateID;
	const currentRate = currentRateID ? getDistanceRateCustomUnitRate(policy, currentRateID) : undefined;
	if (!currentRateID || !currentRate || currentRate.enabled === false) {
	const defaultRate = DistanceRequestUtils.getDefaultMileageRate(policy);
	if (defaultRate?.customUnitRateID) {
	transactionIDToUpdatedCustomUnitRateID[transaction.transactionID] = defaultRate.customUnitRateID;

A distance expense tracked in Self DM carries the P2P rate (FAKE_P2P_ID), which is never a member of any workspace's rate list. So getDistanceRateCustomUnitRate(policy, currentRateID) returns undefined, the !currentRate branch is taken, and the rate is swapped to the workspace default. Because transactionForViolations now holds a valid rate, nothing downstream can flag it.

This directly contradicts the behavior that ViolationsUtils.getViolationsOnyxData is written to produce for exactly this scenario — a tracked expense should keep FAKE_P2P_ID and raise CUSTOM_UNIT_OUT_OF_POLICY so the user is prompted to choose a workspace rate:

App/src/libs/Violations/ViolationsUtils.ts

Lines 604 to 614 in c88326a

	if (customUnitRateID && customUnitRateID.length > 0 && (!isSelfDM || isDistanceRequestForCustomUnit)) {
	// A P2P distance rate (FAKE_P2P_ID) isn't tied to any workspace, so it can never be "out of policy"
	// when the expense is genuinely P2P (a person chat or self DM). Clear any stale violation instead of
	// flagging it. This prevents a spurious "Rate not valid for this workspace" from appearing optimistically
	// when a P2P expense is created while a workspace policy is still in context (e.g. the new manual expense
	// flow switching the recipient from the default workspace to a person before the API distance response
	// arrives). We must NOT clear it when the transaction is still bound to a policy expense chat, because a
	// track expense moved onto a workspace intentionally keeps FAKE_P2P_ID until the user picks a workspace
	// rate, and the violation is what prompts them to do so — so that case falls through to the rate check below.
	const isTransactionOnPolicyExpenseChat = updatedTransaction.participants?.some((participant) => participant?.isPolicyExpenseChat);
	if (TransactionUtils.isCustomUnitRateIDForP2P(updatedTransaction) && !isTransactionOnPolicyExpenseChat) {

And MoneyRequestView already knows how to surface the message from an unresolved rate, but the auto-swap removes the condition that would trigger it (isDistanceRequest && !rate):

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 590 to 591 in c88326a

	const isCustomUnitOutOfPolicy =
	(transactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY) || (isDistanceRequest && !rate)) && !isTrackExpense;

In short: the auto-select from #88286 pre-empts the invalid-rate signal that the rest of the app relies on.

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

Don't auto-swap when the moved expense is on a P2P rate (FAKE_P2P_ID). Guard the auto-select condition so it only fires for genuine workspace rates that are missing or disabled, and leave a tracked expense's rate untouched so the invalid-rate state can surface.

In changeTransactionsReport, the branch that currently reads:

if (!currentRateID || !currentRate || currentRate.enabled === false) {

becomes:

if ((!currentRateID || !currentRate || currentRate.enabled === false) && !isCustomUnitRateIDForP2P(transaction)) {

isCustomUnitRateIDForP2P is already exported from TransactionUtils (customUnitRateID === CONST.CUSTOM_UNITS.FAKE_P2P_ID), so it just needs importing here.

With the P2P rate preserved, DistanceRequestUtils.getRate resolves no valid workspace rate, MoneyRequestView.isCustomUnitOutOfPolicy becomes true via isDistanceRequest && !rate && !isTrackExpense, and Rate not valid for this workspace is shown — prompting the user to select a valid rate, which is the expected result. Real workspace-to-workspace moves (a rate that exists but was disabled/removed) still get #88286's auto-select behavior.

What specific scenarios should we cover in automated tests to prevent this regression in the future?

• Move a Self DM tracked distance expense (rate = FAKE_P2P_ID) onto a workspace and assert changeTransactionsReport does not write transactionIDToUpdatedCustomUnitRateID and keeps customUnitRateID === FAKE_P2P_ID, and that the resulting transaction yields the CUSTOM_UNIT_OUT_OF_POLICY / unresolved-rate state.
• Move a distance expense whose customUnitRateID is a real workspace rate that is disabled/absent on the destination policy, and assert the auto-select to the default rate still happens (guard doesn't regress Auto-select valid distance rate when moving expense to workspace #88286).

What alternative solutions did you explore? (Optional)

Explicitly push the CUSTOM_UNIT_OUT_OF_POLICY violation from changeTransactionsReport for the P2P case instead of relying on the UI's !rate fallback. This is more code and duplicates logic that already lives in ViolationsUtils, so preventing the premature rate swap is the cleaner fix. Another option is dropping the auto-select entirely and always surfacing the violation, but that would regress the intended workspace-to-workspace behavior from #88286, so scoping the guard to FAKE_P2P_ID is preferable.

[melvin-bot]

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

[wildan-m]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 15:05:07 UTC.

Proposal

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

When a tracked distance expense is created in the Self DM and then moved onto a workspace (Report field → Upgrade → Create report), the "Rate not valid for this workspace" error does not appear on the report. Instead the expense's distance rate is silently replaced with the workspace's default rate, which also silently changes the expense amount.

What is the root cause of that problem?

A tracked distance expense created in the Self DM carries the P2P rate FAKE_P2P_ID as its customUnitRateID. That rate belongs to no workspace, so once the expense lands on a workspace it is out of policy, and the app is supposed to raise the CUSTOM_UNIT_OUT_OF_POLICY violation ("Rate not valid for this workspace") to prompt the user to pick a workspace rate.

There are two separate reasons the violation never appears on this flow, and both have to be addressed for the message to show up.

First, the rate is overwritten before violations are ever computed. changeTransactionsReport — the action the Upgrade / Create report flow calls to move the expense — auto-selects the destination workspace's default mileage rate whenever the incoming rate is invalid for that workspace:

App/src/libs/actions/Transaction.ts

Lines 1199 to 1212 in 13c2d5d

	// Auto-select a valid default distance rate when moving to a workspace where the current rate is invalid,
	// and recalculate derived fields (amount, merchant, currency) to match the new rate.
	let transactionForViolations = transaction;
	if (isGroupPolicy(policy) && policy?.id && isDistanceRequest(transaction)) {
	const currentRateID = transaction.comment?.customUnit?.customUnitRateID;
	const currentRate = currentRateID ? getDistanceRateCustomUnitRate(policy, currentRateID) : undefined;
	if (!currentRateID || !currentRate || currentRate.enabled === false) {
	const defaultRate = DistanceRequestUtils.getDefaultMileageRate(policy);
	if (defaultRate?.customUnitRateID) {
	transactionIDToUpdatedCustomUnitRateID[transaction.transactionID] = defaultRate.customUnitRateID;
	// Build an updated transaction with the new rate so we can derive fields from it
	const updatedTransaction: typeof transaction = {
	...transaction,
	comment: {

Its invalid-rate condition is !currentRateID || !currentRate || currentRate.enabled === false. FAKE_P2P_ID is not a rate on the destination workspace, so getDistanceRateCustomUnitRate returns nothing and the condition is true — the P2P rate of a tracked expense is treated as just another invalid rate and overwritten with the workspace default, and the derived amount, merchant and currency are recalculated from it. That is the "rate is changed into the default rate automatically" part of the report.

The overwritten transaction is then what gets handed to the violation calculation as transactionForViolations:

App/src/libs/actions/Transaction.ts

Lines 1303 to 1305 in 13c2d5d

	const violationData = ViolationsUtils.getViolationsOnyxData({
	updatedTransaction: transactionForViolations,
	transactionViolations: currentTransactionViolations[transaction.transactionID] ?? [],

By that point customUnitRateID is a valid workspace rate, so isCustomUnitRateIDForP2P is false and the rate lookup succeeds — CUSTOM_UNIT_OUT_OF_POLICY is never generated.

Second, even if the P2P rate did survive the move, the violation would still be cleared. ViolationsUtils.getViolationsOnyxData intends to let a track expense that has been moved onto a workspace fall through to the rate check, and its comment says so explicitly. But it decides whether the transaction is on a policy expense chat by reading the transaction's own participants:

App/src/libs/Violations/ViolationsUtils.ts

Lines 613 to 616 in 13c2d5d

	const isTransactionOnPolicyExpenseChat = updatedTransaction.participants?.some((participant) => participant?.isPolicyExpenseChat);
	if (TransactionUtils.isCustomUnitRateIDForP2P(updatedTransaction) && !isTransactionOnPolicyExpenseChat) {
	newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY});
	} else {

changeTransactionsReport never updates participants when it moves a transaction — the transaction it passes for violations still describes the Self DM it was created in. So isTransactionOnPolicyExpenseChat is false on this flow, the P2P rate takes the reject branch, and the violation is removed rather than raised. The destination being a workspace expense report is known to the caller, but it is not visible on the transaction itself.

So the intent added in July — that a moved track expense keeps FAKE_P2P_ID until the user picks a workspace rate, with the violation prompting them to do so — is defeated twice over: the April auto-select rewrites the rate first, and the participants-based policy-expense-chat check would not recognise the moved expense even if it hadn't.

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

Both causes above need addressing; fixing either one alone still leaves the error message absent.

In changeTransactionsReport (src/libs/actions/Transaction.ts), narrow the auto-select so it does not apply to a distance expense still carrying the P2P rate. Keep auto-selecting the workspace default when the expense carries a real-but-invalid workspace rate (a rate from a different workspace, or one that has since been disabled — the case the auto-select was written for), but skip it when the rate is the P2P rate, which is the signal that this is a tracked or self-DM expense being moved onto a workspace for the first time. TransactionUtils.isCustomUnitRateIDForP2P already answers this question and is the same check ViolationsUtils uses, so both sides of the behaviour stay in agreement. This preserves the rate, and with it the original amount.

In ViolationsUtils.getViolationsOnyxData, let the caller state that the transaction is on a policy expense chat. Add an optional flag that takes precedence over the participants-based check, and have changeTransactionsReport set it from the destination report when that report is an expense report. The participants check stays as the fallback for every existing caller, so no other flow changes behaviour. With the destination known, the moved track expense no longer takes the reject branch, falls through to the rate check as the July code already intended, and CUSTOM_UNIT_OUT_OF_POLICY is raised on its own.

Together these make the "Rate not valid for this workspace" message appear on the moved report, leave the expense amount untouched, and let picking a workspace rate clear the violation through the normal rate-update path. The April auto-select keeps working for the case it actually targeted.

I verified this with a unit test covering the reported flow: on main the moved expense's rate becomes the workspace default (the reported bug), and with the change it keeps FAKE_P2P_ID, keeps its amount, and carries exactly one CUSTOM_UNIT_OUT_OF_POLICY violation. Two existing tests asserted the auto-select for a FAKE_P2P_ID rate; they are updated to use a real-but-invalid workspace rate, which is the case the auto-select is meant to cover, so that coverage stays intact.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/96319-keep-p2p-rate-on-move?expand=1

What alternative solutions did you explore? (Optional)

Leaving the auto-select in place and instead raising the violation from the moved transaction anyway was considered, but that would mean flagging a rate the app itself had just chosen as invalid, which is contradictory and would leave the user with a violation they cannot resolve by picking a different rate.

Updating the transaction's participants during the move, so the existing participants-based check recognises the policy expense chat on its own, was also considered. That would avoid the new flag, but participants is read well beyond violations, so rewriting it as a side effect of moving a report risks changing unrelated behaviour; passing the destination context explicitly is the narrower change.

Treating the report as outdated and closing the issue as working-as-intended was also considered, since the auto-select behaviour was deliberate when it was added. The July change in ViolationsUtils is the more recent statement of intent and explicitly relies on the P2P rate surviving the move, so the auto-select is the side that is now out of date.

[samranahm]

🚨 Edited by proposal-police: This proposal was edited at 2026-08-19 01:03:39 UTC.

Proposal

What is the root cause of that problem?

When a user tracks a distance expense in Self DM and then moves it onto a workspace (Report field, Upgrade, Create report), the original rate is replaced with the new workspace default and the amount is recalculated. The expected "Rate not valid for this workspace" message never appears on confirm, so the user is not asked to pick a valid workspace rate.

That happens in getChangeTransactionsReportOnyxData inside src/libs/actions/Transaction.ts. For every distance expense moved onto a group policy, the action looks up the current customUnitRateID on the destination policy. If the rate is missing or disabled, it auto-selects the workspace default, clears defaultP2PRate, recalculates amount, merchant, and currency, and stores the swap in transactionIDToUpdatedCustomUnitRateID:

App/src/libs/actions/Transaction.ts

Lines 1260 to 1278 in 72c7789

	// Auto-select a valid default distance rate when moving to a workspace where the current rate is invalid,
	// and recalculate derived fields (amount, merchant, currency) to match the new rate.
	let transactionForViolations = transaction;
	if (isGroupPolicy(policy) && policy?.id && isDistanceRequest(transaction)) {
	const currentRateID = transaction.comment?.customUnit?.customUnitRateID;
	const currentRate = currentRateID ? getDistanceRateCustomUnitRate(policy, currentRateID) : undefined;
	if (!currentRateID || !currentRate || currentRate.enabled === false) {
	const defaultRate = DistanceRequestUtils.getDefaultMileageRate(policy);
	if (defaultRate?.customUnitRateID) {
	transactionIDToUpdatedCustomUnitRateID[transaction.transactionID] = defaultRate.customUnitRateID;
	// Build an updated transaction with the new rate so we can derive fields from it
	const updatedTransaction: typeof transaction = {
	...transaction,
	comment: {
	...transaction.comment,
	customUnit: {
	...transaction.comment?.customUnit,
	customUnitRateID: defaultRate.customUnitRateID,
	defaultP2PRate: undefined,

The rewritten transaction is then what gets handed to violation calculation as transactionForViolations:

App/src/libs/actions/Transaction.ts

Lines 1353 to 1374 in 72c7789

	transactionForViolations = {
	...updatedTransaction,
	...optimisticValue,
	};
	}
	}
	}
	let transactionReimbursable = transaction.reimbursable;
	// 2. Calculate transaction violations if moving transaction to a workspace
	if (isGroupPolicy(policy) && policy?.id) {
	const violationData = ViolationsUtils.getViolationsOnyxData({
	updatedTransaction: transactionForViolations,
	transactionViolations: currentTransactionViolations[transaction.transactionID] ?? [],
	policy,
	policyTagList: policyTagList ?? {},
	policyCategories: policyCategories ?? {},
	hasDependentTags: policyHasDependentTags,
	isInvoiceTransaction: false,
	shouldRemoveRejectedExpenseViolation: true,
	ownerLogin: undefined,
	});

By that point the rate is a valid enabled workspace rate, so ViolationsUtils.getViolationsOnyxData rejects CUSTOM_UNIT_OUT_OF_POLICY instead of raising it. The same swapped ID is also sent to the backend:

App/src/libs/actions/Transaction.ts

Lines 2017 to 2023 in 72c7789

	const parameters: ChangeTransactionsReportParams = {
	transactionList: movedTransactionIDs.join(','),
	reportID,
	transactionIDToReportActionAndThreadData: JSON.stringify(transactionIDToReportActionAndThreadData),
	...(Object.keys(transactionIDToUpdatedCustomUnitRateID).length > 0 && {
	transactionIDToUpdatedCustomUnitRateID: JSON.stringify(transactionIDToUpdatedCustomUnitRateID),
	}),

App/src/libs/API/parameters/ChangeTransactionsReportParams.ts

Lines 18 to 23 in 72c7789

	type ChangeTransactionsReportParams = {
	transactionList: string;
	reportID: string;
	transactionIDToReportActionAndThreadData: string; // A map of transactionID to TransactionThreadInfo
	transactionIDToUpdatedCustomUnitRateID?: string; // A JSON map of transactionID to the new customUnitRateID (for distance expenses moving to a workspace with an invalid rate)
	};

So both the client and the server persist the silent rate change. That is the reported "rate changed into default rate automatically" result.

The auto-select condition is !currentRateID || !currentRate || currentRate.enabled === false. It fires for two Self DM shapes, not only the P2P placeholder:

1. A Self DM expense that still carries FAKE_P2P_ID. That ID is never a member of any workspace rate map, so getDistanceRateCustomUnitRate(policy, currentRateID) returns undefined and the swap always runs.

2. A Self DM expense that already has a real default rate. Track-distance creation writes the default or last-selected rate of policyForMovingExpenses via getCustomUnitRateID when isTrackDistanceExpense is true:

App/src/libs/DistanceRequestUtils.ts

Lines 624 to 638 in 72c7789

	// For TrackDistanceExpense we will return the default or last selected rate of the policyForMovingExpenses.
	if (isPolicyExpenseChat || isTrackDistanceExpense) {
	const distanceUnit = Object.values(policy.customUnits ?? {}).find((unit) => unit.name === CONST.CUSTOM_UNITS.NAME_DISTANCE);
	const lastSelectedDistanceRateID = lastSelectedDistanceRates?.[policy.id];
	const lastSelectedDistanceRate = lastSelectedDistanceRateID ? distanceUnit?.rates[lastSelectedDistanceRateID] : undefined;
	if (!expenseDate) {
	if (lastSelectedDistanceRate?.enabled && lastSelectedDistanceRateID) {
	return lastSelectedDistanceRateID;
	}
	const defaultMileageRate = getDefaultMileageRate(policy);
	if (defaultMileageRate?.customUnitRateID) {
	return defaultMileageRate.customUnitRateID;
	}

Upgrade then creates a new workspace whose rate IDs are different. The original Self DM rate is missing on that new policy, so the same !currentRate branch fires and the Self DM default is replaced with the new workspace default. Gating the swap only on isCustomUnitRateIDForP2P does not cover this second shape.

The source of the move is already known in the same loop as isUnreportedExpense:

App/src/libs/actions/Transaction.ts

Lines 1096 to 1098 in 72c7789

	for (const transaction of transactions) {
	const isDeletedExpense = isDeletedTransaction(transaction);
	const isUnreportedExpense = !transaction.reportID || transaction.reportID === CONST.REPORT.UNREPORTED_REPORT_ID;

Keeping the original rate alone is still not enough for an immediate error. getViolationsOnyxData clears CUSTOM_UNIT_OUT_OF_POLICY whenever the rate is P2P and the transaction does not look like a policy expense chat, which it decides from updatedTransaction.participants:

App/src/libs/Violations/ViolationsUtils.ts

Lines 645 to 656 in 72c7789

	if (customUnitRateID && customUnitRateID.length > 0 && (!isSelfDM || isDistanceRequestForCustomUnit)) {
	// A P2P distance rate (FAKE_P2P_ID) isn't tied to any workspace, so it can never be "out of policy"
	// when the expense is genuinely P2P (a person chat or self DM). Clear any stale violation instead of
	// flagging it. This prevents a spurious "Rate not valid for this workspace" from appearing optimistically
	// when a P2P expense is created while a workspace policy is still in context (e.g. the new manual expense
	// flow switching the recipient from the default workspace to a person before the API distance response
	// arrives). We must NOT clear it when the transaction is still bound to a policy expense chat, because a
	// track expense moved onto a workspace intentionally keeps FAKE_P2P_ID until the user picks a workspace
	// rate, and the violation is what prompts them to do so — so that case falls through to the rate check below.
	const isTransactionOnPolicyExpenseChat = updatedTransaction.participants?.some((participant) => participant?.isPolicyExpenseChat);
	if (TransactionUtils.isCustomUnitRateIDForP2P(updatedTransaction) && !isTransactionOnPolicyExpenseChat) {
	newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY});

changeTransactionsReport does not pass destination context, and the snapshot it uses still describes Self DM. On confirm, the optimistic path therefore rejects the violation. The message only appears later, when the backend response writes CUSTOM_UNIT_OUT_OF_POLICY. The expected result is that it appears automatically as soon as the expense is moved.

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

Keep the original rate when an unreported Self DM distance expense (or a P2P placeholder rate) is moved onto a workspace. Write CUSTOM_UNIT_OUT_OF_POLICY into optimistic Onyx data so the error appears on confirm, not after the network response. Keep auto-select only for a real workspace rate that is missing or disabled on another workspace.

Step 1. Skip the auto-select for unreported expenses and unset P2P rates in getChangeTransactionsReportOnyxData

App/src/libs/actions/Transaction.ts

Lines 1260 to 1266 in 72c7789

	// Auto-select a valid default distance rate when moving to a workspace where the current rate is invalid,
	// and recalculate derived fields (amount, merchant, currency) to match the new rate.
	let transactionForViolations = transaction;
	if (isGroupPolicy(policy) && policy?.id && isDistanceRequest(transaction)) {
	const currentRateID = transaction.comment?.customUnit?.customUnitRateID;
	const currentRate = currentRateID ? getDistanceRateCustomUnitRate(policy, currentRateID) : undefined;
	if (!currentRateID || !currentRate || currentRate.enabled === false) {

isUnreportedExpense is already computed in this loop. DistanceRequestUtils.isUnsetDistanceCustomUnitRateID already returns true for FAKE_P2P_ID and the -1 marker:

App/src/libs/DistanceRequestUtils.ts

Lines 490 to 495 in 72c7789

	function isUnsetDistanceCustomUnitRateID(customUnitRateID: string | undefined): boolean {
	if (!customUnitRateID) {
	return true;
	}
	return customUnitRateID === CONST.CUSTOM_UNITS.FAKE_P2P_ID || customUnitRateID === CONST.CUSTOM_UNITS.UNSET_DISTANCE_RATE_ID;

Add a preserve flag and use it to skip the swap:

let transactionForViolations = transaction;
const shouldPreserveOriginalDistanceRate =
    isUnreportedExpense ||
    DistanceRequestUtils.isUnsetDistanceCustomUnitRateID(transaction.comment?.customUnit?.customUnitRateID);

if (
    isGroupPolicy(policy) &&
    policy?.id &&
    isDistanceRequest(transaction) &&
    !shouldPreserveOriginalDistanceRate
) {
    const currentRateID = transaction.comment?.customUnit?.customUnitRateID;
    const currentRate = currentRateID ? getDistanceRateCustomUnitRate(policy, currentRateID) : undefined;
    if (!currentRateID || !currentRate || currentRate.enabled === false) {
        // existing auto-select body unchanged
    }
}

This keeps the original customUnitRateID, defaultP2PRate, quantity, and amount. No transactionIDToUpdatedCustomUnitRateID entry is sent, so the backend keeps the same rate. Workspace-to-workspace auto-select for a real disabled or missing rate is unchanged.

Step 2. Tell getViolationsOnyxData that the destination is a policy expense report

App/src/libs/actions/Transaction.ts

Lines 1363 to 1374 in 72c7789

	if (isGroupPolicy(policy) && policy?.id) {
	const violationData = ViolationsUtils.getViolationsOnyxData({
	updatedTransaction: transactionForViolations,
	transactionViolations: currentTransactionViolations[transaction.transactionID] ?? [],
	policy,
	policyTagList: policyTagList ?? {},
	policyCategories: policyCategories ?? {},
	hasDependentTags: policyHasDependentTags,
	isInvoiceTransaction: false,
	shouldRemoveRejectedExpenseViolation: true,
	ownerLogin: undefined,
	});

changeTransactionsReport already has newReport. Pass that destination explicitly:

const violationData = ViolationsUtils.getViolationsOnyxData({
    updatedTransaction: transactionForViolations,
    transactionViolations: currentTransactionViolations[transaction.transactionID] ?? [],
    policy,
    policyTagList: policyTagList ?? {},
    policyCategories: policyCategories ?? {},
    hasDependentTags: policyHasDependentTags,
    isInvoiceTransaction: false,
    shouldRemoveRejectedExpenseViolation: true,
    ownerLogin: undefined,
    isPolicyExpenseChat: isExpenseReport(newReport),
});

This does not rewrite stored participants. It only gives the violation calculator the destination it already knows.

Step 3. Prefer that flag in ViolationsUtils.getViolationsOnyxData

App/src/libs/Violations/ViolationsUtils.ts

Lines 654 to 656 in 72c7789

	const isTransactionOnPolicyExpenseChat = updatedTransaction.participants?.some((participant) => participant?.isPolicyExpenseChat);
	if (TransactionUtils.isCustomUnitRateIDForP2P(updatedTransaction) && !isTransactionOnPolicyExpenseChat) {
	newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.CUSTOM_UNIT_OUT_OF_POLICY});

Add an optional isPolicyExpenseChat argument and use it before the existing participants probe. Do not delete the participants line. It is the fallback for every other caller:

isPolicyExpenseChat?: boolean;

const isTransactionOnPolicyExpenseChat =
    isPolicyExpenseChat ??
    updatedTransaction.participants?.some((participant) => participant?.isPolicyExpenseChat);

Without this flag, Step 1 still keeps the original rate, but the optimistic path still treats the expense as P2P and rejects CUSTOM_UNIT_OUT_OF_POLICY. The error then appears only after the backend response. With the flag, confirm writes the violation into optimistic Onyx data, so "Rate not valid for this workspace" shows immediately.

After these steps, Create report keeps the original Self DM rate and shows "Rate not valid for this workspace" on confirm. Picking a workspace rate clears it through the normal rate-update path.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Results

Kapture.2026-08-19.at.05.36.47.mp4