Disclosure: I built this dataset and publish it on my own site. Posting under rule 1.
It covers 183 non-financial Korean listed companies, built entirely from DART (dart.fss.or.kr — Korea’s regulatory filing system). Every figure carries the receipt number of the filing it was read from, so any row traces back to the original document.
Coverage
- 183 non-financial listed companies (financials excluded — different balance-sheet structure)
- FY2021–FY2025 annual figures, plus 2026 H1 where filed
- Base date 2026-08-14; share counts and closing prices from the exchange snapshot that day
38 columns — market capitalisation, equity (total and controlling-interest), net profit (total and controlling-interest), net cash, P/B on both equity bases, P/E, listed share count vs. the count printed in the annual report, treasury shares, cancellation history, dividend per share, sector, and two receipt-number columns.
Access — the sortable table and the per-company pages are free and ungated, and the JSON the table loads is a plain static file. The CSV sits behind an email form; disclosing that rather than pretending otherwise. Nothing is paid.
Source: https://accidentalorder.com/en/data/adjusted-valuation/ — methodology at /en/data/methodology/
The part that may actually be useful here: an XBRL aggregation trap
I nearly shipped 29 wrong rows last week, and the failure mode seems general enough to be worth writing down.
I define total borrowings as the sum of every leaf line on the balance sheet whose account name contains “borrowing” or “bond”, excluding leases. Name matching, not account-code mapping — because mapping the four component accounts (short-term borrowings, current portion of long-term debt, long-term borrowings, bonds) breaks on real filings in at least six distinct ways: single aggregate lines, missing standard codes, mezzanine instruments as separate accounts, parenthetical annotations in the account name, and genuine zeros. Name matching survives all six.
It does not survive a company that splits the balance sheet only into financial and non-financial liabilities. Those companies keep their borrowings inside captions like “current financial liabilities” — no account name contains “borrowing”, none contains “bond”, and the scan returns zero.
Korea Electric Power came out of my pipeline with zero borrowings. It carries about KRW 150tn of them.
Two things I’d tell my past self:
1. A completeness check that can’t fire on a zero isn’t a completeness check. Mine was “total borrowings must not exceed total liabilities” — an upper bound, when the failure mode was at the lower one. Zero passes trivially. Ask what your guard does when the input is empty, not when it’s wrong.
2. Name-based extraction from XBRL fails silently, not loudly. The tagging is a floor, not a ceiling: a filer can satisfy every requirement while presenting liabilities at a level of aggregation that makes your derived figure uncomputable from that filing. You get a plausible number back, not an error.
The fix I landed on wasn’t to compute the missing number but to bound it. Collect every financial-liability line on the balance sheet — derivative captions, “other” captions, everything, making no judgement about what any of them contains — and ask: if all of them were borrowings, how far could the published ratio move?
If it could move net cash / market cap by ≥1 percentage point, don’t publish net cash. Blank cell, flag on the row. If <1pp, publish.
The threshold is denominated in the units of the number I publish, not the units of the thing I’m uncertain about. My first three attempts were all “aggregate financial liabilities as a share of total liabilities > X%” for X in {5, 1, 0} — three arbitrary constants, none of which answers the question that matters, which isn’t “how big is this caption” but “how far can it move what I’m claiming”.
Cost: net cash went from 182 published rows to 97. Positive-net-cash companies from 80 to 51. Companies I’d described as carrying no borrowings at all, from 32 to 15 — 18 of that original 32 were actually sitting on material aggregate financial liabilities, which would have been the most quotable and most wrong line in the writeup.
Benefit: across the 97 that survive, the worst-case bound is 0.951pp, median 0.004pp. So the guarantee needs no footnote — every published figure holds to within one point even if every aggregate caption turned out to be borrowings.
86 of 183 rows now have an empty net-cash cell. That isn’t a gap I’m apologising for; it’s the disclosure regime reported accurately. The alternative to a blank cell is the same blank filled with an assumption and presented as if it were read off a filing.
Happy to go into DART API specifics if anyone’s pulling from it — it’s under-documented and I’ve hit most of its edges by now.
submitted by /u/Mean-Lavishness1515
[link] [comments]
