내부거래 제거 후 손익 범주 잔여 점검 — 합계는 0 인데 범주에 남는 금액을 쌍 단위로 찾는 연결 결산

개발 배경 — 이 앱을 사용해야 하는 이유

연결 결산의 내부거래 제거는 “합계가 0 이 되었는가” 로 마무리되는 경우가 많습니다. 판매 종속기업이 받은 이자 수익과 지배기업이 낸 이자 비용을 같은 금액으로 제거하면 연결 손익에는 아무것도 남지 않기 때문입니다. 그런데 IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)가 손익을 영업 · 투자 · 재무 · 법인세 · 중단영업 범주로 나눠 보이게 하면, 제거 분개를 어느 범주에 걸었는가가 범주별 연결 손익을 바꿉니다.

이자 수익을 투자 범주로, 이자 비용을 재무 범주로 기록한 거래를 제거하면서 분개를 둘 다 영업에 걸었다면, 합계는 0 이지만 투자 범주에는 이자 수익이 그대로, 재무 범주에는 이자 비용이 그대로 남고 영업 범주에는 반대 부호가 생깁니다. 이 앱은 내부거래 쌍마다 양측이 기록한 범주와 제거 분개가 걸린 범주를 맞춰 보고, 제거를 마친 뒤 범주별로 남는 금액을 보여 줍니다. IFRS 18 은 2027년 1월 1일 이후 개시하는 회계연도부터 적용되는 기준이며, K-IFRS 제1118호의 국내 적용 시기와 세부는 공표 내용을 확인해야 합니다. 이 화면은 준비·점검을 돕는 도구이며 범주 분류와 연결 제거의 최종 판단은 회사와 감사인이 합니다.

핵심 포인트 여섯 가지

합계가 0 이어도 범주에는 금액이 남는다

검증용 샘플의 보고기업 1000 · 8월은 내부거래 쌍 13건의 잔여 순액 합계가 0 원입니다. 그런데 범주별로 펼치면 영업 −268,750,000원, 중단영업 +272,560,000원, 재무 −5,920,000원, 투자 +2,110,000원이 남아 범주별 잔여 절댓값이 549,340,000원이었습니다. 원인은 이자 거래 1건(투자·재무 범주), 지급보증 수수료 1건(영업·재무 범주), 중단영업 종속 제품 거래 1건(중단영업·영업 범주)의 제거 분개를 영업 범주에 건 것입니다. 연결 합계만 보는 점검에서는 정상으로 보였을 숫자입니다.

제거 분개의 범주는 거래가 아니라 사람이 정한다

거래 전표의 범주는 계정에서 나오지만 제거 분개는 연결 담당자가 별도로 올립니다. 올리는 사람의 기본값이 ‘영업’ 이라면 영업이 아닌 거래도 영업에 걸립니다. 이 앱은 제거 분개 한 줄마다 제거 범주와 거래 측 범주를 나란히 두고, 다른 줄만 점검 필요로 표시합니다.

금액이 다른 문제와 범주가 다른 문제는 처리 순서가 다르다

양측이 기록한 금액이 다르면 먼저 내부거래 대사를 마쳐야 합니다. 금액이 같은데 범주만 다르면 제거 분개의 범주를 고치면 됩니다. 둘이 한 쌍에 겹치면 대사를 먼저 하고 범주를 다시 봅니다. 앱은 이 셋을 판정 코드(금액 차이 · 범주 어긋남 · 둘 다)로 나눠, 담당자가 어느 일부터 할지 바로 알게 합니다.

제거가 빠진 거래 측과 범주가 비어 있는 거래 측

제거 분개가 한쪽에만 있으면 그 측의 금액은 제거되지 않고 연결 손익에 남습니다. 거래 측 범주가 비어 있으면 어느 범주에 걸어야 하는지조차 가릴 수 없습니다. 앞의 것은 ‘점검 필요’ 로, 뒤의 것은 ‘확인 필요’ 로 구분해 표시합니다.

사용 방법

1. 회계연도(필수)를 입력하고, 기간·보고기업·거래 유형·범주·거래 내용·거래일·점검 코드·점검 결과는 필요할 때만 고릅니다. 비워 두거나 “전체” 이면 그 조건은 걸리지 않습니다.
2. 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 처음 열면 자동으로 한 번 조회합니다.
3. 요약 지표에서 점검한 보고기업·기간, 쌍 수익측 합계, 제거 분개 수익측 합계, 범주별 잔여 절댓값, 점검·확인이 필요한 쌍, 범주 어긋남 쌍, 정합성 대사 차이를 먼저 봅니다.
4. 탭을 회사·기간 요약 → 범주별 잔여 → 내부거래 쌍 점검 → 제거 분개 명세 → 대사 결과 순서로 넘기며 원인을 좁힙니다.
5. 요약 행이나 쌍 행을 누르면 상세 창이 열려 양측 금액과 제거 분개를 비교할 수 있습니다.
6. CSV 내려받기를 누르면 지금 보는 탭의 조회 결과가 UTF-8 CSV 로 내려옵니다.

