Back to blog
dataengineering

Japan Has the Deepest Financial Disclosures. No One Can Use Them.

Onkar Dahale

Japan requires every listed company to file a 有価証券報告書 — a "securities report" that runs 100 to 200+ pages. It covers everything: full financial statements, segment breakdowns, risk factors, executive compensation, cross-shareholdings, even the number of employees by division.

Every number is XBRL-tagged. Every filing is free and public. Every company, from Toyota to a ¥2B micro-cap, files through the same system.

4,125 companies. Up to 10 years of history. Three accounting standards. All machine-readable.

And almost nobody outside Japan uses any of it.

The Depth

Here's what a typical 有価証券報告書 (annual securities report) contains:

  • Full financial statements — balance sheet, income statement, cash flow statement, changes in equity — all XBRL-tagged at the field level
  • Management discussion & analysis — management's own narrative on the year, in their words
  • Risk factors — every material risk the company has identified
  • Segment reporting — revenue and profit by business unit
  • Corporate governance — board composition, committees, compensation
  • Major shareholders — top 10 holders with exact percentages
  • Related-party transactions — every deal with insiders
  • Employee data — headcount, average age, average salary, average tenure

Compare this to a US 10-K. The structure is similar, but Japan's XBRL tagging is more granular. The FSA (Financial Services Agency) mandates specific taxonomy elements for each field — hundreds of them across three accounting standards. Every number has a machine-readable label, a reporting period, a currency, and a consolidation status.

The data exists. It's structured. It's free. It's been this way since 2008.

The Wall

So why isn't every quant fund and fintech startup pulling from EDINET?

Language. The filings are in Japanese. The taxonomy labels are in Japanese. The API documentation is a 97-page Japanese PDF. The error messages are in Japanese. There is no official English-language developer guide. (We wrote the first one.)

The API. EDINET's API is date-based. You query by calendar date and get every filing submitted that day. There is no company search. No GET /companies/toyota/financials. To find Toyota's annual report, you query every day in June (when March-fiscal-year companies file), scan 100+ results per day for the right EDINET code, and download a ZIP file containing raw XBRL.

# To get Toyota's latest filing, you do this — for every day in June
curl "https://api.edinet-fsa.go.jp/api/v2/documents.json?date=2026-06-25&type=2"
# Then search 142 results for edinetCode "E02144"
# Then download the ZIP
curl "https://api.edinet-fsa.go.jp/api/v2/documents/S100ABCD?type=1" -o filing.zip

XBRL parsing. The ZIP contains XML (or Inline XBRL embedded in HTML). Revenue isn't tagged as revenue — the element name depends on the accounting standard, the industry, and the section of the report. JP-GAAP manufacturers, IFRS filers, US-GAAP filers, banks, and insurance companies all use different element names for the same concept. Six or more different tags for one field.

Three accounting standards. Unlike the US (US-GAAP, with some IFRS filers) or Europe (IFRS), Japan has three active standards: J-GAAP, IFRS, and US-GAAP. Each uses different taxonomy elements, different line-item structures, and different definitions of "operating income." A screener that works for J-GAAP companies breaks on IFRS filers.

Encoding. Some older filings use Shift-JIS encoding. Negative numbers appear as △1,234 (a Japanese triangle character), (1,234), or with a standard minus sign. Full-width commas , mix with half-width ,. A dash ― might mean zero, null, or "not applicable."

Each of these is solvable. Together, they form a wall that stops most developers before they extract their first clean data point. We estimate 2-4 weeks of engineering time to build a working parser from scratch — and that's before you handle edge cases.

The Gap

The result: a gap between the data that exists and the data that's accessible.

In the US, a developer can get Apple's revenue with one API call to Polygon.io, Alpha Vantage, or FinancialDatasets. Dozens of APIs compete on price, coverage, and developer experience.

In Japan? Before Axiora, a developer's options were:

OptionCostDeveloper experience
Bloomberg Terminal$24,000/yearExcellent — but not an API
Refinitiv / LSEG$15,000+/yearGood — enterprise sales process
Yahoo Finance JapanFreeNo API, HTML scraping, frequently breaks
EDINET directFreeDate-based API, raw XBRL, Japanese docs
Build your own parserFree + 2-4 weeksFull control, full pain

There's a Bloomberg-shaped hole in the middle: structured, developer-friendly, affordable access to Japanese financial data. The data is public and free at the source. The tooling to make it usable didn't exist.

What This Means for Builders

Most Japanese small-caps have minimal analyst coverage. Not because the companies aren't interesting — because the data required to analyze them is locked behind a language and format barrier. A quantitative fund that can read EDINET filings programmatically has an information edge over one that relies on translated summaries from a single analyst.

AI agents can't access it. LangChain has toolkits for US financial data (FinancialDatasets, Alpha Vantage). None for Japan. Ask Claude or GPT about Toyota's revenue and it either hallucinates or says "I don't have access to financial databases." The world's third-largest equity market is invisible to AI tools.

Cross-border analysis is broken. A developer building a global equity screener can pull US data from a dozen APIs, European data from several more, and Japanese data from... nowhere developer-friendly. Japan gets excluded from comparisons not because the data doesn't exist, but because the API doesn't.

What's Changing

We built Axiora to close this gap. Same EDINET source data, parsed and normalized:

import httpx

resp = httpx.get(
    "https://api.axiora.dev/v1/companies/7203/financials",
    headers={"Authorization": "Bearer ax_live_..."},
)
data = resp.json()["data"][0]
print(f"Revenue: ¥{data['revenue']:,}")
# Revenue: ¥48,036,704,000,000

One API call. Typed JSON. 4,125 companies. 52 normalized fields across all three accounting standards. No XBRL, no ZIPs, no triangle characters.

We don't have everything yet. No stock prices (that's JPX/J-Quants territory). No real-time TDnet earnings announcements. English translations cover 54 companies so far — growing daily, but not full coverage. We're building on the structured XBRL data first and expanding from there.

The bigger shift isn't us — it's the tooling layer building on top. LangChain agents with 18 financial tools. MCP servers that let Claude query Japanese financials in natural language. Streamlit dashboards that screen across the full market. The moment the data becomes accessible, the applications follow.

Japan's financial disclosures have always been deep. They're becoming usable.


Get started at axiora.dev — free tier, no credit card.