손익 범주 분류 변경 영향 점검 — 비교기간이 새 범주로 함께 옮겨졌는지 변경건·월·소계로 다시 구해 원장과 맞춰 보는 화면

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

손익계산서의 범주를 바꾸는 일은 계정 하나의 분류표를 고치는 것으로 끝나지 않습니다. 새 범주로 바꾼 뒤에는 비교기간 금액과 적용일 이전 당기 금액도 같은 범주로 옮겨져 있어야 하고, 옮긴 만큼 영업이익은 달라져도 당기순이익은 그대로여야 합니다. 이 확인은 지금 엑셀 위에서 계정별로 손으로 이루어집니다. 이 앱은 변경건 단위로 그 확인을 자동으로 다시 계산해 어느 건의 어느 달이 옮겨지지 않았는지를 바로 보여 줍니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 24건 가운데 11건은 한 번 더 봐야 합니다

샘플은 가상 회사 두 곳(1000 · 2000)의 2026년 분류 변경건 24건입니다. 화면은 이 중 13건을 정상, 8건을 점검 필요, 3건을 확인 필요로 가려냅니다. 점검 필요 8건 가운데에는 비교기간 금액이 하나도 옮겨지지 않은 건, 일부 월만 옮겨진 건, 사유나 승인이 없는 건, 적용일 이전 당기 금액이 남은 건이 섞여 있습니다. 상단 요약에는 미이동 금액 합계 475.9백만원과 영업이익 변동 +271.2백만원이 한 줄로 나오고, 당기순이익 변동은 0.0 으로 확인됩니다.

이 숫자들은 "회계처리가 틀렸다"는 선언이 아닙니다. 재분류 처리를 다시 들여다볼 순서를 정하는 신호입니다. 확인 필요로 분류된 3건은 이전 범주와 새 범주가 같거나 적용일이 조회 회계연도 밖이어서, 변경이 맞는지부터 회사가 확인해야 합니다.

도입하면 달라지는 것

• 점검 순서 — 어느 변경건부터 열어 볼지가 점검 코드와 이동 차이 금액으로 정해집니다.
• 설명의 단위 — "합계가 안 맞는다"가 아니라 "이 건의 이 달이 옮겨지지 않았다"로 이야기합니다.
• 같은 숫자의 재사용 — 화면·CSV·서비스가 같은 계산을 쓰므로 보고서마다 다른 숫자가 나오지 않습니다.
• 증빙의 위치 — 사유와 승인이 없는 건이 코드로 따로 모여 증빙 보완 대상이 한눈에 보입니다.

이런 회사에 맞습니다

IFRS 18 적용을 준비하며 손익 계정의 범주 매핑을 바꾸고 있는 회사, 비교기간을 새 범주로 다시 표시해야 하는 연결·별도 결산팀, 그리고 변경 이력을 감사인에게 설명할 자료가 필요한 재무보고 조직에 맞습니다. 범주 매핑을 한 번도 바꾸지 않는 회사에는 필요하지 않습니다.

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

점검 도구에서 가장 비싼 질문은 "이 도구의 계산이 맞나"입니다. 그래서 먼저 대사식을 세우고 전수로 돌렸습니다. 아래는 샘플 자료의 결과입니다.

앞의 일곱 식은 모두 차이가 0 이고, 이 밖에 독립 재계산 검사를 더해 모두 538건을 확인해 차이는 없었습니다. 마지막 두 식의 차이는 샘플에 일부러 넣은 점검 대상에서 나오는 값이며 계산 오류가 아닙니다. 화면은 별도로 브라우저 자동화로 열어 조회조건·탭 전환·상세 창·CSV 내려받기를 확인했습니다.

도입 후 쓰는 순서

1. 회계연도를 넣고 조회를 누릅니다. 회사·이전 범주·새 범주·계정·적용일 범위는 필요할 때만 좁힙니다.
2. 상단 요약 여섯 지표로 규모를 봅니다 — 조회된 변경건, 점검·확인 필요 건, 미이동 금액, 영업이익·당기순이익 변동, 대사 차이.
3. 점검 결과를 "점검 필요"로 고르면 옮겨지지 않았거나 증빙이 없는 건만 남습니다.
4. 건을 눌러 상세 창에서 기대 이동액과 장부 이동액, 월별 내역을 봅니다.
5. 범주·소계 탭에서 재분류 후 금액이 원장과 맞는지, 대사 결과 탭에서 계산 자체가 맞는지 확인합니다.
6. 필요하면 CSV 로 내려받아 담당자에게 조치를 요청합니다.

실행 화면

실제로 돌아가는 화면 8종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

처음 열었을 때

조회조건은 회계연도만 필수입니다. 회사·이전 범주·새 범주·계정·적용일 범위·점검 코드·점검 결과는 비워 두면 조건에서 빠집니다. 요약 지표는 조회된 변경건 24건, 점검·확인 필요 11건, 미이동 금액 475.9백만원, 영업이익 변동 +271.2백만원, 당기순이익 변동 0.0, 대사 차이 0 입니다. 금액 단위가 지표마다 달라 화면 위에 단위를 한 줄로 적어 두었습니다.

