XBRL... 단순한 규정 준수를 넘어선 가치

최근에 짧은 방문을 마치고 돌아온 저는 제19회 XBRL 국제 컨퍼런스 파리에 와서 보니, 많은 기관들이 핵심을 제대로 파악하지 못하고 있다는 생각이 들었습니다. 그리고 어쩌면 이는 미국 증권거래위원회(SEC)의 규제가 부분적으로 원인일 수도 있습니다. 세계 최대 경제 규모의 국가에서 XBRL 보고 의무가 발표된 후, 이 회의에는 기업의 대표들이 모여 XBRL에 대해 더 자세히 배우고, 무엇보다 중요한 부분을 익히기 위해 열성적으로 참여할 것이라고 생각했습니다 (물론, 저는 그렇게 생각했습니다) 왜요 그들은 재무 데이터를 XBRL 형식으로 작성해야 하지만, 안타깝게도 그렇게 되지 않았습니다.

참석자 수가 저조한 이유, 특히 미국에서의 낮은 참여율은 아마도 기업들이 XBRL을 여전히 단순히 규제 준수 문제로만 인식하고 있으며, 재무 제표에 대한 "태깅" 작업을 여전히 금융 인쇄업체나 다른 EDGAR 제출 기관에 위탁하고 있기 때문일 것입니다.

따라서 XBRL은 규정 준수와 관련된 문제일까요? 물론 그렇습니다. 하지만 그것은 훨씬 더 중요한 의미를 지닙니다. 저는 Altova에서 일하고 있으며, 저희는 단순히 규정 준수 소프트웨어에만 집중하지 않습니다. 저희는 기업들이 업무 효율성을 극대화할 수 있도록 돕는 도구를 개발합니다 내부의, 내부적인 데이터 관리 프로세스를 개선하여 전체적인 시간과 비용을 줄이는 것을 목표로 합니다. 이는 XBRL을 사용하는 모든 회사에서 충분히 달성 가능한 목표이지만, 데이터 관리 방식을 적극적으로 검토해야 합니다.

"태깅(Tagging)"이란, 재무제표가 기존 방식대로 스프레드시트나 회계 프로그램에서 작성된 후, XBRL 규정을 준수하도록 사후적으로 꼼꼼하게 XBRL 태그를 추가하는 것을 의미합니다. 으휴… 그래서인지 규정 준수가 그렇게 부정적인 느낌을 주는군요! 우리 모두 벌써 할 일이 충분하지 않나요? 그리고 잠깐만요, 이것은 단순히 또 다른 수동 작업을 추가하는 것인데, 인간의 실수가 발생할 가능성을 두 배로 늘리는 것 아닌가요? 정확히 언제부터 이 단어 "태깅"이 XBRL 구현을 설명하는 데 그렇게 널리 사용되기 시작했는지는 모르겠지만, 결과적으로 이 용어는 처음부터 그렇게 복잡하지 않았던 것을 지나치게 단순화했을 뿐입니다 (물론, 이 용어는 아마도 마케팅 분야의 누군가가 만들어낸 것일 겁니다 - 저도 그 분야의 일원입니다).

어쨌든, 지금은 태깅이라는 아이디어는 잠시 접어두고, 조금 더 흥미로운 것을 생각해 볼까요? 예를 들어, 귀사의 모든 재무 데이터가 백엔드 저장소, 데이터베이스, 회계/ERP 시스템, XML 파일, 또는 이들의 조합 형태로 존재한다고 가정해 봅시다. 만약 여러분이 단순히 데이터를 XBRL 형식에 맞게 변환합니다 외부 컨설턴트들이 보고서를 꼼꼼히 검토하고 각 항목을 하나하나 분석하는 대신, 내부적으로 처리할 수 있다면 어떨까요? 그리고 만약 다음에 유사한 재무 보고서를 작성해야 할 때, 이 과정을 재사용할 수 있다면 어떨까요? 또한, IT 부서에서도 이 작업을 수행할 수 있다면 어떨까요 XBRL 보고서 제출 프로세스를 자동화하세요?

XBRL 매핑 Altova MapForce는 기업 수준의 데이터 통합 도구로, 위와 같은 작업을 수행할 수 있습니다. 이 도구는 개발자와 애플리케이션 아키텍트들이 주로 사용하지만, 사용하기 쉬운 그래픽 인터페이스 덕분에 데이터 매핑에 대한 이해만 있다면 누구나 쉽게 사용할 수 있습니다. 다음은 예시를 통해 얼마나 간단한지 보여드리겠습니다. 첫 번째 단계는 매핑할 소스 데이터를 MapForce 디자인 창에 불러오는 것입니다. 여기서는 데이터베이스를 예로 들어보겠습니다.

