경영진 성과측정치(MPM) 정의 변경 점검 — IFRS 18, 지표 정의가 바뀌면 사유·영향 공시와 전기 비교금액 재작성이 맞는지 다시 계산해 대조한다

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

경영진 성과측정치(MPM)는 회사가 스스로 정의한 지표입니다. 정의가 한 번 바뀌면 질문이 세 개 따라옵니다. 왜 바꿨는지 공시했나, 금액에 미치는 영향을 적었나, 전기 비교금액을 새 정의로 다시 만들었나. 지금은 이 세 답이 공시 초안 · 엑셀 조정표 · 메일 속에 따로 있습니다. 이 앱은 세 답을 한 화면에서 장부 숫자와 맞춰 봅니다.

앞선 글의 경영진 성과지표 조정표가 한 시점의 지표를 소계로 되돌리는 화면이라면, 이 글의 화면은 정의가 바뀐 지표의 전기 비교정보를 따로 봅니다. 두 화면은 같은 조정항목 개념 위에 있어서 이어서 쓸 수 있습니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 3,007 백만 원이 비어 있던 이유

이 사례 데이터에서 회사 2000 의 신규 지표(핵심 영업이익)는 새로 정의됐지만, 전기 비교금액이 공시에는 0으로 남아 있었습니다. 조정항목에서 다시 계산한 기대 재작성 금액은 3,007 백만 원이었고 차이는 −3,007 백만 원입니다. 공시 초안의 문구만 읽어서는 보이지 않던 숫자가 화면 맨 위 점검 필요 줄에 올라옵니다. 같은 회사의 조정 당기순이익(정의 변경)은 기대 재작성 −233 백만 원인데 공시가 0 이어서 233 백만 원 차이로 잡힙니다.

회사 1000 의 조정 영업이익은 정의 변경이 확인되고 재작성도 되어 있지만, 공시된 재작성 금액이 기대보다 12 백만 원 큽니다. 이 정도 금액은 반올림이나 매핑 차이일 수도 있어서 원인을 단정하지 않고 조정항목 탭으로 안내합니다. 반대로 금액은 맞는데 사유나 영향 문구가 비어 있는 지표(M01·M02)도 함께 올라옵니다.

판정 규칙 — 위에서 아래로 처음 걸리는 하나

도입하면 달라지는 것

• 공시 전 점검 시간 — 지표마다 사유·영향·재작성 문구를 찾아다니던 일이 한 표를 훑는 일로 줄어듭니다.
• 회의의 주제 — "이 비교금액 어디서 나왔나"가 아니라 "차이가 난 이유가 무엇인가"를 이야기합니다.
• 근거가 남는 점검 — 판정 코드와 기대 금액 산식이 화면에 그대로 있어 감사인 질의에 같은 자료로 답합니다.
• 단정하지 않는 표현 — 점검 필요·확인 필요로만 표시해 화면이 회계 결론을 대신하지 않습니다.

이런 회사에 맞습니다

영업이익이나 EBITDA 같은 자체 지표를 공시하면서 매년 정의를 다듬는 회사, IFRS 18 도입을 앞두고 비교정보 재작성 절차를 미리 점검해 보려는 재무보고팀, 그리고 공시 초안과 장부 숫자를 맞추는 일이 엑셀에 흩어져 있는 결산 조직에 맞습니다.

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

만드는 쪽에서 먼저 대사식을 세워 검증용 샘플 데이터 전수로 돌렸습니다. 아래는 이 사례의 결과입니다.

R01~R05 는 데이터가 스스로 맞는지 보는 정합성 대사로 모두 차이가 없습니다. R06 은 점검 화면이라 일부러 넣은 예외가 걸려 나오는 값이며, 앞의 정합성 차이와 섞지 않고 따로 기록합니다. 이 외에 서비스 검증(필터 조건, 날짜 구간, 함수 결과)과 화면 실행 검증을 따로 돌렸습니다.

도입 후 쓰는 순서