점검 필요 건만 좁히기

24건 가운데 8건이 남습니다. 비교기간 원보고 금액은 있는데 비교기간 이동이 0 이거나, 사유·승인 칸이 비어 있는 건이 주황색 "점검 필요"로 표시됩니다. 이동 금액이 0 인 칸은 지워지지 않고 0 으로 남아 "옮겨지지 않았다"는 사실이 보입니다.

적용일은 시작과 종료를 한 범위로 묶어 서비스에 보냅니다. 한쪽만 입력하면 그쪽 경계만 걸립니다. 시작이 종료보다 늦으면 조회하지 않고 안내를 띄웁니다.

건에서 월까지

상세 창은 판정 근거를 한 자리에 모은 곳입니다. 비교기간 원보고 금액과 이동 금액, 적용일 이전 당기 금액과 이동 금액, 장부 이동액과 기대 이동액의 차이, 그리고 점검 결과 문구가 나란히 있어, 담당자에게 "무엇을 확인해 달라"고 그대로 전달할 수 있습니다.

남은 금액이 0 이 아닌 달이 곧 옮겨지지 않은 달입니다. 비교기간 12개월과 적용일 이전 당기 월이 같은 표에 구분되어 놓입니다.

범주와 소계

범주별로 변경 전 금액, 들어온 금액, 나간 금액, 순이동, 재분류 후 금액, 원장 반영 금액, 차이가 한 줄에 놓입니다. 소계 줄은 별도로 표시되며, 범주 사이 이동은 합이 0 이어서 당기순이익이 그대로인 것을 확인할 수 있습니다.

앞의 일곱 식은 계산 자체를 검증하는 식이고 차이가 0 이어야 합니다. 뒤의 두 식은 점검 대상 차이를 모으는 식이라 차이가 나는 것이 정상 동작입니다. 이 둘을 같은 색으로 칠하지 않고 구분해 두었습니다.

데이터 서비스를 열어 보면

주소는 모두 앱 기준 상대 경로이고, 복사 버튼·닫기 버튼·배경 클릭·ESC 키로 다룰 수 있습니다. 서비스 문서·엔티티셋 네 개·함수 세 개가 모두 이 방식으로 설명되어 있습니다.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 아래 표의 표준 거래 이름과 동작은 릴리스와 환경에 따라 다를 수 있어 확인 필요입니다.

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

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지 적었습니다. 운영에 올릴 때 "기존 확인 절차를 없애야 하느냐"는 질문이 꼭 나오는데, 대부분은 없애지 않고 둡니다 — 최종 대사와 감사 대응은 표준 거래가 맡는 편이 안전합니다.

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

S/4HANA 에서는 CDS 뷰로 만든 분석 쿼리를 표준 Fiori 앱이 그대로 띄워 줍니다. 이 앱을 올리기 전에 표준 스택으로 먼저 되는지를 확인하는 편이 좋습니다.

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

1. 변경건 원천을 정한다. 샘플은 변경건을 자료로 들고 있습니다. 운영에서는 범주 변경 이력을 어느 테이블·결재 문서에서 읽을지 먼저 합의해야 합니다 (확인 필요).
2. 범주 매핑을 회사 기준으로 바꾼다. 샘플은 영업·투자·재무·법인세·중단영업 다섯 범주입니다. 실제 계정과목표와 사내 손익 체계에 맞는 매핑 테이블을 하나 두고 거기서 읽습니다.
3. 비교기간 이동 기준을 정한다. 비교기간을 전기 12개월로 볼지, 공시 대상 기간 전체로 볼지는 회사와 감사인이 정할 일입니다.
4. 집계를 CDS 로 내린다. 월별 내역과 범주 집계를 DB 에서 만들고, 화면은 표시만 맡습니다.
5. 권한을 표준 객체로 건다. 범주 합계를 읽는 자리에 회사코드 권한을 건 DCL 을 붙입니다.
6. 점검 코드의 기준을 합의한다. 샘플의 여섯 코드 판정은 점검용 약속입니다. 회사 기준에 맞게 조건과 우선순위를 조정하고 문서로 남깁니다.

CDS 구성

이 사례의 화면은 샘플 자료를 서비스에서 읽어 옵니다. 운영 데이터에서는 집계를 CDS 로 내리는 것이 첫 작업입니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

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

뷰 레이어 구성

① 범주 매핑과 변경건 테이블

범주가 어디에서 어디로 바뀌었고 언제부터 적용되는지를 담는 자리입니다. 운영 전환에서 가장 먼저 합의해야 하는 항목이며, 이력이 지워지지 않도록 적용일을 키에 둡니다.

