How to Read EDINET's Index

EDINET is the Financial Services Agency's system for disclosure filed under the Financial Instruments and Exchange Act. Its document list is served by an API: a request names a file date and type=2, and the response is a JSON object whose results array holds one row of twenty-nine fields, from seqNumber to legalStatus, for every filing processed that day and for every registered operation on an earlier one. The field names are English. Their definitions are in a Japanese specification, EDINET API 仕様書 version 2, and most of what follows is that specification read against one month of the list — the twenty-two weekday indexes of June 2026, which carried 15,741 rows for 15,715 distinct documents.

The first thing to know is that a row is not a document, and the date you request is not a submission date. The key is docID, an eight-character identifier such as S100Y8NY, and in June 2026 twenty-six of them appear twice, 21 on two different dates and five twice on the same date; all twenty-six are the same event, an edit of the registered information by Finance Bureau staff, which adds a row on the day of the edit and marks the original. Count by docID, keeping the edited row where both appear, or the population is inflated by exactly the edits; the counts below keep the edited values. The date is a file date: the specification says the list for a date holds the documents processed that day together with any information edits and non-disclosure changes registered that day, that a document submitted on disk or on paper is listed on the day of the operation rather than the day it is dated, and that any date within ten years can be requested, weekends included. In June 2026 the shortest weekday list was 161 rows, on 2 June, and the longest 1,881, on 25 June.

secCode is the filer's securities code, and it is five characters long. The specification names the field 提出者証券コード, the filer's securities code, and every one of the 10,782 June documents that carry it print five characters ending in 0: Toyota's annual report reads 72030, not 7203, and companies with a letter in their code print forms like 150A0. Drop the trailing zero to get the four-character code used on the exchange. The field is empty on 4,933 documents, and an empty field says nothing about the company a document is about.

Nowhere does that matter more than in large-shareholding reports. On 15 June 2026 TOYOTA MOTOR CORPORATION filed a 変更報告書, the change report that amends a large-shareholding report about another company's shares; the row's secCode reads 72030, Toyota's own, and the company whose shares the report concerns appears only in issuerEdinetCode, as E04425. The specification defines that field for exactly this purpose: 大量保有について発行会社のEDINETコードが出力されます. The EDINET code list resolves E04425 to KDDI CORPORATION. Search the index by a company's securities code and you select what it filed. What others filed about it sits in the other-party fields: issuerEdinetCode for large-shareholding reports, subjectEdinetCode for the tender-offer documents, filled on 50 June documents, and subsidiaryEdinetCode for parent-company status reports, filled on 47.

June 2026 carried 2,366 documents of types 350 and 360, the large-shareholding family. issuerEdinetCode was filled on every one of them. secCode was filled on 93, and in all 93 it matched the filer's own code on the EDINET code list; in four of the 93 the filer and the issuer carry the same EDINET code — TOSNETCORPORATION and AI storm CO.,LTD. each filed two documents in which issuerEdinetCode is their own code. The 2,273 blanks are documents from 410 filers that have no securities code on the list. Counted by document, 1,221 came from filers registered there as 外国法人・組合（有価証券報告書等の提出義務者以外）, foreign entities that are not themselves reporting companies, 663 from domestic entities in the equivalent category, 302 from individuals, 81 from unlisted domestic corporations and 6 from unlisted foreign ones; counted by filer, the 410 are 74 foreign and 165 domestic non-reporting entities, 154 individuals, 15 unlisted domestic corporations and 2 unlisted foreign ones.

The code list is the companion file. EDINETコードリスト is a CSV the agency publishes at an address the specification gives, with one row per registered filer: the EDINET code, the Japanese name, an English name in a column headed 提出者名（英字）, the five-character securities code, the corporate number and a filer category. The copy used here, dated 26 July 2026, holds 11,360 rows and resolved 812 of the 822 distinct issuer codes in June's large-shareholding rows, covering 2,351 of the 2,366 documents. The specification adds that the filer attributes printed in the index are those at the moment the row was created, and that the list is where current ones are kept.

