[$250] Expense - Tax amount changes to zero after creating negative expense with non-zero tax rate

[jponikarchuk]

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.24-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-5896/folder/13176868/41237330/1203273528
Email or phone of affected tester (no customers): soidnjosdjojdnosnjdosjd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Taxes are enabled.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Click + > Create expense > Manual.
4. Enter negative amount > Next.
5. On confirm page, click Tax field and select 5% rate.
   → Tax amount is not zero when 5% rate is selected for negative amount.
6. Click Create expense.
7. Open the expense.

Expected Result:

Tax amount should be non-zero and same as confirm page in Step 5 when 5% rate is selected for negative amount.

Actual Result:

Tax amount changes to zero after creating negative expense with non-zero tax rate.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7083689_1771608312440.5.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @CortneyOfstad

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022024903783911413849
• Upwork Job ID: 2024903783911413849
• Last Price Increase: 2026-02-20

[melvin-bot]

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

[MelvinBot]

Proposal

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

When creating a negative expense (e.g., -$5.00) with a non-zero tax rate (e.g., 5%), the tax amount displays correctly on the confirmation page but becomes zero after the expense is created.

What is the root cause of that problem?

The root cause is in MoneyRequestConfirmationList.tsx at line 545, where the taxableAmount is set to the raw transaction?.amount without taking the absolute value:

const taxableAmount = isDistanceRequest ? DistanceRequestUtils.getTaxableAmount(policy, customUnitRateID, distance) : (transaction?.amount ?? 0);

For a negative expense (e.g., -$5.00), transaction.amount is -500 (in smallest currency units). This negative value is passed to calculateTaxAmount (TransactionUtils/index.ts:2025-2033), which preserves the sign, producing a negative tax amount (e.g., -0.24 for 5% tax). This negative tax gets stored on the draft transaction via setMoneyRequestTaxAmount at line 558.

The confirmation page appears to show the correct tax because the display function getTaxAmount (TransactionUtils/index.ts:937-941) applies Math.abs before displaying — this masks the underlying negative value.

When the user confirms, IOURequestStepConfirmation.tsx reads the raw negative taxAmount from the draft (line 274) and passes it directly to requestMoney, which sends the negative value to the backend API (IOU/index.ts:6756). The backend likely interprets the negative tax amount as zero or invalid.

Notably, the tax rate page (IOURequestStepTaxRatePage.tsx:82) handles this correctly by using getAmount(currentTransaction, false, true) which returns a positive value, but the MoneyRequestConfirmationList useEffect then overwrites this correct value with its own negative calculation when the confirmation page renders.

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

In src/components/MoneyRequestConfirmationList.tsx at line 545, wrap the non-distance taxable amount in Math.abs:

// Current (buggy):
const taxableAmount = isDistanceRequest ? DistanceRequestUtils.getTaxableAmount(policy, customUnitRateID, distance) : (transaction?.amount ?? 0);

// Fixed:
const taxableAmount = isDistanceRequest ? DistanceRequestUtils.getTaxableAmount(policy, customUnitRateID, distance) : Math.abs(transaction?.amount ?? 0);

This ensures calculateTaxAmount always receives a positive amount, producing a positive tax value that correctly flows through the rest of the creation pipeline.

What alternative solutions did you explore? (Optional)

1. Fix at IOURequestStepConfirmation.tsx:274 — Apply Math.abs when reading transactionTaxAmount. This would work but is a downstream band-aid; it's better to fix the calculation at the source so the draft always stores the correct positive tax value.

2. Fix inside calculateTaxAmount — Make it always return Math.abs of its result. This would work but changes the function's general contract; the current sign-preserving behavior may be intentional for other callers.

3. Fix at IOU/index.ts:3522 — Apply Math.abs in getMoneyRequestInformation when building the optimistic transaction. This would partially work (for expense reports, the double-negation already accidentally produces the correct value), but wouldn't fix the underlying incorrect draft value.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[annaweber830]

Proposal

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

When creating a manual expense with a negative amount and selecting a non-zero tax rate, the confirmation screen shows a non-zero tax, but the created expense later shows tax as zero. The tax value is being recalculated on confirmation using a different amount-sign convention than the tax-rate step, which causes inconsistent persisted tax data for negative expenses.

What is the root cause of that problem?

App/src/components/MoneyRequestConfirmationList.tsx

