Let's talk for a minute about user expectations and magic.
A user comes to your tool with certain expectations, and not every user's expectations are the same. You're seeing this first-hand. Culture, up-bringing and life experience all shape how a user will interact with a tool, opening a vast array of expectations to potentially meet.
One expectation almost every user has, however, is that when an illusionist or magician does a trick -- say, picking a card from a card deck -- the illusionist is always going to guess their card correctly.
Put another way, if your tool is going to automate something, and going to guess what the user meant to type, it needs to get that guess correct, or the user will end up disappointed or frustrated.
As you stated as well, they may end up overcharged which, if your system changed what they entered without their express desire and increased the amount, could make you legally responsible for the overcharge and get you in trouble.
To guess or not to guess; that is the question. So, we have two courses of action to choose from:
Option 1: Analyze what's typed in and fix it
In this case, you may need to look for a solution that can better accommodate all of the edge cases you're seeing. If accounting.js isn't correctly reformatting the text, you may need to do something more custom.
Enter the regular expression.
What you'll need to do is figure out all of the patterns you might encounter, which are correct, and which need to be changed. When we start looking at common cases,
- ###.###,## > ###,###.##?
- ###,###,## > ###,###.##?
- ######,## > ###,###.## or ##,###,###?
It starts getting tricky pretty quick. To do this you'll need to do enough testing to know if your test and replacement patterns are getting it all right, and you'll need to watch out that new patterns don't emerge.
As well, if one of your patterns incorrectly changes the content, the user might not notice you've updated the amount (or, when you ask them to confirm the updated value is what they meant, they could miss an important change) and end up paying the wrong amount. What's more, if you did it for them, you might be legally on the hook.
Option 2: Guide them to the right formatting
This option will take a little less work and be safer from a number of standpoints. It's probably also more likely to end up in a pleasant user experience.
Here, still look for a strangely formatted string. Too many periods, too many digits between commas, a comma delimiting the final two strings of numbers, things like this.
What'd I'd suggest is using some implementation of live field validation to confirm that they're formatting their input correctly. When they type something strange, click out of the box, or try and submit the form, make sure to process the string to flag any of the tests you're looking for. If it fails a test, display a message next to or below the field (have a look at some of these images for ideas of how to display the messages) that explains specifically what looks strange.
Don't change anything automatically -- ask them to do that themselves.
Check again as soon as you can whether they've made correct changes. Ideally do this before they have to hit the submit button again, when they focus-off from the field for example. If it's all good, display a message (in a friendly success color like green or blue) that tells them they successfully fixed the error. If they need to try and fix it again, re-display an error message, and indicate that you checked and they still have more to do.
Oops, looks like it's still not quite right. <error mitigation message follows.>
This way, they know they still have work to do and the form is explicitly asking for follow-up action.
Good luck!
