Provide Reliable Company Categorization for Accurate Financial Analysis

[amcamc92]

Feature Category

• New API functionality
• Performance improvement
• Developer experience improvement
• Documentation enhancement
• Tool/utility addition

Problem Statement

Is your feature request related to a problem? Please describe.
Yes. When performing financial analysis at scale, it is crucial to accurately classify companies by their primary business type. Applying the same analytical models and financial metrics (e.g., P/E ratio, revenue growth, EPS) to all entities listed with the SEC is fundamentally flawed, as different company types require different analytical frameworks.

For example, a screener based on a methodology like CAN SLIM (focused on operational growth) is designed for operating companies. Its metrics are largely irrelevant or misleading for investment funds, ETFs, REITs, or Business Development Companies (BDCs).

Currently, EdgarTools provides no reliable, standardized attribute or method to distinguish these fundamental company types. Users are left to implement their own heuristic-based classification systems, which are prone to error and inconsistency. A simplistic check (e.g., merely detecting a 13F-HR filing) is insufficient, as many operating companies also have investment arms and file 13Fs. This leads to misclassification of operating companies as "Investment" firms, distorting analytical results.

Who would benefit from this feature?

• Beginner Python users working with SEC filings
• Financial analysts and researchers
• Advanced developers building financial applications
• Data scientists working with financial datasets

Proposed Solution

Describe the solution you'd like
I propose enhancing the Company object in EdgarTools to include a new, reliable classification method or attribute, such as company.get_business_category() or company.entity_type. This would return a standardized string representing the company's primary business type (e.g., "Operating", "Investment Manager", "Fund", "ETF", "REIT", "SPAC").

This classification should be derived using a multi-factor, priority-based algorithm that leverages various data points already accessible through EdgarTools:

1. Primary Signal: SIC Code Analysis: The company's Standard Industrial Classification (SIC) code is a strong indicator. The algorithm should check company.sic against known ranges for specific entity types (e.g., SIC codes in 67xx for holding/investment offices, 65xx for real estate, 62xx for brokers).
2. Secondary Signal: SEC Form Type Analysis: The portfolio of SEC forms a company files is highly indicative. Companies primarily filing 10-K and 10-Q are typically operating entities. Companies filing forms like N-CSR, N-CEN, N-PORT, N-MFP are registered investment companies or funds.
3. Tertiary Signal: Company Name Keyword Analysis: Keywords in company.name (e.g., "Fund", "ETF", "Trust", "REIT", "Acquisition Corp") can serve as reinforcing signals, especially when SIC codes are broad or ambiguous.
4. Priority-Based Decision Logic: These signals should be combined in a prioritized manner. For instance, N-* form filings might take precedence over a less specific SIC code, or a specific SIC code might override a keyword in the name. A final "Other" or "Unclassified" category could handle edge cases.

This would provide users with a clean, programmatic way to correctly segment their universe of companies, enabling them to apply the appropriate analytical models and avoid misinterpretations.

Describe alternatives you've considered

1. Manual Implementation by Users: This is the current state, where each user building an application on top of EdgarTools has to implement their own heuristic-based classification logic. This is inefficient, error-prone, and leads to inconsistent results across different applications.
2. Relying on a Single Factor (e.g., 13F-HR): As discussed, checking solely for the presence of a 13F-HR filing is insufficient and often misleading, leading to misclassification.

Use Case Example

