I think Invoice Ninja has a problem with rounding VAT amounts. Let’s suppose that I want to sell a product for 225 incl. 19% VAT - Invoice Ninja only allows the following combinations: 189.07 + 35.92 = 224.99 or 189.08 + 35.93 = 225.01. This happens in both methods, exclusive and inclusive - the latter results in Invoice Ninja changing the total amount by itself (although this should be a constant amount in this method).
If this were a “manual” invoice, I would write:
Product 189.07
VAT 35.93
Total 225.00
But right now, Invoice Ninja would not accept a total of 225 with 19% VAT.
I have one product, how do I “increase the precision”?
an adjustment item would be a second product, which would mean that I couldn’t create the invoice with a buy now link, right?
I really don’t want to go through the whole tweaking again. Please allow us to change this setting for existing companies or to migrate all the settings to a new one.
For example, you could change the price to 189.075
It would be a surcharge not a second product but it wouldn’t work with buy now links
You may be able to migrate the data by exporting the data, adjusting the spreadsheet and then reimporting it
Sorry, we don’t plan on supporting this setting for existing companies. Our primary goal is to provide an app which works accurately, one way we accomplish this is by placing limits on the complexity we’re willing to take on. This is a good example of that, having a single account with a combination of both types of taxes would be complicated for both developers and users.
Okay, got it. Now it just needs to calculate with increased precision
A general remark on your “limiting complexity” policy: Limiting complexity is a good thing in itself, no doubt about that, but unfortunately, law makers don’t seem to have the same policy. In Europe, VAT is not just company-based - it also depends on the client ( local/foreign [what kind of foreign, EU or non-EU, B2C or B2B?] ) and on the service provided ( digital / educational / etc. etc.). I’m sure non-European tax systems can have similar complexity, maybe even worse… So a good invoicing app should take that into account, even if it means increasing complexity and making the programmer’s life harder…