Report - Tax Rate Filter Missing Until Expense with Tax is Viewed

[lanitochka17]

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.1.79-8
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: #65547
Email or phone of affected tester (no customers): applausetester+dp232@applause.expensifail.com
Issue reported by: Applause - Internal Team

Action Performed:

Prerequisites:
• User account has at least one expense that includes taxes.

1. Log in to staging.new.expensify.com.
2. Navigate to Account > Troubleshoot and click Clear cache and restart.
3. Go to the Reports page and open the Filters panel. Observe Tax Rate filter is missing.
4. Close the filter panel.
5. Open any expense that includes tax.
6. Return to Reports > Filters. Observe Tax Rate filter is there.

Expected Result:

Tax Rate filter should be visible from the start, as the account has at least one expense with tax

Actual Result:

Tax Rate filter is missing initially and only appears after opening an expense with tax

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
• MacOS: Desktop

Platforms Tested:

On which of our officially supported platforms was this issue tested:

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

Screenshots/Videos

Add any screenshot/video evidence

Bug6884018_1752178659123.1_16_PM_2025-07-10.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @johncschuster (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.

[MobileMage]

Proposal

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

The Tax Rate filter is missing from the Reports page filter panel when users first access it, even when their account has expenses that include taxes. The filter only appears after the user opens an expense that contains tax information. This creates an inconsistent user experience where available filters depend on navigation history rather than actual data availability.

What is the root cause of that problem?

The issue happens because tax policy data isn't automatically loaded when you visit the Reports page. The code that decides whether to show the Tax Rate filter checks if there are any tax rates available by looking at Object.keys(taxRates).length. The function that gathers these tax rates pulls from policy objects stored in Onyx, but these policies only contain the actual tax data after openPolicyTaxesPage() gets called. This API call normally happens when users visit workspace tax settings or when viewing expenses triggers policy data to load. Since the Reports page doesn't automatically fetch this tax information, the filter stays hidden even though users have tax-enabled policies and expenses with tax data.

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

We should add a useEffect hook in the AdvancedSearchFilters component that detects when taxes are enabled but the tax rate data is missing from policies, then automatically fetches the needed tax data. The implementation would import openPolicyTaxesPage from the Policy actions and add the effect after the existing feature detection logic. The hook would check if areTaxEnabled is true but taxRates is empty, then call openPolicyTaxesPage() for each policy that has taxes enabled but doesn't have loaded tax data yet. This follows the same pattern used by AccessOrNotFoundWrapper for loading missing policy data and makes sure the Tax Rate filter appears right away when users access the Reports page.

useEffect(() => {
        if (!areTaxEnabled || Object.keys(taxRates).length > 0) {
            return;
        }

        // Find policies with taxes enabled that don't have tax data loaded
        const policiesNeedingTaxData = Object.values(policies).filter(
            (policy) => policy && isPolicyFeatureEnabled(policy, CONST.POLICY.MORE_FEATURES.ARE_TAXES_ENABLED) && !policy.taxRates?.taxes
        );

        // Load tax data for these policies
        policiesNeedingTaxData.forEach((policy) => {
            if (!policy?.id) {
                return;
            }
            openPolicyTaxesPage(policy.id);
        });
    }, [areTaxEnabled, taxRates, policies]);

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

We should add tests that verify the Tax Rate filter shows up when accessing the Reports page with tax-enabled policies, even with cleared cache. The tests should cover scenarios where policies have taxes enabled but no tax data loaded, multiple policies with different tax configurations, and ensure the filter appears without requiring navigation to expenses or workspace settings first.

What alternative solutions did you explore? (Optional)

Global preloading would load all policy tax data during app initialization, but this would slow down startup times for users who never access Reports filters. Just-in-time loading would trigger data fetching when filters are rendered, but this creates complex loading states and makes filters appear progressively. Server-side metadata would modify APIs to include filter availability information, but requires significant backend changes. Enhanced caching would persist tax data across sessions, but doesn't solve the initial loading problem for new users or when cache gets cleared.

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[thelullabyy]

Looks like it is fixed by this PR

#65543

[melvin-bot]

@johncschuster Whoops! This issue is 2 days overdue. Let's get this updated quick!

[johncschuster]

Nice find, @thelullabyy! I'll close this up then.

[melvin-bot]

@johncschuster Whoops! This issue is 2 days overdue. Let's get this updated quick!