I got the same number today as well. It should never be negative, strange they don't have a check for that.

Shares shouldn't really be calculated either, it's always listed in the report.

Getting this right is super important because it's the basis of all per share calculations.

AAPL

The current shares outstanding is listed on the first page of every report:

And the weighted average is in the income statement, below the EPS calculations:

AAPL FY: https://www.sec.gov/Archives/edgar/data/320193/000032019323000106/aapl-20230930.htm

Visa - Missing Shares and EPS

Moved this section and screenshots to a new issue: #282

from issues.

The current shares outstanding is listed on the first page of every report:

It would be nice if Polygon also included the current shares outstanding in the API. But that's a separate feature request not a bug.

I agree, although I'm not sure if this value will be included in the XBRL files that they use to collect data since its not in a table. Hope I'm wrong though.

And the weighted average is in the income statement, below the EPS calculations: AAPL FY: https://www.sec.gov/Archives/edgar/data/320193/000032019323000106/aapl-20230930.htm

Visa

The weighted average is the important one, because that's what you need to calculate 'per share' values accurately.

Correct me if I am wrong but shares should never be calculated either, it's always listed in the report.

The reason they do these calculations, is that many companies do not publish a Q4 report, only an annual report.

So to work out Q4 values, they seem to be doing the annual values minus Q1 to Q3. As I stated in the original post, this is the right thing to do for values like revenue but definitely not for the average number of shares.

The financials API is still in an experimental state, so some problems are to be expected I suppose.

Personally I would rather do calculations like this myself, and just get the raw data from Polygon.

Tangentially related: The API does not return ANY share numbers if there are multiple share classes, like with Visa. Might make a separate issue for that. (Not sure if they should be added together or reported separately in the API)

The API also seems to be missing EPS in these cases, that could have been used to roughly calculate the shares outstanding.

Visa FY: https://www.sec.gov/Archives/edgar/data/1403161/000140316123000099/v-20230930.htm

Berkshire Hathaway

Here there are two classes in the same report. They should not be combined.

BRK Q3: https://www.sec.gov/Archives/edgar/data/1067983/000095017023058993/brka-20230930.htm

Yes it seems you are right. I would raise it as a separate issue, as you suggested.

They will have to figure out how to match each value to the right ticker, which doesn't sound fun.

Thanks for bringing more attention to these issues.

from issues.

Implied Q

The reason they do these calculations, is that many companies do not publish a Q4 report, only an annual report.

Just to be totally clear on this. The entire Balance Sheet and the current shares outstanding are point-in-time reported numbers. They do not need to be calculated in an implied Q4.

For the Income Statement you need to calculate the Q4.

And for the Cash Flow Statement you actually need to imply the Q2, Q3, and Q4. As very often only the Q1 is reported as three months ended.

XBRL

I'm not sure if this value will be included in the XBRL files ... since its not in a table.

The current shares yes, a lot of data is in XBRL, even outside of tables.

Here is the XBRL on a Visa 10-Q https://www.sec.gov/ix?doc=/Archives/edgar/data/1403161/000140316123000031/v-20230331.htm

Moved this issue here: #282

from issues.

Just to be totally clear on this. The entire Balance Sheet and the current shares outstanding are point-in-time reported numbers. They do not need to be calculated in an implied Q4.

For the Income Statement you need to calculate the Q4.

And for the Cash Flow Statement you actually need to imply the Q2, Q3, and Q4. As very often only the Q1 is reported as three months ended.

Yep, you're absolutely right.

XBRL

I'm not sure if this value will be included in the XBRL files ... since its not in a table.

The current shares yes, a lot of data is in XBRL, even outside of tables.

Ah, good. Hopefully they can add it to the API.

from issues.

Hi! Thanks for reaching out. We have a ticket open for this issue and hopefully it will be investigated and corrected soon. Please let me know if there's anything else I can help you with!

from issues.

@AHangstefer Why did you close the issue as completed? I am still seeing the negative number in the API.

from issues.