[Due for payment 2026-05-07] [$250] Expense - Tax field is missing when bulk editing unreported expenses

[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.3.60-17
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #84756
Email or phone of affected tester (no customers): sdsodijnosdjoij@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Enable Taxes in workspace settings.

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create two expenses.
4. Go to Reports > Expenses.
5. Bulk select both expenses from Step 3.
6. Click dropdown button > Edit multiple.

Expected Result:

Tax field should be present when bulk editing unreported expenses.

Actual Result:

Tax field is missing when bulk editing unreported expenses.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7133103_1776530771147.2.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @Krishna2323

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022045563226589520073
• Upwork Job ID: 2045563226589520073
• Last Price Increase: 2026-04-18

[MelvinBot]

Proposal

What is the root cause of that problem?

The isTaxTrackingEnabled check in SearchEditMultiplePage.tsx:104 iterates over each selected transaction's transactionPolicy to verify tax.trackingEnabled:

const isTaxTrackingEnabled = !hasPerDiemOrTimeTransaction && selectedTransactionContexts.every(({transactionPolicy}) => !!transactionPolicy?.tax?.trackingEnabled);

For unreported expenses (reportID === '0'), getTransactionEditContext resolves transactionPolicy by looking up the report via transaction.reportID, then the policy via report.policyID. Since reportID is '0', no real report exists, so report is undefined, transactionPolicy is undefined, and !!undefined?.tax?.trackingEnabled evaluates to false. Because .every() is used, even one unreported expense causes the entire Tax field to be hidden.

Other fields like Categories and Tags avoid this problem because they use the fallback policy variable (resolved via getSearchBulkEditPolicyID which falls back to activePolicyID), not the per-transaction transactionPolicy.

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

In the isTaxTrackingEnabled computation at SearchEditMultiplePage.tsx:104, add an unreported-expense fallback inside the .every() callback: when a transaction has no reportID or has reportID === CONST.REPORT.UNREPORTED_REPORT_ID, fall back to checking policy?.tax?.trackingEnabled (the same fallback policy used by categories/tags) instead of the per-transaction transactionPolicy.

This mirrors the existing pattern on lines 106-108 where areSelectedTransactionsExpenses already handles the unreported case with an early return.

What alternative solutions did you explore? (Optional)

An alternative would be to fix getTransactionEditContext in SearchEditMultipleUtils.ts to resolve transactionPolicy via activePolicyID when reportID is '0'. However, this would change behavior for all consumers of that function and could have unintended side effects. The targeted fix in isTaxTrackingEnabled is safer and consistent with how other field checks handle unreported expenses.

Related issues

• Expensify/App#86855 — Related bulk edit tax display issue (different symptom: wrong tax rate displayed after selection)

---

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.

[melvin-bot]

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

[melvin-bot]

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

[MobileMage]

Proposal

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

When bulk editing unreported expenses, the Tax field is absent from the edit form even when the workspace has tax tracking enabled.

What is the root cause of that problem?

The isTaxTrackingEnabled flag is computed by calling .every() over selectedTransactionContexts and checking transactionPolicy?.tax?.trackingEnabled for each entry. For unreported expenses, getTransactionEditContext resolves transactionPolicy as undefined because unreported transactions have no real reportID, so report is undefined, and policies?.[...undefined] returns undefined. When transactionPolicy is undefined, the optional-chain evaluates to false, causing .every() to return false and the Tax field to be omitted from the form.

App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

Line 104 in 03023c1

const isTaxTrackingEnabled = !hasPerDiemOrTimeTransaction && selectedTransactionContexts.every(({transactionPolicy}) => !!transactionPolicy?.tax?.trackingEnabled);

The same component already handles this pattern correctly in areSelectedTransactionsBillable (line 81–87): when a transaction is unreported it short-circuits with return true, relying on the workspace-level policy resolved via getSearchBulkEditPolicyID to decide feature availability. The tax check needs the same treatment.

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

For unreported expenses, fall back to checking the workspace-level policy (already available in scope) instead of the per-transaction transactionPolicy. This mirrors the existing pattern used by areSelectedTransactionsBillable and areSelectedTransactionsReimbursable.

App/src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

Line 104 in 03023c1

const isTaxTrackingEnabled = !hasPerDiemOrTimeTransaction && selectedTransactionContexts.every(({transactionPolicy}) => !!transactionPolicy?.tax?.trackingEnabled);

-    const isTaxTrackingEnabled = !hasPerDiemOrTimeTransaction && selectedTransactionContexts.every(({transactionPolicy}) => !!transactionPolicy?.tax?.trackingEnabled);
+    const isTaxTrackingEnabled =
+        !hasPerDiemOrTimeTransaction &&
+        selectedTransactionContexts.every(({transaction, transactionPolicy}) => {
+            // Unreported expenses have no resolved policy yet — fall back to the active workspace policy
+            if (!transaction.reportID || transaction.reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
+                return !!policy?.tax?.trackingEnabled;
+            }
+            return !!transactionPolicy?.tax?.trackingEnabled;
+        });

This ensures unreported expenses use the workspace policy's tax setting (the same policy object already resolved by getSearchBulkEditPolicyID) rather than defaulting to false, so the Tax field appears whenever the active workspace has tax tracking enabled.

What alternative solutions did you explore? (Optional)

N/A

[ReaperOAK]

Proposal

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

On the bulk-edit form for unreported expenses (Reports > Expenses → multi-select → Edit multiple), the Tax row is never rendered, even though tax tracking is enabled on the user's active workspace and the same form correctly shows Category and Tag.

What is the root cause of that problem?

The isTaxTrackingEnabled gate in src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx resolves the policy per transaction instead of from the workspace-level policy that the rest of the form (and the rendered Tax row itself) uses:

// L104
const isTaxTrackingEnabled =
    !hasPerDiemOrTimeTransaction &&
    selectedTransactionContexts.every(({transactionPolicy}) => !!transactionPolicy?.tax?.trackingEnabled);

The per-transaction transactionPolicy is built inside getTransactionEditContext (SearchEditMultipleUtils.ts:60) by chaining transaction.reportID → report.policyID → policies[…]:

const report = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${transaction.reportID}`];
…
const transactionPolicy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report?.policyID}`];