숫자를 믿을 수 있는가 — 검증 결과

샘플 데이터를 만든 쪽과 따로 다시 계산한 값과 서비스가 돌려주는 값을 대사식 단위로 맞췄습니다. 쌍 · 범주 · 회사·기간 요약 · 제거 분개의 합계가 서로 맞물려야 합니다.

검사 건수 합계 410건, 대사 차이 0건입니다. 일부러 넣은 예외 11개 쌍은 대사 차이와 따로 집계했습니다 — 범주 어긋남 5 · 금액 차이 2 · 금액과 범주가 함께 어긋남 1 · 제거 누락 2 · 범주 미지정 1.

무엇으로 만들었나

실행 화면

아래 화면은 모두 가상 보고기업 두 곳(1000 · 2000)의 2026년 7~9월 검증용 샘플 데이터입니다. 실제 사용 순서대로 봅니다.

처음 열었을 때 — 요약에서 범주로

먼저 보고기업·기간마다 한 줄로 요약해 점검할 기간을 고르고, 범주 탭에서 어느 범주에 금액이 남았는지 봅니다.

맨 위 안내문이 이 화면의 성격(점검 도구, 최종 판단은 회사와 감사인)을 먼저 알려 줍니다. 요약 지표 여섯 개는 서비스 펑션과 서비스 집계가 계산한 값이라 표의 행 수와 상관없이 같습니다. 샘플에서는 점검·확인이 필요한 쌍이 11건, 범주 어긋남 쌍이 6건, 범주별 잔여 절댓값이 647,520,000원입니다. 회계연도는 2026 이 기본으로 들어 있고, 조회 버튼은 입력 칸 맨 오른쪽 끝에 있습니다.

한 보고기업·기간에서 범주 여섯 줄(영업·투자·재무·법인세·중단영업·미지정)을 봅니다. 제거 후 수익측 잔여와 비용측 잔여가 따로 있어, 순액이 0 이어도 양쪽에 같은 금액이 남아 상쇄되는 경우를 알아봅니다. 산식은 제거 전 순액 − 제거 분개 순액 = 잔여 순액이며, 0 이 아니면 점검 필요(C01)입니다.

쌍에서 제거 분개까지 — 원인 찾기

범주에 남은 금액이 보이면 내부거래 쌍 탭으로 내려가 어긋난 쌍을 찾고, 쌍을 눌러 양측과 제거 분개를 비교합니다.

쌍은 보고기업·기간마다 13건입니다. 수익측·비용측 범주와 제거 수익측·제거 비용측 범주가 한 줄에 있어 어디서 어긋났는지 바로 보입니다. 코드 조건을 P01 로 고르면 금액은 같고 범주만 다른 쌍만 남습니다. 거래 내용에 ‘이자’ 를 넣고 조회하면 이자 거래만 좁혀 볼 수 있습니다.

예시는 보고기업 2000 · 7월의 대여금 이자 쌍입니다. 수익측은 투자 범주 2,660,000원, 비용측은 재무 범주 1,410,000원으로 1,250,000원 차이가 나고, 제거 분개는 수익측이 투자, 비용측이 영업에 걸려 범주도 어긋납니다. 아래 제거 분개 줄에서 어느 줄이 거래 범주와 다른지 확인합니다. 두 문제가 겹쳤으므로 내부거래 대사를 먼저 마친 뒤 제거 범주를 다시 봅니다.

제거 분개는 샘플에서 153줄입니다. 범주 조건을 ‘재무’ 로 두면 재무 범주에 걸린 제거 줄만 남아, 이자 비용 제거가 제대로 재무에 걸렸는지 한눈에 봅니다. 거래일 시작·종료를 함께 넣으면 해당 기간의 분개만 조회됩니다.

숫자를 믿게 하는 대사와 상세

마지막으로 대사 결과로 합계가 맞물리는지 확인하고, 요약 행을 눌러 한 보고기업·기간을 상세로 봅니다.

대사식 일곱 가지(내부 대사)는 모두 차이 건수 0 이어야 합니다. 여덟 번째 줄은 점검 대상으로 일부러 넣은 쌍의 건수라 ‘차이’ 처럼 보여도 대사 오류가 아닙니다. 요약의 정합성 대사 차이 지표는 내부 대사 줄의 차이 건수만 더합니다.

