SAP 중단영업 범주 손익 표시 점검 — IFRS 18, 중단영업으로 분류된 사업의 손익이 중단영업 범주에 모두 놓였는지 사업 단위로 다시 따져 장부와 맞춰본다

도입 포인트 — 이 앱을 사용해야 하는 이유

사업을 접거나 팔기로 한 해의 결산에서 나오는 질문은 늘 비슷합니다. 중단영업 범주에 그 사업의 손익이 빠짐없이 들어갔나, 계속하는 사업의 손익이 거기 섞여 들어가지 않았나, 그 손익에 대응하는 법인세효과와 전기 비교금액까지 같이 옮겼나. IFRS 18 은 손익을 영업·투자·재무·법인세·중단영업 다섯 범주로 나누어 표시하도록 하므로, 중단영업 범주가 어긋나면 영업이익 같은 소계가 달라지고 비교하는 숫자도 흔들립니다. 지금은 이 확인이 계정 잔액 조회, 엑셀 분류표, 담당자의 기억에 흩어져 있습니다. 이 앱은 그 확인을 한 화면에 모아, 어디가 다른지를 먼저 보여 줍니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 중단영업 범주가 45.60억 크게 보였던 이유

가상의 회사 1000 에서 중단영업 범주의 장부 금액은 +53.85억, 점검 기준 금액은 +8.25억으로 45.60억 차이가 났습니다. 합계만 보면 “중단영업에서 번 돈이 많다”로 끝났을 이야기가, 구성 줄을 펼치자 두 방향의 이동이 겹친 결과로 풀립니다. 중단영업으로 분류된 소형가전 사업부의 비용 세 줄이 다른 범주에 남아 있었고, 반대로 계속하는 본사 사업의 처분이익 한 줄이 중단영업 범주에 들어가 있었습니다.

중단영업 범주에서 빠진 비용이 42.50억(판매관리비 26.80 + 측정손실 11.50 + 법인세효과 4.20)이고 잘못 들어온 이익이 3.10억이라, 장부 금액이 점검 기준보다 합쳐서 45.60억 큽니다. 한 방향만 보았다면 놓쳤을 이동입니다. 그리고 이 이동은 이익 총합을 바꾸지 않습니다. 회사 1000 의 5범주 합계는 장부로도 점검 기준으로도 항목 금액 합계와 같고, 범주가 달라지면 영업이익 같은 소계와 중단영업 범주 금액이 달라지는 것이지 합계가 달라지는 것이 아닙니다. 회사 2000 은 판매관리비 한 줄(12.60억)이 같은 이유로 어긋나 있었고, 두 회사를 합친 금액 차이는 요약에 5,820백만 원으로 나옵니다.

화면은 여기까지만 말합니다. 위 항목을 실제로 옮길지는 회사의 회계정책과 원문 문단, 감사인의 의견으로 정할 일입니다. 물류 사업부는 매각예정 분류 요건을 채운 시점이 확정되지 않아 단정하지 않고 확인 필요로 남겨 두었고, 소형가전 사업부의 전기 비교금액 조정 0.95억은 범주는 맞지만 재표시가 되지 않아 별도로 점검 필요로 띄웠습니다.

도입하면 달라지는 것

• 결산 점검 — 범주 확인과 금액 대사가 한 화면에서 나와 분류표를 따로 맞추는 일이 줄어듭니다.
• 회의의 주제 — “합계가 왜 다른가”가 아니라 “이 비용을 어느 범주에 둘 것인가”를 이야기합니다.
• 근거의 위치 — 판정 근거와 전표 라인이 같은 창에 있어 감사인에게 보여 줄 자료가 따로 필요 없습니다.
• 정책 판단의 분리 — 기준서로 가려지는 것과 회사 정책으로 정할 것이 표시로 나뉘어, 정책 문서가 필요한 사업이 드러납니다.

이런 회사에 맞습니다

• 사업 일부를 매각하거나 접어 중단영업 손익을 처음 표시해야 하고, IFRS 18 적용에 맞춰 손익 계정 묶음을 다섯 범주로 다시 짜고 있는 재무회계 조직.
• 중단영업 손익이 영업·투자·법인세 계정에 흩어져 있어 결산마다 분류표를 손으로 맞추는 회사.
• 감사인에게 중단영업 범주의 구성과 비교기간 재작성의 근거를 항목 단위로 보여 줘야 하는 회사.

적용 시기와 경과규정은 원문 확인이 필요합니다. 이 글의 기준서 문단번호는 일부러 적지 않았고, 화면의 규칙은 점검용 가정이므로 회사의 정책 문서와 대조한 뒤 쓰셔야 합니다.

실행 화면

실제로 돌아가는 화면 6종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다. 자료는 가상의 두 회사(1000 · 2000)로 만든 검증용이며 실제 회사의 계정체계나 금액이 아닙니다.

사용 방법

