XBRL 주석 화면을 띄워두고 "이건 블록태깅인가, 디테일태깅인가" 망설이신 적 있으신가요?
판단이 흔들리는 건 담당자 역량 문제가 아닙니다. XBRL가 원래 좀 어려운 작업이거든요. XBRL 주석공시 첫 시즌, XBRL을 제출한 상장사 498곳 중 61곳(12.2%)이 주석 작성 오류로 정정 요청을 받았을 정도로요. 블록태깅과 디테일태깅이 헷갈리는 분들을 위해 개념부터 사례, 기준까지 정리했습니다.
블록태깅(Block Tagging)과
디테일태깅(Detail Tagging)이란?
먼저 두 방식의 차이를 짚고 갈게요.
블록태깅(Block Tagging): 긴 서술형 문장이나 단순 표를 하나의 덩어리로 묶어서 태깅하는 방식
디테일태깅(Detail Tagging): 각 계정과목·금액·날짜·주석 내용을 세부 항목(Line Items)·차원(Axis)·멤버(Member) 단위로 쪼개어 표준 택사노미(Taxonomy)에 1:1로 매핑하는 방식
XBRL 주석은 디테일태깅이 기본 원칙입니다. 다만 세부 공시정보 추출 필요성이 낮은 영역은 작성 효율을 위해 블록태깅으로 처리할 수 있어요.
구분 | 블록태깅 | 디테일태깅 |
|---|---|---|
작성 부담 | 낮음 | 높음 |
데이터 활용성 | 낮음 | 높음 |
오류 가능성 | 상대적으로 낮음 | 매핑·기간·차원 오류 가능 |
검토 포인트 | 목차·영역 적정성 | 태그, 기간, 차원, 금액 정합성 |
적합한 주석 | 설명형 주석 | 표·수치·비교형 주석 |
결국 두 방식의 차이는 "쉬운 방식 vs 어려운 방식"이 아닙니다. 이 정보가 데이터로 활용되느냐 vs 마냐의 문제예요. 판단 기준 없이 작업하면 정정공시로 이어질 수 있습니다.
자산 규모별 디테일태깅 적용 시기
디테일태깅은 작업 부담이 큰 만큼, 자산 규모에 따라 단계적으로 적용됩니다. 본인 회사가 어느 그룹에 속하는지부터 짚고 가세요.
비금융업 상장사
자산 규모 | 기업 수 | 첫 XBRL 주석 제출 시기 |
|---|---|---|
2,000억 이상 5,000억 미만 | 약 550곳 | 2026년 3월 |
1,000억 이상 2,000억 미만 | 약 500곳 | 2027년 3월 |
1,000억 미만 | 약 750곳 | 2028년 3월 |
금융업 상장사
자산 규모 | 기업 수 | 첫 XBRL 주석 제출 시기 |
|---|---|---|
10조 원 이상 | 약 30곳 | 2025년 8월 |
2조 원 이상 10조 원 미만 | 약 30곳 | 2026년 8월 |
2조 원 미만 | 약 80곳 | 2027년 8월 |
디테일태깅 검토가 필요한 주석
표를 옮기는 작업이 아니라, 각 셀을 분석 가능한 데이터로 바꾸는 작업이라고 생각하면 됩니다.
판단 기준
표 안의 각 숫자가 독립적으로 의미 있는가
당기/전기, 기초/증가/감소/기말 같은 분석 구조가 있는가
계정과목별·거래상대방별·기간별 비교가 가능한 데이터인가
감사인이나 내부 검토자가 근거를 확인할 가능성이 높은가
대표적인 항목
유형자산 변동내역, 무형자산 변동내역, 매출 구성, 금융상품 공정가치, 차입금 만기 구조, 특수관계자 거래내역, 우발부채 및 약정사항, 법인세, 충당부채, 리스 관련 표
블록태깅을 검토할 수 있는 주석
읽는 사람이 문장 전체를 이해하는 것이 핵심이고, 개별 금액이나 비율을 따로 추출할 필요가 낮은 영역이에요. 참고로 문장형이라고 무조건 블록태깅을 해야 하는 건 아닙니다. 문장 안에 금액, 만기, 거래상대방, 손실추정액 등이 들어 있으면 디테일태깅 검토 대상이에요.
판단 기준
읽는 사람이 문장 전체를 이해하는 것이 핵심인가
개별 금액이나 비율을 따로 추출할 필요가 낮은가
기간별 비교 표가 없거나 단순 서술 중심인가
대표적인 항목
회사의 개요, 재무제표 작성 기준, 중요한 회계정책 설명, 기준서 최초 적용 설명, 단순한 회계추정 변경 설명, 정성적 위험관리 정책 설명
디테일태깅 vs. 블록태깅, 헷갈리는 사례
표 앞에서 망설이게 되는 순간들을 모아봤어요. 다음 시즌에 헷갈리지 않도록 정리해두세요.
1. 표가 있지만 단순 목록인 경우
특수관계자 명단을 표로 정리했는데 회사명·국가·관계 구분만 들어 있고 거래금액이나 지분율이 없는 경우라면, 블록태깅으로 처리해도 됩니다. 표의 행이 '분류 축'이 아니라 단순 식별 정보거든요. 누군가 나중에 "B사와의 거래금액 시계열"을 뽑을 일이 없다면, 셀 단위로 쪼갤 이유가 없습니다.
다만 지분율, 거래금액, 채권채무 잔액이 한 줄이라도 들어가면 디테일태깅을 적용해야 합니다. 작년에 블록으로 처리했더라도 올해 데이터가 추가됐다면 다시 고민해 보세요.
2. 문장형인데 금액이 들어간 경우
"회사는 A사와 관련하여 100억 원의 지급보증을 제공하고 있으며, 보증기간은 2027년 12월 31일까지입니다.”
이런 문장은 외형만 서술형이지, 안에 들어 있는 정보(보증 상대방, 금액, 만기일)는 모두 독립적으로 추출·비교될 자산입니다. 따라서 디테일태깅 대상이에요.
문장형이라는 외형 때문에 통째로 블록으로 묶어버리는 실수가 가장 자주 나오는데요. 우발부채·특수관계자 거래·약정사항 문장을 만나면, 일단 "이 문장 안에서 Line Item을 분리할 수 있는가"부터 보세요.
Line Items이 궁금하다면 이 글을, XBRL 표의 ‘열’이 되는 Axis, Member가 궁금하다면 이 글을 참고해 보세요.
3. 전기 정보가 함께 표시된 경우
유형자산 변동내역을 당기·전기로 보여주는 표라면 디테일태깅 + 기간축 분리가 필수입니다. 당기/전기는 가장 기본적인 비교 축이라, 기간 차원이 분리되지 않으면 XBRL 데이터로서 가치가 거의 사라져요.
이 경우의 함정은 판정 자체가 아니라 매핑에 있습니다. 디테일태깅은 했는데 기간(Period) 차원 부여를 빠뜨리거나 당기 셀에 전기 기간이 들어가는 매핑 오류가 대표적이거든요. 검증 단계에서 "기간 차원이 빠진 셀이 있는지"만 따로 한 번 더 돌려보세요.
디테일태깅의 한계, 이렇게 풀어 보세요
앞서 세 가지 사례를 살펴봤지만, 결국 모두 같은 작업의 반복이에요. 표 한 장, 문장 한 줄을 두고 "이 항목이 데이터로서 가치가 있는가"를 판단하는 일이죠. 주석이 1~2개라면 충분히 할 만한 작업이지만, 수십 개 주석을 매번 셀 단위로 검토하기는 현실적이지 않습니다.
이런 막막함을 줄이고 싶다면, 인벡터를 한 번 살펴보세요. 인벡터는 공시 담당자가 XBRL 기준에 맞는 태깅을 빠르고 정확하게 할 수 있도록 돕는 소프트웨어와 컨설팅을 함께 제공합니다.
AI 추천 태깅
항목마다 AI가 주석 구조를 분석해 적합한 택사노미를 제안합니다.
DSD ↔ IXD 대사
DSD 파일과 XBRL 제출 파일인 IXD 파일의 숫자를 자동으로 대조합니다. 두 파일의 숫자가 일치하는지 사람 눈으로 일일이 비교하지 않아도 돼요.
매년 같은 항목에서 멈칫하고, 동종업계 사례를 따라 쓰면서도 불안한 마음으로 제출하고 있다면 인벡터에 문의해 주세요. DSD 파일을 바탕으로 XBRL 기준을 수립하고 데이터를 설계해, 담당자가 작업할 수 있는 기반을 만들어 드립니다.