Appearance
Known under-taggers
Some S&P 500 filers tag their EDGAR companyfacts in ways that leave EqtyTrk unable to compute certain metrics. This page documents each known case, the affected canonicals, and how EqtyTrk compensates (or where it does not).
STZ (Constellation Brands)
Constellation Brands does not tag the generic share-count concepts (EntityCommonStockSharesOutstanding, CommonStockSharesOutstanding) in its companyfacts. EqtyTrk walks the full shares_outstanding canonical chain plus the class-specific fallbacks in compute_and_store_market_cap (src/eqtytrk/companies/market_cap.py), but if none of the expected concepts appear, the function returns None and companies.market_cap stays NULL.
A NULL market_cap has downstream effects: pe_ratio and other market-cap-dependent multiples cannot be computed for STZ, and it is excluded from weighted_mcap sector aggregations in sector_medians_cache. As of the current ingest, the column remains NULL for STZ until a paid price/share-count source backfills it. This is tracked in the BACKLOG.
Note that the class_a_shares_outstanding and class_b_shares_outstanding fallback chains (added in the comments in src/eqtytrk/edgar/concepts.py) are the intended long-term fix — they cover dual-class issuers like STZ, BF, and BRK that only tag class-specific share counts. The fallback is active in _sum_class_shares; whether STZ's companyfacts include class-specific concepts must be verified per ingest.
Dual-class names (BF.B, BRK.B, FOXA, GOOGL, NWS)
The S&P 500 index CSV uses ticker symbols like GOOGL, FOXA, and NWS. EDGAR's company_tickers.json does not always list these class-variant tickers directly — it may list only GOOG, FOX, or NWSA. When a user or ingest job requests a ticker that EDGAR doesn't recognize, resolve_ticker in src/eqtytrk/edgar/tickers.py normalizes dot/dash variants (e.g. BRK.B → BRK-B) and falls back to a SELECT against companies_aliases if the normalized form still produces no match.
The companies_aliases table (migration src/eqtytrk/migrations/007_companies_aliases.sql) seeds five rows:
| Alias ticker | CIK | Note |
|---|---|---|
BF.B | 0000014693 | Brown-Forman class B → same CIK as BF-B |
BRK.B | 0001067983 | Berkshire Hathaway class B → same CIK as BRK-B |
FOXA | 0001754301 | Fox class A → same CIK as FOX |
GOOGL | 0001652044 | Alphabet class A → same CIK as GOOG |
NWS | 0001564708 | News Corp class B → same CIK as NWSA |
All metrics, TSR, and peer calculations are keyed by CIK, so once the alias resolves to a CIK, the data is already present. The alias table is purely a ticker → CIK lookup; it does not affect how XBRL facts or share counts are stored or computed.
For share-count metrics, class-specific filers may tag only CommonClassACommonStockSharesOutstanding and CommonClassBCommonStockSharesOutstanding. The _sum_class_shares helper in src/eqtytrk/companies/market_cap.py sums both classes when the generic concepts are absent, so market cap resolves correctly even for these issuers.
Banks (JPM, BAC, WFC, and similar)
Bank balance sheets are structured differently from operating companies. Concepts like InventoryNet and AccountsReceivableNetCurrent have no meaningful equivalent on a bank's balance sheet, so these filers simply do not tag them. As a result, the inventory and accounts_receivable canonical chains resolve to None for banks, and any metrics that depend on those canonicals — inventory_turnover, days_sales_outstanding, and similar working-capital ratios — also return None.
This is correct behavior, not a bug. The metrics engine propagates None rather than emitting a misleading zero or fabricated value. The API, peer table, and correlation views all render None as "—". Sector medians for the Financials sector naturally exclude those metrics when fewer than three constituent companies have a valid value (the MIN_N = 3 guard in src/eqtytrk/sectors/cache.py).
If you observe inventory_turnover = None for JPM or similar large-cap banks, it is expected. The same applies to any metric whose canonical chain bottoms out in a concept that banks do not tag.
If you encounter a new under-tagger, add it here with the affected canonicals and the workaround.