[Due for payment 2026-06-19] [Due for payment 2026-06-18] Expense - No error when tax amount exceeds the limit

[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.5-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92161
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@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 > Next.
5. On confirm page, click Tax amount.
6. Enter a large amount and save it.

Expected Result:

Error will show up when tax amount exceeds the limit.

Actual Result:

Error does not show up when tax amount exceeds the limit and it can be saved.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7177431_1781135644919.10.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7177431

[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/a9aaa4033303a32c5071985231845dabe1cdc15c9def585d2f267a2e14a51454

[melvin-bot]

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

[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

Posted by 🤖 MelvinBot — confidence: High (deterministic routing/string-match regression, code evidence below).

What is the root cause of that problem?

The tax-amount validation is gated on a substring check of the active route URL, and PR #92161 renamed that route from camelCase taxAmount to kebab-case tax-amount, so the check now always returns false.

In MoneyRequestAmountForm.tsx:171 the form decides whether it is the tax form via:

const isTaxAmountForm = Navigation.getActiveRouteWithoutParams().includes('taxAmount');

The over-limit error is only raised when isTaxAmountForm is true (MoneyRequestAmountForm.tsx:180):

if (isTaxAmountForm && isTaxAmountInvalid(currentAmount, taxAmount, getCurrencyDecimals(currency))) {
    setFormError(translate('iou.error.invalidTaxAmount', formattedTaxAmount));
    return;
}

PR #92161 (deploy blocker source) migrated the route. The path changed from :action/:iouType/taxAmount/... to money-request/tax-amount/:action/.... The active URL no longer contains the substring taxAmount, so isTaxAmountForm is permanently false → the limit check is skipped and any amount saves. This exactly matches the reported symptom (regresses in staging, not yet in production).

Secondary effect worth verifying

The same flag also guards MoneyRequestAmountForm.tsx:175 (!isTaxAmountForm && isAmountInvalid(...)), whose comment notes that 0 is a valid tax input. With isTaxAmountForm now false, entering 0 as a tax amount may incorrectly raise invalidAmount. Worth checking while fixing the primary bug.

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

Stop string-matching the route to detect the tax form. The tax-amount page already knows it is the tax form, so pass an explicit isTaxAmountForm prop from DynamicIOURequestStepTaxAmountPage into MoneyRequestAmountForm and use that instead of the getActiveRouteWithoutParams().includes('taxAmount') check. This is robust to future route renames.

If a minimal fix is preferred over the prop approach, update the substring to the new kebab-case route (.includes('tax-amount')), but the explicit prop is safer since it removes the URL-string coupling entirely.

What alternative solutions did you explore? (Optional)

None needed — the regression is a direct, deterministic consequence of the route rename in #92161.

---

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

[huult]

@MelvinBot

App/src/pages/iou/MoneyRequestAmountForm.tsx

Line 171 in 0300718

const isTaxAmountForm = Navigation.getActiveRouteWithoutParams().includes('taxAmount');

Since we updated taxAmount to tax-amount, I think we should keep the existing check and update it to use the new parameter like this.

- const isTaxAmountForm = Navigation.getActiveRouteWithoutParams().includes('taxAmount');
+ const isTaxAmountForm = Navigation.getActiveRouteWithoutParams().includes('money-request/tax-amount');

If possible, could we create a constant for this?

@MelvinBot implement this to create a draft PR.