docTypeCode is a three-character code, and the specification's reference section lists forty-two of them, from 010 有価証券通知書 to 380 変更の届出書. In June 2026 the largest classes were 120 有価証券報告書, the annual securities report, with 3,061 documents; 180 臨時報告書, the extraordinary report, 2,880; 135 確認書, the confirmation letter, 2,450; 235 内部統制報告書, the internal control report, 2,203; 350, 1,696; 030 有価証券届出書, the registration statement, 724; 360 訂正大量保有報告書, the corrected large-shareholding report, 670; 220 自己株券買付状況報告書, the monthly buyback report, 531; 090 訂正発行登録書, the corrected shelf registration, 435; and 160 半期報告書, the semi-annual report, 343. The other 17 codes in use that month held 676 documents between them, and 46 rows carried no code at all, which brings the total to 15,715. A corrected document takes its own code, usually the next one up — 130 for a corrected annual report, 170 for a corrected semi-annual report, 230 for a corrected buyback report. One code covers two documents: 350 is named 大量保有報告書 in the specification, but the index uses it for the initial report and for the 変更報告書 that amends it, and in June 250 of the 1,696 were initial reports and 1,446 were change reports, 33 of those marked 短期大量譲渡. Only docDescription and formCode separate them — 010000 for the initial report, 010002 for the change report, 020002 for the 短期大量譲渡 change report, 030000 and 030002 for the 特例対象株券等 forms — so a count of docTypeCode 350 is not a count of new large-shareholding reports.

A single filing event spreads across several rows. On 10 June 2026 Toyota's annual report was listed at 15:33 (docID S100Y8NY, type 120), its confirmation letter at 15:34 (S100Y8NZ, type 135) and its internal control report at 15:36 (S100Y7HF, type 235). The three rows carry two ordinance codes: 010 for the first two, 企業内容等の開示に関する内閣府令, the Cabinet Office Ordinance on Disclosure of Corporate Affairs, and 015 for the third, 財務計算に関する書類その他の情報の適正性を確保するための体制に関する内閣府令, the ordinance behind the internal control report. ordinanceCode is the quickest partition of the list: in June, 8,946 documents under 010, 2,366 under 060 for large shareholdings, 2,214 under 015, 2,067 under 030, and small numbers under 020, 040 and 050 — the ordinance for foreign bond issuers and the two tender-offer ordinances.

Code 030 is 特定有価証券の内容等の開示に関する内閣府令, the ordinance for investment trusts and similar securities, and its documents are the ones with a fundCode. The two coincide exactly: 2,067 documents carried a fund code in June and 2,067 carried ordinance code 030, the same documents. A 有価証券報告書 with a fund code is a fund's annual report, and 592 of June's 3,061 annual reports were of that kind, most of them labelled 有価証券報告書（内国投資信託受益証券） in docDescription. Any count of companies has to drop them first.

On the June 2026 lists periodStart and periodEnd are filled on two types only, 120 and 160, and the specification says what they hold: the fiscal year, for the annual report and for the semi-annual report alike, and the quarterly accounting period for the quarterly report, of which June carried none. So a 半期報告書 carries the year it falls in, not the six months it covers, and 330 of June's 343 spanned about twelve months. Three that had been registered with a six-month end were edited during the month to the year end, one of them from 2026-04-30 to 2026-10-31. docDescription repeats the period in its own format after the term number — 有価証券報告書－第122期(2025/04/01－2026/03/31) for Toyota — and it is the only place the term number appears.

Those edits have their own field. docInfoEditStatus reads 1 on the row that records an edit by Finance Bureau staff and 2 on the row of the document that was edited, and opeDateTime carries the time of the operation. The document itself is untouched: the specification says 提出された書類自体は修正されないため、書類取得APIで取得できる書類は、書類情報修正の前後で同一です, and lists the twelve fields that can be edited, among them the form code, the document type, both period dates, the description and the parent ID. June 2026 recorded thirty such edits. Twenty-six were to documents listed in the same month: fourteen changed only the form code and description of a large-shareholding row, and one changed those and its issuer code; four changed a description alone — one internal control report's period had been registered as 2026/06/23－2026/06/23 and became 2025/04/01－2026/03/31; three changed a period end and the description with it; two turned a 訂正確認書 into a 確認書 and set its parent; one changed only an issuer code and one only a parent ID. The other four concerned documents listed earlier, one of them an internal control report filed in June 2025.

A filer's own correction is a different thing entirely: a new document with its own docID and its own type, linked backwards by parentDocID. The specification lists when that field is set — a correction's original, a change report's base report, a confirmation letter's report, a withdrawal's target — and twice adds 提出操作上設定されている場合のみ, only where it was set at submission. The June figures show how selective that is. All 670 訂正報告書 on large holdings carry a parent; of 1,446 change reports, 893 do and 553 do not; of 250 initial reports, none. Of 2,450 confirmation letters, 162 carry one, and every one of the 162 names a correction — 138 corrected annual reports, 19 corrected semi-annual reports, 5 corrected quarterly reports — while 2,223 of the 2,288 that leave it empty sit beside an annual report from the same filer on the same day, Toyota's among them. An empty parent field is not a statement that a document stands alone.

