Cannot Enter Decimal Amounts for COP Currency in New Expensify

[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.11-53
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: @Liz-Canary
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Navigate to workspace chat or click global +
2. create a new expense
3. Set the currency to COP
4. Attempt to enter an amount that includes a decimal value (e.g., 1234.56)

Expected Result:

The expense amount should accept and display 2 decimal values, consistent with Expensify Classic behavior.

Actual Result:

New Expensify does not register any input after the decimal point.
The user cannot enter the full amount as intended.

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

Recording.2350.mp4

View all open jobs on GitHub

[melvin-bot]

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

[trjExpensify]

Response from the frontend:

"COP": {
        "symbol": "Col$",
        "name": "Colombian Peso",
        "decimals": 0
      },

Looks like this currency has decimals: 0 in the backend in places like here and here.

Not entirely sure why, given that we allow 2 decimal entry for COP in Classic. See below:

2026-02-05_18-46-08.mp4

[c3024]

@trjExpensify

I think the Classic behavior is what’s 'incorrect'. It allows decimals for all currencies like COP, JPY, etc. In Classic, the text box or the submission validation does not check whether decimals are allowed for a given currency. I think we should change the Classic behavior here in the New Expense text box and validation to match the PHP lib, which is used everywhere else (ND, Auth, etc.).

[trjExpensify]

The customer is coming from Classic and they're expecting to have decimals allowed on COP expenses because: "the banks in Colombia use decimals, since they charge the bank fees with specific percentages. We should provide the correct amounts to reconcile our banks in COP."

We could validate this a little though with some of our team. Tagged you.

[c3024]

Not overdue. Discussing on Slack.