Python library for SEC Edgar filings analysis.
- Simple API, complex data: Hide SEC complexity behind intuitive Python objects
- Progressive disclosure: Basic usage is easy; advanced features available when needed
- Read before write: Understand existing patterns before modifying code
| Need | Location | Key Classes |
|---|---|---|
| Filing access | edgar/_filings.py |
Filing, Filings |
| Company data | edgar/entity/core.py |
Company, Entity |
| XBRL parsing | edgar/xbrl/xbrl.py |
XBRL |
| Statements | edgar/xbrl/statements.py |
Statement |
| Documents | edgar/documents/ |
Document, HTMLParser |
| Reports (10-K/Q/8-K) | edgar/company_reports/ |
TenK, TenQ, EightK, AuditorInfo, SubsidiaryList |
| Reference data | edgar/reference/ |
Tickers, forms |
from edgar import Filing, Filings, Company, find, objCompany("AAPL")- Get company by ticker or CIKcompany.get_financials()- Financial statements from latest 10-K (recommended)company.get_quarterly_financials()- Financial statements from latest 10-Qfind(form="10-K", ticker="AAPL")- Search filingsfiling.xbrl()- Parse XBRL financialsfiling.obj()- Get typed report object (TenK, TenQ, etc.)
Company → company.get_financials() → Financials → income/balance/cashflow
Filing → filing.obj() → TenK/TenQ/EightK → .reports → Reports
Filing → filing.xbrl() → XBRL → statements
Company → company.get_facts() → EntityFacts → Statement
Filing → filing.document() → Document → extractors
When modifying these, read in chunks:
_filings.py(72KB),xbrl/rendering.py(72KB),xbrl/xbrl.py(66KB)entity/entity_facts.py(63KB),xbrl/facts.py(55KB),xbrl/statements.py(46KB)
We use bd (beads) for issue tracking. Full docs: docs/beads-workflow.md
bd list --status open # Ready/open issues
bd list --status in_progress # Currently active
bd list --status open -p 0 # Critical priority (0=critical, 4=backlog)
bd list -t bug # Filter by type (bug/feature/task)
bd show ISSUE_ID # View details
bd update ISSUE_ID --status in_progress # Change status
bd create --title "..." --type bug --priority P1 # Create issueStatuses: open, in_progress, blocked, closed
| Task | Reference |
|---|---|
| Verification | docs/verification-guide.md |
| Constitution | docs/verification-constitution.md |
| Roadmap | docs/verification-roadmap.md |
| API examples | edgar/ai/skills/core/quickstart-by-task.md |
| Data objects | edgar/ai/skills/core/data-objects.md |
| Workflows | edgar/ai/skills/core/workflows.md |
We use "verification" not "testing". Verification is outward-facing — does this library deliver what we promised?
Governing principle: The Verification Constitution defines 11 principles. The three most important for daily work:
- Documentation is the specification — every documented example must be verifiable
- Data correctness is existential — assert specific values, not just
is not None - The API must be solvable — users and agents can navigate to answers
Every new user-facing feature must include:
- One ground-truth assertion — a specific value from a real SEC filing, verified by hand
- One verified documented example — a code example that is itself a runnable test
- One silence check — verify that bad/missing input produces a useful error, not
None - Solvability — update skill YAML files so agents can discover and use the feature
hatch run test-fast # Fast tests (no network) — run often
hatch run test-network # Network tests (sequential, rate-limited)
hatch run test-regression # Regression tests
hatch run cov # With coverageOnly parallelize fast tests to avoid SEC rate limits.
- Assert values, not existence:
assert revenue == 394328000000notassert revenue is not None - Use VCR cassettes for network tests to enable speed and determinism
- Diversify companies: Don't default to AAPL — use companies from different industries
- Test error paths: Verify that failures produce useful messages, not silent
None - Place regression tests in
tests/issues/regression/test_issue_NNN.py
Check edgar/__about__.py