[Due for payment 2026-07-06] [$250] Expense - When non-zero decimal amount in tax is removed, it is replaced with 0

[applause-bot]

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.4.17-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94134
Email or phone of affected tester (no customers): sdjnoisdjdosijsonssjo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Enable Taxes in workspace settings.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Click + > Create expense > Manual.
4. Enter amount.
5. Click Tax and change it to 5% rate.
6. Click Tax amount field.
7. Click backspace one time to remove the last digit.
   BUG 1: When the last digit is removed, it is replaced with 0.
8. Click backspace to remove the second last digit.
   BUG 2: When the last two digits are removed, it is replaced with 00.
9. Clear the field.
10. Enter 10.
    BUG 3: .00 is auto added to the amount.

Expected Result:

BUG 1: When the last digit is removed, it will not be replaced with 0.
BUG 2: When the last two digits are removed, it will not be replaced with 00.
BUG 3: After clearing field and adding new amount .00 will not be added to the amount.

Actual Result:

BUG 1: When the last digit is removed, it is replaced with 0.
BUG 2: When the last two digits are removed, it is replaced with 00.
BUG 3: After clearing field and adding new amount .00 is auto added to the amount.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188094_1782172074311.20.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Rizky Gunawan
Bug ID: 7188094

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022070371587884042278
• Upwork Job ID: 2070371587884042278
• Last Price Increase: 2026-06-26
• Automatic offers:
• thelullabyy | Reviewer | 111834824

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/195416558d1d5fa08253143d8320b11b1b1647d3178c15f08c75624ccd2ea6d3

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #94134

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

PR #94134 removed the isNewManualExpenseFlowEnabled beta, which makes the inline tax amount input in the confirmation list the default. That input is fed by a force-sync effect that overwrites whatever the user is typing on every keystroke.

In TaxFields.tsx the value shown is always re-derived from the stored amount with fixed decimal padding:

const taxAmountInput = convertToFrontendAmountAsString(taxAmount, decimals); // e.g. always "5.00"

and this effect pushes it back into the field whenever it changes (L92-L97):

useEffect(() => {
    if (numberFormRef?.current && numberFormRef.current.getNumber() === taxAmountInput) {
        return;
    }
    numberFormRef.current?.updateNumber(taxAmountInput);
}, [taxAmountInput]);

The feedback loop is: user types → handleTaxAmountChange writes the parsed amount to Onyx → taxAmount recomputes → taxAmountInput is re-padded to fixed decimals → the effect runs. The guard is supposed to break the loop, but it compares raw strings: the in-progress text getNumber() returns "5.0" while taxAmountInput is "5.00". They differ, so updateNumber("5.00") overwrites the user's edit.

This explains all three symptoms:

• BUG 1/2 (backspace re-adds 0/00): deleting a digit yields "5.0", which re-pads back to "5.00".
• BUG 3 (.00 appended): clearing then typing 10 stores 1000, which re-pads to "10.00".

The main amount field (AmountField.tsx) does not have this force-sync effect, which is why it doesn't exhibit the bug.

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

Make the effect's guard compare the numeric value instead of the formatted string, so an in-progress edit that already represents the stored amount ("5.0" ≡ "5.00" ≡ backend 500) is recognized as in-sync and is not overwritten. The effect should only call updateNumber when the stored tax amount genuinely differs from what's in the field (e.g. when the tax rate changes and the amount is recalculated externally).

Concretely, in TaxFields.tsx:92-97, change the guard to compare convertToBackendAmount(Number.parseFloat(getNumber() || '0')) against taxAmount (treating empty input as 0), and skip the updateNumber call when they match.

Why this fixes all three bugs

• Backspace "5.00"→"5.0": parses to 500 === stored taxAmount → guard returns, edit preserved.
• Clear field "": parses to 0 === stored 0 → guard returns, field stays empty (no "0.00").
• Type 10: parses to 1000 === stored 1000 → guard returns, no .00 appended.
• Tax rate change recalculates taxAmount to a different value → numeric mismatch → updateNumber correctly refreshes the field.

What alternative solutions did you explore? (Optional)

Drop the force-sync effect entirely and rely on the component's remount key (taxAmountInputKey already includes taxCode/taxValue) plus the value prop, mirroring how AmountField works. This is cleaner but a larger behavioral change; the numeric-guard fix is the minimal, low-risk change appropriate for a deploy blocker.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94264) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.