1. 회계연도를 정하고 조회를 누릅니다. 필요하면 회사, 변경 구분, 변경 적용일 구간을 좁힙니다.
2. 위쪽 요약에서 정의 변경·신규·중단과 점검 필요 건수를 봅니다.
3. MPM 변경 점검 탭에서 점검 필요 줄부터 훑습니다. 코드(M01~M09)가 무엇이 비어 있는지 알려 줍니다.
4. 줄을 눌러 상세를 열고 조정항목 내역과 소계 대사를 봅니다.
5. 조정항목 변경 → 소계 대사 → 대사 결과 탭 순서로 근거를 확인합니다.
6. 필요한 탭은 CSV 로 내려받아 공시 초안 점검표에 붙입니다.

실행 화면

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

처음 열면 기본 조건(회계연도 2026)으로 자동 조회됩니다. 요약 카드는 점검 필요 7건·확인 필요 1건처럼 건수를 먼저 보여 주고, 아래 표에서 어느 지표인지 찾아 내려가게 했습니다. 조회 버튼은 입력 칸 오른쪽 끝에 두었고 Enter 키로도 조회됩니다.

정의가 바뀐 지표가 점검의 중심입니다. 변경 적용일 구간과 점검 코드까지 함께 걸 수 있어서, 올해 1월 1일 적용분만 따로 보는 식으로 범위를 좁힙니다. 조건은 모두 $filter 로 서비스에 전달됩니다.

재작성 금액의 근거가 모이는 자리입니다. 지표 하나가 어떤 조정항목을 새로 품었고 무엇을 내보냈는지, 그 항목의 당기·전기 금액이 얼마인지를 한 표에서 확인합니다. 금액 단위는 원이며 화면에는 천 단위 구분이 붙습니다.

조정표의 기본 산식을 세 기준(당기, 옛 정의의 전기, 새 정의의 전기)으로 모두 검산합니다. 이 대사가 어긋나면 재작성 금액을 논하기 전에 조정항목 집계부터 의심해야 하므로, 판정 화면과 같은 앱 안에 두었습니다.

상세 창에는 조정항목 내역과 소계 대사가 같이 있어 목록 화면으로 되돌아가지 않아도 근거를 끝까지 따라갈 수 있습니다. 판정 문구는 단정하지 않고 '확인이 필요합니다' 형태로만 적습니다.

R01~R05 는 데이터가 스스로 맞는지 보는 정합성 대사이고 모두 차이 0 입니다. R06 은 공시 금액이 기대 금액과 다른 지표를 세는 공시 점검 대사로, 점검 화면이라 일부러 넣은 4건이 차이로 나옵니다. 두 종류를 섞어 세지 않도록 구분해 표시합니다.

연계 설계와 보안 검토에서 가장 먼저 찾는 정보를 설명서 안에서 바로 복사해 가도록 했습니다. 팝업은 복사 버튼, X 버튼, 배경 클릭, ESC 로 닫힙니다.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다.

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

표준 거래와의 연계 지점

OData 계약 — 화면이 실제로 부르는 주소

서비스 이름은 소문자 한 가지로 고정했습니다. 엔티티셋 네 개와 펑션 하나로 구성됩니다.

조회조건은 모두 $filter 로 전달됩니다. 회계연도는 eq, 회사는 선택 eq, 변경 구분은 eq, 변경 적용일은 ge·le 한 묶음, 점검 코드와 점검 결과는 eq, 지표 이름은 부분 일치입니다. 금액은 Edm.Decimal 문자열, 날짜는 Edm.DateTime 으로 내려갑니다.

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

