금융청이 운영하는 EDINET에서는 상장 기업의 재무 정보를 API를 통해 제공하여 누구나 사용할 수 있습니다. API의 출력은 XBRL (eXtensible Business Reporting Language)이라 불리는 재무 데이터의 표준 포맷입니다. 표준 사양으로 구조화되어 있기 때문에, 이를 통해 기업을 횡단하는 투자 분석이 가능할 것이라 생각하며 이 API를 사용하기 시작하지만, 이것이 생각만큼 쉽지 않습니다.

XBRL이라면 '매출액'에 대응하는 태그를 하나 지정하기만 하면 각 기업의 수치를 취득할 수 있을 것이다. 개발을 시작했을 당시에는 그렇게 생각했습니다.

하지만 실제로는 '매출액'이라는 하나의 항목을 취득하는 것만으로도, 기업별 차이를 흡수하는 처리가 필요했습니다.

참고로 EDINET API에서는 CSV 형식으로도 수치 데이터를 다운로드할 수 있습니다. 얼핏 보기에는 취급이 간편해 보이지만 사실 이것도 함정이며, 다년도, 다수 기업을 분석하는 용도로는 실용성에 견디지 못합니다. 저도 이것을 안일하게 사용했다가 결국 멀리 돌아가게 되었습니다.

EDINET의 XBRL에는 '매출액'이 하나만 존재하는 것이 아니다

XBRL은 재무 정보에 태그를 붙여 기계적으로 다룰 수 있도록 하기 위한 메커니즘입니다.

일반적인 일본 기준 재무제표에서는 매출액에 해당하는 요소로서, 예를 들어 다음과 같은 태그가 있습니다.

jppfs_cor:NetSales

한편, 유가증권보고서의 '주요 경영 지표 등의 추이'에서는 다음과 같은 별도의 태그가 사용됩니다.

jpcrp_cor:NetSalesSummaryOfBusinessResults

둘 다 화면상으로는 '매출액'으로 표시될 수 있지만, 역할은 다릅니다.

jppfs_cor는 주로 재무제표 본표의 항목입니다 -
jpcrp_cor는 유가증권보고서 등의 공시 항목입니다 -
같은 매출액이라도 연결·개별, 대상 기간, 게재 위치가 다를 가능성이 있습니다

즉, 표시명이 같다고 해서 동일한 조건으로 이용할 수 있는 데이터라고 단정할 수 없습니다.

매출액에 해당하는 과목은 기업마다 다르다

기업의 수익 규모를 나타내는 과목에는 다양한 명칭이 있습니다.

• 매출액
• 영업수익
• 영업수입
• 완성공사고
• 경상수익

EDINET 택소노미 (Taxonomy)에도 이러한 차이에 대응하는 여러 요소가 정의되어 있습니다.

실재하는 요소의 예로는 다음과 같은 것들이 있습니다.

jppfs_cor:NetSales
jppfs_cor:OperatingRevenue1
jppfs_cor:OperatingRevenue2
...

업종에 따라 사용되기 쉬운 과목에는 경향이 있습니다.

하지만 '이 업종이라면 반드시 이 태그를 사용할 것이다'라고 단정할 수는 없습니다.

같은 업종으로 분류되는 기업이라도 다음과 같은 차이가 있기 때문입니다.

• 주력 사업이 다르다
• 지주회사와 사업회사의 재무제표 구성이 다르다
• 여러 사업을 운영하고 있는 경우가 있다
• 기업 고유의 표시 과목을 사용하는 경우가 있다

업종은 태그를 찾는 실마리는 될 수 있지만, 업종만으로 채택할 값을 결정할 수는 없습니다.

하나의 기업에 여러 수익 과목이 존재한다

상장 기업 중에는 하나의 사업만 수행하는 기업도 있고, 여러 사업을 가진 기업도 있습니다.

예를 들어, 도요타 자동차는 2026년 3월기 결산에서 다음과 같이 두 가지 사업의 수익을 계상하고 있습니다.

