XBRL 단수 차이, 왜 생길까? 반올림·단위·입력 오류 점검법

XBRL 주석 표에서 세부 항목을 더해 보니 합계와 1이 차이 납니다. 입력을 잘못한 걸까요? 꼭 그렇지는 않습니다. 금액을 반올림하거나 절사하는 과정에서도 이런 끝자리 차이가 생길 수 있고, 이를 흔히 단수 차이라고 부릅니다. 그렇다고 1 차이가 모두 단수 차이인 것은 아닙니다. 반올림 순서 때문에 생겼을 수도 있지만, 단위 설정이나 입력값에 문제가 있어 생겼을 수도 있습니다. 차이의 크기만으로는 단수 차이인지 입력 오류인지 판단할 수 없는 이유입니다.

그래서 점검은 그 ‘1’이 1원인지, 1천 원인지, 1백만 원인지, 그리고 같은 범위의 금액끼리 비교하고 있는지를 확인하는 데서 시작합니다. 그다음 원금액과 표시 금액, 작성기의 단위 설정, 입력값을 차례로 대조하며 원인을 좁혀 갑니다. 이 글에서는 차이의 원인을 구분하는 방법과 작성기 검증 결과를 함께 점검할 때 유의할 점을 살펴봅니다.

XBRL 주석 공시가 어떤 범위에서 어떤 과정을 거쳐 작성되는지 먼저 살펴보고 싶다면 XBRL 주석 공시의 작성 범위와 검토 과정을 함께 읽어보셔도 좋습니다.

단수 차이란? 반올림 순서에 따라 합계가 달라지는 이유

먼저 반올림만으로 1 차이가 생기는 원리부터 간단한 예로 살펴보겠습니다. 아래는 원금액을 천 원 단위로 표시하는 가상 사례입니다. 원금액을 천 원으로 나눈 값의 소수 첫째 자리에서 반올림(0.5 이상 올림)한다고 가정합니다.

원금액으로 보면 1,400원 + 1,400원 = 2,800원입니다. 그런데 각 항목을 먼저 반올림해 더하면 1 + 1 = 2가 되고, 합계 2,800원을 반올림하면 3이 됩니다. 계산이 틀린 게 아니라, 반올림을 언제 했느냐에 따라 1 차이가 생긴 것입니다. 이것이 단수 차이입니다.

다만 모든 1 차이가 반올림 때문인 것은 아닙니다. 실제 표에서 같은 결론을 내리려면 원금액과 표시 단위, 그리고 적용한 반올림 또는 절사 방식을 함께 봐야 합니다. 어떤 순서로 점검하면 되는지 이어서 알아보겠습니다.

XBRL 합계 불일치 원인을 찾는 4단계

점검에 들어가기 전에 앞의 사례에서 쓴 두 금액을 구분해 두겠습니다. 원금액은 표시 단위로 환산하거나 반올림하기 전의 금액이고, 표시 금액은 표에 적힌 단위로 보여주는 금액입니다. 아래 네 단계는 이 두 금액을 오가며 차이의 원인을 좁혀 가는 과정입니다.

1. 표시 단위와 비교 기간·재무제표 범위 확인

먼저 표의 단위를 보고 그 ‘1’이 실제로 얼마인지 확인합니다. 천 원 단위 표의 1 차이는 1천 원, 백만 원 단위 표의 1 차이는 1백만 원입니다. 차이를 원금액 기준으로 환산해 적어 두면, 다음 단계에서 반올림으로 설명되는 크기인지 비교하기 쉽습니다.

단위를 확인했다면 같은 범위의 금액끼리 비교하고 있는지도 봅니다. 당기와 전기, 연결과 별도 재무제표가 섞여 있으면 비교 대상부터 어긋납니다. 표의 제목만 보지 말고 행·열이 가리키는 기간과 범위까지 맞춰 봅니다.

범위가 같다면 더하고 있는 세부 항목이 실제로 그 합계를 구성하는지 확인합니다. 화면에서 가까이 놓인 숫자라고 해서 모두 같은 합계의 구성 항목은 아닙니다. 소계를 다시 더해 중복 집계하지 않았는지, 분류 기준이 다른 금액을 함께 더하지 않았는지 살펴봅니다. 일반 XBRL 2.1의 계산 검증 역시 정의된 계산 관계와 관련 데이터의 조건을 바탕으로 수행됩니다.

2. 원금액과 표시 금액의 반올림·절사 결과 대조