For unreported expenses transaction.reportID is '0' (CONST.REPORT.UNREPORTED_REPORT_ID), so report is undefined, report?.policyID is undefined, transactionPolicy is undefined, and !!undefined?.tax?.trackingEnabled collapses to false. Because the check is wrapped in .every(...), a single unreported expense in the selection is enough to permanently hide the Tax row.

This is also internally inconsistent with the rest of the same component:

• areCategoriesEnabled / areTagsEnabled (L109-110) read from the workspace-level policy resolved by getSearchBulkEditPolicyID(...) (L96).
• The Tax MenuItemWithTopDescription itself reads policy?.taxRates?.name (L257) from the same workspace-level policy.
• areSelectedTransactionsBillable, areSelectedTransactionsReimbursable, and areSelectedTransactionsExpenses (L80-95, L105-108) all explicitly short-circuit transaction.reportID === CONST.REPORT.UNREPORTED_REPORT_ID.

isTaxTrackingEnabled is the only feature-availability gate on this page that still iterates transactionPolicy and has no unreported short-circuit — that mismatch is the bug.

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

File: src/pages/Search/SearchEditMultiple/SearchEditMultiplePage.tsx

Replace L104 so the gate uses the workspace-level policy (already resolved on L94 via getSearchBulkEditPolicyID), exactly like areCategoriesEnabled / areTagsEnabled two lines below. policy is currently declared on L94 (after L104), so move the isTaxTrackingEnabled declaration to sit alongside areCategoriesEnabled / areTagsEnabled:

-    const isTaxTrackingEnabled = !hasPerDiemOrTimeTransaction && selectedTransactionContexts.every(({transactionPolicy}) => !!transactionPolicy?.tax?.trackingEnabled);
     const areSelectedTransactionsExpenses = selectedTransactionContexts.every(({transaction, report}) => {
         if (!transaction.reportID || transaction.reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
             return true;
         }
         return !isIOUReport(report);
     });
     const areCategoriesEnabled = areSelectedTransactionsExpenses && !!policy?.areCategoriesEnabled && hasEnabledOptions(policyCategories ?? {});
     const areTagsEnabled = !!policy?.areTagsEnabled && hasEnabledTags(policyTagLists);
+    const isTaxTrackingEnabled = !hasPerDiemOrTimeTransaction && !!policy?.tax?.trackingEnabled;

Why this is the right fix:

1. Single source of truth. getSearchBulkEditPolicyID is the canonical resolver for the bulk-edit context: same policy → that policy; mixed or unreported → fall back to activePolicyID. The Tax row already renders from this policy; the gate should evaluate against the same object.
2. Consistency. It makes Tax behave identically to Categories and Tags, removing a one-off .every(transactionPolicy) pattern that no other field uses.
3. Correctly handles every selection mix:
   • All unreported on active workspace → policy = activeWorkspace, gate honors workspace tax setting → Tax row appears (bug fixed).
   • All reported on the same workspace → policy = sharedPolicy, identical behavior to today.
   • Reported across mixed policies → getSearchBulkEditPolicyID falls back to activePolicyID; matches the existing Categories/Tags semantics on the same form.
4. Handles the per-diem/time guard unchanged — !hasPerDiemOrTimeTransaction is preserved.

No other call sites need to change; policy?.taxRates?.name on L257 already resolves from the same workspace-level policy, so the rendered description stays correct.

What alternative solutions did you explore? (Optional)

The naive patch (and the one already posted by MelvinBot / MobileMage) keeps the .every() loop and only adds a transaction.reportID === CONST.REPORT.UNREPORTED_REPORT_ID short-circuit that returns !!policy?.tax?.trackingEnabled for unreported rows while still checking transactionPolicy?.tax?.trackingEnabled for reported rows.

That works for the reported reproducer but is strictly worse than this proposal:

• It leaves a hidden divergence between the gate (per-transaction policy) and the render source (workspace-level policy.taxRates). It is possible to construct a state where the row is gated open while policy?.taxRates is empty, or gated shut while policy?.taxRates?.name is populated.
• It does not match the established pattern for areCategoriesEnabled/areTagsEnabled and reintroduces the same class of transactionPolicy === undefined regression any time report.policyID is briefly missing (stale Onyx, snapshot-only data after a hard refresh, etc.).
• The .every() loop becomes load-bearing for no functional gain — getSearchBulkEditPolicyID already encodes the "all same policy vs. fall back to active workspace" semantics, so iterating again is redundant work.

A second alternative — fixing getTransactionEditContext in SearchEditMultipleUtils.ts to fall back to activePolicyID when reportID === '0' — would change the transactionPolicy field for every consumer of that helper (including isFieldDisabledForAnyTransaction's canEditFieldOfMoneyRequest call on L66, which intentionally treats unreported expenses as "always editable" via an explicit short-circuit). Mutating that shared helper to suit one gate risks regressions across the entire bulk-edit page and is rejected for blast-radius reasons.

[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.

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @wildan-m 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.