• 상품·제품 매출수익
• 금융 사업에 따른 금융수익

이 경우, 손익계산서의 톱라인 (Top-line)이 하나의 '매출액'이 아니라, 여러 수익 과목에 의해 구성될 수 있습니다.

영업수익 합계 (IFRS)
+ 상품·제품 매출수익 (IFRS)
+ 금융 사업에 따른 금융수익 (IFRS)

하나의 태그만 취득하는 방식으로는 일부 수익만을 취득하게 될 가능성이 있습니다.

반면, 수익다운 과목을 모두 합산하면 되는 것도 아닙니다. 합계 항목과 내역 항목을 동시에 취득하여 이중 계상될 가능성이 있기 때문입니다.

같은 태그라도 원하는 매출액이 아닐 수 있다

동일한 요소 ID가 서류 내에 여러 개 존재하는 경우도 있습니다.

예를 들어 jppfs_cor:NetSales에는 다음과 같은 서로 다른 조건의 값이 포함될 가능성이 있습니다.

CurrentYearDuration
Prior1YearDuration
CurrentYearDuration_NonConsolidatedMember
...

이것들은 각각 다음과 같은 차이를 나타냅니다.

• 당기인가 전기인가
• 연결인가 개별인가
• 기업 전체인가 특정 세그먼트 (Segment)인가

필요한 것이 당기의 연결 매출액이라면, 태그뿐만 아니라 대상 기간이나 연결·개별 구분도 확인할 필요가 있습니다.

"매출액 태그를 찾는 것"과 "분석에 사용해야 할 매출액을 선택하는 것"은 별개의 처리입니다.

기업 고유의 XBRL 요소도 사용됨

EDINET 택소노미 (Taxonomy)에 기업이 표시하고자 하는 계정이 존재하지 않을 경우, 제출 기업은 고유의 요소를 정의할 수 있습니다.

개념적으로는 다음과 같은 요소입니다.

company_namespace:RevenueFromSpecificBusiness

실제 명칭은 기업마다 다릅니다.

이 때문에 기지의 요소 ID를 리스트에 추가해 나가는 것만으로는 모든 기업을 커버할 수 없습니다.

또한, 요소명에 Revenue나 Sales가 포함되어 있더라도, 그것이 기업 전체의 톱라인 (Top-line)이라고 단정할 수 없습니다. 특정 사업의 수익이나 세그먼트 (Segment) 내역, 주석에 게재된 부수적인 수익인 경우도 적지 않으며, 태그의 이름만으로는 해당 수치가 재무제표 내에서 어떤 역할을 하는지 판단할 수 없습니다.

같은 기업이라도 연도에 따라 태그가 변함

기업이 채택하는 회계 기준을 변경하면, 같은 기업이라도 사용하는 요소가 바뀔 수 있습니다.

예를 들어, 일본 기준에서 IFRS로 이행한 경우입니다.

일본 기준
jppfs_cor:NetSales
IFRS
...

회계 기준을 변경하지 않더라도, 기업이 재무제표의 표시 방법이나 계정명을 변경하는 경우가 있습니다.

따라서 동일한 기업 코드의 수치를 연도순으로 나열하는 것만으로는 지속적으로 비교 가능한 데이터가 된다고 보장할 수 없습니다.

태그 후보를 열거하는 것만으로는 한계가 있음

초기에는 톱라인이 될 수 있는 요소 ID를 열거하고, 순서대로 값을 찾는 방법을 사용했습니다.

개념적으로는 다음과 같은 처리입니다.