1. 조회조건을 입력합니다. 회계연도는 필수(기본 2026)이고 회사·장부 범주·점검 기준 범주·최근 전기일·항목명·점검 코드·점검 결과는 선택이며, 비워 두면 전체입니다.
2. 조회 버튼은 조회조건 오른쪽 끝에 있습니다. 입력 칸에서 Enter 키를 눌러도 조회되고, 화면을 처음 열면 기본 조건으로 자동 조회됩니다.
3. 위쪽 요약에서 점검한 항목 수·점검 기준 중단영업 범주 항목·점검 필요·확인 필요 건수와 금액 차이를 봅니다.
4. 항목 범주 점검 탭에서 항목별 판정을 보고, 범주별 합계 → 중단영업 범주 구성 → 대사 결과 탭 순서로 옮겨 가며 근거를 확인합니다.
5. 행을 누르면 상세가 열려 판정 근거와 전표 라인을 한 창에서 봅니다. 지금 보는 탭의 결과는 CSV 로 내려받을 수 있습니다.

처음 열었을 때

화면을 열면 기본 조건으로 바로 조회됩니다. 점검 결과 칸은 정상·점검 필요·확인 필요 세 색으로 갈라 보이므로, 표를 위에서 아래로 읽지 않아도 다른 행이 눈에 들어옵니다. 숫자는 모두 가상 두 회사의 검증용 자료입니다.

점검 결과 좁혀 보기

좁히는 일은 서비스에 $filter 로 전달됩니다. 화면이 받은 전체를 걸러 보여 주는 것이 아니라 서비스가 조건에 맞는 줄만 내려 주므로, 항목이 수만 건으로 늘어도 같은 방식으로 동작합니다.

범주와 구성으로 근거 따라가기

범주를 옮겨도 합계는 바뀌지 않습니다. 한 범주에서 빠진 금액이 다른 범주로 들어갈 뿐이므로 차이 열을 모두 더하면 0 이 됩니다. 이 성질이 뒤의 대사 결과에서 다시 검산됩니다.

합계 줄의 차이가 곧 중단영업 범주의 장부−점검 기준 차이입니다. 어느 줄이 비었는지, 어느 줄이 넘치는지가 한눈에 보이므로 합계가 다르다는 사실보다 어디가 다른지를 먼저 이야기할 수 있습니다.

한 항목의 근거까지

숫자를 의심할 때 다른 화면으로 옮기지 않아도 됩니다. 항목 금액과 전표 라인 합계가 같은지도 이 창에서 바로 보이고, 표준 화면에서 더 보려면 FAGLL03 에 같은 조건을 넣으면 됩니다.

대사 결과

두 대사는 뜻이 다릅니다. 정합성 대사는 화면이 만든 숫자가 서로 맞는지 보는 것이라 차이가 0 이어야 하고, 공시 점검 대사는 장부와 점검 기준의 차이를 세는 것이라 차이가 곧 찾은 대상입니다. 둘을 섞어 적으면 어느 쪽이 오류인지 헷갈리므로 따로 기록합니다.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다. 표준 화면의 세부 동작은 릴리스와 설정에 따라 다르므로 아래 내용은 확인이 필요한 일반론입니다.

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

이 앱이 읽는 자료

항목의 “장부 범주”는 손익 계정 묶음에 회사가 부여해 둔 범주이고, 사업 단위의 중단영업 분류는 계정 묶음 매핑에 둔 속성입니다. 운영에서는 이 속성을 어디에 둘지(계정 묶음 마스터, 별도 매핑 테이블 등)와 분류를 누가 확정해 넘겨줄지가 먼저 정해져야 하며, 이는 도입할 때 가장 시간을 쓰는 부분입니다.

이 앱이 하지 않는 것

• 전기·재분류 전표를 만들지 않습니다. 조회와 점검 화면이며, 옮기기로 정한 항목은 회사의 절차대로 처리합니다.
• 중단영업 해당 여부를 판정하지 않습니다. IFRS 5 요건에 따른 판정은 화면 밖에서 이루어지고, 이 화면은 이미 정해진 분류를 받아 범주 안에 있는지만 봅니다.
• 비교기간 재작성의 범위를 정하지 않습니다. 전기 비교금액이 재표시되었는지 여부만 신호로 띄우며, 재작성의 범위와 방법은 원문 확인이 필요합니다.

CDS 구성

이 사례의 화면은 가상의 두 회사에서 만든 손익 항목 25건, 전표 라인 34건을 서비스에서 받아 보여 줍니다. 데모라서 되는 일이고, 운영 데이터에서는 항목 집계를 CDS 로 내리고 화면은 그 결과만 받습니다. 아래는 그때 만드는 뷰의 스케치입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스·환경에 따라 다르므로 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 사업 단위 분류의 출처(매핑 뷰)와 범주 판정 조건은 회사 정책에 따라 달라지므로 확인이 필요합니다.

뷰 레이어 구성

뷰 스케치

