[금융권 XBRL①]외부제출 XBRL보고서의 체계적인 관리

출처] http://www.ciobiz.co.kr/news/articleView.html?idxno=5238

[금융권 XBRL①]외부제출 XBRL보고서의 체계적인 관리

보고서 작성 담당자가 직접 데이터 처리시 '휴먼리스크' 존재

2011년 05월 02일 (월) 10:47:10 이태훈 코오롱베니트 책임 컨설턴트 xbrl@kolon.com

<script type="text/javascript">< /script> <script language="javascript"> </script> 금융권 확장성재무보고언어(XBRL) 기반 시스템 도입과 관련해 종종 착각을 일으키는 사실이 있다. △이미 제출된 보고서는 다시 볼 수 없고 △국제회계기준(IFRS), 기존 회계기준(KGAAP)의 New, New(1)로 표시된 계정은 정상적인 것이며 △XBRL 보고서 생성 기능은 ERP 시스템에만 있다는 것이다. 진실은 △외부 제출 보고서는 리스크 관리 측면에서 체계적인 관리가 필요하며 △기업은 IFRS 공시(XBRL) 제출 시 글로벌 투자자를 고려하여 계정관리를 해야 하고 △XBRL 보고서는 ERP뿐 아니라 전문 솔루션을 통해 감독기관의 데이터 실시간 추출(Interactive Filing)을 지원할 수 있다는 것이다. 이 세 가지를 하나씩 짚어보자. ◇데이터 수집, 보고서 작성과 전송 시 리스크=일반적인 기업의 최고정보책임자(CIO)는 조직의 경영과 전략적 관점의 정보기술 및 정보시스템을 총괄 관리하는 기존 업무 외에 금융감독기관 등 회사 외부로 제출되는 정보의 리스크 관리 업무도 병행하고 있다. 기업들은 이처럼 리스크가 포함돼 있는 보고서를 어떻게 관리하고 있을까. 기업이 3년간 외부 기관에 제출한 컴플라이언스 보고서를 기반으로 GRC(Governance·Risk management·Compliance) 시스템 또는 데이터마트를 구축한다고 가정해 보자. 이 경우 기업 외부로 제출된 모든 보고서들을 확보하는 것은 결코 쉬운 일이 아닐 것이다. 기업의 대외 보고서 관리 능력 편차 때문에 느끼게 되는 상대적인 어려움도 있겠지만, 외부 제출 보고서의 프로세스 문제도 큰 원인으로 꼽을 수 있다. 외부에 제출되는 보고서 프로세스는 기업의 규모와 성격에 따라 천차만별이다. 그럼에도 불구하고 큰 맥락에서 보면 데이터 수집, 데이터 생성, 보고서 작성, 보고서 전송 등으로 단계를 분류할 수 있다. 이 과정에서 리스크가 발생하는 상황은 다음과 같이 몇 가지로 압축해 볼 수 있다. ①데이터 수집 및 데이터 생성 리스크:보고서 작성자가 데이터 취합 및 가공을 직접 할 경우. 모 외국계 은행의 보고서 작성 담당자는 보고서를 제출하기 위해 관련 시스템에서 자료를 수집하고 수집된 자료를 엑셀로 편집해서 보고서 데이터를 만든다고 한다. 이 과정에서 휴먼 리스크가 발생할 수 있다. 작성자가 데이터를 편집하기 때문인데, 데이터를 편집하는 이유는 내부 시스템 데이터를 글로벌 표준으로 관리하기 때문에 제출하려는 보고서의 데이터로 정확하게 가져올 수 없다. 이런 이는 특수한 외국계 기업의 경우만 해당되는 것은 아니다. 일반적인 기업들도 제출해야 하는 보고서가 많고 다수의 감독기관이 요청하는 서식이 다르기 때문이다. 한 외국계 은행 담당자는 외부에 제출해야 하는 보고서 작성을 위해 시스템에서 직접 데이터를 조회하고 확보한 자료를 엑셀 포맷으로 제출하기 위해 데이터로 계산한다. 데이터를 계산하는 이유는 내부 시스템에서 제공하는 데이터와 외부 감독기관에서 제시하는 보고서 데이터 계정, 단위 등이 다르기 때문이다. 외국계 은행의 경우 내부 시스템의 데이터는 글로벌 표준으로 관리하기 때문에 국내 감독기관의 데이터에 시스템을 맞출 수 없다. 이 문제는 외국계 기업뿐이 아니라 국내 기업도 유사하다. 금융 기업의 경우 감독기관마다 제출해야 하는 보고서가 다르고, 유사한 보고서도 제출 시기와 항목이 다르기 때문이다. ②보고서 작성 리스크:대량의 보고서를 작성자가 직접 입력할 경우. 기업이 제출하는 보고서는 기업에게 제출 의무가 부여되는 공시보고서(Disclosure)와 감독기관이 규제를 목적으로 제출 요청을 받는 업무보고서(Call Report)로 크게 구분할 수 있다. 공시보고서는 작성 담당자가 보고서 프로그램을 설치해 개별 컴퓨터에서 리포트를 만들게 된다. 제출 담당자는 이 같이 작성된 파일을 취합해 전송기를 통해 전달하거나 제출 사이트에서 개발한 프로그램을 통해 웹 서비스로 보고서를 전송하는 방식이 사용되고 있다. 위 경우 모두 데이터는 작성 담당자가 직접 입력하고 전송된 데이터는 개인 컴퓨터에 저장되거나 외부로 전송된다. 업무보고서의 경우도 유사한 절차로 처리되고 있다. 최근에 업무보고서는 서버 방식으로 변경되어 PC에 저장되는 보고서는 사라지게 될 것으로 전망된다. 이렇게 보고서를 직접 입력하는 방식은 사람이 입력하는 과정에서 발생하는 데이터 오류 또는 취합하는 과정에 버전 오류 등이 발생하게 된다. 이런 경우 정정보고를 통해 데이터를 수정하지만, 기업은 이미 잘못된 데이터를 외부에 공개된 이 후 수정하게 된다. 예를 들어 일반 기업인 경우 사업보고서의 재무제표는 감사보고서의 재무제표를 이용하여 제출하지만 상장기업은 XBRL 기반의 재무제표를 별도로 작성하게 된다. 이 과정에서 계정에 대한 선택 및 입력은 작성자가 직접 하므로 감사인이 제출한 감사보고서의 재무제표와 차이가 발생하게 된다. ③보고서 전송의 리스크:제출하는 시점에 따라 다른 정보가 공개되는 경우. 기업의 중요한 평가 기준인 재무정보만 넣고 보면, 금융기업인 경우 감사가 완료되기 이전에 업무보고서를 감독기관에 제출하게 된다. 그 후 감사가 완료되면 회계법인을 통해 감사보고서가 공시되고 기업은 사업보고서를 통해 공시를 하게 된다. 이 과정에서 업무보고서의 데이터가 변경되었을 경우 데이터 정정 보고를 하게 된다. 정정보고는 기업에 따라 다수의 감독기관에 제출된다. 저축은행의 경우 저축은행중앙회, 금융감독원, 예금보험공사 등 여러 감독기관에 대해 보고서를 정정해야 하는 경우도 발생하게 된다. 각각의 감독기관에 전송되는 데이터의 정보도 최종 조회 사이트에서 최종 확인해야 한다. 예를 들어 저축은행의 경영공시 내용에는 2010년 12월말 정보가 공개되어 있지만, 감독기관의 경영정보 조회 시스템에는 조회되지 않는 경우도 있다. ◇외부제출 보고서 관리 능력이 위험도 좌우=외부 제출 보고서는 기업의 이미지다. 개인 투자자들이 기업 분석시 처음 접하게 되는 것이 기업이 제출한 공시보고서이다. 잘못된 공시로 인해 ‘공시번복으로 불성실공시법인’으로 지정된 기업은 투자자들에게 좋은 이미지를 주지 못한다. 기업의 CIO는 외부 제출 보고서의 생성 프로세스를 체계적으로 관리해야 한다. 데이터 취합, 보고서 생성, 제출 프로세스 관리, 제출 원본 관리, 전송 데이터 관리까지 전략적으로 시스템화 하거나 절차를 개선해야 한다. 국내 증권사들도 대량의 데이터를 공시해야 하는 주식워런트증권(ELW) 관련 공시의 경우 시스템을 도입하여 생성 절차를 생성하고 있다. 내부 관리 데이터를 이용하여 공시를 자동 생성하고 제출하는 솔루션이다. 프로세스의 개선은 감독기관들로부터 진행되고 있는 부분도 있다. 미국의 증권거래위원회(SEC)의 경우 XBRL을 기반으로 실시간 추출하여 데이터 수집 비용을 줄였고, 유럽은행감독위원회(CEBS)는 CoRep, FinRep 등 XBRL 보고서를 준비하여 제출 및 유통의 프로세스를 개선하고 있다. 글로벌 기업에게 이는 XBRL 기반의 제출 프로세스를 정비해야 하는 이유가 된다.