Problem
Japanese companies file their annual and quarterly securities reports with the Financial Services Agency’s EDINET system as XBRL. The data is public and free, but it is organised by filing rather than by company, and account titles are in Japanese. Comparing five years of a company’s statements, or two peers, in English takes real effort.
Approach
- Ingest: a nightly Java ETL pulls new filings from the EDINET API v2 (incremental pulls only; EDINET does not allow bulk downloads).
- Normalise: account titles are mapped to English with the JP–EN account-title lists published by the exchange, into one tidy fact table. Company-specific elements without an English label keep their Japanese name, marked as such.
- Serve: a small API on Cloudflare Workers over a Turso database; the React front end shows five-year statements in Japanese or English, ratios and peer comparisons, with CSV downloads that carry the source attribution.
- Test: JUnit and Mockito for the ETL, with a real database container in CI.
Architecture
Standard pattern: a scheduled batch ETL into a relational store, behind a thin read API and a static front end. Customisations for EDINET: incremental, rate-limited pulls only, a bilingual label layer, and a fallback to the Japanese name wherever an English label is missing. This is the plan from the proposal; the architecture is not decided yet.
01 · Source
- EDINET API v2 (XBRL)
- JP–EN account-title lists
02 · ETL
- Nightly Java job
- Maven · MyBatis
- Normalised fact table
03 · Store + API
- Turso (SQLite)
- Cloudflare Worker API
04 · Explorer
- Company search
- JP / EN statements
- Ratios, peers, CSV
Where it stands
Planned, after Typhoon Replay and LGU Lights. No code yet.
Known limitations to design for: EDINET forbids bulk downloads, so the history fills in gradually; the EDINET taxonomy itself may not be redistributed, so labels come from the exchange’s published lists; and company-specific elements can lack an English label.