1. 조정항목 매핑을 먼저 확정한다. 어느 계정이 어느 항목이고 옛·새 정의에 각각 들어가는지를 표로 정합니다. 여기서 숫자가 갈립니다.
2. 공시 확인 여부의 원천을 정한다. 사유·영향·재작성 문구가 공시 초안 어디에 있고 누가 확인 표시를 하는지가 정해져야 판정이 의미를 가집니다.
3. 집계를 CDS 로 내린다. 이 사례는 샘플 데이터를 서비스가 읽습니다. 운영에서는 아래 CDS 구성처럼 DB 에서 합산합니다.
4. 반올림 기준을 정한다. 공시 금액이 백만 원 단위라면 기대 금액도 같은 단위로 맞춘 뒤 비교할지를 정해야 작은 차이에 경고가 쏟아지지 않습니다.
5. 권한을 집계 단계에 건다. 회사별 지표는 합계 카드까지 같은 권한으로 묶어야 뺄셈으로 새지 않습니다.
6. 점검 주기를 배치로 둔다. 마감 주간에 정기 실행해 점검 필요 건수가 변하는 것을 추적합니다.

CDS 구성

아래는 운영으로 올릴 때 만드는 뷰를 레이어 순서대로 적은 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스와 환경에 따라 다르므로, 붙여 넣기 전에 View Browser 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적었습니다.

뷰 레이어 구성

① 조정항목 매핑 기준

어느 계정이 어느 조정항목인지, 어느 지표 정의(옛·새)에 포함되는지를 정하는 기준입니다. 이 표가 비어 있으면 재작성 금액은 계산할 수 없으므로 도입에서 가장 먼저 합의하는 항목입니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@EndUserText.label: 'MPM 조정항목 매핑'
define view entity ZI_MpmAdjMap
  as select from zmpm_adjmap            // 확인 필요: 실제 기준 테이블 이름
{
  key MpmId,
  key AdjItemNo,
  key ValidFrom,
      GLAccountFrom,
      GLAccountTo,
      InOldDef,        // 옛 정의에 포함되는가
      InNewDef,        // 새 정의에 포함되는가
      ValidTo
}

② 조정항목 금액 뷰

ACDOCA 의 손익 계정 금액을 조정항목과 회계연도별로 모읍니다. 당기와 전기를 같은 뷰에서 만들어 재작성 영향이 같은 산식에서 나오게 합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'MPM 조정항목 금액'
define view entity ZI_MpmAdjAmount
  as select from I_JournalEntryItem as Je    // 확인 필요: 릴리스별 표준 뷰 이름
  association [0..*] to ZI_MpmAdjMap as _Map
    on  $projection.GLAccount >= _Map.GLAccountFrom
    and $projection.GLAccount <= _Map.GLAccountTo
{
  key Je.CompanyCode,
  key Je.FiscalYear,
  key Je.GLAccount,
      Je.AmountInCompanyCodeCurrency as Amount,
      _Map
}
where Je.Ledger = '0L' 

③ 소계(IFRS) 뷰

손익 계정을 영업이익·당기순이익 범주로 합산한 소계입니다. 지표에서 조정항목을 빼면 이 값으로 돌아와야 소계 대사가 맞습니다.

@EndUserText.label: 'MPM 기준 IFRS 소계'
define view entity ZI_MpmIfrsBase
  as select from I_JournalEntryItem as Je
    inner join   ZI_PnlAccount      as Ac on Ac.GLAccount = Je.GLAccount
{
  key Je.CompanyCode,
  key Je.FiscalYear,
  key Ac.SubtotalType,                 // 영업이익 / 당기순이익
      sum( Je.AmountInCompanyCodeCurrency * Ac.SignFactor ) as IfrsAmount
}
where Je.Ledger = '0L'
group by Je.CompanyCode, Je.FiscalYear, Ac.SubtotalType

④ 지표별 금액과 재작성 영향

당기, 옛 정의의 전기, 새 정의의 전기 세 금액을 한 행에 세웁니다. 기대 재작성 금액은 이 세 금액의 차이로만 만들어 화면에서 다시 계산하지 않게 합니다.

