Invoice miscalculations with comma as decimal separator (v5.2.19-C58)


I noticed some weird behaviour with IN when inputting monetary values with a comma as a decimal separator. There are also some discrepancies between the invoice table in the admin panel and displayed values on the generated PDF.

Let’s start with a new line:

The total is obviously wrong, it should be 41,475 rounded to 41,48.

The same line on the PDF shows this:


For some unknown reason, 0,75 is now 0,70, but the total is right this time.

Let’s try another line. I input the same numbers, but now with periods instead of commas:

Now the total is almost right, but there is a rounding error (it should be 41,48, not 41,47).

The PDF however does the rounding properly and shows the correct total:


Now if I save this invoice and reopen it, the line with the periods is converted to the use of commas as decimal separators (as per my currency settings), and the calculation is right this time in the admin panel, minus the rounding error:

The PDF is unchanged from the previous step.

Now if I change a number on the line that had periods converted to commas (55,3 → 55,3), the calculation is working properly (with a rounding error once again):

If I now try tho replicate that exact same combination on a new line, it just works on the first try:

I really can’t figure the logic here!

One last thing (I am still trying to find how to replicate it), sometimes the commas simply disappear and the numbers are calculated as integers. For instance, on an invoice I charged my client 27,7 km of travel expenses, and on the invoice it ended up being 277 km… I then had an unpleasant chat with him :sweat_smile:
The same thing happened a few other times too.

So basically the calculations are inconsistent and I am for now forced to double check (and manually calculate) everything. Here is a summary of the issues:

  1. The admin panel does not round numbers correctly but the PDF does;
  2. Numbers with commas as decimal separators are sometimes misinterpreted as totally different numbers - replacing commas with periods fixes the problem, and upon saving and reloading the periods are now commas and work properly ;
  3. Sometimes commas as decimal separators are simply removed from the input numbers, creating a much bigger integer;

I can work around the weird commas bug for now, but I cannot fix the rounding errors, which end up creating different totals in the PDFs that what is calculated in the admin panel, leading to wrong client balances:

Admin total:

PDF total:


Not a big difference, but still, those should match!

Thanks in advance for looking into that.


Thanks for reporting this, we’ll look into it.

1 Like

Which country and currency do you have selected in the settings?

I am setup as Canada - CAD but I had to alter the database so that the currency display matches the French Canadian display standard (space thousand separator, comma decimal separator, dollar sign on the right with a space before)


I reverted all of my Canadian clients to the default (blank) country though, as there was a conflict between the hardcoded country settings and my custom currency settings that made the commas appear as periods on the PDFs (as discussed here: Invoice currency display on PDFs do not match admin panel currency display (v5.2.11-C53) - Discourse (

All of my clients (for now) are also setup to use the default currency, but for testing purposes if I setup the client I’m currently invoicing with the USD currency, the rounding errors in the admin panel still happen:





And commas as decimal separators (instead of the standard period) are still interpreted by IN regardless of the USD currency setting, and the line total rounding is still not correct, so I’m not sure the issue is directly related to the chosen currency:

There are two separate problems:

  • Currently the app checks the country/currency decimal separator to determine how to parse numbers. We’ll change this to add an option to make it more explicit.

  • There is a rounding issue triggered by certain numbers, we’ll work to correct this.


Perfect, thanks. But what can explain that parsing commas (,) works intermittently? Sometimes I have zero problem and some other times I get really weird results with very similar entries.

Great, thank you!

Please retest with the next release and let us know if you still experience any issues.

1 Like

Hi @hillel,

I just updated to v5.3.0-C58 and I’m still getting rounding errors. The rounding is actually happening differently in the admin panel whether the numbers are shown in the preview pane or the edit page:

Preview pane:


Edit page:



I’m also still getting weird calculation results with specific numbers combinations, both with commas and periods:

1st try with commas, wrong result:

2nd try with commas after deleting previous values, wrong result:

3rd try with periods after deleting previous values, ok but rounding error:

4th try with periods after deleting previous values and omitting zero on 0.75, wrong resut:

5th try, this time I saved, closed and reopened the invoice after letting the values of 4th try calculations are OK but the numbers were changed:

6th try, I simply edited the values, ok calculation minus rounding error…

Basically the results are all over the place and inconsistent from time to time with constant parameters.

Meanwhile I have no problem whatsoever with other items that have integer quantity numbers:

1st try with comma, ok:

2nd try with period after deleting previous values, ok:

3nd try with previous input with period, saved, closed and reopened: properly converted to comma, result still OK:

Thanks for the feedback, I’ll look into these samples.

Are you aware there is a new option on Settings > Account Management to enable the comma decimal separator.


Sounds good, but I can’t see that option in any of the Account Management tabs!

I’m running the latest version (manually updated since the auto updater for this version gives me a 500 Error for some reason.)


It’s possible the changes didn’t make it in time for the release, you should see the option in v5.3.1.

You can see it now in the demo:

OK good, thank you!

But apparently I was actually still running parts of the old code, or so it seems (even though I thought I flushed the cache both locally and on the server after the update and I also ran artisan optimize, as usual), because tonight when firing up IN, several hours after the update, suddenly a popup told me to refresh the page because the app was updated. :face_with_monocle:

I now see the new comma option and some of the rounding errors I noticed earlier seem to have been corrected… so thanks a lot for the fixes and sorry if my posts were not properly related to the latest version!

I’ll report back if I still get some errors. Thanks!

Thanks for the update, glad to hear it!

1 Like

Hello @hillel.

I no longer see the setting to set commas as decimal separators in v5.3.25-C60!

I just sent a quote and I noticed that the decimals in the Quantity column displayed with a period instead of a comma in the PDF, even though a comma was used in the admin panel. The total calcualtes fine and it is properly displayed with a comma as per my currency settings, so it’s just a display issue it seems. Still, it makes it pretty inconsistent visually! Could this be a bug?


Are you using the web app? Not sure why you aren’t seeing the setting. Note: the setting only applies to form inputs.

@david @ben any ideas about the PDF?

At this time yes, since the Windows app is a CPU hog at the moment, but I fired it up just to check:

Web app (Edge):

Windows App:

The “Decimal Comma” options appears on the Windows app but not on the web app! I tried flushing the app data/cache on my browser, but the toggle still doesn’t appear. I guess it’s still active since it’s turned on in the Windows version?

Thanks for the screenshots, in the latest version the setting was moved to Settings > Localization.

1 Like

Oh, great, thanks! I guess my Windows app is outdated then.

Though with the toggle turned on, there is still the issue with periods instead of commas on decimals on the PDFs Quantity columns.

@david @ben any thoughts?

I don’t think we localise quantity.