참고로, 매핑 구성 요소는 데이터베이스 내의 테이블과 컬럼을 표현한 것이며, 따라서 실제 데이터는 언제든지 변경될 수 있지만, 매핑 자체에는 영향을 미치지 않습니다. 이는 MapForce에서 사용하는 모든 매핑 구조(XML, 데이터베이스, 일반 파일, EDI, 엑셀, XBRL, 웹 서비스 등)에도 동일하게 적용됩니다. 다음으로, 저희는 목표 매핑 구성 요소를 추가할 예정인데, 이 경우에는 미국 GAAP(US GAAP) - 상업 및 산업을 기반으로 구축된 기본적인 XBRL 확장 분류 체계를 사용할 것입니다.

이제 우리는 단순히 항목들을 연결하는 선을 그려 매핑을 시작할 수 있습니다. 데이터베이스에 존재하지 않는 XBRL 보고 요구 사항을 충족하기 위해, 때로는 데이터 형식을 약간 수정하거나, 데이터를 필터링하거나, 심지어 상수를 추가하는 등 데이터 처리 규칙을 적용해야 할 수도 있습니다. 이러한 모든 작업은 사이드바에 있는 MapForce 라이브러리에서 중간 함수들을 끌어서 놓기만 하면 매우 쉽게 수행할 수 있습니다.

예를 들어, 데이터베이스가 회계 기간을 기록할 때 자동으로 날짜와 시간을 모두 포함하는 형식을 요구한다고 가정해 보겠습니다. XBRL 보고는 날짜만 필요하기 때문에, 데이터 매핑 과정에서 시간 정보는 제거해야 합니다. 따라서 라이브러리에서 "날짜 추출 (date-from-datetime)" 함수를 선택하여 데이터베이스와 XBRL 구성 요소 간의 연결선을 연결하면 됩니다.

물론, 데이터에 다양한 종류의 수학, 논리 또는 기타 함수를 추가해야 할 수도 있습니다. 이러한 함수들은 이미 함수 라이브러리에 많이 준비되어 있으니, 필요에 따라 활용하시면 됩니다.

필요에 따라 그래픽 함수 빌더를 사용하여 사용자 정의 함수를 쉽게 추가할 수도 있습니다. 최종적으로 매핑 결과는 다음과 같은 형태가 될 것입니다

이제 "출력" 탭을 클릭하여 XBRL 데이터가 어떻게 보이는지 확인해 보세요. 자, 이렇게 하면 재사용 가능하고 확장 가능한 데이터 매핑을 사용할 수 있으며, 필요할 때마다 XBRL 데이터를 제출할 수 있습니다. 또한, 이 매핑 인터페이스를 다른 애플리케이션에 통합하거나, IT 부서에 요청하여 보고서 제출 시마다 XBRL 파일을 자동으로 생성하는 코드를 만들어 사용할 수도 있습니다. MapForce에서 XBRL 매핑이 어떻게 작동하는지에 대한 자세한 내용은 Altova의 XBRL 튜토리얼을 참조하십시오.

따라서, 여기에서는 회계 시스템에서 XBRL 데이터를 직접 생성하는 매우 간단한 예시를 보여드립니다. 정보를 다시 입력할 필요가 없고, 기존의 재무제표를 만들 필요도 없으며, 당연히 "태깅" 작업도 필요하지 않습니다. 무엇보다 가장 좋은 점은 이러한 모든 작업을 내부적으로, 그리고 훨씬 저렴한 비용으로 수행할 수 있다는 것입니다. 물론, 아웃소싱이 귀사의 XBRL 시스템 구축에 적합한 부분이 있을 수 있습니다. 예를 들어, XBRL 확장 분류 체계를 구축하는 것은 XBRL 문법 및 기타 복잡성에 대한 오랜 경험을 가진 전문가에게 맡기는 것이 더 효율적일 수 있습니다. 하지만, 귀사의 재무 데이터를 XBRL 형식으로 변환하는 작업은... 결국 데이터를 가장 잘 이해하는 사람들이 담당하는 것이 옳지 않을까요?

Altova MissionKit에 대한 더 자세한 정보는 다음을 참조하십시오 XBRL 관련 도구들 - 다음을 지원합니다: XBRL 매핑 및 자동화, XBRL 유효성 검사 및 분류 체계 생성, 그리고 XBRL 데이터 렌더링 - 방문해 주세요 https://www.altova.com/solutions/xbrl-tools.html ...또는 Altova MissionKit을 다운로드하세요 오늘!