XBRL 오류 사례 분석｜딜로**·삼* 용역
안녕하세요, 인벡터 팀입니다.
이번 글에서는 실제 공시된 XBRL 파일을 기반으로 실제 오류 사례를 분석했습니다.
검토 자료는 모두 reference-xbrl.invector.co에서 직접 확인할 수 있습니다.
본 분석은 특정 기업·회계법인을 비판하기 위한 목적이 아니라,
상장사 XBRL 작성에서 반복 발생하는 구조적 오류를 객관적으로 공개함으로써
향후 발생 가능한 정정공시 리스크를 예방하기 위한 공익적 목적입니다.
1. 분석 배경
해당 4곳의 회사는 딜로** ,삼*에게서 XBRL 용역을 받고 공시를 했습니다.
표준 택사노미로 충분한데 확장(Extension)을 사용한 오류
HD 계열사 XBRL 작성본(안진·삼일 용역)에서 반복적으로 확인된 핵심 문제 중 하나는 표준 택사노미로 표현 가능한 항목을 불필요하게 확장 태그로 생성해 사용한 사례입니다.
이 문제는 단순한 비효율이 아니라,
금감원 검증·동일성 매칭·동종업계 비교 기능에도 직접적인 영향을 줍니다.
표준 표 구조 무시 + 열 태그 오태깅(라인아이템 남용)
이번 HD 계열사 XBRL 파일(안진·삼일 용역)에서는 원래 표준 택사노미의 표(Table)·열(Column) 구조로 태깅해야 하는 주석 표를, 전부 라인아이템(LineItem)으로 처리하고 별도 확장 표(Extension Table)를 만들어 공시한 사례가 확인 되었습니다.
반복되는 오류가 정정공시로 이어지는 구조적 이유
상기 이미지에서 지적한 오류들은 모두 금감원 검증 단계에서 직접 적발되는 유형입니다. 특히 위에 유형들은 정정공시 사유로 가장 자주 등장합니다.
문제는 이런 오류 상당수가 사람(수습·주니어 인력)의 수작업 과정에서 발생한다는 점입니다. Big4/중견 회계법인이 XBRL 업무를 내부적으로 자동화한다고 해도, 실제 태깅·검토는 인력 의존입니다. 이 때문에 동일 유형의 실수가 매 분기 반복되고 있습니다.
왜 회계법인 기반 XBRL 용역에서 오류가 반복되는가
XBRL은 대부분 수습 회계사 / 대학생 인턴 담당 업무
분기마다 인력 로테이션 → 동일 기업이라도 품질 편차 발생
내부 자동화 툴이 존재해도 “최종 태깅”은 인력 중심
즉, 구조적으로 오류를 막기 어렵고, 기업 입장에서는 매 분기 정정공시 리스크가 누적됩니다.
인벡터(XBRL 자동화)의 차이점: 동일 오류를 자동으로 검출
이번 사례들처럼 발생한 오류들은 인벡터에서는 모두 자동 검출 대상입니다.
인벡터 자동화로 검출 가능한 항목
표준 태그 매칭 누락 → 자동 경고
DSD 구조 비교 → 불일치 즉시 표시
주석·본문 수치대사 → 수치 불일치 자동 검출
Negated 처리 오류 → 변환 시점에서 바로 검증
누락 태그, 중복 태그 → 에디터에서 즉시 로그 생성
타 기업 대비 비정상적 구조 → Reference-XBRL 기반 비교
즉, 지금 첨부한 사례처럼 사람이 놓치는 오류는 우리 시스템에서는 제출 전에 100% 사전 검출됩니다.
결과적으로:
정정공시 0건 유지 가능
Big4 대비 오류 발생률을 구조적으로 낮춤
분기마다 인력 변경에 따른 품질 편차 없음
제출 파일(IXD)까지 일관된 품질 유지
결론: 회계법인은 “잘하려고 해도 구조적으로 못하는 일”, 인벡터는 “검증까지 자동화된 시스템”
상장사 XBRL의 핵심은
“누가 태그하느냐”가 아니라 “시스템이 얼마나 자동 검출하느냐”입니다.
회계법인 인력 구조상 반복되는 실수는 피하기 어렵습니다.
반면 인벡터는 제출 파일 생성까지 전 과정을 자동화해 오류를 원천 차단합니다.
따라서 이번에 정리한 오류 사례들은
기업 입장에서 “정정공시가 왜 반복되는지”를 가장 명확하게 보여주는 근거이며,
자동화 기반 XBRL 전환이 필요한 이유를 실증적으로 보여주는 데이터입니다.