How would you use this feature?

    1 # Provide a code example of how you envision using this feature
    2 from edgar import Company
    3
    4 # Example 1: An operating company
    5 company_aapl = Company("AAPL")
    6 category_aapl = company_aapl.get_business_category() # Proposed new method
    7 print(f"{company_aapl.name} ({company_aapl.ticker}) is classified as: {category_aapl}")
    8 # Expected output: Apple Inc. (AAPL) is classified as: Operating
    9
   10 # Example 2: An investment vehicle (e.g., a BDC or holding company)
   11 company_bk = Company("BK") # Bank of New York Mellon Corp
   12 category_bk = company_bk.get_business_category()
   13 print(f"{company_bk.name} ({company_bk.ticker}) is classified as: {category_bk}")
   14 # Expected output might be "Bank" or "Investment Manager"
   15
   16 # Example 3: An ETF (e.g., SPY)
   17 company_spy = Company("SPY")
   18 category_spy = company_spy.get_business_category()
   19 print(f"{company_spy.name} ({company_spy.ticker}) is classified as: {category_spy}")
   20 # Expected output: SPDR S&P 500 ETF Trust (SPY) is classified as: ETF
   21
   22 # Example 4: A REIT
   23 company_o = Company("O") # Realty Income Corporation
   24 category_o = company_o.get_business_category()
   25 print(f"{company_o.name} ({company_o.ticker}) is classified as: {category_o}")
   26 # Expected output: Realty Income Corporation (O) is classified as: REIT
   27
   28 # This allows for accurate segmentation in analytical pipelines
   29 def analyze_company(company: Company):
   30     category = company.get_business_category()
   31     if category == "Operating":
   32         # Apply CAN SLIM or traditional fundamental analysis
   33         print(f"Applying CAN SLIM for {company.name}...")
   34     elif category in ["Fund", "ETF", "Investment Manager"]:
   35         # Apply NAV-based analysis, compare expense ratios, etc.
   36         print(f"Analyzing portfolio for {company.name}...")
   37     elif category == "REIT":
   38         # Analyze FFO (Funds From Operations)
   39         print(f"Analyzing FFO for {company.name}...")
   40     else:
   41         print(f"Unknown analysis framework for {company.name}.")
   42
   43 # analyze_company(company_aapl)
   44 # analyze_company(company_spy)

Implementation Considerations

Complexity Level:

• Simple (minor API addition)
• Moderate (new functionality with existing patterns)
• Complex (significant architectural changes)

Reasoning: Implementing a robust, multi-factor classification algorithm requires careful design, data analysis of SIC codes and filing patterns, and ongoing maintenance. It's more than a minor API addition but fits within existing patterns of data processing and attribute generation.

Backwards Compatibility:

• This feature maintains backwards compatibility
• This feature might break existing code (please explain below)
• Unsure about compatibility impact

Additional Context

Accurate company segmentation is a foundational step for any meaningful financial analysis. Providing this capability directly within EdgarTools would dramatically improve its utility for advanced users, saving them from reinventing complex heuristic wheels. It ensures consistency and reliability across applications built using the library. This feature aligns perfectly with EdgarTools' core principle of providing accurate financials and a powerful developer experience.

Related Issues/Features:

---

Feature requests are evaluated based on EdgarTools' core principles: Simple yet powerful, accurate financials, beginner-friendly, and joyful UX.

[dgunning]

Feature Request Assessment

Thank you @amcamc92 for this excellent, well-researched feature request! Your problem statement is clear, use cases are compelling, and the proposed solution is thoughtful.

Classification: MEDIUM Priority (P2)

Priority Score: 12.8 (MEDIUM range: 10-20)

Breakdown:

• User Value: 4/5 (Fills API gap for advanced users)
• Urgency: 2/5 (Enhancement, not blocking)
• Feasibility: 4/5 (Clear path with minor research)
• Effort: 2-3 days (M size)

Decision: Under Consideration for v5.7.0 or v5.8.0

Rationale:
This feature aligns strongly with EdgarTools' "simple yet powerful" philosophy. Your proposed multi-factor classification algorithm (SIC codes + form types + name keywords) strikes the right balance between accuracy and simplicity. The API design (company.get_business_category()) is elegant and Pythonic.

Strategic Fit:

• ✅ Simple yet powerful: Single-method API hiding complex classification logic
• ✅ Joyful UX: Removes frustration of manual heuristic implementations
• ⚠️ Advanced use case: Primary beneficiaries are financial analysts/researchers (not beginners)
• ⚠️ Indirect accuracy benefit: Improves analytical accuracy, not data accuracy

Next Steps:

1. ✅ Tracked: Created Beads issue edgartools-5b9f with P2 priority
2. ✅ Roadmap: Added to "Under Consideration" for v5.7.0+
3. 🔄 Planning: Will prioritize alongside other entity API enhancements
4. 🔄 Timeline: Estimated 2-3 days development when scheduled

Implementation Considerations:
Your proposed approach is sound. A few refinements to consider:

• 13F-HR caveat: You're absolutely correct that 13F-HR alone is insufficient (many operating companies with investment arms file 13Fs). Form type should be secondary signal, not primary.
• Priority logic: SIC codes should take precedence (most reliable), followed by N-* form filings, then name keywords as tie-breaker.
• Extensibility: Consider allowing custom classification rules (JSON config file pattern, similar to XBRL standardization customization).
• Edge cases: "Other/Unclassified" category for ambiguous entities is wise.

Community Feedback Welcome:

• Would you find a confidence score useful? (e.g., (category, confidence) tuple)
• Should this support historical classification (entity type changes over time)?
• Any specific SIC code ranges or form patterns you've found particularly reliable?

Thank you for contributing to EdgarTools' mission of making SEC data elegantly accessible! This feature will significantly improve analytical workflows for advanced users.

---

Tracking:

• Beads Issue: edgartools-5b9f
• Priority: P2 (MEDIUM)
• Target Release: v5.7.0 or v5.8.0 (Q1 2026)
• Estimated Effort: 2-3 days

[amcamc92]

Thank you @dgunning for your feedback. My opinion on these topics:

• Would you find a confidence score useful?
  Not really. Confidence scores make sense when classification is probabilistic or ambiguous. In this case, most categorizations are deterministic or can be validated against primary data. Adding a confidence layer could introduce perceived uncertainty that isn’t actionable or representative of the underlying data quality.

• Should this support historical classification (entity type changes over time)?
  No. While some companies shift sectors over time, the only classification that matters for investment analysis is the current, verifiable state of the entity.

• Any specific SIC code ranges or form patterns you've found particularly reliable?
  No, not specifically.

[amcamc92]

Hi @dgunning

Is it actually this enhancement related to #624 ? I'm trying to figure it out, but I'm not sure.

Thank you!

[dgunning]

Hi @amcamc92 — this feature has been implemented and is available now. Here's how it works:

from edgar import Company

# Operating company
Company("AAPL").business_category  # → 'Operating Company'

# REIT
Company("O").business_category     # → 'REIT'

# Bank
Company("JPM").business_category   # → 'Bank'

# ETF
Company("SPY").business_category   # → 'ETF'

# Helper methods
Company("AAPL").is_operating_company()      # → True
Company("SPY").is_fund()                    # → True
Company("JPM").is_financial_institution()   # → True

The classification uses a multi-signal approach (SIC codes → form types → name patterns), as you suggested. 12 categories are supported: Operating Company, ETF, Mutual Fund, Closed-End Fund, BDC, REIT, Investment Manager, Bank, Insurance Company, SPAC, Holding Company, and Unknown.

To your question about #624 — that was a related but separate fix for is_individual misclassification. Both improvements work together to give more reliable entity classification.

Regarding the community feedback questions:

• Confidence scores: Agreed with your take — classification is deterministic from SEC data, no need for probabilistic scores.
• Historical classification: Also agreed — current state is what matters for analysis.

Closing this as implemented. Let us know if the classification doesn't match your expectations for any specific companies.

[amcamc92]

Hi @dgunning, I ran a systematic audit of a subset of tickers of the US universe. I found that there are some misclassification issues.

---

Summary

Issue
ETFs classified as Operating Company
Commodity Trusts / Funds classified as Operating Company
SPAC/Acquisition Corps classified as Operating Company
Likely SPAC classified as BDC

---

Issue 1 — ETFs classified as Operating Company

These are clearly exchange-traded funds (the word "ETF" is literally in their name), but they all land in Operating Company:

Symbol	Name
AAAU	Goldman Sachs Physical Gold Etf
ARKB	Ark 21Shares Bitcoin Etf
BITB	Bitwise Bitcoin Etf
BITW	Bitwise 10 Crypto Index Etf
BRRR	Coinshares Bitcoin Etf
BSOL	Bitwise Solana Staking Etf
BTC	Grayscale Bitcoin Mini Trust Etf
BTCO	Invesco Galaxy Bitcoin Etf
BWOW	Bitwise Dogecoin Etf

Most of these have Security And Commodity Brokers as their EDGAR SIC sector, which is a strong signal that the classification logic isn't catching them. They probably warrant their own ETF category (or at least Investment Fund).

---

Issue 2 — Commodity Trusts, Royalty Trusts, and Funds classified as Operating Company

Same problem, slightly different wrappers:

Symbol	Name	Notes
AGQ	Proshares Trust Ii	Commodity ETP
BAR	Graniteshares Gold Trust	Commodity trust
BCHG	Grayscale Bitcoin Cash Trust Bch	Crypto trust
BDRY	Amplify Commodity Trust	Commodity trust
BNO	United States Brent Oil Fund Lp	Commodity fund LP
BTCW	Wisdomtree Bitcoin Fund	Crypto fund
BPPTU	Bp Prudhoe Bay Royalty Trust	Royalty trust — arguably closer to REIT-like income vehicle
CANE	Teucrium Commodity Trust	Commodity trust

These share the same Security And Commodity Brokers SIC sector as the ETFs above. BPPTU is the odd one out — it's an oil royalty trust, which is neither an operating company nor a conventional fund. If there's no Royalty Trust category, it could arguably go alongside REITs.

---

Issue 3 — SPAC/Acquisition Corps classified as Operating Company

The SPAC classifier correctly assigns Holding And Other Investment Offices SPACs to the SPAC category. However, 7 Acquisition Corps slipped into Operating Company — likely because EDGAR assigned them non-holding SIC codes (possibly because they already completed a merger or de-SPAC'd, or because the SIC was set incorrectly at filing time):

Symbol	Name	Assigned Sector
AEAE	Altenergy Acquisition Corp	Transportation Equipment
ALSAF	Alpha Star Acquisition Corp	Business Services
APAD	Aparadise Acquisition Corp	Amusement And Recreation Services
ATEK	Athena Technology Acquisition Corp Ii	Electric Gas And Sanitary Services
BCAR	D Boral Arc Acquisition I Corp	Business Services
BKHA	Black Hawk Acquisition Corp	Chemicals And Allied Products
BSAA	Best Spac I Acquisition Corp	Educational Services

The telltale sign here is "Acquisition Corp" in the name combined with Emerging growth company in Filer Category. These look like shells that were assigned an operating SIC at formation or post-merger. A name-based fallback rule (e.g., if company name contains "Acquisition Corp" and has no real operating financials → classify as SPAC) could catch these.

---

Issue 4 — Likely SPAC classified as BDC

Symbol	Name	Current Category	Note
CCIX	Churchill Capital Corp Ix Cayman	BDC	"Churchill Capital Corp" is a well-known SPAC sponsor family

Churchill Capital Corp IX is almost certainly a SPAC, not a Business Development Company. Worth double-checking the EDGAR entity type for CIK 2006291.

---

Root Cause Hypothesis

The issues above mainly arise from one of these conditions:

1. EDGAR SIC doesn't match economic reality — ETFs and trusts filed under Security And Commodity Brokers (SIC 6200s) are not being distinguished from broker-dealers.
2. SPACs with non-holding SIC codes — the SPAC detector only catches Holding And Other Investment Offices (SIC 6726), but some SPACs file under their target sector's SIC from day one.
3. Name-based signals are ignored — "ETF", "Trust", "Fund", "Acquisition Corp" in a company name are very high-confidence signals that could serve as a secondary classification layer.

Happy to help test a fix if useful. Let me know if you want the full list of affected CIKs as well.

[dgunning]

Thanks for the detailed testing. I updated the classification logic in Release 5.28.2. which should address much of the issues.