TOPLINE_CANDIDATES = [
"jppfs_cor:NetSales",
"jppfs_cor:OperatingRevenue1",
...

이 방법으로도 많은 기업으로부터 수치를 취득할 수 있습니다.

하지만 후보를 늘려가다 보면 다른 문제가 발생합니다.

• 동일 기업에서 여러 후보가 발견됨
• 기업 고유의 요소를 포착할 수 없음
• 톱라인이 아닌 내역을 취득해 버림
• 복수 사업을 가진 기업에서는 일부 수익만 취득할 수 있음
• 새로운 계정이 발견될 때마다 개수가 필요함
• 취득률을 높일수록 오판정도 늘어남

요소 ID를 지식으로서 계속 추가하기만 해서는 예외 처리가 끝없이 늘어납니다.

요소명이 아니라, 재무제표의 구조로부터 찾기

ToramiStock에서는 이용 가능한 경우 XBRL의 계산 링크 (Calculation Link)를 참조합니다.

Calculation Link에는 손익계산서의 항목들끼리 어떤 가감산 관계에 있는지가 기록되어 있습니다.

예를 들어, 영업이익이 수익과 비용으로부터 어떻게 구성되어 있는지를 추적함으로써, 요소명이 NetSales나 Revenue가 아닌 기업 고유 요소에 대해서도 톱라인 후보로서 검출할 수 있습니다.

중요한 것은 업종명이나 요소명만으로 결정하지 않는 것입니다.

같은 업종이라도 기업에 따라 표시 방법이 다릅니다. 하나의 기업이 여러 사업을 영위하며 여러 수익 계정을 사용하는 경우도 있습니다.

재무제표의 구조를 봄으로써, 고정적인 태그 목록만으로는 포착할 수 없는 기업 고유의 표현에도 대응하기 쉬워집니다.

Calculation Link만으로는 「매출액」을 확정할 수 없음

단, Calculation Link는 계정의 의미를 설명하는 사전이 아닙니다.

알 수 있는 것은 항목 간의 계산 관계입니다.

예를 들어, 영업이익 계산에 다음 두 가지 수익이 포함되어 있는 경우가 있습니다.

영업이익
├─ + 본업의 수익
├─ + 기타 수익
...

이 구조를 통해서는 두 수익이 모두 영업이익 계산에 포함되어 있다는 사실은 알 수 있습니다.

반면, 어느 쪽이 기업의 주된 사업에서 발생한 톱라인이고, 어느 쪽이 부수적인 수익인지는 계산 관계만으로는 판단할 수 없습니다.

양쪽을 합산하면 영업이익까지의 계산은 일치하더라도, 투자 분석에서 일반적으로 사용되는 「매출액」이나 「매출 수익」으로서 적절하다고 단정할 수 없습니다.

특히 IFRS에서는 Revenue와 Other income 같은 여러 양(+)의 수익 항목이 영업이익을 구성하는 항목으로서 나열되는 경우가 있습니다.

요소명을 보면 Revenue를 선택할 수 있을 것처럼 보입니다. 하지만 기업 고유 요소나 서로 다른 표시 형식까지 포함하면, 명칭에만 의존한 판정은 새로운 오류를 낳게 됩니다.

따라서 ToramiStock에서는 구조만으로 일의적으로 결정할 수 없는 경우, 무리하게 추측하지 않고 다른 취득 방법으로 폴백 (Fallback) 합니다.

여러 취득 방법을 조합하기

Calculation Link만으로 모든 기업을 처리할 수는 없습니다.

ToramiStock에서는 대체로 다음과 같은 정보를 조합하여 탑라인 (Top-line) 을 정리하고 있습니다.

• Calculation Link에서 읽어낼 수 있는 재무제표의 구조
• 「주요 경영 지표 등의 추이」에 게재된 수치
• 기지 (Known)의 표준 요소
• 기업 고유 요소
• 대상 기간
• 연결·개별 구분

Calculation Link에서 취득할 수 있는 경우에는 그 구조를 이용합니다.

구조만으로 일의적으로 취득할 수 없는 경우에는 주요 경영 지표나 기지의 요소 ID로부터 취득한 값을 이용합니다.

하나의 방법만으로 모든 기업을 처리하려 하지 않고, 취득할 수 없는 케이스나 판단할 수 없는 케이스를 남겨두면서 여러 방법을 조합하고 있습니다.

EDINET에서 값을 가져오는 것과 비교 가능한 데이터를 만드는 것은 다르다

XBRL 파일을 읽어 들여 특정 태그 (Tag)의 값을 취득하는 단계까지는 그리 어렵지 않습니다.

어려운 것은 기업이나 연도에 따라 다른 표현을 동일한 지표로서 비교할 수 있는 상태로 만드는 것입니다.

• 업종에 따라 과목이 다름
• 동일 업종이라도 기업에 따라 다른 경우가 있음
• 하나의 기업이 여러 사업을 보유하는 경우가 있음
• 기업 고유 요소가 사용됨
• 회계 기준이나 표시 방법이 변함
• 동일한 요소가 본표, 주석, 세그먼트에서 사용됨
• 하나의 계산 구조에 여러 수익이 포함되는 경우가 있음

즉, EDINET XBRL에서 「매출액」을 취득하는 처리는 단순한 태그 검색이 아닙니다.

기업마다 다른 재무제표를 읽어 들여, 비교 가능한 공통 항목으로 변환하는 처리입니다.

투자 도구를 만들고 싶은데, XBRL의 예외 처리가 끝나지 않는다

AI의 발전과 침투로 직접 분석 도구 개발에 도전하시는 분들도 늘어나지 않았을까 합니다. 실제로 단순하게 1개 기업의 데이터를 읽어 들이는 정도라면 비교적 빠르게 구현할 수 있습니다.

하지만 기업 횡단적으로 이용할 수 있는 재무 데이터를 만들려고 하면, 매출액을 명寄せ (Name matching) 하는 것만으로도 기업별 고유 요소, 회계 기준의 이해, Calculation Link만으로는 판단할 수 없는 수익, 다양한 에지 케이스 (Edge case) 등 다양한 문제에 대한 대응이 필요하다는 것을 보아왔습니다. 회계라는 도메인이 치밀하고 폭넓은 만큼, 이를 표현하는 XBRL도 복잡하고 강력한 사양으로 되어 있음을 실감할 수 있었습니다.

나아가 모든 기업, 장기간의 데이터, 최신 데이터를 정기적으로 가져오려고 하면 더욱 폭넓은 에지 케이스 대응이나 인프라 구축이 필요하게 됩니다.

AI의 힘으로 코딩은 거의 불필요해졌지만, 사양 결정, 지시, 문제 해결에는 회계 도메인 지식, XBRL 사양 이해, 인프라 구축 등 여전히 코딩 이외의 과제, 그리고 토큰 비용 (Token cost) 이 병목 현상이 됩니다.

결과적으로 처음에는 투자 분석 화면이나 스크리닝 기능을 만들 생각이었는데, 어느샌가 XBRL 태그 조사나 예외 처리에 대부분의 시간을 쓰게 됩니다.

투자 도구를 직접 제작할 경우, 화면이나 분석 로직보다 그 전 단계에 있는 데이터 수집과 정규화가 큰 벽이 됩니다.

이 전처리를 ToramiStock으로서 공개하고 있습니다

이러한 EDINET XBRL의 수집, 구조 해석, 명寄せ (Name matching), 정규화를 지속해 온 메커니즘을 ToramiStock으로서 공개했습니다.

기업 분석이나 투자 도구를 만들고 싶은 사람이 XBRL의 예외 처리에 시간을 쓰는 대신, 분석 방법이나 애플리케이션 개발에 집중할 수 있는 데이터 기반을 목표로 하고 있습니다.

Web UI에서는 기업 정보나 재무 추이, IR 정보 등을 확인할 수 있습니다.

MCP를 통해 AI로부터 재무 데이터를 가져오거나, SQL을 통한 스크리닝 결과를 분석할 수도 있습니다.

EDINET의 XBRL을 직접 다루려다 매출액 취득이나 기업 간 명寄せ (Name matching) 단계에서 막혔다면, ToramiStock의 데이터를 이용하는 방법도 있습니다.

Discussion