United States United Kingdom Australia Canada (English) Canada (French) France Singapore South Africa Global Ireland
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Liqua
Level 1
posted
‎July 15, 2021 02:07 PM
last updated ‎July 14, 2021 9:07 PM

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!

Reply
5 Comments 5
Nona_O
QuickBooks Team
QuickBooks Team
‎July 15, 2021 04:35 PM

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

Hi Liqua,

 

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. 

Reply
Liqua
Level 1
‎July 16, 2021 09:28 AM

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

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?

 

Thank you!

Reply
Nona_O
QuickBooks Team
QuickBooks Team
‎July 16, 2021 10:48 AM

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

Hi Liqua,


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.

Reply
Liqua
Level 1
‎July 19, 2021 10:01 AM

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

Hi there,

 

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.

 

  • First of all, unit price shouldn't be mandatory in the API when creating an invoice. If the API consumer is feeding in the product id and the quantity. Quickbooks should figure out the rest, using the same strategy on rounding that the front end does, therefore the problem would be solved.
  • Second, if we are forced to feed in the price, think about this: first we have to find out the unit price from the product by its id, but not forgetting we have to find the tax, which are two different enpoints to find out the type of tax to apply and how to the unit price. So the base price to make calculations is the price given by the product and it shouldn't change, however you do change it and when dumping the invoice JSON, the unit price has a value that IT IS NOT the value that the product has saved in the product itself. Simple as that.
  • Third, on the point of the round trip to find out the price that I already have... the consumer is forced to make one call for the product to find the price, another one for the tax code, another one for the tax rate and then the final one to save the invoice. There are three calls per line that are not needed and you guys, Quickbooks, by forcing the consumer to do that, are wasting money as the user has to hit your API and servers 3 times per line on an invoice unnecessarily. It's in your own benefict not to force people to do this round trip.
  • And fourth, since Quickbooks is the accounting tool, the third party tool shouldn't be forced to do this kind of calculations, that's Quickbooks job and not messing with prices and taxes is what keeps separation of concerns in check.

 

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!

Reply
Bonny_
Moderator
Moderator
‎July 20, 2021 01:17 PM

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

Hi Liqua,

 

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. 

 

Bonny

Reply