Deal entity - Weighted open pipeline in company currency returns different default values

[ASuthar]

There is one property in the Deals entity in the HubSpot viz 

Weighted open pipeline in company currency ( internal name - hs_weighted_pipeline_in_company_currency).

Currently I'm working on an integration and Migration product known as OpsHub Integration Manager, which is used for the bidirectional integration of the HubSpot system with any other CRM systems like Salesforce, ServiceNow etc.

Now the issue I'm currently facing with this field is, when I don't set this field value, then by default it's value when fetched from the Deal API response as 0.

But sometimes this same field's value is returned as 0.0, from the API response.

So, just want to clarify that is there any issue with such type of calculated field or not. Or is there any additional configuration required in order to not set this kind of fields.

The below is the sample response for this properties' metadata fetched from the properties API.

[d-lupo · Accepted solution]

Hi @ASuthar 

You definitely sent me far down the rabbit hole with this one. But after digging through it, here's what I found.

1. The property is calculated

The value of "hs_weighted_pipeline_in_company_currency" is calculated using:

hs_open_amount_in_home_currency * hs_deal_stage_probability

So whatever you get back from the API depends entirely on the output of these two fields at that exact moment.

2. different "types" of zero

Let's have a look at the "hs_open_amount_in_home_currency" property, which is also calculated. Its logic behaves roughly like this:

• Deal is open → use "amount_in_home_currency" (stored as decimal e.g. 0.0)
• Deal is closed → return 0 (not a decimal)
• If values are missing / haven't ben calculated yet → return "" (empty string) / null

So the calculation may receive:

• 0.0 (decimal)
• 0 (integer)
• "" (empty String)
• null

Even though all of them look like "nothing," they are stored as different data types, and HubSpot seems to treat them differently within the calculation.

3. How HubSpot behaves with each case

Based on testing, HubSpot seems to follow this pattern:

Input	Result
0.0 × probability (any)	"0.0" (decimal)
0 × probability (0 or 100%)	"0" (integer)
"" × probability (any)	"" (empty String)
null × probability (any)	null

This confirms that HubSpot does not normalize the result into a single numeric format.
Instead, it preserves the "type" of whatever went into the formula.

4. Why this happens

This is likely due to how HubSpot’s calculated fields propagate values internally,

how null and empty values are handled and how the API serializes numbers differently depending on the source. So even though mathematically everything is "zero", HubSpot treats decimal zero, integer zero, empty String and null as different inputs.

5. Recommendation

Since HubSpot may return "0", "0.0", "", or null, the safest approach is to normalize the value in your integration logic before using it. This prevents parsing issues, type errors, or unexpected behavior when HubSpot switches between these formats.

Did my post resolve your question? If so, please consider marking it as the accepted solution to help others in the community.

Kind regards
Dennis

[RubenBurdin · Accepted solution]

Hi @ASuthar 

You’re right to question the inconsistency here. With this specific property, nothing is “wrong” with your integration. The inconsistency comes from how HubSpot evaluates and serializes calculated currency fields at different moments in the deal lifecycle.

A few things can help clarify what you’re observing.