수익측·비용측 합계, 제거 분개 합계, 금액 차이 합계, 범주별 잔여 절댓값, 쌍 · 점검 쌍 · 범주 어긋남 쌍 건수가 한 창에 모입니다. 아래 범주별 표로 어느 범주에 잔여가 남았는지 확인한 뒤 쌍 점검 탭으로 이동해 원인 쌍을 찾습니다.

화면 뒤에서 일어나는 일

1. 쌍 금액 차이 — 수익측 기록 금액 − 비용측 기록 금액.
2. 제거 금액 — 제거 분개가 있는 측만 제거 금액을 가집니다(수익측 제거 · 비용측 제거).
3. 쌍 잔여 순액 — (수익측 − 비용측) − (제거 수익측 − 제거 비용측).
4. 범주별 제거 전 순액 — 거래 측 범주 기준으로 수익측 합계 − 비용측 합계.
5. 범주별 제거 분개 순액 — 제거 범주 기준으로 제거 수익측 합계 − 제거 비용측 합계.
6. 범주별 잔여 순액 — 제거 전 순액 − 제거 분개 순액. 수익측 잔여와 비용측 잔여도 같은 방식으로 구합니다.
7. 회사·기간 요약 — 범주별 잔여 순액의 절댓값을 더해 범주별 잔여 절댓값을 만들고, 쌍 판정을 모아 요약 판정을 정합니다.

판정 규칙 — 조건 · 결과 · 조치

판정 우선순위는 쌍에서 P04 → P05 → P03 → P02 → P01, 보고기업·기간에서 R02 → R01 → R03 입니다. 모든 코드는 점검 대상을 가리는 표시이며 처리 방법은 회사가 정합니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

창이 좁아지면 조회조건이 여러 줄로 접히고 요약 지표도 줄을 바꿔 놓입니다. 표는 보고기업과 기간 두 열을 고정한 채 나머지 열을 가로로 넘겨 봅니다. 탭과 상세 창은 그대로 쓸 수 있어 휴대폰에서도 점검 대상을 고를 수 있습니다.

파일 구성

앱 폴더/
├─ index.html            앱 진입점
├─ readme.html           설명서
├─ Component.js · manifest.json
├─ controller/           BaseController · Main.controller
├─ view/                 Main.view.xml · 상세·쌍 상세 fragment
├─ model/                formatter · ErrorHandler
├─ css/ · i18n/
├─ odata/                서비스 정의 · 서비스 로직 · 엔티티셋별 데이터
└─ media/                소개 영상

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 제거 분개를 올리고 전기하는 일, 법정·공시 보고는 표준 기능에 그대로 둡니다.

표준으로 되는 것과 안 되는 것

T-code 별 연계 지점

기존 연결 리포트를 없애야 하나요? 없애지 않습니다. 기존 연결 결산 리포트와 법정 제출 자료는 그대로 두고, 제거 단계에서 범주별 잔여를 미리 점검하는 자리를 더하는 쪽으로 씁니다.

S/4HANA 분석 스택과의 자리

이 앱의 집계는 CDS 큐브와 분석 쿼리로 내려 운영에서도 같은 구조를 씁니다. 표준 Fiori 분석 앱이나 Analysis for Office 는 합계 확인에 적합하고, 이 앱은 쌍·분개 단위의 비교와 판정 코드를 더합니다. 그룹 리포팅 같은 연결 기능을 쓰는 회사는 그쪽의 제거 결과를 이 화면의 쌍·분개 형태에 맞추는 매핑이 필요하며, 어느 테이블에서 읽을지는 확인이 필요합니다.

요구사항 매핑표

확장 포인트 — 운영에서 실제로 손대는 자리

CDS 구성

이 사례의 화면은 샘플 데이터를 서비스가 읽어 보여 줍니다. 운영 데이터에서는 쌍·범주 집계를 CDS 로 내려 서비스가 그 결과를 읽게 합니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스·환경에 따라 다르므로, 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다.

뷰 레이어 구성

① 범주 매핑 테이블 — 정책이 사는 곳

가장 먼저 정할 것은 어느 계정이 어느 손익 범주인가입니다. 이 표가 있어야 거래 측 범주와 제거 분개의 범주가 같은 기준으로 읽힙니다. 유효 시작일을 두어 정책이 바뀌어도 지난 기간의 범주가 흔들리지 않게 했습니다. 범주 정책은 IFRS 18 적용 준비와 함께 회사가 확정할 항목입니다.