@EndUserText.label: 'MPM 금액 3기준'
define view entity ZC_MpmRestate
  as select from ZI_MpmAdjAmount as A
    inner join   ZI_MpmAdjMap    as M on M.MpmId is not null
{
  key A.CompanyCode,
  key M.MpmId,
      sum( case when A.FiscalYear = $parameters.p_year
                 and M.InNewDef = 'X' then A.Amount else 0 end )      as CurAmt,
      sum( case when A.FiscalYear = $parameters.p_year - 1
                 and M.InOldDef = 'X' then A.Amount else 0 end )      as PrvRepAmt,
      sum( case when A.FiscalYear = $parameters.p_year - 1
                 and M.InNewDef = 'X' then A.Amount else 0 end )      as PrvRstAmt
}
group by A.CompanyCode, M.MpmId

⑤ 공시 관리 입력

사유·영향·비교 재작성 공시 여부, 정의 변경 이력은 전표에서 나오지 않습니다. 공시 초안을 관리하는 쪽의 입력을 읽는 뷰로 두고, 여기서 읽지 못하면 점검 규칙은 '확인되지 않음'으로 떨어집니다.

@EndUserText.label: 'MPM 공시 관리 입력'
define view entity ZI_MpmDisclosure
  as select from zmpm_disc              // 확인 필요: 공시 관리 원천
{
  key CompanyCode,
  key MpmId,
  key FiscalYear,
      ChgType,          // DEF 정의 변경 / NEW 신규 / STOP 중단 / SAME 변경 없음
      ChgDate,
      ReasonYn,         // 사유 공시 확인
      EffectYn,         // 금액 영향 공시 확인
      RestateYn,        // 비교정보 재작성 확인
      BookRestAmt       // 공시된 재작성 금액
}

⑥ 판정 쿼리

기대 금액과 공시 금액을 맞붙여 판정 코드를 만듭니다. 판정은 위에서 아래로 처음 걸리는 조건 하나만 쓰므로 case 의 순서가 곧 규칙의 순서입니다.

@EndUserText.label: 'MPM 변경 점검'
@Analytics.query: true
define view entity ZC_MpmChgCheck
  as select from ZC_MpmRestate  as R
    inner join   ZI_MpmDisclosure as D
      on  D.CompanyCode = R.CompanyCode and D.MpmId = R.MpmId
{
  key R.CompanyCode,
  key R.MpmId,
      D.ChgType,
      ( R.PrvRstAmt - R.PrvRepAmt )                       as ExpRestAmt,
      D.BookRestAmt,
      ( D.BookRestAmt - ( R.PrvRstAmt - R.PrvRepAmt ) )   as DiffAmt,
      case
        when D.ChgType = 'SAME' and D.BookRestAmt =  0 then 'M00'
        when D.ChgType = 'SAME'                        then 'M05'
        when D.ReasonYn  <> 'X'                        then 'M01'
        when D.ChgType = 'STOP'                        then 'M09'
        when D.EffectYn  <> 'X'                        then 'M02'
        when D.RestateYn <> 'X'                        then 'M03'
        when D.BookRestAmt <> ( R.PrvRstAmt - R.PrvRepAmt ) then 'M04'
        else 'M00'
      end                                                 as CheckCode
}

⑦ 권한 (DCL)

지표 금액은 회사 단위로 민감하므로 집계를 읽는 자리에 회사코드 권한을 겁니다. 목록에만 걸고 합계 카드에 걸지 않으면 빼기로 남의 회사 숫자가 드러납니다.

@EndUserText.label: 'MPM 점검 권한'
@MappingRole: true
define role ZC_MPMCHGCHECK {
  grant select on ZC_MpmChgCheck
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 왼쪽은 대부분 코딩이 아니라 합의입니다.

점검 필요·확인 필요는 개별 확인 신호이며 공시 적정성에 대한 결론이 아닙니다. 기준서 요구사항과 문단은 원문에서 확인한 뒤 적용하시기 바랍니다.

자주 묻는 질문

도입 상담과 데모에서 나온 질문 24개를 다섯 묶음으로 적었습니다.

판정과 해석

금액과 산식

데이터와 연계

범위와 한계

화면과 도입