[Due for payment 2026-05-12] [$250] Tax columns shown when split expense

[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.66-0
Reproducible in staging?: Y
Reproducible in production?: Y
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: @situchan
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Create an expense
2. Split expense
3. Observe that Tax rate and Tax columns briefly appear and disappear
4. Go offline
5. Delete one split
6. Observe that Tax rate and Tax columns appears again
7. Observe Total column of remaining expense
8. Go online
9. Tax rate and Tax columns disappear

Expected Result:

Tax columns should not be shown in any case.

Actual Result:

Tax columns are shown offline and hidden after online

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

staging.mov

Recording.2807.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @QichenZhu

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022051296368466904263
• Upwork Job ID: 2051296368466904263
• Last Price Increase: 2026-05-04

[MelvinBot]

Proposal

What is the root cause of that problem?

The tax column visibility in SearchUIUtils.ts:5325-5329 is determined purely by whether any transaction has tax data (taxCode, taxAmount, or taxValue), without checking whether the workspace policy actually has tax tracking enabled.

Two things combine to trigger the bug:

1. Brief flash on split: When splitting an expense, optimistic child transactions unconditionally copy tax fields from the parent at Split.ts:1443-1445. This makes hasTaxInfo true in getColumnsToShow, so tax columns appear until the server response cleans them up.

2. Reappears on offline delete: The transaction filter at MoneyRequestReportActionsList.tsx:112 keeps pending-delete transactions visible while offline (isOffline || transaction.pendingAction !== 'delete'). The deleted transaction still carries its tax fields, so getColumnsToShow at MoneyRequestReportTransactionList.tsx:304-307 sees tax data and re-enables the columns.

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

In getColumnsToShow in SearchUIUtils.ts, skip transactions that have pendingAction === 'delete' when computing which columns to show. Pending-delete transactions are visually struck through and should not influence column visibility. This fixes the offline delete scenario (symptom 2) and is consistent with how the online path already filters them out.

For the brief flash on split (symptom 1), stop copying tax fields to optimistic child transactions in Split.ts when the policy doesn't have tax tracking enabled — check policy.tax.trackingEnabled before setting taxCode/taxAmount/taxValue on the optimistic split children.

What alternative solutions did you explore? (Optional)

An alternative would be to pass the policy into getColumnsToShow and add a isTaxTrackingEnabled check (the function already exists in PolicyUtils.ts). This would be a more comprehensive fix but has a larger surface area since getColumnsToShow is also used by the search page, which would require threading policy data through additional callsites. The proposed fix is more surgical and addresses the two specific symptoms.

---

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.

[aswin-s]

Proposal

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

When a user creates a split expense on a workspace without tax tracking enabled (or any split expense), tax columns (TAX_RATE and TAX_AMOUNT) briefly appear and then disappear after the transaction syncs with the server. When the user goes offline and deletes one split, the tax columns reappear. This flicker is confusing and suggests incorrect data is being displayed client-side before the server corrects it.

What is the root cause of that problem?

The bug originates in src/libs/SearchUIUtils.ts in the getColumnsToShow function at lines 5323–5329. The buildOptimisticTransaction() function in src/libs/TransactionUtils/index.ts (line 423) defaults taxAmount to 0 when no taxAmount is provided in the transaction parameters. During the split expense flow—initiated by initSplitExpenseItemData—buildOptimisticTransaction is called without setting taxAmount, so every optimistic split draft transaction has taxAmount=0.

In getColumnsToShow's column-update closure, the hasTaxInfo predicate checks transaction.taxAmount != null, which evaluates to true for the value 0, causing TAX_RATE and TAX_AMOUNT columns to appear for split expenses that have no actual tax data. When the split is saved and the server responds with taxAmount=null for non-tax transactions, hasTaxInfo becomes false and the columns disappear, producing the observed flicker.

App/src/libs/SearchUIUtils.ts

Lines 5323 to 5329 in e097189

	// If the transaction has any tax info (code, value, or amount),
	// show both TAX_RATE and TAX_AMOUNT columns. Zero is valid tax data.
	const hasTaxInfo = !!transaction.taxCode || transaction.taxAmount != null || (transaction.taxValue !== undefined && transaction.taxValue !== '');
	if (hasTaxInfo) {
	columns[CONST.SEARCH.TABLE_COLUMNS.TAX_RATE] = true;
	columns[CONST.SEARCH.TABLE_COLUMNS.TAX_AMOUNT] = true;
	}

App/src/libs/TransactionUtils/index.ts

Line 423 in e097189

taxAmount = 0,

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

1. File: src/libs/SearchUIUtils.ts **Function:** getColumnsToShow **Change:** Modify thehasTaxInfopredicate at line 5325 to excludetaxAmount=0, which is the buildOptimisticTransactiondefault for unset taxes. Replace the conditiontransaction.taxAmount != nullwith(transaction.taxAmount != null && transaction.taxAmount !== 0). A legitimate zero-amount tax always has a non-empty taxCode` (caught by the first OR arm), so this guard change correctly excludes the optimistic split expense default without suppressing real zero-tax rows.

   Exact edit:

   const hasTaxInfo = !!transaction.taxCode || (transaction.taxAmount != null && transaction.taxAmount !== 0) || (transaction.taxValue !== undefined && transaction.taxValue !== '');
   

Blast radius: Isolated to getColumnsToShow—it is called only once by MoneyRequestReportTransactionList. No shared helper is modified, and the change only tightens the column visibility predicate.

What alternative solutions did you explore?

• Location: src/libs/TransactionUtils/index.ts:buildOptimisticTransaction
  Rejection reason: Changing the taxAmount = 0 default to undefined would alter the type contract (from number to number | undefined) for all callers across the codebase, with unknown downstream effects on serialization, math operations, and Onyx storage. This approach is too broad and would require auditing every call site.

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

⚠️ @MobileMage 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]

Proposal

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

On a workspace where tax tracking is not enabled, splitting an expense and then deleting one of the splits while offline causes the Tax rate and Tax columns to appear in the report's transaction list. They also flicker into view briefly when the splits are first created online, then disappear once the server's response arrives. Tax columns should never be shown for these transactions.

What is the root cause of that problem?

The column-visibility helper that decides whether to render the Tax rate / Tax amount columns treats a taxAmount value of 0 as a real signal that the transaction has tax info, even when the transaction has no taxCode. The check is in getColumnsToShow:

App/src/libs/SearchUIUtils.ts

Lines 5325 to 5329 in e097189

	const hasTaxInfo = !!transaction.taxCode || transaction.taxAmount != null || (transaction.taxValue !== undefined && transaction.taxValue !== '');
	if (hasTaxInfo) {
	columns[CONST.SEARCH.TABLE_COLUMNS.TAX_RATE] = true;
	columns[CONST.SEARCH.TABLE_COLUMNS.TAX_AMOUNT] = true;
	}

The transaction.taxAmount != null clause returns true for 0 (because 0 != null). Every optimistic transaction built in the app gets taxAmount = 0 by default, courtesy of the destructuring default in buildOptimisticTransaction:

App/src/libs/TransactionUtils/index.ts

Lines 422 to 424 in e097189

	taxCode = '',
	taxAmount = 0,
	taxValue,

So the moment a split's optimistic Onyx record lands locally, hasTaxInfo evaluates to true even though no tax was applied, and the Tax rate / Tax amount columns get added to the transaction list. The server response writes the splits back without those tax fields populated, which is why the columns then disappear once online; going offline and deleting one split rebuilds optimistic state that re-introduces the default taxAmount: 0, and the columns re-appear until the next online roundtrip cleans them up.

This is a recent regression. The previous logic at the same call site checked if (transaction.taxAmount) (truthy), which correctly excluded 0. It was rewritten to transaction.taxAmount != null as part of consolidating the two separate if (taxCode) / if (taxAmount) checks into a single hasTaxInfo boolean. The intent of that consolidation — show both Tax columns whenever any tax signal exists — is fine; the bug is purely that != null admits the default-init zero where the prior truthy check did not.

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

In getColumnsToShow inside src/libs/SearchUIUtils.ts, change the taxAmount clause of the hasTaxInfo predicate from a non-null check to a truthy check, matching the pre-regression behavior. After the change, a transaction with taxAmount: 0 and no taxCode no longer satisfies hasTaxInfo, so the Tax rate and Tax amount columns are not added on its behalf. A transaction with a real taxCode, or with a non-zero taxAmount, or with a non-empty taxValue, still satisfies hasTaxInfo and both columns are still shown together.

This is a one-token fix in the predicate at the line linked above (replace the != null test with a truthy test on taxAmount). It keeps the consolidated behavior the recent commit introduced and only filters out the false positive caused by the default taxAmount = 0 of optimistic transactions.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/89497-fix-tax-columns-zero-amount?expand=1

What alternative solutions did you explore? (Optional)

• Drop the taxAmount clause entirely and rely solely on taxCode as the tax signal. This would also fix the bug because the taxCode field is what actually carries the rate identifier when a tax has been applied. I rejected it because it changes behavior for any caller that sets only taxAmount without taxCode — the truthy fix is strictly narrower and stays equivalent to the pre-regression contract.
• Change buildOptimisticTransaction so the default for taxAmount is undefined instead of 0. This would prevent the false signal at the source, but the field is widely consumed downstream as a number and the surrounding type/serialization layer assumes it is numeric, so the blast radius is much larger than necessary for a column-visibility regression. The column-visibility helper is the right boundary to filter "default-init zero" from "real tax".
• Plumb the workspace's tax-enabled flag (isPolicyTaxEnabled) into getColumnsToShow and gate tax columns on it. This would fix the symptom but getColumnsToShow is policy-agnostic by contract today (it accepts a policy? in its type signature but never destructures it), so threading the flag through every call site is a wider refactor than this regression warrants.

[wildan-m]

Proposal updated — added compare branch with implementation.

[situchan]

This is recent regression.
@MelvinBot which PR caused this? Should be in this deploy checklist