Lines 545 to 558 in a8f2d3a

	const taxableAmount = isDistanceRequest ? DistanceRequestUtils.getTaxableAmount(policy, customUnitRateID, distance) : (transaction?.amount ?? 0);
	// First we'll try to get the tax value from the chosen policy and if not found, we'll try to get it from the policy for moving expenses (only if the transaction is moving from track expense)
	const taxPercentage =
	getTaxValue(policy, transaction, transaction?.taxCode ?? defaultTaxCode) ??
	(isMovingTransactionFromTrackExpense ? getTaxValue(policyForMovingExpenses, transaction, transaction?.taxCode ?? defaultTaxCode) : '');
	const taxDecimals = getCurrencyDecimals(transaction?.currency ?? CONST.CURRENCY.USD);
	const taxAmount = isMovingTransactionFromTrackExpense && transaction?.taxAmount ? Math.abs(transaction?.taxAmount ?? 0) : calculateTaxAmount(taxPercentage, taxableAmount, taxDecimals);
	const taxAmountInSmallestCurrencyUnits = convertToBackendAmount(Number.parseFloat(taxAmount.toString()));
	useEffect(() => {
	if (!transactionID || isReadOnly || !shouldShowTax || isMovingTransactionFromTrackExpense) {
	return;
	}
	setMoneyRequestTaxAmount(transactionID, taxAmountInSmallestCurrencyUnits);

// Calculate and set tax amount in transaction draft
const taxableAmount = isDistanceRequest ? DistanceRequestUtils.getTaxableAmount(policy, customUnitRateID, distance) : (transaction?.amount ?? 0);
// First we'll try to get the tax value from the chosen policy and if not found, we'll try to get it from the policy for moving expenses (only if the transaction is moving from track expense)
const taxPercentage =
    getTaxValue(policy, transaction, transaction?.taxCode ?? defaultTaxCode) ??
    (isMovingTransactionFromTrackExpense ? getTaxValue(policyForMovingExpenses, transaction, transaction?.taxCode ?? defaultTaxCode) : '');
const taxDecimals = getCurrencyDecimals(transaction?.currency ?? CONST.CURRENCY.USD);
const taxAmount = isMovingTransactionFromTrackExpense && transaction?.taxAmount ? Math.abs(transaction?.taxAmount ?? 0) : calculateTaxAmount(taxPercentage, taxableAmount, taxDecimals);

const taxAmountInSmallestCurrencyUnits = convertToBackendAmount(Number.parseFloat(taxAmount.toString()));

For non-distance requests, this code uses raw transaction amount directly, which can be negative in this flow. That negative taxable amount is then passed into calculateTaxAmount, producing a negative tax that gets saved to the draft via setMoneyRequestTaxAmount. This causes the created expense to carry an invalid sign for tax and eventually appear as zero, because other parts of the flow (like tax-rate selection) compute tax from normalized request amount semantics while this confirmation recalculation does not.

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

App/src/components/MoneyRequestConfirmationList.tsx

Lines 46 to 58 in a8f2d3a

	import {
	areRequiredFieldsEmpty,
	calculateTaxAmount,
	getDefaultTaxCode,
	getDistanceInMeters,
	getRateID,
	getTag,
	getTaxValue,
	hasMissingSmartscanFields,
	hasRoute as hasRouteUtil,
	isMerchantMissing,
	isScanRequest as isScanRequestUtil,
	} from '@libs/TransactionUtils';

Current code:

import {
    areRequiredFieldsEmpty,
    calculateTaxAmount,
    getDefaultTaxCode,
    getDistanceInMeters,
    getRateID,
    getTag,
    getTaxValue,
    hasMissingSmartscanFields,
    hasRoute as hasRouteUtil,
    isMerchantMissing,
    isScanRequest as isScanRequestUtil,
} from '@libs/TransactionUtils';

// Calculate and set tax amount in transaction draft
const taxableAmount = isDistanceRequest ? DistanceRequestUtils.getTaxableAmount(policy, customUnitRateID, distance) : (transaction?.amount ?? 0);

Updated code:

import {
    areRequiredFieldsEmpty,
    calculateTaxAmount,
    getAmount,
    getDefaultTaxCode,
    getDistanceInMeters,
    getRateID,
    getTag,
    getTaxValue,
    hasMissingSmartscanFields,
    hasRoute as hasRouteUtil,
    isMerchantMissing,
    isScanRequest as isScanRequestUtil,
} from '@libs/TransactionUtils';

// Use normalized request amount semantics so tax stays positive for negative-stored IOU amounts.
const taxableAmount = isDistanceRequest ? DistanceRequestUtils.getTaxableAmount(policy, customUnitRateID, distance) : getAmount(transaction);

This reuses the existing amount-normalization helper already used by the tax-rate step and keeps tax calculation consistent across steps. It avoids introducing a one-off Math.abs branch and instead aligns confirmation tax recalculation with the app's established IOU amount sign conventions.

What alternative solutions did you explore? (Optional)

• Existing proposal suggested Math.abs(transaction?.amount ?? 0) at this line, but it does not explain why this path should match tax-rate step semantics and does not reuse the existing normalization helper.
• Normalizing later in IOURequestStepConfirmation or requestMoneyIOUActions would be a downstream patch; it leaves inconsistent draft tax state in Onyx during the flow.
• Changing calculateTaxAmount globally would be riskier because that utility is shared and should keep its current generic contract.

[btkcodedev]

🚨 Edited by proposal-police: This proposal was edited at 2026-02-20 18:36:40 UTC.

Proposal

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

When creating a negative manual expense (for example, -$5.00) with a non-zero tax rate (for example, 5%), tax appears non-zero on confirmation, but after creating the expense the final tax becomes 0.

What is the root cause of that problem?

The confirmation flow was calculating tax from a signed transaction amount, so negative expenses produced a negative tax value internally.

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

Use normalized IOU amount (getAmount) when calculating non-distance taxable amount in confirmation, so tax is always computed from a positive base for manual IOU requests.

[~/App/src/components/MoneyRequestConfirmationList.tsx:546]

const taxableAmount = isDistanceRequest ? DistanceRequestUtils.getTaxableAmount(policy, customUnitRateID, distance) : getAmount(transaction);

This is the correct source-level fix because getAmount already enforces IOU sign normalization for this flow
Add regression coverage for negative manual expenses with tax:

[~/App/tests/ui/components/IOURequestStepConfirmationPageTest.tsx:357]

it('should keep tax amount positive for manual negative expenses', async () => {
    ...
    amount: -500,
    taxCode: 'taxRate1',
    ...
    expect(transaction?.taxAmount).toBe(24);
    expect(transaction?.taxAmount).toBeGreaterThan(0);
});

What alternative solutions did you explore? (Optional)

None

[abbasifaizan70]

Proposal

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

Tax amount changes to zero after creating negative expense with non-zero tax rate.

What is the root cause of that problem?

On the confirm page, tax is computed correctly for negative amounts: MoneyRequestConfirmationList uses transaction?.amount (negative) with calculateTaxAmount, so the draft gets a negative tax amount and the UI shows the correct non-zero tax.

When the user taps Create expense, the TRACK_EXPENSE API is called with taxAmount from the draft (a negative number for negative expenses). The backend likely expects a positive tax amount and either rejects or zeroes negative tax, so the stored transaction is returned with taxAmount: 0. The client then shows zero tax when the expense is opened.

Relevant flow:

• Confirm page passes transaction?.taxAmount (negative) into track expense:

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Line 274 in a8f2d3a

const transactionTaxAmount = transaction?.taxAmount ?? 0;

• TRACK_EXPENSE parameters send that value as-is:

App/src/libs/actions/IOU/index.ts

Lines 7647 to 7649 in a8f2d3a

	tag,
	taxCode,
	taxAmount,

• Optimistic transaction is built with taxAmount: taxAmount ? -taxAmount : undefined (so a negative draft tax becomes positive in the stored transaction), but the server response overwrites the transaction with the backend value (taxAmount: 0):

App/src/libs/actions/IOU/index.ts

Lines 4288 to 4291 in a8f2d3a

	tag,
	taxCode,
	taxAmount: taxAmount ? -taxAmount : undefined,
	billable,

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

Send the tax amount as an absolute value in the TRACK_EXPENSE API request so the backend receives a positive value and can persist it. The client already applies the correct sign for display in expense report context via getTaxAmount(transaction, isFromExpenseReport) in TransactionUtils, which returns the negated value for expense reports, so the displayed tax will remain correct.

File: App/src/libs/actions/IOU/index.ts

            const parameters: TrackExpenseParams = {
                amount,
                attendees: attendees ? JSON.stringify(attendees) : undefined,
                currency,
                comment,
                distance: distance !== undefined ? roundToTwoDecimalPlaces(distance) : undefined,
                created,
                merchant,
                iouReportID: iouReport?.reportID,
                chatReportID: optimisticReportID ? undefined : chatReport?.reportID,
                transactionID: transaction?.transactionID,
                reportActionID: iouAction?.reportActionID,
                createdChatReportActionID,
                createdIOUReportActionID,
                reportPreviewReportActionID: reportPreviewAction?.reportActionID,
                optimisticReportID,
                optimisticReportActionID,
                policyID: undefined,
                receipt: isFileUploadable(trackedReceipt) ? trackedReceipt : undefined,
                receiptState: trackedReceipt?.state,
                reimbursable,
                category,
                tag,
                taxCode,
-               taxAmount,
+               taxAmount: Math.abs(taxAmount ?? 0),
                billable,
                receiptGpsPoints: gpsPoint ? JSON.stringify(gpsPoint) : undefined,
                transactionThreadReportID,
                createdReportActionIDForThread,
                waypoints: sanitizedWaypoints,
                customUnitRateID,
                description: parsedComment,
                gpsCoordinates,
                isDistance: isGPSDistanceRequest || isMapDistanceRequest(transaction) || isManualDistanceRequestTransactionUtils(transaction),
            };