" ────────────────────────────────────────────────────────────────
"  ZCAT_CHANGE — 손익 범주 분류 변경건 (투명 테이블)
"  확인 필요: 변경 이력을 이미 다른 곳에서 관리한다면 그 원천을 읽는다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '손익 범주 분류 변경건'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcat_change {
  key mandt    : mandt not null;
  key bukrs    : bukrs not null;
  key gjahr    : gjahr not null;
  key chgno    : abap.numc(3) not null;   " 변경 번호
  racct        : racct;                    " 계정
  old_cat      : abap.char(3);             " 이전 범주 OPR/INV/FIN/TAX/DSC
  new_cat      : abap.char(3);             " 새 범주
  eff_date     : abap.dats;                " 적용일
  reason_code  : abap.char(3);             " 사유 코드 (없으면 점검 대상)
  approved     : abap.char(1);             " X = 승인
  appr_doc     : abap.char(12);            " 승인 문서 번호 (확인 필요)
}

② 변경건 차원 뷰

계정 텍스트와 범주 이름을 여기서 붙여, 아래 큐브가 join 을 반복하지 않게 합니다.

@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label                : '분류 변경건 차원'
@Analytics.dataCategory           : #DIMENSION
define view entity ZI_CatChange
  as select from zcat_change as c
  association [0..1] to skat as _txt
    on  _txt.saknr = c.racct
    and _txt.spras = $session.system_language   " 계정과목표 조건 확인 필요
{
  key c.bukrs  as Bukrs,
  key c.gjahr  as Gjahr,
  key c.chgno  as ChgNo,
      c.racct  as Racct,
      _txt.txt20 as RacctText,
      c.old_cat as OldCat,
      c.new_cat as NewCat,
      c.eff_date as EffDate,
      case when c.reason_code = '' or c.approved = '' then 'X' else '' end as NoEvidence
}

③ 월별 이동 큐브

ACDOCA 에서 변경건의 계정을 월 단위로 모읍니다. 비교기간(전기)과 당기를 구분하는 열을 따로 둡니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '분류 변경 월별 이동 큐브'
@Analytics.dataCategory           : #CUBE
define view entity ZI_CatLineCube
  as select from acdoca as a
  inner join ZI_CatChange as c
    on  c.Bukrs = a.rbukrs
    and c.Racct = a.racct
{
  key a.rbukrs as Bukrs,
  key c.ChgNo,
  key a.gjahr  as Gjahr,
  key a.poper  as Monat,
      c.OldCat,
      c.NewCat,
      @Semantics.amount.currencyCode : 'Hwaer'
      @Aggregation.default           : #SUM
      a.hsl    as OrigAmt,               // 필드·부호 규칙 확인 필요
      a.rhcur  as Hwaer
}
where a.rldnr = '0L'                    // 원장 확인 필요

④ 범주 집계 큐브

범주별 들어온·나간 금액과 재분류 후 금액을 한 번만 정의합니다. 화면의 "범주·소계" 탭이 이 값을 읽습니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '범주 재분류 집계 큐브'
@Analytics.dataCategory           : #CUBE
define view entity ZI_CatSummaryCube
  as select from ZI_CatLineCube
{
  key Bukrs,
  key Gjahr,
  key NewCat as CatCode,
      sum( OrigAmt ) as InAmt,           // 새 범주로 들어간 금액
      sum( 0 )       as OutAmt           // 나간 금액은 OldCat 기준 별도 집계 후 합침 (확인 필요)
}
group by Bukrs, Gjahr, NewCat

⑤ 분석 쿼리

표준 Fiori 앱과 Analysis for Microsoft Office 가 그대로 띄우는 자리입니다. 기본 행 축은 범주, 열 축은 회계연도입니다.

@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '범주 재분류 쿼리'
@Analytics.query                  : true
define view entity ZC_CatShiftQuery
  as select from ZI_CatSummaryCube
{
  @AnalyticsDetails.query.axis : #ROWS
  key CatCode,
  @AnalyticsDetails.query.axis : #COLUMNS
  key Gjahr,
  @AnalyticsDetails.query.axis : #FREE
  key Bukrs,
      InAmt,
      OutAmt
}

⑥ 권한 (DCL)

집계를 읽는 자리에 걸어 상세에서만 막았을 때 생기는 "뺄셈으로 알아내기"를 막습니다. 객체 이름과 활동 값은 확인 필요입니다.

@EndUserText.label : '범주 재분류 집계 권한'
@MappingRole : true
define role ZI_CATSUMMARYCUBE {
  grant select on ZI_CatSummaryCube
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

위 코드는 설명용 스케치이며 실제 활성화 전에 표준 필드명, 원장 조건, 계정과목표, 권한 객체를 확인해야 합니다. 확인하지 못한 항목은 "확인 필요"로 남겼습니다.

자주 묻는 질문

도입 상담에서 자주 받는 질문들입니다. 네 묶음으로 나눠 적었습니다. 모든 답은 점검 도구라는 전제에서 읽어야 합니다.

범위와 용도

숫자와 산식

데이터와 서비스

운영 전환