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:
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?
Thanks for posting.
Quickbooks Online is dependent on the data being feed during the import process. We'd highly suggest you contacting our Quickbooks Online Support via Chat or Phone Support Hotline on this link https://help.quickbooks.intuit.com/en_AU/contact.
They can check on the data you are trying to import and see what went wrong.
Thank you! Will do... Although I think I found what's the way the product unit price is being calculated (and in my humble opinion it's wrong...), here is it:
- My product had a price of $63.58
- A tax on it of 15%
- 63.58 * 1.15 = 73.117, rounded to 2 decimal places = 73.12
- Now, if I had 3.5 units of this product... 73.12 * 3.5 = 255.92 (the extra cent I was missing is there now)
- And they you guys calculate again the unit price from there like: 255.92 / 1.15 = 222.5391304... rounded to 2 decimal places 222.92 and then divided by the quantity 3.5 again that gives me 63.5828571... the unit price you assign to the product even though I had it as 63.58...
I honestly don't know why doing it this way? Can you clarify, please?
There are sometimes that due to different rule in rounding by QuickBooks Online API the 1 cent is always left off.
The rounding precision for sales tax calculations is designed for 2 decimal place precision in QuickBooks Online. So when inputting numbers into the UI or the API, you need to take this rounding into account.
Rounding off is done per line. To have a better illustration on how this is done in the system, please refer on this article from Intuit Developer on how they are being calculated: https://help.developer.intuit.com/s/article/QBO-APIs-Tax-Rounding-off-logic-in-QuickBooks-Online
Hope this answers your questions. Feel free to reach out again if you have any other questions.
Yes, I understand the rounding strategy, however I'm not talking about rounding per-se, I'm talking about the round-trip Quickbooks does to figure out the unit price when, in fact, that is given by the product.
Hopefully I made the issue clear. Please, by all means, feel free to escalate this issue to developers if that's what you feel as, anyone could agree, this is clearly a flaw in design (or, at least, a very arguable choice, unless anybody can explain what's the reasoning behind doing it this way).
Thank you for your time!
Thanks for expanding on the unexpected behaviour you're experiencing with the calculations. I would recommend getting in touch directly with our app developer team by raising a ticket from your Intuit Developer account, or reaching out to them on the Question Board. They'll be able to provide more insight into this and check if this is expected behaviour.
You have clicked a link to a site outside of the QuickBooks or ProFile Communities. By clicking "Continue", you will leave the community and be taken to that site instead.