[$250] DEV: Rate not valid error is displayed when submitting a distance expense, but the Rate field is not editable

[m-natarajan]

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

---

Version Number:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @FitseTLT
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Create a Track Distance expense in Self DM.
2. Click Submit to a friend and choose a workspace.
3. Observe the Rate not valid error.
4. Try to edit the Rate field.

Expected Result:

The Rate field should contain a valid rate before submission.
If the rate is invalid, the user should be able to edit it and correct the value.
The expense should be submitted successfully once a valid rate is provided.

Actual Result:

The expense submission fails with Rate not valid.
The Rate field is not interactive/editable.
The user has no way to correct the invalid rate and is blocked from submitting the expense.

Workaround:

Unknown

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

2026-08-12.15-49-05.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022087538471250492293
• Upwork Job ID: 2087538471250492293
• Last Price Increase: 2026-08-20

[MelvinBot]

Proposal

What is the root cause of that problem?

Both symptoms trace back to one thing: the P2P sentinel rate _FAKE_P2P_ID_ survives when a Self-DM Track Distance expense is submitted to a workspace.

A distance expense created in a Self DM has no policy, so it is given the placeholder rate _FAKE_P2P_ID_ (TransactionUtils/index.ts:2412, CONST/index.ts:4588). When you "Submit to a friend" and choose an existing workspace, the action routes through requestMoney, whose distance branch forwards the transaction's customUnitRateID unchanged:

• TrackExpense.ts:1804-1809 and :1850 send customUnitRateID = _FAKE_P2P_ID_ straight into AddTrackedExpenseToPolicy.

Compare this to the sibling trackExpense/shareTrackedExpense paths, which explicitly null the placeholder out (TrackExpense.ts:2662: const mileageRate = isCustomUnitRateIDForP2P(transaction) ? undefined : customUnitRateID;). The requestMoney submit path is missing that normalization.

Because _FAKE_P2P_ID_ matches no rate on the destination workspace, ViolationsUtils raises customUnitOutOfPolicy → "Rate not valid for this workspace" (ViolationsUtils.ts:661-679, PolicyUtils.ts:374).

The "can't edit the Rate" half is the trap that makes this a hard block. The Rate row's chevron/tap is bound to canEditDistanceRate (MoneyRequestView.tsx:451-462, consumed at :1010), which requires canEditFieldOfMoneyRequest(DISTANCE_RATE) — and that returns true only when the transaction is on an expense report (ReportUtils.ts:5353-5356). If the submit lands the expense on an IOU/P2P report instead of a workspace expense report, the Rate field is read-only, so the user is prompted to fix an invalid rate they physically cannot edit.

Investigation details, data flow & the one open question

Data flow

1. Self-DM Track Distance expense → customUnit.customUnitRateID = '_FAKE_P2P_ID_'.
2. "Submit to a friend" + workspace → action SUBMIT, routed to requestMoney (not trackExpense) via useExpenseSubmission.ts:1116.
3. requestMoney forwards _FAKE_P2P_ID_ to AddTrackedExpenseToPolicy unchanged (TrackExpense.ts:1804-1850).
4. ViolationsUtils finds no matching workspace rate → customUnitOutOfPolicy → "Rate not valid".
5. MoneyRequestView shows the violation; the Rate row is non-interactive if the field-edit gate fails.

