유상증자를 결정했는데, DART에 제출하면 거래소 공시까지 함께 처리되는 걸까요? 아니면 KIND에 따로 올려야 할까요?
공시 사유가 생길 때마다 이 지점에서 멈칫한다면, 핵심은 사이트 선택이 아니라 제출의무의 경계를 구분하는 데 있습니다.
이 글에서는 금감원 공시와 거래소 공시가 어떻게 나뉘는지, 어떤 공시는 한 번 제출로 끝나고 어떤 공시는 별도로 챙겨야 하는지, 실무자가 바로 확인할 수 있는 기준으로 정리해보겠습니다.
금감원 공시 vs. 거래소 공시, 한 눈에 비교하기
금감원 공시와 거래소 공시의 차이는 단순히 제출 사이트가 다르다는 데 있지 않습니다. 핵심은 무엇을, 어떤 근거 규정에 따라, 어느 기관 소관으로 제출하느냐입니다.
DART는 금융감독원의 전자공시시스템입니다. 상장법인 등이 공시서류를 인터넷으로 제출하고, 투자자는 제출된 공시를 조회할 수 있는 종합 기업공시 시스템입니다.
KIND는 한국거래소의 상장공시 시스템입니다. 상장회사의 수시공시, 공정공시, 조회공시, 자율공시와 투자유의 정보를 확인하는 채널에 가깝습니다.
구분 | 금감원 공시 DART | 거래소 공시 KIND |
|---|---|---|
운영 주체 | 금융감독원 | 한국거래소 |
실무상 성격 | 법정 제출 보고서 중심 | 상장회사 시장 공시 중심 |
대표 공시 | 사업보고서, 반기보고서, 분기보고서, 증권신고서, 주요사항보고서, 지분공시, 감사보고서 등 | 수시공시, 공정공시, 조회공시, 자율공시 등 |
담당자가 먼저 볼 것 | 자본시장법상 제출 대상인지 | 거래소 공시규정상 공시사항인지 |
핵심 리스크 | 제출기한, 서식, XBRL, 정정 여부 | 공시사유 발생 시점, 당일공시, 거래소 확인 여부 |
쉽게 말해 정기보고서·증권신고서류는 DART 중심, 상장회사 이벤트 공시는 거래소 KIND 중심으로 먼저 확인하는 경우가 많습니다.
다만 여기서 끝내면 위험해요. 어떤 사안은 DART와 KIND가 함께 엮입니다. 예를 들어 유상증자는 DART 주요사항보고서와 거래소 수시공시를 함께 검토해야 하는 경우가 있죠. 그래서 실무에서는 “어디에 보이는가”보다 어느 규정에 따른 제출의무인가를 먼저 봐야 합니다.
다트편집기에서 제출하면 KIND에 자동으로 올라갈까?
답은 공시에 따라 다르다입니다.
합병, 자기주식 취득·처분 결정처럼 동일 서식을 쓰는 일부 항목은 DART에 제출하면 거래소 수시공시 의무까지 함께 이행됩니다.
DART 기업공시 길라잡이에서도 “주요사항보고 중 거래소의 수시공시와 동일서식을 사용하는 항목은 하나의 서식으로 작성하여 DART에 한 번에 제출함으로써 주요사항보고 및 수시공시의무를 동시에 이행”한다고 안내하고 있죠.
하지만 모든 공시가 그런 것은 아닙니다. 거래소 고유의 자율공시, 의결권행사 공시, 일부 시장 안내성 공시 등은 KIND나 거래소 공시 제출 절차를 별도로 확인해야 합니다.
이 차이는 작성 방식에서도 드러납니다.
구분 | DART | KIND |
|---|---|---|
주된 작업 | 보고서 작성·제출 | 거래소 공시 제출·조회 |
자주 쓰는 도구/업무 | DART 편집기, DSD, XBRL, 정기보고서 작성 | 수시공시, 공정공시, 조회공시, 자율공시 확인 |
핵심 체크 | 서식, 첨부, 수치, 제출기한 | 공시사유 발생 시점, 거래소 기준, 당일공시 여부 |
DART는 사업보고서, 반기보고서, 분기보고서, 주요사항보고서처럼 정해진 서식에 맞춰 문서를 작성·편집해 제출하는 성격이 강합니다. 반면 KIND는 거래소 기준으로 시장에 알려야 하는 이벤트성 공시를 확인하고 처리하는 흐름에 가깝습니다.
조회공시·공정공시처럼 거래소에서 접수된 공시가 DART에서 함께 조회되기도 합니다. 하지만 ‘화면에 보인다’와 ‘제출의무를 이행했다’는 다른 문제예요. 그래서 최종 판단은 항상 공시 사유와 근거 규정 기준으로 해야 합니다.
DART 제출 대상인지
거래소 공시규정상 KIND 확인이 필요한지
동일 서식으로 일원화된 공시인지
별도 제출이 필요한 거래소 공시인지
공시시점이 결의일, 발생일, 확인일 중 언제인지
공시, 어떻게 관리해야 할까?
핵심은 정기공시와 수시공시를 성격이 다른 두 업무로 나눠 관리하는 거예요.
정기공시는 말 그대로 정기적인 업무입니다. 사업·반기·분기보고서 마감은 연초에 먼저 박아두고, 결산·감사·내부 검토·XBRL 작업 일정을 거꾸로 역산하면 됩니다.
반면 수시공시는 이벤트 업무예요. 언제 무슨 일이 생길지 모르니, 사안별로 '왜 이렇게 판단했는지'를 로그로 남겨둬야 합니다.
관리 항목 | 관리 이유 |
|---|---|
정기공시 일정표 | 사업보고서·반기보고서·분기보고서 마감 관리 |
이벤트 공시 로그 | 수시공시 누락 방지 |
공시시점 판단 메모 | 상급자 보고와 사후 설명 대비 |
제출 채널 기록 | DART/KIND 착오 방지 |
정정 이력 | 반복 오류 예방 |
감사인·법무 검토 일정 | 마감 직전 병목 방지 |
일정을 관리해도 마감 때마다 바쁜 이유
그런데 왜 공시 일정을 관리하는데도, 할 때마다 정신이 없는 걸까요?
이유는 단순해요. 예정된 일과 갑자기 생기는 일이 같이 굴러가기 때문입니다.
사업보고서, 반기보고서, 분기보고서는 미리 일정이 보입니다. 하지만 주요사항보고서나 거래소 수시공시는 사유가 생기는 순간부터 바로 판단해야 해요. “다음 주에 정리하자”가 어려운 업무죠.
문제는 이 둘이 자주 겹친다는 겁니다. 8월 반기보고서, 11월 3분기보고서 시즌에는 주석 정리, 내부 결재, DART·XBRL 작업이 몰립니다. 여기에 유상증자, 계약 체결, 임시주주총회 같은 이벤트까지 생기면 병목이 바로 생겨요.
이때 생기는 리스크는 꽤 현실적입니다.
거래소 공시 기한을 놓쳐 불성실공시 이슈가 생길 수 있습니다.
풍문이나 주가 급변으로 조회공시 대응이 필요할 수 있습니다.
주요사항보고서나 증권신고서 제출을 빠뜨릴 수 있습니다.
마감 직전에 검토 시간이 줄어 정정 가능성이 커집니다.
판단 기준이 담당자 머릿속에만 남아 인수인계가 어려워집니다.
그래서 공시 업무는 모든 변수를 예측하는 일이 아닙니다. 반복되는 정기보고서 업무를 미리 줄여두고, 갑자기 생기는 수시공시에 대응할 시간을 남겨두는 일에 가깝습니다.
매 분기 반복되는 작업을 매번 처음부터 다시 하지 않도록 양식과 절차를 고정해두면 작업 시간을 줄일 수 있습니다. 이런 반복 작업을 줄여주는 솔루션이 있습니다. 바로 인벡터입니다.
정기보고서 사이클 전체를, 인벡터 하나로
인벡터는 정기보고서 작성에서 가장 손이 많이 가는 구간을 하나로 이어줍니다. 정산표를 정기보고서 형식에 맞는 DSD 파일로 변환하는 단계부터 XBRL 태깅까지, 따로 돌던 작업을 한 흐름으로 연결해 마감 직전 병목을 줄이는 솔루션이에요.
1. 정산표 → DSD 파일 생성
기업마다 형식이 다른 정산표도 보고서 형식에 맞는 DSD 파일로 바로 전환할 수 있습니다. 기존에는 내부 회계 데이터 → 감사보고서 → DSD로 이어지던 프로세스를 내부 회계 데이터 → DSD로 한 단계 단축할 수 있는 거죠.
2. AI 추천 태깅
항목마다 AI가 주석 구조를 분석해 적합한 택사노미를 제안합니다.
3. DSD ↔ IXD 대사
DSD 파일과 XBRL 제출 파일인 IXD 파일의 숫자를 자동으로 대조합니다. 두 파일의 숫자가 일치하는지 사람 눈으로 일일이 비교하지 않아도 돼요.
인벡터와 함께라면 회계팀은 회계 판단에, 공시팀은 누락 없는 제출에 더 집중할 수 있습니다.
공시 일정 관리에 대한 불안이 크다면 인벡터에 문의 주세요. 반복 작업을 자동화할 수 있는 솔루션은 물론, DSD 파일을 바탕으로 XBRL 기준을 수립하고 데이터를 설계해, 담당자가 작업할 수 있는 기반을 만들어 드립니다.