정기보고서 시즌마다 공시팀과 회계팀 사이에서 반복되는 질문이 있습니다.
"XBRL 주석 작성은 공시팀이 해야 할까, 회계팀이 해야 할까?"
XBRL 업무분장 논쟁은 겉으로는 "공시팀 일이냐, 회계팀 일이냐"의 문제처럼 보입니다. 하지만 실제로는 업무 자체가 어렵고, 실수했을 때 리스크가 크며, 책임 경계까지 흐릿하기 때문에 생기는 문제에 가깝습니다.
이 글에서는 XBRL 주석 작성이 왜 업무분장 갈등으로 번지는지, 공식 자료로 볼 때 XBRL 업무가 어떤 성격의 일인지, R&R 재정의만으로는 왜 풀리지 않는지, 그리고 업무 난이도를 어떻게 낮출 수 있는지까지 정리했습니다.
읽기에 앞서 XBRL 업무 자체가 무엇인지 궁금하다면 XBRL 초보 담당자를 위한 A to Z 가이드(2026년 최신판)을 먼저 읽어 보세요.
XBRL, 공시팀 vs 회계팀 중 누가 해야 할까?
XBRL 주석 작성은 단순히 DART 편집기에 값을 넣는 행정 업무가 아닙니다. 재무제표 본문과 주석을 이해하고, 계정과목과 주석 항목을 연결하며, 숫자와 태그가 올바르게 매핑됐는지 확인해야 하는 재무보고 업무에 가깝습니다.
이 점은 한국상장회사협의회의 「XBRL 주석 재무공시 적용예정기업의 준비 및 점검사항」에서도 확인할 수 있습니다.
… XBRL 주석 재무공시의 경우 회계적인 지식과 기업의 주석사항에 대한 충분한 이해가 필요합니다. 이와 관련하여 금융감독원은 상장회사협의회 실무교육 시 회계부서가 XBRL 재무공시 업무를 담당할 것을 권고하였습니다. 다만, 사업보고서 공식파일과 실제 공시 프로세스는 공시부서에서 담당하고 있을 것이므로 공시부서와 회계부서 간의 유기적인 협력을 강조하였으며, …
핵심은 두 가지입니다.
금감원이 회계부서를 XBRL 재무공시 업무 담당으로 권고했다는 점,
동시에 공시부서와의 유기적인 협력을 강조했다는 점입니다.
따라서 XBRL 주석 작성의 경우 회계팀이 주석 내용과 회계 판단을 검토하고, 공시팀이 DART 제출 프로세스에 맞게 제출하고 관리하는 업무를 하는 게 안전합니다.
그렇다면 "회계팀이 주도하고 공시팀이 제출 프로세스를 관리한다"는 원칙만 세우면 문제가 끝날까요? 실무에서는 여기서 한 번 더 막힙니다.
업무분장 정리해도 해결되지 않는 이유
이유는 단순합니다. XBRL 업무 자체의 난이도가 너무 높기 때문입니다.
XBRL 주석 작성은 단순히 태그 몇 개를 붙이는 일이 아닙니다. XBRL 편집기 안에서 주석별로 표를 만들고, 각 항목을 구조에 맞게 입력하고, 숫자마다 적절한 태그를 붙이고, 검증 오류까지 잡아야 합니다. 이 과정에는 회계 판단이 필요할 뿐만 아니라, 매우 많은 단순 반복 작업을 해야 합니다.
심지어 XBRL 편집기 자체가 직관적이지 않아, 생각한 대로 표를 만들고 태깅하는 작업이 예상 시간의 2~3배는 걸리는 일도 흔합니다. 중간, 중간 수정 사항을 반영해야 하는 데다, 마지막에 DSD 파일과의 대사까지 필요하죠.
그래서 업무분장을 정리해도, 보고서 시즌이 되면 불만이 터져 나오고 병목이 생기며, 다시 한 번 갈등이 생기는 겁니다.
그런데 이런 갈등이 반복되면 스트레스를 받는 것에 그치지 않습니다. 실제로 회사가 떠안는 리스크마저 커집니다.
정정공시 리스크: 태깅 오류가 형식 오류를 넘어 데이터 오류로 이어질 수 있습니다.
감사인 지적 증가: 본문과 태깅 값이 다르면 추가 확인과 수정 요청이 반복됩니다.
담당자 의존성: 다트 편집기와 XBRL 편집기 사용·매핑 노하우가 한 사람에게만 쌓여 인수인계하기 어려워집니다.
마감 직전 병목: 수십 개 표 작성과 검증 오류 수정이 제출 직전에 몰립니다.
임원 설명 불가: "왜 숫자 입력인데 이렇게 오래 걸리는지" 윗선이 이해하지 못합니다.
따라서 업무분장만 다시 그어서는 문제가 풀리지 않습니다. 진짜 해결책은 XBRL 업무의 난이도 자체를 낮추는 일입니다.
XBRL 업무 난이도를 낮추는 방법 3가지
핵심은 반복되는 검토 부담을 줄이고, 회계팀과 공시팀이 같은 기준으로 판단할 수 있는 흐름을 만드는 일입니다.
① 변환·검증·이력을 한 도구 안에서
전자공시용 DSD 파일 작성부터 XBRL 변환, 검증, 제출까지 한 흐름으로 묶여야 회계팀과 공시팀이 같은 화면을 보고 판단할 수 있습니다.
② 변경 이력을 사람이 아니라 시스템이 기억
"이번 수정이 어느 버전에 반영됐는지"를 사람이 일일이 추적하면, 실수가 반복되고 작업량은 늘어납니다.
③ 반복 검증은 자동화로
숫자 정합성, 태깅 누락 등 자동화가 가능한 영역은 수작업에 맡기지 않아야 합니다. 사람은 회계 판단에만 시간을 쓰는 구조가 되어야 다음 분기에 같은 다툼이 줄어듭니다.
문제는 다트 편집기나 XBRL 편집기만으로는 이 세 가지를 동시에 챙기기 어렵다는 점이에요. 세 흐름을 한 도구 안에서 묶어주는 방식이 필요할 텐데요. 그런 솔루션이 있습니다. 바로 인벡터예요.
인벡터를 쓰면 ‘누가 할지’ 다투지 않아도 됩니다
인벡터는 DSD 작성·XBRL 변환·검증을 하나의 흐름으로 연결해 보고서 업무의 난이도를 낮추는 솔루션입니다.
회계팀은 회계 판단에만 집중하고, 공시팀은 공시를 누락 없이 제출하는 데만 집중하면 됩니다. 그 사이에서 반복되는 숫자 비교, 태깅, 누락 확인, 변경 이력 추적 등은 모두 인벡터가 대신 해드립니다.
소트프웨어를 쓰는 것도 만만치 않다고 생각하시나요? 그런 분들을 위해 인벡터는 사용 전 교육을 진행하고 있으며, XBRL 컨설팅과 최종본 IXD 파일 제작까지 도와드리고 있습니다. 인벡터는 공시 역량이 회사 내부에 차곡차곡 쌓일 수 있도록 도와드리고 있으니, 의존에 대한 걱정도 덜으셔도 됩니다. 왜 회사 내부에 역량이 쌓여야 하는지 궁금하다면 이 글을 읽어 보세요.
결국 XBRL 업무분장 갈등은 업무가 어렵고 파일이 흩어져 있다 보니 생기는 문제입니다. 업무분장을 나누는 것으로 해결할 게 아닌, 두 팀이 유기적으로 협력할 수 있는 시스템을 회사 내부에 만드는 게 해결책입니다.
매 분기 같은 갈등, 같은 병목을 겪고 있다면 인벡터에 문의해 보세요. 보고서 업무가 한결 수월해질 거예요.