비교 대상이 맞는다면 앞의 가상 사례처럼 두 금액을 나누어 대조합니다. 원금액을 구할 수 있다면 먼저 원금액끼리 더해 합계가 맞는지 확인합니다. 그다음 실제 작성에 사용한 반올림 또는 절사 방식을 그대로 적용해, 각 항목을 표시 단위로 환산해 더한 결과와 합계를 환산한 결과를 비교합니다. 합계가 맞고 같은 방식으로 차이가 재현된다면, 표시 과정에서 생긴 단수 차이로 설명할 수 있습니다.

원본 보고서(DSD)에 이미 반올림된 금액만 남아 있다면 어떨까요? 이때는 숨겨진 원금액을 임의로 추정해 숫자를 맞추지 않습니다. 반올림 차이인지 확인하는 데 필요한 원금액과 작성 기준을 확보하는 것이 먼저입니다.

3. DART 작성기의 단위 설정과 본문·주석 연동 확인

다음으로 원본 표와 작성기의 단위 설정이 같은지 확인합니다. 예를 들어 원본 표는 천 원 단위인데 작성기에는 원이나 백만 원 단위로 설정돼 있을 수 있습니다. 금감원 2026년 작성가이드도 금액 정보의 단위 속성을 설명하면서, Monetary 유형의 주석 금액을 입력할 때 정확한 단위를 지정하도록 안내합니다.

단위는 본문과 주석의 연동 방식과도 맞물려 있습니다. 보고기간과 재무제표 범위가 같다면, 가이드는 아래 조건을 갖춘 값이 서로 연동된다고 설명합니다.

• 같은 행에 있는 값

• 축·도메인·구성요소가 같은 값

이때 본문은 원 단위로, 주석은 천 원 단위로 입력하면 마지막에 입력한 값으로 저장됩니다. 그러므로 한 셀을 수정했다면 연결된 위치의 금액도 다시 확인합니다.

가이드에 실린 유형자산 사례의 숫자로 계산해 보면 다음과 같습니다.

• 본문 금액: 209,108,598,049원

• 천 원 단위 주석의 합계 칸 표시: 209,108,598

• 주석 금액을 원으로 환산: 209,108,598,000원

• 본문 금액과의 차이: 49원

단위가 다르다는 것만으로 오류는 아니며, 환산한 숫자가 완전히 일치하기만을 요구하면 이런 표시상의 차이까지 오류로 보게 됩니다. 반대로 합계 칸이 연동된다고 해서 주석 표의 합계 차이가 모두 반올림 때문인 것도 아닙니다. 단위를 통일하고 실제 반올림·절사 방식을 적용했을 때 차이가 설명되는지를 기준으로 판단합니다.

단위를 확인할 때 함께 주의할 것이 XBRL의 정확도 속성(decimals)입니다. 이 속성은 금액에 곱하는 배율이 아닙니다. 일반 XBRL 사양에서 decimals는 수치가 어느 자릿수까지 정확한 것으로 보고됐는지를 나타냅니다. 예를 들어 통화가 KRW이고 천 원 수준으로 반올림한 금액을 보고한다면 다음과 같이 표현합니다.

• 숫자 값: 1이 아니라 1,000

• 정확도 표시: decimals="-3"

다만 이는 일반 사양의 설명이므로, DART 입력창에 넣을 숫자는 작성기의 단위 설정을 기준으로 확인합니다.

4. DSD·IXD 입력값과 부호·누락·중복 확인

마지막으로 입력값 자체를 확인합니다. DSD의 숫자와 XBRL 작성 파일(IXD)의 입력값을 대조해 자릿수, 복사 범위, 항목 누락, 중복 입력을 살펴봅니다. 부호도 함께 봐야 하는데, 화면에 보이는 괄호와 실제 입력값이 다를 수 있으므로 괄호로 표시된 금액을 모두 음수로 입력하는 방식은 피합니다.

금감원 가이드의 재무상태표 감가상각누계액 사례를 보면, 양수를 입력한 뒤 반대부호 표시 기능을 사용해 괄호 금액으로 보여줍니다. 이 방식이 모든 항목에 똑같이 적용되는 것은 아니므로, 다른 주석은 해당 주석의 입력·표시 기준을 따로 확인합니다.

원인을 찾았다면 다음 행동은 그에 따라 달라집니다. 아래는 원인별로 정리한 실무 점검안입니다.

단수 차이와 DART 검증 결과를 구분해야 하는 이유

일반 XBRL 2.1 사양은 정의된 계산 관계와 보고된 수치의 정확도를 바탕으로 계산 일치 여부를 확인하는 기준을 정하지만, 이런 불일치를 어떻게 처리할지는 각 공시 시스템에 맡깁니다. 따라서 이것만으로 DART 작성기의 구체적인 오류 분류나 제출 가능 여부까지 알 수는 없습니다.