Alternative explanations considered: A changeTransactionsReport move (drag to another report) does remap the placeholder to the workspace default rate (Transaction.ts:1259-1265) — so this bug is specific to the tracked-expense submit path, which lacks that remap. The isP2PDistanceRequest branch of canEditDistanceOrRate is not the blocker on its own (it's true whenever the placeholder is kept); the decisive gate is canEditFieldOfMoneyRequest(DISTANCE_RATE) requiring an expense report.

Open question needing a runtime check (why this is Medium, not High confidence): confirm, in Onyx right after submit, (a) that comment.customUnit.customUnitRateID is still _FAKE_P2P_ID_, and (b) the destination report's type — expense report vs IOU report. That disambiguates whether the missing chevron comes from the report being IOU-typed (ReportUtils.ts:5355) or a transient render state.

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

1. Stop persisting the P2P placeholder on submit. In the requestMoney distance branch (TrackExpense.ts:1804-1809 / :1850), normalize the same way the trackExpense/shareTrackedExpense paths already do at :2662 — i.e. resolve _FAKE_P2P_ID_ to the destination workspace's default mileage rate (or drop it and let the backend default it) so a valid rate is submitted.
2. Keep the Rate field editable in the "rate out of policy" state so a user can always self-correct an invalid rate — verify the final report type in the repro and, if the expense is not landing on an expense report, that gate needs adjusting for this flow.

What alternative solutions did you explore? (Optional)

Normalize the placeholder once at the confirmation layer (getRateID in useExpenseSubmission.ts:310) so every submit path is consistent, rather than patching each action path individually.

Related issues

This is part of a cluster of Self-DM-distance → workspace rate bugs; the fix should be checked against them:

• [Exploratory] Expense-Rate not valid for workspace is shown briefly on submitting self dm expense to 1:1 #93643 — "Rate not valid for workspace" shown briefly on submitting self DM expense to 1:1
• [Due for payment 2026-08-17] [$250] Distance - Rate field is blank when distance is submitted from self DM offline #93575 — Rate field is blank when distance submitted from self DM offline
• Expense - Error after editing amount/distance/rate or adding distance split in self DM #91878 — Error after editing amount/distance/rate or adding distance split in self DM
• [Exploratory] Expense-Split distance expense with rate not valid violation shows unexpected error. #98339 — Split distance expense with rate-not-valid violation shows unexpected error

---

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

[j3ffffff]

VERDICT: POST
ROOT_CAUSE_ONELINER: After a track distance expense is submitted from Self DM to a workspace, the "Rate not valid" violation fires but the Rate field is non-interactive because canEditFieldOfMoneyRequest for DISTANCE_RATE only permits editing on expense reports or unreported transactions — the Self DM parent report satisfies neither condition.
PROPOSAL_TYPE: FIRST
AUTOPOST_SAFE: YES

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@Ollyws Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

@Ollyws Still overdue 6 days?! Let's take care of this!

[Ollyws]

@MelvinBot what would the code look like?

[MelvinBot]

yusufdeveloper2903 is right that this is a confirmation-screen bug (it never reaches requestMoney), so my original submit-path proposal was off. Here's what the fix actually looks like.

The fix

The confirmation screen already has an effect that swaps an unset/P2P placeholder rate for the destination workspace's default rate — but it explicitly bails out for exactly this scenario (moving a tracked expense whose rate is _FAKE_P2P_ID_):

DistanceRequestController.tsx:188-199

     useEffect(() => {
         if (
             !DistanceRequestUtils.isUnsetDistanceCustomUnitRateID(customUnitRateID) ||
             !isDistanceRequest ||
             !isPolicyExpenseChat ||
             !transactionID ||
             !lastSelectedRate ||
-            (isMovingTransactionFromTrackExpense && customUnitRateID === CONST.CUSTOM_UNITS.FAKE_P2P_ID) ||
             !selectedParticipants.some((participant) => participant.policyID === policy?.id)
         ) {
             return;
         }

And drop the now-unused isMovingTransactionFromTrackExpense from that effect's dependency array (L212-224).

Why this resolves both symptoms

The effect is already gated by !isPolicyExpenseChat (L192), so it only runs once a real workspace is the target — removing the FAKE_P2P_ID exclusion is safe. It then calls setCustomUnitRateID(...) with the workspace's default rate (L211), which fixes the whole chain:

• The placeholder is replaced by a valid workspace rate, so the first effect clears iou.error.invalidRate (L114-118) → "Rate not valid" goes away.
• mileageRate.rate is now truthy, so isRateInteractive = !!rate becomes true in RateField.tsx:97-98 → the Rate row is tappable/editable again.

This mirrors the swap that already works when a workspace is picked via the participant list (IOURequestStepConfirmation.tsx:456-468) and the report-move path (Transaction.ts:1263-1281) — the confirmation-submit path was just missing it.

Full trace & one thing to verify

Trace: Self-DM track distance → customUnitRateID = _FAKE_P2P_ID_. On submit-to-workspace, isMovingTransactionFromTrackExpense is true (IOUUtils.ts:325-331). The default-rate effect bails at L195, so the placeholder survives → DistanceRequestUtils.getRate returns the P2P rate branch / no workspace rate (DistanceRequestUtils.ts:714-724), and the controller sets formError = 'iou.error.invalidRate' (L128-129), which also blocks submit in confirmAction.ts:98-101. isUnsetDistanceCustomUnitRateID treats _FAKE_P2P_ID_ as unset (DistanceRequestUtils.ts:490-496), so the first guard at L190 already passes — L195 is the only thing stopping the fix.

To verify during implementation: when the rate flips from the P2P placeholder to the workspace default, confirm the displayed amount recomputes to the new rate (the report-move path in Transaction.ts recomputes amount/merchant explicitly — check the amount effect at DistanceRequestController.tsx:146-159 covers this case rather than sticking at the old P2P amount). Also worth checking the "Submit to a friend" (P2P, non-workspace) variant separately, since that error comes from a different branch.

---

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

---

view run