Bank Reconciliation with "This month" filter does not display all current Expensify Card settlements

[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: 9.4.43-1
Reproducible in staging?: Needs reproduction (Reproduction blocked)
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: @abbagail
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Log in as a workspace admin.
2. Navigate to Spend > Accounting > Bank Reconciliation.
3. Set the Withdrawal Type filter to Expensify Card.
4. Set the date filter to This month.
5. Review the list of settlements.

Expected Result:

All current settlements for the selected month, including pending settlements, should be displayed in the reconciliation view.

Actual Result:

The most recent settlements are missing from the reconciliation results.
Users must switch to Classic Expensify to view the missing settlements.

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

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/~022081824464320976887
• Upwork Job ID: 2081824464320976887
• Last Price Increase: 2026-07-27

[MelvinBot]

Issue Analysis

Root Cause: This is a backend issue, not an App bug. Bank Reconciliation is a pure renderer of the backend Search command. When you pick Withdrawal Type = Expensify Card + date = "This month", App builds the query type:expense groupBy:withdrawal-id withdrawalType:expensify-card withdrawn:<this-month> and the backend does all grouping and date filtering. The withdrawn ("This month") filter is applied against the settlement completion date — the debitPosted field, documented in App as "When the withdrawal completed". A pending / not-yet-settled settlement has no completed debitPosted date, so it falls outside the "This month" window and the backend omits it — while Classic surfaces it because Classic keys off a different (scheduled/entry) date. That is exactly why the most recent settlements are missing in New and users must switch to Classic.

Where the fix belongs: The inclusion/exclusion decision is made entirely in the backend Search command (Auth / Web-Expensify), not in App. The App frontend cannot fix this — it only serializes the query and renders the withdrawal groups the backend returns. An internal engineer with backend access should adjust how the withdrawn date range treats pending settlements (e.g. match pending settlements on their scheduled/estimated settlement date rather than only on the completed debitPosted date, or include pending groups regardless of the completion window).

This also looks like the same root cause behind the recently closed/related reconciliation date issues below.

Related issues:

• [HOLD][$250] Expensify Card settlement visible in Classic not surfaced in New Reconciliation (group-by: withdrawal-id) #84417 (closed) — Expensify Card settlement visible in Classic not surfaced in New Reconciliation (group-by: withdrawal-id)
• [$250] Spend Filter > Last Statement date range doesn't follow the monthly settlement date for the Expensify card #95834 (closed) — "Last Statement" date range doesn't follow the monthly settlement date for the Expensify Card
• [$250] [CFI] Show cash back to Expensify Card reconciliation in NewDot #94133 (open) — possibly related reconciliation gap (cash back in NewDot)

Investigation details & evidence (confidence: High)

App is a pure renderer — no client-side filtering:

• src/libs/SearchUIUtils.ts:943-960 — the Bank Reconciliation tab's default query: type:expense, groupBy:withdrawal-id, withdrawalType:expensify-card, and a withdrawnOn date preset. The date facet is withdrawnOn (the settlement withdrawn field), not the expense/transaction date.
• src/types/onyx/SearchResults.ts:174-199 — the withdrawal-id group model. Its date is debitPosted = "When the withdrawal completed", and state (5/6/7 = failed, 8 = cleared, others = pending). Pending settlements have not completed → no debitPosted inside the window.
• src/components/Search/SearchList/ListItem/WithdrawalIDListItemHeader.tsx:92-97 — the row renders debitPosted/state straight from the backend; App does no date computation or filtering.
• src/libs/actions/Search.ts:1040-1062 — App serializes the query and calls the backend Search command, then renders the response snapshot. All grouping-by-withdrawal-id and withdrawn date filtering happen server-side.

Alternative explanations considered: A client-side filtering/rendering bug in App was ruled out — the reconciliation list contains only what the backend returns, with no App-side date filtering. The consistent pattern across #84417 and #95834 (New excludes recent/pending settlements that Classic shows) points to the backend settlement-date selection, not a per-view App bug.

To fully confirm the exact backend date column and pending-exclusion logic, an internal engineer should capture a production reconciliation Search request (jsonQuery with groupBy:withdrawal-id, withdrawalType:expensify-card, withdrawn:<this-month>) and inspect whether pending groups (state not in {5,6,7,8}) are dropped because debitPosted is null/outside the window.

---

Next Steps: This requires a backend fix (Auth / Web-Expensify) and can't be implemented from the App repo — please escalate to an internal engineer with backend access. Reply with @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[j3ffffff]

Proposal

What is the root cause of that problem?

The Bank Reconciliation view (Search groupBy:withdrawalID) uses the withdrawn date filter to scope which settlement groups are displayed. The withdrawn field maps to debitPosted — the date the bank debit was actually posted — as defined in src/libs/SearchUIUtils.ts (line 366–367) and src/types/onyx/SearchResults.ts (line 195).

When a user selects "This month," the query becomes withdrawn:this-month, which the backend resolves to a strict date window (e.g., debitPosted >= 2026-07-01 AND debitPosted <= 2026-07-31). Pending settlements — those where the debit has been initiated but not yet posted to the bank account — have no debitPosted value. Because they carry an empty/null debitPosted, they fail the date comparison and are completely excluded from results. The user sees only cleared/failed settlements from the current month, while all recent pending ones are invisible.

Classic Expensify's reconciliation view uses the settlement initiation date (not the posting date) for date scoping, which is why pending settlements appear there.

Key code locations:

• src/libs/SearchUIUtils.ts:366–368 — GROUP_WITHDRAWN / WITHDRAWN columns both map to debitPosted
• src/libs/SearchUIUtils.ts:952 — default reconciliation query uses withdrawnOn: CONST.SEARCH.DATE_PRESETS.LAST_MONTH
• src/libs/SearchQueryUtils.ts:1251–1254 — THIS_MONTH preset resolves to startOfMonth(now) → endOfMonth(now)
• src/types/onyx/SearchResults.ts:195 — debitPosted: string (empty for pending settlements)

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

The reconciliation view should include pending settlements whenever a date-based withdrawn filter is active. Since search syntax does not support OR across different filter types, the best approach is a backend change: when processing a groupBy:withdrawalID query with a withdrawn date filter, the backend should also return settlement groups whose state is pending (state ≠ 5/6/7/8) and whose transactions fall within the requested date range — effectively falling back to the settlement's creation/initiation timestamp when debitPosted is absent.

On the frontend side, no query-string change is strictly required once the backend handles this correctly. However, to be extra explicit, the reconciliation search query could append withdrawal-status:pending,cleared,failed to ensure pending settlements are always in scope, and rely on the backend to combine this with the date filter as an OR for the pending bucket.

What alternative solutions did you explore? (Optional)

• Changing the filter from withdrawn to date (transaction date): This would include pending settlements' transactions by their expense date, but the reconciliation view groups by settlement, not by transaction. Filtering by transaction date in this grouped context would change the semantics entirely.
• Adding withdrawal-status:pending as an additional OR filter: Search syntax doesn't support OR across different filter types, so this can't be expressed purely in the query string without backend support.
• Removing the date filter for pending settlements client-side and merging results: This would require two separate API calls and then client-side merging, which is more complex and inconsistent with the existing query model.

[suneox]

I'll take a look at this one tomorrow

[suneox]

I'm still setting up the data to verify the issue.