[$250] Continuous reconciliation setting not carried over to New Expensify and company card list fails to load

[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: 9.3.38-4
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: @PedroEspinoza1999
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Enable continuous reconciliation in Classic Expensify.
2. Navigate to the workspace in New Expensify.
3. Go to Workspace Settings → Accounting.
4. Check for reconciliation-related settings.
5. Navigate to Workspace Settings → Company Cards / Expensify Cards.
6. Observe that:
   The reconciliation setting is not visible.
   The company card list does not load properly.

Expected Result:

The continuous reconciliation setting enabled in Classic should:
Carry over to New Expensify.
Be visible and configurable in workspace settings.
The company card list should load successfully and display all cards and assignments.

Actual Result:

The continuous reconciliation setting is not visible anywhere in New Expensify.
There is no way to confirm or manage the feature from the New UI.
The company card list fails to load, limiting visibility into card assignments and usage.

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 screenshots for the issue are in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @apeyada

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022034685587939729277
• Upwork Job ID: 2034685587939729277
• Last Price Increase: 2026-04-30
• Automatic offers:
• apeyada | Contributor | 111320033

[MelvinBot]

Proposal

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

When a user enables continuous reconciliation in Classic Expensify and then navigates to the same workspace in New Expensify, two things fail: (1) the reconciliation setting is not visible anywhere in Workspace Settings > Accounting, and (2) the company card list does not load under Workspace Settings > Company Cards / Expensify Cards.

What is the root cause of that problem?

There are two related root causes -- one for each symptom:

Symptom 1 -- Reconciliation setting not visible:

The "Card Reconciliation" menu item on the Accounting page is gated by isExpensifyCardFullySetUp() at src/pages/workspace/accounting/PolicyAccountingPage.tsx:139:

const shouldShowCardReconciliationOption = Object.values(allCardSettings ?? {})?.some(
    (cardSetting) => isExpensifyCardFullySetUp(policy, cardSetting)
);

This calls src/libs/CardUtils.ts:1105-1107:

function isExpensifyCardFullySetUp(policy, cardSettings) {
    return !!(policy?.areExpensifyCardsEnabled && getCardSettings(cardSettings)?.paymentBankAccountID);
}

Both policy.areExpensifyCardsEnabled and a paymentBankAccountID in the card settings are required. Additionally, card settings are only fetched when areExpensifyCardsEnabled is true (PolicyAccountingPage.tsx:219):

if (!policyID || !policy?.areExpensifyCardsEnabled || !workspaceAccountID) { return; }
openPolicyExpensifyCardsPage(policyID, workspaceAccountID);

For workspaces that had continuous reconciliation enabled in Classic but don't have areExpensifyCardsEnabled set in New Expensify, the card settings are never fetched, isExpensifyCardFullySetUp returns false, and the Card Reconciliation option is permanently hidden.

Symptom 2 -- Company card list fails to load:

The company cards page requires a valid workspaceAccountID to make its API call. At src/pages/workspace/companyCards/WorkspaceCompanyCardsPage.tsx:56-59, if domainOrWorkspaceAccountID === 0, the API call is skipped entirely:

if (domainOrWorkspaceAccountID === CONST.DEFAULT_NUMBER_ID) { return; }

The table then synthesizes a WORKSPACE_FEEDS_LOAD_ERROR at WorkspaceCompanyCardsTable/index.tsx:97-101. Additionally, feed filtering in useCardFeeds.tsx:31-33 requires feeds to have preferredPolicy === policyID or domainID === workspaceAccountID -- feeds that don't match are excluded, potentially resulting in an empty card list.

Both symptoms likely share a common underlying cause: the workspace policy data in New Expensify is not correctly reflecting the configuration that was set up in Classic Expensify (specifically areExpensifyCardsEnabled, workspaceAccountID, and/or card feed preferredPolicy/domainID mappings).

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

This needs investigation from the backend/platform side to understand why Classic Expensify configuration isn't properly reflected in the New Expensify policy data. The specific questions that need answering:

1. When continuous reconciliation is enabled in Classic, does the corresponding NE policy get areExpensifyCardsEnabled set to true? If not, the Card Reconciliation option will never appear.
2. What is the workspaceAccountID value for the affected policy? If it's 0, company cards will never load.
3. Do the card feeds have the correct preferredPolicy or domainID to match the NE workspace?

On the frontend side, a potential improvement would be to decouple the Card Reconciliation visibility from the Expensify Card setup state. Continuous reconciliation is conceptually an accounting integration feature, not strictly an Expensify Card feature -- if the backend reports that reconciliation is enabled, the UI should show it regardless of areExpensifyCardsEnabled. This could mean:

• Adding a separate check for continuous reconciliation data in PolicyAccountingPage that doesn't depend on isExpensifyCardFullySetUp
• Ensuring OpenPolicyAccountingPage returns reconciliation state independently of the Expensify Cards data path

For the company card list loading failure, we need the specific workspaceAccountID and feed configuration for the affected workspace to determine whether this is a data provisioning issue or a client-side filtering issue.

What alternative solutions did you explore? (Optional)

An alternative would be to ensure that Classic Expensify always sets areExpensifyCardsEnabled = true on the NE policy when continuous reconciliation is enabled. However, this couples Classic configuration changes to NE policy state in a way that could have unintended side effects. The cleaner approach is to make the NE UI independently aware of reconciliation state from the backend.

---

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

[melvin-bot]

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

[melvin-bot]

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

[twilight2294]

Proposal

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

When continuous reconciliation is enabled for a workspace, the Card Reconciliation toggle in New Expensify always shows OFF, even though the setting is active.

What is the root cause of that problem?

The backend's OpenPolicyAccountingPage response sets the expensifyCard_useContinuousReconciliation_{id} Onyx key to a raw boolean (true/false), but the frontend type CardContinuousReconciliation expects an object {value: boolean, pendingAction?: PendingAction}.

At runtime, continuousReconciliation = true (a primitive). Accessing .value on a primitive returns undefined, so the toggle evaluates !!undefined = false. The useEffect guard at CardReconciliationPage:127 (continuousReconciliation?.value !== undefined) also stays false, causing infinite refetches.

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

Add a useOnyx selector that normalizes both formats at read-time. This handles the raw boolean from the API and the object format already written by the optimistic update in toggleContinuousReconciliation (Card.ts:1471-1477).

Both consumers need the selector:

1. CardReconciliationPage.tsx:76
2. WorkspaceSettlementAccountPage.tsx:51

const continuousReconciliationSelector = (value: OnyxEntry<CardContinuousReconciliation> | boolean) => {
    if (typeof value === 'boolean') {
        return {value};
    }
    return value;
};

const [continuousReconciliation] = useOnyx(
    `${ONYXKEYS.COLLECTION.EXPENSIFY_CARD_USE_CONTINUOUS_RECONCILIATION}${effectiveDomainID}`,
    {selector: continuousReconciliationSelector},
);

Raw true → {value: true}. Object {value: true, pendingAction: 'update'} → passes through. null/undefined → passes through. All existing .value accesses keep working unchanged.

What alternative solutions did you explore? (Optional)

apeyada's proposal identifies the same type mismatch but suggests replacing all continuousReconciliation?.value with continuousReconciliation directly. That breaks the optimistic update path — toggleContinuousReconciliation in Card.ts already writes {value: boolean, pendingAction: ...} to Onyx. After a user toggles, the stored value is an object, so reading it as a bare boolean would show [object Object] as truthy regardless of actual state, and pendingAction feedback would be lost. A selector normalizes at the boundary without touching any downstream consumer logic.

twilight2294's proposal (recommended by MelvinBot's review) focuses on ?? vs || and feed filtering. The reproduction video from m-natarajan shows the Card Reconciliation page loads successfully — meaning feeds ARE found and effectiveDomainID IS valid. The only visible symptom is the toggle value being wrong, which those fixes don't address.