그래서 작성기 검증 결과는 표의 대조와 별도로 봐야 합니다. 메시지가 나온다면 대상 항목, 기간, 단위, 계산 관계와 실제 입력값을 점검하고, 원인을 수정한 뒤 다시 검증합니다. 반대로 메시지가 없더라도 원본 대비 누락이나 부호 오류까지 없다는 뜻은 아닙니다.

제출 전에는 원본과의 대조 결과, 단위와 부호 설정, 수정 후 미리보기, 남아 있는 검증 메시지와 그 처리 근거를 점검합니다. 이때도 특정 항목에 1을 임의로 더하거나 빼서 합계를 맞추지 말고, 왜 차이가 났는지 설명할 수 있는 자료부터 갖춰야 합니다.

지금까지 살펴본 점검은 결국 원본과 작성 파일을 나란히 놓고 단위와 부호, 입력값을 하나씩 대조하는 일입니다. 표 한두 개라면 직접 확인할 수 있지만, 주석 전체로 범위를 넓히면 같은 확인을 여러 표에서 반복해야 합니다. 이런 반복 대조는 도구에 맡기고, 사람은 차이의 원인을 판단하고 근거를 남기는 데 집중하는 편이 효율적입니다.

인벡터로 XBRL 태그 배정부터 숫자 대사·값 수정까지 검토하기

합계 차이는 숫자를 대조하는 단계에서 드러나지만, 원인은 그 앞 단계에서 비롯될 수 있습니다. 어떤 셀에 어떤 태그를 배정하느냐에 따라 그 값이 어떤 계산 관계에 포함되고 어디와 연동되는지가 정해지고, 값을 입력하는 과정에서 단위와 부호도 함께 결정되기 때문입니다. 그래서 숫자 대사는 태그 배정과 값 수정까지 하나의 흐름으로 이어서 볼 필요가 있습니다.

이 과정에는 XBRL 태그 배정부터 파일 간 숫자 대사, IXD 값 편집까지 지원하는 인벡터를 활용할 수 있습니다. 이 흐름에 따라 각 기능을 어떻게 사용하는지 살펴보겠습니다.

1. AI 오토태깅으로 주석에 맞는 태그 배정

인벡터 오토태깅은 업로드한 DSD의 표와 셀을 분석해 XBRL 태그를 배정합니다. 표에 담긴 숫자·항목명·맥락을 바탕으로 라인아이템과 축·구성요소를 배정하며, 필요한 표만 선택하거나 문서 전체를 대상으로 실행할 수 있습니다.

태그마다 선택 근거도 함께 제공하므로, 담당자는 배정 결과를 주석의 내용과 대조하며 검토할 수 있습니다. 회사가 공시하려는 의미에 맞는지 확인하고, 필요한 부분을 수정하는 방식입니다.

2. DSD·IXD 대사로 작성 파일의 숫자 비교

태깅과 값 입력을 마쳤다면 작성 결과가 기준 자료와 일치하는지 확인할 차례입니다. 인벡터 DSD·IXD 대사는 두 파일의 숫자를 자동으로 비교하고, 일치·불일치와 부호 차이를 색으로 구분해 보여 줍니다. 이를 통해 보고서의 숫자가 XBRL 파일에 맞게 반영됐는지 살펴볼 수 있습니다.

검토 의견을 반영한 뒤에는 IXD·IXD 대사로 수정 전후 파일을 비교할 수 있습니다. 값이 달라지거나 항목이 추가·삭제된 부분을 확인하고, 의도한 수정 내역과 일치하는지 검토하는 데 활용합니다.

DSD의 숫자와 대응하는 IXD 항목을 함께 보면서, 색으로 표시된 일치 여부와 부호 차이를 확인할 수 있습니다.

대사에서 차이가 발견되면 기준 자료와 수정 내역을 바탕으로 어느 파일을 수정해야 하는지 판단합니다.

3. IXD 값 편집기로 수정사항 반영

IXD의 값을 수정해야 한다면 인벡터 IXD 값 편집기에서 작업을 이어갈 수 있습니다. 브라우저에서 IXD를 열어 숫자와 문장을 편집하고, 변경 내용이 반영된 새 파일을 내려받는 기능입니다.

수정할 셀과 연결된 다른 주석이나 재무제표의 값도 함께 확인할 수 있습니다. 다만 태그 자체를 변경하거나 별칭을 설정해야 한다면 태깅 단계에서 해당 작업을 진행해야 합니다.

매번 보고서의 최종본을 찾고, 수정본과 제출 파일의 숫자를 일일이 대조하고 있다면 인벡터에 문의해 보세요. 반복적인 사례 탐색과 파일 대조에 드는 시간을 줄이고, 담당자는 주석의 의미와 최종 수치를 검토하는 데 더욱 집중할 수 있습니다.