Creating an Invoice from the API, unit price's (and GST rate's) decimal places behave differently from the UI

Hi there,

I developed an integration with our software and from there I'm creating invoices in Quickbooks. Customers are reporting inconsistencies (that I have been able to replicate and verify) in the decimal places shown in RATE column when creating an invoice manually versus importing it from our software.

I dumped the JSON result from the one created manually and the one created from the API to see what's the difference and I can only see that unit_price field in the manual one has 7 decimal places where the one created from the API call has only 2 decimal places. This is interesting since that's the unit price the products API is giving me, only 2 decimal places so I cannot make up more precision from where there isn't... In fact, I don't understand why the UI would generate more decimal points for something that was registered with ONLY 2 decimal points.

So I went ahead and tested it following the next steps like such:

• First I created a product whose unit price was $63.58, it does not include purchase tax and it has a tax rate applied of a (odd) 15%
• Then I created an invoice manually from the UI (online) with 3.5 units of this product and I observed that the column RATE is being automatically calculated by applying a rounding of 2 decimals, therefore the line results like 3.5 in quantity, $73.12 in the column Rate and $255.92 in the column Amount.

Now, interestingly enough, if I go to the API playground and I read this invoice just created, the line entered manually has a UnitPrice of 63.5828571... and I really can't explain why is that... the unit price in the product is 63.58... Trying to explain it by doing the reverse calculation I tried 73.117 / 1.15, which is exactly 63.58 and 73.12 / 1.15, which is 63.58260869... but not 63.5828571... it just doesn't add up. It's odd.

Now, for the next step, I went ahead and pushed the same invoice (same product, same quantity) through the invoices endpoint API, feeding the exact price that the products endpoint API gave me for tax applicable rate (15%) and product price (63.58, EXACTLY as I wrote it, exactly as the product API returns it). I feed 3.5 units of this product at this price and to my surprise, if I peek into the invoice created in the database, I can see that rate column for this line has 7 decimal places of precision as such: 73.1171429... and that totally puzzles my customers and myself, to be quite honest. I don't find the reasoning behind it.

If I go ahead and modify that line's price manually, the rate will keep on being recalculate with 7 decimal places of precision, but if I create a new line (or I remove that one and create a new one) with the same product, automatically the rate is displayed correctly as 73.12, with alway 2 decimal places of precision.

If I keep both lines (imported and manual one) in the invoice and get the JSON of that invoice from the API playground, I get no difference whatsoever between both lines in terms of config, just the unit price is simply different.

As far as I can tell there is no way I can feed in the invoice line the tax rate amount as well as the unit price, which could help me force it to 2 decimal places, but even if there was a way, this shouldn't be the preferred method... the job of the third party application is not to calculate rates, apply taxes and figure out ammounts... but only export the product (by the product key) and Quickbooks should automatically apply the price, the tax and everything else. That's the whole point of having two tools and one specifically (Quickbooks in this case) for accounting purposes. As a developer, I shouldn't even have to feed in a calculated unit price with or without tax applied as the product has it already configured in Quickbooks system so it'd be more consistent for final users to have Quickbooks to do this job. This is the way, in fact, other APIs such Xero, Vend or Myob work. I think you guys should consider make your Invoice API endpoint simpler and more consistent, although I don't mind having an optional way of forcing prices and taxes, that shouldn't be imposed by the API definition.

Can anybody, please let me know what am I doing wrong here?

Thank you!