KJ21-ENG and aswin-s's proposals focus on useDefaultFundID and areExpensifyCardsEnabled gating. Again, the reproduction video shows the page is accessible — these aren't the blocking issue here.

[chengyixu]

Proposal

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

The continuous reconciliation setting from Classic Expensify is not visible in New Expensify's workspace settings, and the company card list fails to load for workspaces that have this setting enabled.

What is the root cause of that problem?

This is a settings migration/parity issue between Classic and New Expensify. Two separate bugs are likely occurring:

1. Missing UI for continuous reconciliation: The New Expensify workspace accounting settings UI does not include a toggle/display for the continuous reconciliation flag. The setting may exist in the backend data but the frontend component in src/pages/workspace/accounting/ does not render it.

2. Company card list fails to load: The company card fetching logic likely depends on some accounting settings being in an expected shape. When continuous reconciliation is enabled, the card data fetch may fail silently (unhandled promise rejection or an API error that isn't surfaced) because the reconciliation config is not fully migrated to the new data schema.

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

1. Add continuous reconciliation setting to New Expensify UI: In the workspace accounting settings page, add a row/toggle for continuous reconciliation using the same pattern as other accounting settings (e.g. auto-sync). Read the value from the workspace policy Onyx data.
2. Fix company card list loading: Audit the getWorkspaceCardsForDomain (or equivalent) action to handle the case where the policy has continuous reconciliation enabled. Add error handling for the card fetch so it surfaces a user-friendly error rather than silently failing.
3. Policy data migration: Ensure the continuous reconciliation flag is included in the policy data migration from Classic to New Expensify (check the relevant migration script or Onyx policy data shape).

What alternative solutions did you explore? Why are we not using them?

Directing users to Classic to manage this setting is not acceptable for parity. Both issues need to be fixed in New Expensify.

Upwork: https://www.upwork.com/jobs/~022034685587939729277

ETA: 3-4 days from assignment.

[chengyixu]

Proposal

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

When continuous reconciliation is enabled in Expensify Classic, the setting does not appear in New Expensify workspace settings, and the company card list fails to load on the same workspace.

What is the root cause of that problem?

There are likely two related issues:

1. Missing migration / field mapping for reconciliation flag: The New Expensify workspace settings page reads policy data from Onyx. If the autoReimbursement or reconciliation-related field (e.g., reconciliationEnabled, harvestingConfig) is not included in the policy data fetch or is keyed differently between Classic and New Dot APIs, the setting is simply absent from the New Dot store and therefore never rendered.

2. Company card list load failure: The card list component likely depends on the same workspace policy data fetch. If a missing or null field (the reconciliation config) causes the selector or loader to bail out early (e.g., a ??/|| short-circuit on effectiveDomainID or domainName), the card list never receives its data, resulting in a blank/loading state.

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

1. Identify the exact policy field that stores the reconciliation setting and confirm it is included in the New Dot GetPolicyData / OpenWorkspaceView command response.
2. If absent, add the field to the command's response schema and update the Onyx policy type definition accordingly.
3. Add a UI section in Workspace Settings → Accounting (or Cards) that reads and displays the reconciliation flag, with a toggle to enable/disable it.
4. Fix the card-list loader: replace any ?? / && chain that can return undefined for domainName or effectiveDomainID with a safe fallback so the list always attempts to load even when reconciliation config is absent.
5. Add a regression test: verify that a workspace with reconciliation enabled in Classic renders the correct setting value and a non-empty card list in New Dot.

What alternative solutions did you explore? Why did you reject them?

• Surfacing a 'Manage in Classic' redirect link: rejected because the feature should be fully manageable in New Expensify.
• Hiding the card list when reconciliation config is missing: rejected because it hides a separate, pre-existing data-loading bug.

[chengyixu]

Proposal

I'd like to work on this issue.

Approach: The continuous reconciliation setting from Classic Expensify isn't surfacing in the New Expensify workspace accounting settings, and the company card list fails to load. This is a settings migration gap — the reconciliation flag exists in the classic data model but the ND workspace settings page doesn't read or display it. I'll map the classic reconciliation setting to its equivalent in the ND data layer, add the appropriate UI control in the Accounting settings page, and fix the company card list load failure which is likely a dependent API call that errors when the reconciliation state is undefined.

Stack fit: TypeScript, React Native, Expensify codebase patterns.
Timeline: 2-3 days.
Available: Immediately.

Please assign.

[chengyixu]

Proposal

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

Continuous reconciliation settings are not being carried over when users migrate to New Expensify, and the company card list fails to load — leaving admins unable to reconcile card transactions in the new interface.

What is the root cause of that problem?

The reconciliation settings migration logic likely doesn't include the continuousReconciliation flag when copying workspace settings from OldDot to NewDot. Additionally, the company card list API call may be failing silently (possibly a missing auth token or endpoint mismatch) after migration, rendering the card management UI broken.

What changes do you need to make?

1. Settings migration: Audit the workspace migration code path to ensure continuousReconciliation and related card reconciliation fields are included in the migration payload. Add these fields to the CONST.MIGRATED_SETTINGS list (or equivalent) so they are transferred.

2. Company card list loading: Investigate the getCompanyCards API call after migration — check for missing parameters or stale auth state that prevents the list from populating. Add error handling and a retry mechanism for the card list fetch.

3. Testing: Reproduce in staging by migrating a workspace with continuous reconciliation enabled, verifying settings persist and card list loads post-migration.

My background: Full-stack TypeScript/React Native developer with 8 years experience. Familiar with Expensify's onyx-based state management, OldDot→NewDot migration patterns, and the workspace settings architecture.

Timeline: Will complete within 2-3 days.

Please assign.