[$250] Per Diem expense does not appear in Expenses or Reports after creation in New Expensify

[m-natarajan]

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: v9.3.88-2
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: @jean-santos85
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Click Scan.
2. Select Per Diem.
3. Select Destination = Canada.
4. Set the trip period from May 12, 2026 at 12:00 AM to May 16, 2026 at 12:00 AM.
5. Select Subrate = Half day.
6. Set Quantity = 5.
7. Confirmed the details and clicked Create expense.
8. Search for the resulting expense under Expenses and Reports.

Expected Result:

A Per Diem expense should be created and appear either as an unreported expense or within the selected report.

Actual Result:

No corresponding Per Diem expense or report can be found after creation.

Additional Notes:

• Per Diem is enabled in the Minimal Canada workspace.
• Per Diem rates are imported successfully.
• Searched Expenses and Reports for both users and could not find a matching Per Diem expense.
• Verified that unreported expenses are visible and filters are working as expected.

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

The video for the issue is in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022060389461294442174
• Upwork Job ID: 2060389461294442174
• Last Price Increase: 2026-06-12

Issue Owner

Current Issue Owner: @shubham1206agra

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Create expense" action in the Per Diem flow hits a silent early return in submitPerDiemExpense — no API call is fired, no error toast is shown, so nothing ever lands in Expenses or Reports.

The guard returns early if any of these are missing on the draft transaction: policyParams.policy, customUnit, customUnit.customUnitID, customUnit.customUnitRateID, subRates, or customUnit.attributes.

Looking at how the destination step writes those fields — IOURequestStepDestination.tsx:130-148 — setCustomUnitID(...) is only called inside the openedFromStartPage branch (line 142). setCustomUnitRateID, setMoneyRequestCurrency, and clearSubrates run regardless. So for an entry path where openedFromStartPage is false, the draft transaction is left with customUnitRateID set but customUnitID undefined, and on submit the guard at PerDiem.ts:911 silently bails out.

A second plausible contributing factor — sibling issue #91447 — is an Onyx policy-sync problem with imported foreign rates: when the Canada destinations/customUnits aren't fully synced onto the policy at submit time, getPerDiemRateCustomUnitRate returns undefined, the API parameters at PerDiem.ts:962-971 ship {"id":undefined,"name":undefined}, and the backend rejects the write — leaving the optimistic report to be rolled back.

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

1. Surface the failure instead of swallowing it. Replace the bare return at PerDiem.ts:908-917 with a Log.alert(...) (or an error toast via ErrorUtils) that identifies which field was empty. Today the user gets no feedback at all, which is what makes this so confusing to report.

2. Always stamp customUnitID when a destination is selected. Hoist the setCustomUnitID(transactionID, customUnit.customUnitID) call out of the openedFromStartPage branch in IOURequestStepDestination.tsx:131-144 so it runs for every entry path. customUnitID is required by the submit guard and by the CREATE_PER_DIEM_REQUEST backend call, so it should not depend on which page the flow was opened from.

3. Validate customUnitRate resolution before firing the API call. In submitPerDiemExpense, if getPerDiemRateCustomUnitRate(...) returns undefined, log it and show an error to the user instead of sending {"id":undefined,"name":undefined} to the backend. This is the same Onyx-sync hazard tracked in [$250] Per Diem Option Missing in ND Despite Being Enabled in Workspace (Migration Sync Issue) #91447.

What alternative solutions did you explore? (Optional)

• Defer-on-undefined-rate: pause the write until policy customUnits finish syncing. More complex than option 3 and not obviously safer.
• Backend-only fix: have the server tolerate missing customUnitPolicyID/customUnitRate for imported foreign rates. Doesn't fix the client-side silent failure, which is the symptom users actually see.

Investigation details

Symptom mapping:

• "Tapped Create expense, nothing happens" → silent return at PerDiem.ts:908-917, no toast, no API write.
• "No expense in Expenses or Reports" → optimistic onyx data is never built because the early return happens before getPerDiemExpenseInformation at PerDiem.ts:937.
• "Per Diem enabled in workspace, rates imported" → matches the customUnitRateID set but customUnitID not stamped scenario, since rate selection happens unconditionally (line 145) but customUnit ID stamping is gated.

Repro specifics that fit:

• Foreign destination (Canada/CAD) + a freshly-imported workspace ("Minimal Canada") → both the missing-customUnitID path and the Onyx-sync path from [$250] Per Diem Option Missing in ND Despite Being Enabled in Workspace (Migration Sync Issue) #91447 are triggered most easily here.
• Web (Windows/Mac Chrome) → no platform-specific code in this path; bug should reproduce on any platform.

Related open issues:

• [$250] Per Diem Option Missing in ND Despite Being Enabled in Workspace (Migration Sync Issue) #91447 — Per Diem Option Missing in ND Despite Being Enabled in Workspace (Migration Sync Issue) — same workspace-sync hazard, likely shares contributing factor Fix spaces #2.
• [Due for payment 2026-06-09] [$250] Per diem - Date and time field are empty, unable to select time #90663 — Per diem - Date and time field are empty, unable to select time — another draft-transaction completeness issue on the per diem path.

What would confirm this:

• Console logs from a repro session showing the early return (today there is none — adding a log is part of the fix).
• A repro with transaction.comment.customUnit dumped at submit time, showing customUnitID === undefined while customUnitRateID is set.
• Backend-side trace of whether CreatePerDiemRequest actually arrived for this user's attempt; if no record exists, that confirms the client-side guard fired.