" ─────────────────────────────────────────────
" ZELIM_CATMAP — 계정 → 손익 범주 매핑(고객 정의 테이블)
" 이렇게 나눈 이유: 범주 정책은 회사가 정하고 바뀐다.
"   코드에 박지 않고 표로 두어 현업이 직접 유지한다.
" ─────────────────────────────────────────────
@EndUserText.label : '손익 범주 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zelim_catmap {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key racct      : racct not null;
  key valid_from : abap.dats not null;
  cat_id         : abap.char(2) not null;  " OP 영업 · IV 투자 · FN 재무 · TX 법인세 · DO 중단영업
}

② 범주 차원 뷰 — 이름과 코드를 한 곳에서

큐브가 범주 이름을 매번 case 로 만들지 않도록 차원 뷰로 뺍니다. 범주 코드가 늘거나 이름이 바뀌어도 이 뷰만 고칩니다. 아직 지정되지 않은 계정은 미지정으로 내려 두어, 화면에서 ‘확인 필요’ 로 드러나게 합니다.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '손익 범주 차원'
@Analytics.dataCategory: #DIMENSION
define view entity ZI_ElimCategory
  as select from zelim_catmap
{
  key bukrs      as CompanyCode,
  key racct      as GLAccount,
  key valid_from as ValidFrom,
      cat_id     as CategoryId,
      case cat_id
        when 'OP' then '영업'
        when 'IV' then '투자'
        when 'FN' then '재무'
        when 'TX' then '법인세'
        when 'DO' then '중단영업'
        else '미지정'
      end        as CategoryName
}

③ 내부거래 쌍 뷰 — 양측을 한 행으로

쌍 점검의 출발점입니다. 수익측 라인과 비용측 라인을 거래 상대 회사와 양측을 묶는 참조 키로 맞붙입니다. 어떤 필드를 묶음 키로 쓸지는 회사의 내부거래 전표 규칙에 달려 있어 확인이 필요합니다. 금액 차이는 양측 기록 금액을 빼서 이 뷰에서 바로 구합니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '내부거래 쌍(수익측·비용측)'
define view entity ZI_IcPair
  as select from acdoca as inc
    inner join   acdoca as exp
      on  exp.rldnr  = inc.rldnr
      and exp.gjahr  = inc.gjahr
      and exp.rbukrs = inc.rassc     " 상대 회사
      and exp.rassc  = inc.rbukrs
      and exp.xblnr  = inc.xblnr     " 양측을 묶는 참조 키 — 확인 필요
    association [0..1] to ZI_ElimCategory as _IncCat
      on _IncCat.CompanyCode = inc.rbukrs and _IncCat.GLAccount = inc.racct
    association [0..1] to ZI_ElimCategory as _ExpCat
      on _ExpCat.CompanyCode = exp.rbukrs and _ExpCat.GLAccount = exp.racct
{
  key inc.rbukrs                              as IncCompany,
  key exp.rbukrs                              as ExpCompany,
  key inc.xblnr                               as PairRef,
      inc.gjahr                               as FiscalYear,
      inc.poper                               as FiscalPeriod,
      _IncCat.CategoryId                      as IncCategory,
      _ExpCat.CategoryId                      as ExpCategory,
      @Semantics.amount.currencyCode: 'Currency'
      cast( inc.hsl as abap.curr(23,2) )      as IncAmount,
      @Semantics.amount.currencyCode: 'Currency'
      cast( exp.hsl as abap.curr(23,2) )      as ExpAmount,
      inc.rhcur                               as Currency,
      _IncCat, _ExpCat
}
where inc.racct <> ''   " 수익·비용 계정만 남기는 조건은 매핑으로 대신한다 — 확인 필요

④ 제거 분개 뷰 — 제거가 걸린 범주

제거 전표는 거래 전표와 따로 쌓입니다. 이 뷰는 제거 전표 유형만 읽고, 줄마다 제거 범주와 금액을 돌려줍니다. 제거 전표를 연결 모듈에 쌓는 회사는 이 뷰의 원천만 바꾸면 되고, 아래 큐브는 그대로 둡니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '제거 분개 줄'
define view entity ZI_ElimLine
  as select from acdoca as el
    association [0..1] to ZI_ElimCategory as _Cat
      on _Cat.CompanyCode = el.rbukrs and _Cat.GLAccount = el.racct
{
  key el.rbukrs  as CompanyCode,
  key el.belnr   as ElimDocument,
  key el.docln   as ElimLine,
      el.gjahr   as FiscalYear,
      el.xblnr   as PairRef,            " 제거가 가리키는 쌍 — 확인 필요
      _Cat.CategoryId as ElimCategory,
      @Semantics.amount.currencyCode: 'Currency'
      cast( el.hsl as abap.curr(23,2) ) as ElimAmount,
      el.rhcur   as Currency,
      _Cat
}
where el.blart = 'EL'                  " 제거 전표 유형 — 확인 필요