When HubSpot evaluates a calculation with currency formatting, it can resolve the underlying inputs as either a float or an integer depending on which upstream field finished calculating first. HubSpot’s documentation around property history and how fields recompute after API writes shows how these system fields may not resolve in a fully synchronized order (https://knowledge.hubspot.com/properties/create-and-edit-properties )

That means sometimes the calculation engine receives 0.0 from hs_open_amount_in_home_currency, and sometimes it receives 0 if the previous sync cycle treated that same value as an integer. These inconsistencies show up especially when the deal is just created, or when amount, pipeline, or stage probability are updated in quick succession.

Also, because the field is a calculation_equation combined with displayFormat: currency and dynamic currency logic, HubSpot does not normalize zero values before serialization. That’s why two API calls made just seconds apart can return 0 for one request and 0.0 for the next even though the underlying arithmetic is identical.

The safest pattern for integrations like yours is to standardize these numeric fields on your side before applying business logic.

This prevents unexpected behavior when HubSpot’s calculation engine completes in a slightly different sequence. If your integration also needs consistent deal values from external CRM systems like Salesforce or ServiceNow, Stacksync keeps both sides aligned in real time so these computed HubSpot fields always resolve against stable inputs. Hope this helps.

[ASuthar]

Thanks @RubenBurdin , for your detailed explanation and fix. It really helped me to understand this core issue being occured from the HubSpot end. 

Also thanks to @d-lupo, @GRajput, @mohdisrarmwb and @BérangèreL for your quick responses and analysis.

Thanks,
Aniket.

[BérangèreL]

Hi @ASuthar, I am glad to hear that all is working for you now!
 

Thank you so much for sharing your valuable feedback, it truly means a lot to us!
 

To help ensure your thoughts are seen by the right team, I recommend  submitting the HubSpot Developer feedback form.

If you’d like, I’d be more than happy to submit it for you, just let me know what works best for you.
 

Thanks again, and I hope you have a fantastic weekend!
Bérangère

[ASuthar]

Thanks @BérangèreL , same to you, have awesome weekend.

[d-lupo · Accepted solution]

Hi @ASuthar 

You definitely sent me far down the rabbit hole with this one. But after digging through it, here's what I found.

1. The property is calculated

The value of "hs_weighted_pipeline_in_company_currency" is calculated using:

hs_open_amount_in_home_currency * hs_deal_stage_probability

So whatever you get back from the API depends entirely on the output of these two fields at that exact moment.

2. different "types" of zero

Let's have a look at the "hs_open_amount_in_home_currency" property, which is also calculated. Its logic behaves roughly like this:

• Deal is open → use "amount_in_home_currency" (stored as decimal e.g. 0.0)
• Deal is closed → return 0 (not a decimal)
• If values are missing / haven't ben calculated yet → return "" (empty string) / null

So the calculation may receive:

• 0.0 (decimal)
• 0 (integer)
• "" (empty String)
• null

Even though all of them look like "nothing," they are stored as different data types, and HubSpot seems to treat them differently within the calculation.

3. How HubSpot behaves with each case

Based on testing, HubSpot seems to follow this pattern:

Input	Result
0.0 × probability (any)	"0.0" (decimal)
0 × probability (0 or 100%)	"0" (integer)
"" × probability (any)	"" (empty String)
null × probability (any)	null

This confirms that HubSpot does not normalize the result into a single numeric format.
Instead, it preserves the "type" of whatever went into the formula.

4. Why this happens

This is likely due to how HubSpot’s calculated fields propagate values internally,

how null and empty values are handled and how the API serializes numbers differently depending on the source. So even though mathematically everything is "zero", HubSpot treats decimal zero, integer zero, empty String and null as different inputs.

5. Recommendation

Since HubSpot may return "0", "0.0", "", or null, the safest approach is to normalize the value in your integration logic before using it. This prevents parsing issues, type errors, or unexpected behavior when HubSpot switches between these formats.

Did my post resolve your question? If so, please consider marking it as the accepted solution to help others in the community.

Kind regards
Dennis

[GRajput]

Hi @ASuthar 

"It appears that when either the deal amount or the probability value required for the calculation is not present, HubSpot resolves the computed property to its default value of 0. If your integration requires consistent numeric handling, you should normalize the value by explicitly converting it to a decimal/double, for example:
value = parseFloat(hs_weighted_pipeline_in_company_currency || 0);
"

I hope this will help you out. Please mark it as Solution Accepted and upvote to help another Community member.

Thanks!

[ASuthar]

Thanks @GRajput , for your solution, just one thing to confirm, that if when it will return 0.0, like in which case this can happen

[GRajput]

Hi @ASuthar 

Two scenarios that come to my mind are :
When the amount is 0 and the probability has any value, or when amount is 0.0 and the probability has 100%. In either case, it will return "0.0".
For a better understanding, you can check the value of the amount and probability for the values whose is coming out as "0.0".

[mohdisrarmwb]

Hi  @ASuthar ,

This happens because the field is a calculation equation (fieldType: "calculation_equation") AND its type is number with showCurrencySymbol: true, and HubSpot automatically formats number + currency values depending on: hs_open_amount_in_home_currency*hs_deal_stage_probability  

HubSpot only adds decimal places when "currency formatting" is enabled, so that you can use this curl

curl --request PATCH \
  --url "https://api.hubapi.com/crm/v3/properties/deals/hs_weighted_pipeline_in_company_currency" \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer YOUR_PRIVATE_APP_TOKEN" \
  --data '{
    "showCurrencySymbol": true,
    "displayFormat": "currency",
    "decimalPlaces": 2
  }'

I hope this will help.

Best regards,
Mohd Israr

[ASuthar]

Thanks @mohdisrarmwb , for your reply,

But the issue I'm facing is, this field's value is changing arbitarily, like let's say 10 API calls are made then there are chances that all 10 will return same value for this fields as 0.

But there can be another case as well, where out of 10, 1 API call returns the value as 0.0.

So, want to understand how this can be possible.

[BérangèreL]

Hi @ASuthar and thanks for reaching out to the HubSpot Community!

I'd love to put you in touch with our top Experts: Hi @d-lupo, @coldrickjack and @sylvain_tirreau do you have any insights to share with @ASuthar, please?

Have a wonderful day and thanks so much!
Bérangère

[ASuthar]

Thanks @BérangèreL , for your speedy response, looking for the genuine and worth solution.