# Bizarre Rounding Issue When Posting to "/crm/v3/objects/line\_items/batch/update" **URL:** \ **Category:** APIs & Integrations\ **Tags:** php, object\ **Created:** [January 10, 2025, 4:01pm UTC](https://community.hubspot.com/t/bizarre-rounding-issue-when-posting-to-crm-v3-objects-line-items-batch-update/123689 "2025-01-10T16:01:14Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![DaveLinderman](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/davelinderman/32/76793_2.png) [@DaveLinderman](https://community.hubspot.com/u/DaveLinderman)\ **Post date:** [January 10, 2025, 4:01pm UTC](https://community.hubspot.com/t/bizarre-rounding-issue-when-posting-to-crm-v3-objects-line-items-batch-update/123689/1 "2025-01-10T16:01:14Z")
Hello all- Has anyone seen a strange rounding issue when posting values to “/crm/v3/objects/line\_items/batch/update”? I have an instance where I am sending a value to two decimal places, but receiving a 400 error that the value is invalid. **Value I send:** [discount] =\> -0.09 **API Error Response:** Exception = [400] Client error: `POST [https://api.hubapi.com/crm/v3/objects/line\_items/batch/update](https://api.hubapi.com/crm/v3/objects/line_items/batch/update)` resulted in a `400 Bad Request` response: {“status”:“error”,“message”:“Property values were not valid: [{\“isValid\”:false,\“message\”:\”**-0.0899999999999999966693 (truncated…)** I cannot figure out why -0.09 turns into -0.89 repeating. If anyone has any insights that would be fantastic, thank you! Dave ---
**Author:** ![Jaycee\_Lewis](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/jaycee_lewis/32/61352_2.png) [@Jaycee\_Lewis](https://community.hubspot.com/u/Jaycee_Lewis)\ **Post date:** [January 10, 2025, 9:35pm UTC](https://community.hubspot.com/t/bizarre-rounding-issue-when-posting-to-crm-v3-objects-line-items-batch-update/123689/2 "2025-01-10T21:35:28Z")
Hey, @DaveLinderman 👋 Can you share the full request body, please? I’d like to try to reproduce this in my test portal, and I want to make my test as close to yours as possible. Thanks! — Jaycee ---
**Author:** ![DaveLinderman](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/davelinderman/32/76793_2.png) [@DaveLinderman](https://community.hubspot.com/u/DaveLinderman)\ **Post date:** [January 10, 2025, 9:44pm UTC](https://community.hubspot.com/t/bizarre-rounding-issue-when-posting-to-crm-v3-objects-line-items-batch-update/123689/3 "2025-01-10T21:44:21Z")
```lia-code-sample line items = Array ( [0] => Array ( [id] => 27410380823 [properties] => Array ( [price] => 7.5384615384615 [discount] => -0.09 ) ) ) ``` ---
**Author:** ![Jaycee\_Lewis](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/jaycee_lewis/32/61352_2.png) [@Jaycee\_Lewis](https://community.hubspot.com/u/Jaycee_Lewis)\ **Post date:** [January 15, 2025, 6:53pm UTC](https://community.hubspot.com/t/bizarre-rounding-issue-when-posting-to-crm-v3-objects-line-items-batch-update/123689/4 "2025-01-15T18:53:37Z")
Hey @DaveLinderman 👋 Does the same or similar error happen when you remove the negative value and instead send it as “0.09” for “discount”? Using Postman, when I send it as “-0.09”, I get a validation error (but not the floating-point weirdness). And when I send it without the “-” it is accepted. I ask because when we [**enter a discount in-app**](https://knowledge.hubspot.com/products/edit-products-and-terms-in-the-line-items-editor#add-discounts-and-taxes-to-a-deal), we don’t include the “-” as the system handles the discounting for us. Example: `PATCH https://api.hubapi.com/crm/v3/objects/line_items/27857501610` ```lia-code-sample { "properties": { "discount": "0.09" } } ``` Response ```lia-code-sample { "id": "27857501610", "properties": { "amount": "11999.82", "createdate": "2025-01-15T18:28:00.867Z", "discount": "0.09", "hs_acv": "143997.84", "hs_arr": "143997.84", "hs_lastmodifieddate": "2025-01-15T18:31:54.044Z", "hs_margin": "11999.82", "hs_margin_acv": "143997.84", "hs_margin_arr": "143997.84", "hs_margin_mrr": "11999.82", "hs_margin_tcv": "287995.68", "hs_mrr": "11999.82", "hs_object_id": "27857501610", "hs_object_source": "INTEGRATION", "hs_object_source_id": "959085", "hs_object_source_label": "INTEGRATION", "hs_post_tax_amount": "11999.82", "hs_pre_discount_amount": "12000.00", "hs_recurring_billing_period": "P24M", "hs_tcv": "287995.68", "hs_term_in_months": "24", "hs_total_discount": "0.18", "quantity": "2", "recurringbillingfrequency": "monthly" }, "createdAt": "2025-01-15T18:28:00.867Z", "updatedAt": "2025-01-15T18:31:54.044Z", "archived": false } ``` Talk soon! — Jaycee ---
**Author:** ![DaveLinderman](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/davelinderman/32/76793_2.png) [@DaveLinderman](https://community.hubspot.com/u/DaveLinderman)\ **Post date:** [January 15, 2025, 7:19pm UTC](https://community.hubspot.com/t/bizarre-rounding-issue-when-posting-to-crm-v3-objects-line-items-batch-update/123689/5 "2025-01-15T19:19:37Z")
Ahhhh, great call. I got so hung up on the fact that the error was showing a different number than I was passing that I glossed over the fact that it was sending a negative and not a positive. This is due to the integration interpreting a price INCREASE as a negative discount instead of its original intended use as a discount-only mechanism. Thank you for trying this in your portal, and getting my focus back on track! ---
**Author:** ![Jaycee\_Lewis](https://d10pqhm3lwygmk.cloudfront.net/user_avatar/community.hubspot.com/jaycee_lewis/32/61352_2.png) [@Jaycee\_Lewis](https://community.hubspot.com/u/Jaycee_Lewis)\ **Post date:** [January 15, 2025, 7:43pm UTC](https://community.hubspot.com/t/bizarre-rounding-issue-when-posting-to-crm-v3-objects-line-items-batch-update/123689/6 "2025-01-15T19:43:19Z")
Hey Dave! I’m glad that got us back on track. I was thinking about it while testing and wondered if a negative discount in this context would actually be an increase (as you noted). But because it wouldn’t validate, I figured it was a moot point. Have a fantastic day! — Jaycee