⑤ 범주 큐브 — 제거 전, 제거 분개, 잔여

이 앱의 핵심 계산입니다. 거래 측 범주 기준의 제거 전 순액과 제거 범주 기준의 제거 분개 순액을 한 큐브에 두고, 잔여는 두 값의 차이로 만듭니다. 수익측은 +, 비용측은 −로 세웁니다. 화면의 대사식도 같은 규칙을 씁니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '범주별 제거 전후 큐브'
@Analytics.dataCategory: #CUBE
define view entity ZI_ElimCatCube
  as select from ZI_IcPair as p
{
  key p.IncCompany,
  key p.FiscalYear,
  key p.FiscalPeriod,
  key p.IncCategory                   as CategoryId,
      p.Currency,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      sum( p.IncAmount ) - sum( p.ExpAmount ) as PreElimNet
}
group by p.IncCompany, p.FiscalYear, p.FiscalPeriod, p.IncCategory, p.Currency
" 제거 분개 순액은 ZI_ElimLine 을 같은 키로 union 해 ElimNet 으로 올린다.
" 잔여 순액(ResidNet) = PreElimNet − ElimNet — 화면 대사식과 같은 규칙.

⑥ 분석 쿼리 — 화면이 받는 모양

화면이 직접 보는 뷰입니다. 필수 조회조건(회계연도)을 파라미터로 받고, 범주·기간·보고기업을 필터로 엽니다. 숫자는 쿼리에서 계산하고 화면은 그대로 보여 주기만 합니다.

@EndUserText.label: '범주별 잔여 쿼리'
@Analytics.query: true
@AccessControl.authorizationCheck: #CHECK
define view entity ZC_ElimCatResidQuery
  with parameters
    @Consumption.derivation: { lookupEntity: 'I_FiscalYearForCompanyCode' }  " 표준 뷰 이름 — 확인 필요
    P_FiscalYear : gjahr
  as select from ZI_ElimCatCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #SINGLE, multipleSelections: false, mandatory: true }
  key IncCompany,
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter.selectionType: #RANGE
  key FiscalPeriod,
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter.selectionType: #SINGLE
  key CategoryId,
  @AnalyticsDetails.query.axis: #COLUMNS
  PreElimNet
}
where FiscalYear = $parameters.P_FiscalYear

⑦ 권한 — 보고기업 단위로

연결 결산 담당자는 보고기업마다 볼 수 있는 범위가 다릅니다. 권한은 쿼리 앞단 집계에서 걸어야 합계로 다른 회사 숫자가 새지 않습니다. 사용하는 권한 오브젝트와 필드는 회사 권한 설계에 맞춰 확인해야 합니다.

@EndUserText.label: '범주별 잔여 — 회사코드 권한'
@MappingRole: true
define role ZC_ElimCatResidQuery {
  grant select on ZC_ElimCatResidQuery
    where ( IncCompany ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의 — 화면이 부르는 문

쿼리를 OData 서비스로 열어 주는 마지막 단계입니다. 서비스 이름은 화면의 manifest.json 에 적힌 서비스 주소와 같아야 하고, 활성화와 게시 절차는 아래 운영 표에 따로 적었습니다.

@EndUserText.label: '범주별 잔여 서비스'
define service ZUI_ElimCatResid {
  expose ZC_ElimCatResidQuery as CatSet;
  expose ZI_IcPair            as PairSet;
  expose ZI_ElimLine          as ElimSet;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 아홉 가지는 코딩이 아니라 합의입니다.

운영 데이터로 갈 때

전표가 수천만 건이면 쌍을 맞붙이는 join 이 가장 먼저 무거워집니다. 회계연도를 필수 파라미터로 받고 보고기업·기간을 필터로 앞에서 좁히며, 쌍 뷰와 제거 줄 뷰는 인덱스가 걸린 키(회사코드 · 회계연도 · 전표번호)로 읽습니다. 범주 집계는 큐브에서 하고 서비스는 집계 결과만 받습니다. 응답 시간 기준은 운영 규모에서 실측해 정해야 하며, 이 사례의 샘플 규모로는 판단할 수 없습니다.

자주 묻는 질문

도입 검토 때 자주 나오는 질문을 네 묶음으로 적었습니다.

숫자와 판정

화면과 조작

기준서와 SAP 표준

도입과 운영