ZI_DiscOpsMap

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '손익 계정 묶음 매핑'
define view entity ZI_DiscOpsMap
  as select from zdiscops_map          // 매핑 테이블(스케치용 이름)
{
  key GLAccount,
      ItemId,
      ItemName,
      UnitId,              // 사업 단위
      LineKind,            // OPS 영업손익 · MEAS 측정손익 · DISP 처분손익 · TAX 법인세효과
      NatCat,              // 항목의 성격상 범주(영업·투자·재무·법인세)
      BookCat              // 장부에 부여된 범주
}

ZI_DiscOpsUnit

@EndUserText.label: '사업 단위 중단영업 분류'
define view entity ZI_DiscOpsUnit
  as select from zdiscops_unit         // 사업 단위 마스터(스케치용 이름)
{
  key UnitId,
      UnitName,
      DiscFlag,            // Y 중단영업 · N 계속영업 · C 분류 시점 확인 필요
      RestatedPrior        // 전기 비교금액 재표시 완료 여부
}

ZI_DiscOpsItem

@EndUserText.label: '손익 항목 장부 범주'
define view entity ZI_DiscOpsItem
  as select from I_JournalEntryItem as Je
  association [0..1] to ZI_DiscOpsMap  as _Map  on _Map.GLAccount = Je.GLAccount
  association [0..1] to ZI_DiscOpsUnit as _Unit on _Unit.UnitId   = _Map.UnitId
{
  key Je.CompanyCode,
  key Je.FiscalYear,
  key _Map.ItemId,
      _Map.ItemName,
      _Map.LineKind,
      _Map.NatCat,
      _Map.BookCat,
      _Unit.DiscFlag,
      _Unit.RestatedPrior,
      max( Je.PostingDate ) as PostDate,
      sum( Je.AmountInCompanyCodeCurrency ) as BookAmt
}
where Je.Ledger = '0L'
group by Je.CompanyCode, Je.FiscalYear, _Map.ItemId, _Map.ItemName,
         _Map.LineKind, _Map.NatCat, _Map.BookCat,
         _Unit.DiscFlag, _Unit.RestatedPrior

ZC_DiscOpsExpected

/* 점검 기준 범주 — 사업 단위의 분류로 정한다. 위에서 아래로 처음 걸리는 조건 */
define view entity ZC_DiscOpsExpected
  as select from ZI_DiscOpsItem
{
  key CompanyCode, key FiscalYear, key ItemId,
      BookCat, BookAmt,
      case when DiscFlag = 'C' then 'C'          // 분류 시점 확인 필요
           when DiscFlag = 'Y' then 'DSC'        // 중단영업 사업의 손익
           else NatCat end as ExpCat,            // 계속영업은 성격상 범주
      case when DiscFlag = 'C'                             then 'D09'
           when DiscFlag = 'Y' and BookCat <> 'DSC'
                and LineKind = 'TAX'                       then 'D03'
           when DiscFlag = 'Y' and BookCat <> 'DSC'        then 'D01'
           when DiscFlag <> 'Y' and BookCat = 'DSC'        then 'D02'
           when DiscFlag = 'Y' and RestatedPrior = 'N'     then 'D04'
           else 'D00' end as CheckCode
}

ZC_DiscOpsCat

/* 범주별 합계 — 장부 기준과 점검 기준을 나란히 */
define view entity ZC_DiscOpsCat
  as select from ZC_DiscOpsExpected
{
  key CompanyCode, key FiscalYear,
  key BookCat as CatCode,
      count(*)                                         as ItemCnt,
      sum( BookAmt )                                   as BookAmt,
      sum( case when ExpCat = BookCat then BookAmt
                else 0 end )                           as KeptAmt
}
group by CompanyCode, FiscalYear, BookCat
/* 점검 기준 금액은 ExpCat 으로 따로 모아 같은 키로 맞춰 붙인다 */

ZC_DiscOpsCompose

/* 중단영업 범주 구성 — 줄 단위로 장부 금액과 점검 기준 금액 */
define view entity ZC_DiscOpsCompose
  as select from ZC_DiscOpsExpected as E
  inner join ZI_DiscOpsItem as I
    on I.CompanyCode = E.CompanyCode and I.ItemId = E.ItemId
{
  key E.CompanyCode, key E.FiscalYear,
  key I.LineKind,
      sum( case when E.BookCat = 'DSC' then E.BookAmt else 0 end ) as BookInDsc,
      sum( case when E.ExpCat  = 'DSC' then E.BookAmt else 0 end ) as ExpInDsc
}
group by E.CompanyCode, E.FiscalYear, I.LineKind

화면 필드와 원천

화면과 서비스 사이의 약속(엔티티셋 5종과 함수 1건)은 앱 설명서의 OData 절에 정리해 두었습니다. 운영 서비스를 만들 때는 그 약속대로 다섯 엔티티셋을 내려 주면 화면은 고치지 않아도 됩니다.

자주 묻는 질문

도입 상담에서 자주 받는 질문들을 네 묶음으로 나눠 적었습니다. 모두 25개입니다. 기준서의 세부 사항은 원문 확인이 필요하다고 표시했습니다.

범위와 기준

점검 규칙

숫자와 대사

도입과 운영