EDINET Scraper — Japanese Securities Filings in English (Japan's EDGAR)

Get structured daily feeds of Japanese corporate disclosures from EDINET, the official electronic disclosure system of Japan's Financial Services Agency — the Japanese equivalent of SEC EDGAR.

The problem this solves

EDINET is a goldmine — every annual report, extraordinary report, and 5% shareholding filing in Japan — but it is effectively closed to non-Japanese speakers: the UI is Japanese-only, filers are named in kanji, and document types are opaque form codes.

This Actor gives you each filing as clean JSON with:

• English company names (official romanizations from the FSA filer registry, 11,000+ entities)
• English document types ("Annual Securities Report", "Large Shareholding Report (5% Rule)"...)
• English industry classification ("Transportation Equipment", "Banks"...)
• Ticker, corporate number (法人番号), fiscal period, submission timestamp, PDF/XBRL/CSV availability flags, and a direct PDF link

Killer use case: 5% rule signals (v0.2)

Large Shareholding Reports (大量保有報告書) disclose when any investor crosses 5% of a listed company — the raw signal behind activist-investor tracking and event-driven strategies. This Actor doesn't just list the filings: it parses each filing's data file and emits a ready-to-read signal — who moved on which stock, from what % to what %, and with what intent:

{
  "signal_summary": "Blue Goats Capital -> Vector HOLDINGS Inc.: 5.02% -> 6.15% (+1.13pt, stake_increase, management_involvement)",
  "doc_type_en": "Large Shareholding Report (5% Rule)",
  "filer_name_ja": "Ｂｌｕｅ Ｇｏａｔｓ Ｃａｐｉｔａｌ株式会社",
  "issuer_name_en": "Vector HOLDINGS Inc.",
  "issuer_ticker": "9263",
  "holding_ratio_pct": 6.15,
  "previous_holding_ratio_pct": 5.02,
  "ratio_change_pts": 1.13,
  "holding_event": "stake_increase",
  "purpose_of_holding_ja": "純投資及び状況に応じて経営陣への助言、重要提案行為等を行うこと",
  "investment_stance": "management_involvement",
  "has_important_proposal": false,
  "has_joint_holders": true,
  "number_of_holders": 2,
  "report_obligation_date": "2026-06-30",
  "submitted_at": "2026-07-03 09:00",
  "pdf_url": "https://api.edinet-fsa.go.jp/api/v2/documents/S100YO9B?type=2"
}

What gets extracted per filing (from the official CSV rendition of the XBRL):

Field	Meaning
holding_ratio_pct / previous_holding_ratio_pct / ratio_change_pts	Current vs. previous holding ratio and the move in points
holding_event	initial_5pct_crossing, stake_increase, stake_decrease, exit_below_5pct, no_change
investment_stance	pure_investment vs. management_involvement (the activist tell), strategic_investment, broker_inventory (dealer stock — filter it out), other — classified from the stated 保有目的
has_important_proposal	Whether 重要提案行為等 (acts of making important proposals) is stated — a strong activist marker
has_joint_holders / number_of_holders / holder_names_ja	Joint-holder structure of the position

The dataset ships a dedicated “5% Rule Signals” table view. Parsing is on by default (parseLargeShareholding: true); it costs one extra EDINET API call per large-shareholding filing and can be switched off.

Historical backfill & position time-series (v0.3)

Daily monitoring tells you what happened today; research needs what happened over years. Set dateFrom/dateTo to any range (multi-year backfills supported) and every large-shareholding filing comes out linked into position histories:

• position_key — a stable key for one holder→issuer relationship (filer EDINET code × issuer EDINET code, with a ticker fallback when EDINET omits the issuer code). Group by it and you have the full stake history: “fund X in company Y: 5.2% → 7.1% → 9.8% → exit, over 18 months.”
• position_seq / prev_report_doc_id — the order of reports within each position, so the series is directly plottable.
• chain_consistent — a data-quality flag most pipelines never build: does this report's stated previous ratio actually match the last ratio we saw for the position? false catches missed filings and out-of-order corrections.
• Amendment resolution — 訂正報告書 (corrections) are resolved across the range: outdated originals carry superseded_by / is_latest_version: false, or can be dropped entirely with skipSuperseded: true (recommended for backfills — you aren't charged for filings whose data was later corrected).
• Two time axes — report_obligation_date (when the position change legally occurred) and submitted_at (when the market learned of it). Use the former to reconstruct positions, the latter to backtest price reactions.

Long backfills are checkpointed: if a multi-hour run dies or hits your spend cap, resurrect it and it continues where it stopped (at most ~50 items re-pushed) instead of re-charging from the start.

Real output from a 3-month, one-fund backfill, grouped by position_key (3D Investment Partners → Seibu Holdings, ticker 9024):

position_seq	obligation date	ratio	event	chain_consistent
1	2026-05-18	5.75% → 6.92%	stake_increase	—
2	2026-05-29	→ 7.97%	stake_increase	true
3	2026-06-05	→ 9.02%	stake_increase	true
4	2026-06-15	→ 10.27%	stake_increase	true
5	2026-06-18	→ 11.41%	stake_increase	true
6	2026-06-26	→ 12.86%	stake_increase	true

Practical notes for large backfills: restrict docCategories to ["large_shareholding"], expect roughly 50–100 such filings per business day (a 3-year backfill is tens of thousands of items and several hours of polite, rate-limited fetching), and set the run's max total charge to your budget — the run stops cleanly at the cap and can be resumed.

Recipes — copy-paste inputs

Add your edinetApiKey to each. Results land in the default dataset; use the “5% Rule Signals” view in Console, or fetch JSON/CSV via the dataset API (.../datasets/{id}/items?format=json).

1. Daily activist monitor — schedule daily; 3 days so Monday runs still catch Friday:

{ "lastNDays": 3, "docCategories": ["large_shareholding"] }

Then keep rows where investment_stance = "management_involvement" or has_important_proposal = true. signal_summary is the ready-made alert text for Slack/email.

2. New 5% stakes as trade events — same input as #1; filter holding_event = "initial_5pct_crossing" and drop investment_stance = "broker_inventory" (broker dealing stock, not conviction buying). submitted_at is when the market learned of the stake — that's your event timestamp.

3. Research backfill — every position history over a period:

{
  "dateFrom": "2025-07-01",
  "dateTo": "2026-06-30",
  "docCategories": ["large_shareholding"],
  "skipSuperseded": true
}

Group rows by position_key, order by position_seq, and you have every holder→issuer stake trajectory in the period. skipSuperseded: true keeps only the corrected version of amended filings (and you're not charged for the outdated ones).

4. One fund's full history — e.g. 3D Investment Partners (E33309):

{
  "dateFrom": "2026-01-01",
  "dateTo": "2026-07-04",
  "docCategories": ["large_shareholding"],
  "edinetCodes": ["E33309"],
  "skipSuperseded": true
}

Cheap and fast: metadata is scanned per day, but filing CSVs are downloaded only for the matching fund.

5. Watchlist feed of all disclosure types — annual/extraordinary reports and more for specific companies:

{ "lastNDays": 7, "tickers": ["7203", "6758", "9984"] }

Schedule it daily with lastNDays: 3 + docCategories: ["large_shareholding"] and pipe into Slack, Sheets, or your pipeline. (Using 3 days rather than 1 means a Monday run still picks up the previous Friday's filings — see the note on business days below.)

Other use cases

• Track annual/semi-annual report submissions for a watchlist of tickers
• Monitor Extraordinary Reports (executive changes, major shareholder changes, incidents)
• Build LLM/RAG pipelines over Japanese disclosure documents (XBRL/CSV/PDF links included)

Setup

1. Create a free EDINET account and issue an API key (5 min): disclosure2dl.edinet-fsa.go.jp
2. Paste the key into the input. Done.

A note on business days (getting zero results?)

EDINET only receives filings on Japanese business days. There are no submissions on weekends or Japanese public holidays, so a run targeting only those dates returns zero items — this is expected, not an error. If you run the Actor on a Saturday with lastNDays: 1, you will correctly get nothing.

For scheduled daily monitoring, use lastNDays: 3 so a run always spans at least one business day (e.g. a Monday run still captures the previous Friday). The run log tells you exactly why a date was empty (weekend, holiday, or filters too narrow).

Data license

EDINET content is published under Japan's Public Data License (PDL 1.0); commercial secondary use is permitted with attribution. Output data includes the source attribution. This Actor is an independent tool and is not affiliated with or endorsed by the FSA.

Coming in v0.4: key financials (revenue, operating income, total assets...) extracted from XBRL for annual reports.