Today, we spent some time reviewing the new N-PX filings and uncovered a few complexities, particularly around the “voterecord_managementRecommendation” column. Initially, I misunderstood what this variable represented (we’ve since updated the N-PX field guide accordingly). As it turns out, it’s more nuanced than before.
An important change in this form relative to the prior versions of the FORM N-PX is that this form does not require the filer to directly report the recommendation of management on the voting issue. Instead of simply reflecting management’s position, the managementRecommendation actually indicates how the filer’s vote compares to the management’s recommendation. For example, if the filer voted AGAINST a shareholder resolution that management also recommended voting AGAINST, the managementRecommendation field would report FOR.
To clarify this, here’s a simple matrix:
| voteRecord_howVoted | managementRecommendation | Management Position |
| FOR | AGAINST | AGAINST |
| AGAINST | AGAINST | FOR |
| FOR | FOR | FOR |
| AGAINST | FOR | AGAINST |
It is a bit convoluted. Reviewing the first line in the table above – the filer voted FOR, which was AGAINST management’s recommendation – therefore the proxy should report that management recommended a vote AGAINST. But the second row demonstrates that the filer cast shares AGAINST the proposal and this was AGAINST management’s recommendation so the proxy should report that the management position was FOR the proposal. The last two rows describe the cases where the filer’s votes matched management’s position (recommendation) as reported in the proxy. The first two rows describe cases where the filer voted in opposition to management.
On to a New Issue: Distorted Vote Counts
While investigating the managementRecommendation variable, we encountered another oddity—absurdly large vote counts. Here’s an example from Amazon’s say-on-pay vote from a few institutional investors’ N-PX filings:
We believe we have identified a pattern across roughly 25,000 individual cases from 153 N-PX filings. The issue seems to stem from a decimal error made by the Filer. We confirmed that this was likely an error by comparing the reported holdings in 13-F and N-PORT filings. We believe that it might be possible to develop a check for this issue and adjust the sharesVoted and voteRecord_sharesVoted values. We have additional testing to do to confirm that our check and fix will perform as expected.
After correcting for this error error, the data relating to Amazon showed 956,903,357 votes AGAINST the say-on-pay proposal by institutional managers. This seems reasonable given that Amazon’s 5.07 8-K filing from their annual meeting reports almost 1.7 billion votes cast against the Say-on-Pay proposal.
Before this discovery, the sum of votes exceeded the total number of shares cast by a factor greater than 10, which understandably raised some eyebrows.
A Cautionary Note for N-PX Data Users
This discovery underscores that the N-PX data, as received from the SEC, may not always be reliable for vote counts. If you’re working with this data, be sure to sanity-check the share numbers to avoid dealing with unrealistic or erroneous figures. Frankly it makes us a bit nervous to make changes in the data because there is always the chance we will introduce an error. Our first and most important goal is to confirm that we collected the data as-reported. Once we have done that it is then possible to investigate for anomalies. The problem with that is we have to switch to heuristics in our coding and analysis. We try to separate coding done deterministically from coding done heuristically.