Expensify Card - Changing settlement frequency leads to not here tab

[jponikarchuk]

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.32-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #84285
Email or phone of affected tester (no customers): applausetester+bp0502fab@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: MacOS Monterey 12.7.4 / Chrome
App Component: Other

Action Performed:

Precondition: workspace with added expensify card and travel feture configured.

1. Open any workspace's Expensify Card page
2. Open card settings
3. Settlement frequency display correctly
4. Open Travel Invoicing page
5. Change Settlement frequency
6. Navigate back to Expensify Card page > open Settlement frequency
7. Change frequency

Expected Result:

User is back to Settings tab with new frequency opened

Actual Result:

Not here tab opens

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @allgandalf

[melvin-bot]

Triggered auto assignment to @JmillsExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MelvinBot]

Proposal

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

After changing the settlement frequency on the Travel Invoicing page, navigating back to the Expensify Card page and opening the Settlement Frequency setting shows the "Hmm... it's not here" blocking view instead of the frequency selection list.

What is the root cause of that problem?

Both Travel Invoicing and Expensify Card store their settlement frequency data (monthlySettlementDate) at the root level of the same Onyx key: private_expensifyCardSettings_{workspaceAccountID}.

• Travel Invoicing writes to this key via getTravelInvoicingCardSettingsKey(workspaceAccountID) in TravelInvoicingUtils.ts:139 (which even has a comment: "Uses the same key pattern as Expensify Card (no program suffix)").
• Expensify Card reads from the same key via useDefaultFundID(policyID) in WorkspaceSettlementFrequencyPage.tsx:29, which falls back to workspaceAccountID for workspaces without legacy domain card programs (useDefaultFundID.ts:48-49).

When Travel Invoicing changes settlement frequency to "Daily", it writes monthlySettlementDate: null to the root of the shared Onyx key (TravelInvoicing.ts:185). When the user then opens the Expensify Card settlement frequency page, it reads this corrupted value and computes:

selectedFrequency = settings?.monthlySettlementDate ? MONTHLY : DAILY  → DAILY (because monthlySettlementDate is null)
shouldShowMonthlyOption = settings?.isMonthlySettlementAllowed ?? false → false
isSettlementFrequencyBlocked = !shouldShowMonthlyOption && selectedFrequency === DAILY → true

This isSettlementFrequencyBlocked = true is passed as shouldBeBlocked to AccessOrNotFoundWrapper (WorkspaceSettlementFrequencyPage.tsx:65-69), which renders the "Hmm... it's not here" FullPageNotFoundView.

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

The Travel Invoicing updateTravelInvoiceSettlementFrequency action should write its monthlySettlementDate nested under the TRAVEL_US program key rather than at the root of the shared Onyx entry. The read side already handles this — WorkspaceTravelInvoicingSettlementFrequencyPage calls getCardSettings(cardSettings, CONST.TRAVEL.PROGRAM_TRAVEL_US) which looks for a TRAVEL_US nested object. But the write side in TravelInvoicing.ts writes to the root, which is what causes the conflict.

The fix should be in src/libs/actions/TravelInvoicing.ts in the updateTravelInvoiceSettlementFrequency function: nest the optimistic, success, and failure data under the TRAVEL_US key within the Onyx value, e.g.:

value: {
    [CONST.TRAVEL.PROGRAM_TRAVEL_US]: {
        monthlySettlementDate,
        previousMonthlySettlementDate: ...,
        pendingFields: { monthlySettlementDate: ... },
        errorFields: { monthlySettlementDate: ... },
    },
}

This separates Travel Invoicing's data from the Expensify Card's root-level data in the shared Onyx key.

What alternative solutions did you explore? (Optional)

1. Use a separate Onyx key for Travel Invoicing — rejected because both features intentionally share PRIVATE_EXPENSIFY_CARD_SETTINGS and the backend returns data under the same key.
2. Remove the shouldBeBlocked guard on the Card frequency page — rejected because the guard exists for a valid reason (preventing access when there's nothing to change).
3. Make useDefaultFundID always return a card-specific ID — this would only fix the symptom for workspaces with domain-level cards, not the underlying data collision.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.