Confidence: Medium. Code path is identified with high confidence; the exact entry-path that produces openedFromStartPage === false for this user's repro (and whether option 2 alone fixes it vs. needing options 1+3 too) is what I'd verify with a runtime repro.

---

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

[melvin-bot]

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

[melvin-bot]

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

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-29 16:09:10 UTC.

Proposal

What is the root cause of that problem?

When creating a Per Diem expense from the global create flow with an explicitly selected workspace, getInitialPerDiemTargetReport decides whether the expense lands on the selected workspace's policy expense chat or gets silently redirected into the user's self-DM (as UNREPORTED). The decision is driven by the wrong policy: it reads autoReporting only from defaultExpensePolicy (the user's active / single group policy returned by useDefaultExpensePolicy) and personalPolicy — it never looks at the workspace the user just picked.

The result for a user with multiple workspaces (the reporter has Per Diem enabled specifically on "Minimal Canada"):

1. User taps "Per Diem" from global create → picks the Minimal Canada workspace in IOURequestStepPerDiemWorkspace. That workspace has Per Diem rates and auto-reporting set up.
2. getInitialPerDiemTargetReport evaluates !!defaultExpensePolicy?.autoReporting || !!personalPolicy?.autoReporting — using the active policy, not Minimal Canada. If the active/personal policy doesn't have autoReporting, shouldAutoReport is false.
3. targetReport gets overwritten to selfDMReport, transactionReportID becomes UNREPORTED_REPORT_ID, and targetIouType is forced to CONST.IOU.TYPE.TRACK.
4. From this point on the route runs as a track expense (useExpenseSubmission calls submitPerDiemExpenseForSelfDM instead of submitPerDiemExpense), so the transaction is attached to the user's self-DM and never gets associated with the Minimal Canada workspace report — that's why nothing matching the workspace shows up in Expenses / Reports.

The same wrong-policy check is repeated at the destination step (IOURequestStepDestination.tsx#L132-L139) when the user re-picks a destination from the start page, so a second pass through the flow doesn't recover the workspace either.

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

Pass the workspace the user actually selected into getInitialPerDiemTargetReport, and prefer its autoReporting setting over the default/personal fallback. The selected policy is already in scope at both call sites — we just aren't threading it through.

 function getInitialPerDiemTargetReport(
     report: OnyxEntry<Report>,
     selfDMReport: OnyxEntry<Report>,
     iouType: IOUType,
+    selectedPolicy: OnyxEntry<Pick<Policy, 'autoReporting'>>,
     defaultExpensePolicy: OnyxEntry<Pick<Policy, 'autoReporting'>>,
     personalPolicy: OnyxEntry<Pick<Policy, 'autoReporting'>>,
     isFromGlobalCreate: boolean,
 ): {targetReport: OnyxEntry<Report>; targetIouType: IOUType; transactionReportID: string | undefined} {
     let targetReport = report;
     let targetIouType = iouType;

     if (isFromGlobalCreate) {
-        const shouldAutoReport = !!defaultExpensePolicy?.autoReporting || !!personalPolicy?.autoReporting;
+        // Prefer the workspace the user explicitly picked; only fall back to default/personal when none is known.
+        const shouldAutoReport = selectedPolicy
+            ? !!selectedPolicy.autoReporting
+            : !!defaultExpensePolicy?.autoReporting || !!personalPolicy?.autoReporting;
         if (!shouldAutoReport) {
             targetReport = selfDMReport;
         }
     }

And at the call site in IOURequestStepPerDiemWorkspace, pass the policy argument that onSelectWorkspace already receives:

 onSelectWorkspace={(policy) => {
     const {targetReport, targetIouType, transactionReportID} = getInitialPerDiemTargetReport(
         getPolicyExpenseChat(accountID, policy?.id),
         selfDMReport,
         iouType,
+        policy,
         defaultExpensePolicy,
         personalPolicy,
         transaction?.isFromGlobalCreate ?? false,
     );

The same one-line addition applies to IOURequestStepDestination.tsx#L132-L139, where policy is already available from usePolicyForTransaction.

As a defense-in-depth follow-up, I'd also surface a user-visible error when submitPerDiemExpense / submitPerDiemExpenseForSelfDM hit their early-return guards (empty policy / customUnit / subRates / attributes) — today they silently swallow the submit with no toast and no red-brick-road, which is what makes this class of bug so hard for users to report ("nothing happened, I just can't find it").

What alternative solutions did you explore? (Optional)

1. Always honor the route's workspace and skip the redirect entirely — i.e. only redirect to self-DM when iouType === TRACK, and trust whatever the user picked otherwise. This is the cleanest behaviorally but it walks back the intentional behavior added in PR Create per-diem in selfDM if auto reporting is disabled #82230 ("Create per-diem in selfDM if auto reporting is disabled"), which exists so personal/individual users without auto-reporting don't end up with orphaned per-diem reports. Threading the selected policy in keeps that original protection for the no-workspace case while fixing the multi-workspace case.

2. Resolve defaultExpensePolicy lazily from the route's selected policyID instead of useDefaultExpensePolicy — works for IOURequestStepDestination (the route already carries the policyID), but doesn't work for IOURequestStepPerDiemWorkspace, because that step is the workspace picker and the policy is only known inside onSelectWorkspace. Passing selectedPolicy explicitly covers both call sites uniformly.

3. Add a confirmation prompt before silently redirecting to self-DM — would address the "no expense appears" complaint by making the redirect visible, but doesn't fix the underlying wrong-policy logic; the user still ends up in self-DM unexpectedly. Better treated as a UX follow-up after the root fix.

[ReaperOAK]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @ReaperOAK Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[15antonian]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @15antonian Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.