withdrawalStatus marks the two sides of a withdrawal: 取下書は"1"、取り下げられた書類は"2"、それ以外は"0". Both sides are stripped. The specification says the withdrawn document is reduced, after midnight on the day of the withdrawal, to its sequence number, docID, parentDocID and the flag, with the other status fields and flags set to 0 and everything else null, and that neither it nor the withdrawal request can be retrieved from the document API. June 2026 carried ten requests, which keep their submission timestamp as well, and fifteen withdrawn documents in that shape: the ten requests point to ten documents, none of them listed in June, and the fifteen withdrawn rows point to seven parents, two of which are named four times each. Asking the document API for one of the fifteen, S100Y7T9, returned 404 Not Found on 7 September 2026.

The index reaches back ten years, and legalStatus says where a document stands in that span: 1 while it is in its statutory inspection period, 2 in the extension the agency grants some types after that period ends, 0 once viewing has ended or a document has been withdrawn. For reports under 企業内容等の開示に関する内閣府令 the specification's table gives five years plus five for annual and semi-annual reports and three plus seven for quarterly reports, ten in all, with the extension limited to semi-annual reports submitted from 1 April 2024 and quarterly reports from 1 April 2015; reports on specified securities, the investment-trust filings under ordinance 030, get no extension. A separate section says an expired document keeps only its sequence number and docID, with every other field null and every flag 0. June 2026's index, read at the end of August, had 14 rows at status 2, all of them corrections filed that month to reports for the year ended March 2021 or for quarters of 2022 and 2023, and 21 rows at status 0 with nothing in them but the two identifiers; the document API returned 404 for one of those too. June 2025's index, read again on 5 September 2026, had 885 such rows. What they were, the index no longer says.

englishDocFlag does not say a document is in English. The specification defines it as 書類に英文ファイルがある場合は"1": an English file exists, and the document API returns it as a ZIP when asked with type=4. In June 2026 the flag was set on 10 of 15,715 documents, filed by six companies, all registered on the code list as foreign entities. BP p.l.c. filed two of the ten, and its extraordinary report of 8 June carries an English file that unpacks to two HTML files; Visa Inc. filed two more, and its semi-annual report of 30 June is the only one of the ten that is not an extraordinary report or a correction of one. None of the ten carries XBRL or CSV. Toyota's annual report reads 0 here, and what that records is the absence of an English file attached to this filing on EDINET; it says nothing about what the company publishes elsewhere.

The remaining flags are literal. xbrlFlag and csvFlag agreed on every June document — 12,460 with both, 3,255 with neither — and the specification explains why: the CSV is a conversion of the XBRL. Every one of the 2,450 confirmation letters and all 435 訂正発行登録書, corrected shelf registrations, have neither. pdfFlag was 1 on every row except the 46 stripped ones, and the specification notes that this PDF is the one behind the PDF表示 link on the viewing site, not any PDF inside the attachments, which come with type=3. Names, finally, are printed in full-width characters throughout: 508 of June's 3,512 distinct filer names contain Latin letters, and every one of them is full-width — 株式会社ＬＩＸＩＬ, ＤＣＭホールディングス株式会社 — so a search for LIXIL in half-width letters finds no row.

On the counts. The June 2026 figures are from the twenty-two weekday lists for 1 to 30 June 2026, requested from the API on 30 August 2026 and deduplicated by docID, 15,741 rows to 15,715 documents; the June 2025 comparison was requested on 5 September 2026 and gave 14,919 rows for 14,905 documents. Quotations from the specification are from EDINET API 仕様書 version 2, revision 2.9 of June 2026, whose cover states its contents as of June 2026. English company names follow the 提出者名（英字） column of the EDINET code list where it is filled; for BP and Visa, where it is blank, the name is the one printed in Latin script on the filing's own cover. EDINET content is reused here under the Public Data License 1.0 with the source stated, and the API key that every request carries appears nowhere in this file. What this guide does not cover is what the documents say; that is the subject of the rest of this site.

Twenty-nine fields, one file a day, and a securities code that belongs to whoever did the filing.