SAP 법인세 범주 손익 귀속 점검 — IFRS 18, 법인세 범주에 담길 손익이 제자리에 놓였는지 세 질문으로 다시 따져 장부와 맞춰본다

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

결산 때 법인세 범주를 두고 나오는 질문은 늘 비슷합니다. 법인세 범주에 담긴 금액이 정말 법인세비용인가, 담겨야 하는데 다른 범주에 놓인 금액은 없나, 중단영업 몫이 법인세 범주에 섞이지 않았나. IFRS 18 은 손익을 영업·투자·재무·법인세·중단영업 다섯 범주로 나누어 표시하도록 하므로, 범주를 잘못 놓으면 소계가 달라지고 비교하는 숫자도 흔들립니다. 지금은 이 확인이 계정 잔액 조회, 엑셀 분류표, 담당자의 기억에 흩어져 있습니다. 이 앱은 그 확인을 한 화면에 모아, 어디가 다른지를 먼저 보여 줍니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 법인세 범주가 1.85억 달랐던 이유

가상의 회사 1000 에서 법인세 범주의 장부 금액은 −64.00억, 점검 기준 금액은 −62.15억으로 1.85억 차이가 났습니다. 합계만 보면 “법인세가 1.85억 더 잡혔다”로 끝났을 이야기가, 구성 줄을 펼치자 두 방향의 이동이 겹친 결과로 풀립니다.

들어올 몫 265백만 원(원천징수세 180 + 외환차이 85)과 나갈 몫 450백만 원(재산세 310 + 중단영업 140)의 차이가 185백만 원입니다. 한 방향만 보았다면 놓쳤을 이동입니다. 그리고 이 이동은 당기순이익을 바꾸지 않습니다. 회사 1000 의 5범주 합계는 장부로도 점검 기준으로도 당기순이익 199.47억으로 같습니다. 범주가 달라지면 영업이익 같은 소계와 법인세 범주 금액이 달라지는 것이지 순이익이 달라지는 것이 아닙니다.

화면은 여기까지만 말합니다. 위 네 항목을 실제로 옮길지는 회사의 회계정책과 원문 문단, 감사인의 의견으로 정할 일입니다. 환급가산금 이자(회사 1000)와 가산세(회사 2000)는 그 성격상 단정하지 않고 확인 필요로 남겨 두었습니다.

도입하면 달라지는 것

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

이런 회사에 맞습니다

• IFRS 18 적용에 맞춰 손익 계정 묶음을 다섯 범주로 다시 짜고 있는 재무회계 조직.
• 법인세와 환산 외환차이, 중단영업 손익이 계정별로 흩어져 있어 결산마다 분류표를 손으로 맞추는 회사.
• 감사인에게 범주 분류의 근거를 항목 단위로 보여 줘야 하는 회사.

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

실행 화면

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

처음 열었을 때

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

점검 결과 좁혀 보기

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

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

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

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

한 항목의 근거까지

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

대사와 좁은 화면

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

결산 중에 자리를 옮겨 다니며 확인하는 경우가 많아 폭이 좁은 화면을 따로 확인했습니다.

SAP 표준 기능 확장 포인트

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

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

이 앱이 읽는 자료

항목의 “장부 범주”는 손익 계정 묶음에 회사가 부여해 둔 범주이고, 세 질문의 답은 계정 묶음별로 둔 속성입니다. 운영에서는 이 속성을 어디에 둘지(계정 묶음 마스터, 별도 매핑 테이블 등)가 먼저 정해져야 하며, 이는 도입할 때 가장 시간을 쓰는 부분입니다.

이 앱이 하지 않는 것

• 전기·재분류 전표를 만들지 않습니다. 조회와 점검 화면이며, 옮기기로 정한 항목은 회사의 절차대로 처리합니다.
• 중단영업 해당 여부를 판정하지 않습니다. IFRS 5 의 판정은 화면 밖에서 이루어지고, 이 화면은 이미 정해진 소속을 받아 범주 안에 있는지만 봅니다.
• IFRS 18 의 모든 범주 규칙을 다루지 않습니다. 영업·투자·재무 사이의 세부 분류(예: 주된 사업 활동 여부)는 이 화면의 범위 밖입니다.

CDS 구성

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

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

뷰 레이어 구성

뷰 스케치

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '손익 항목 장부 범주'
define view entity ZI_TaxCatItem
  as select from I_JournalEntryItem as Je
  association [0..1] to ZI_TaxCatMap as _Map
    on _Map.GLAccount = Je.GLAccount
{
  key Je.CompanyCode,
  key Je.FiscalYear,
  key _Map.ItemId,
      _Map.ItemName,
      _Map.BookCat,        // 장부에 부여된 범주
      _Map.NatureTax,      // 질문 1: 법인세비용에 포함되는가
      _Map.FxRel,          // 질문 2: 법인세 자산·부채 환산 외환차이인가
      _Map.DiscOps,        // 질문 3: 중단영업에 속하는가
      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.BookCat, _Map.NatureTax, _Map.FxRel, _Map.DiscOps

/* 세 질문의 답으로 점검 기준 범주를 정한다 — 위에서 아래로 처음 걸리는 조건 */
define view entity ZC_TaxCatExpected
  as select from ZI_TaxCatItem
{
  key CompanyCode, key FiscalYear, key ItemId,
      case when DiscOps   = 'Y' then 'DSC'
           when NatureTax = 'Y' then 'TAX'
           when FxRel     = 'Y' then 'TAX'
           when NatureTax = 'C' then 'C'     // 회사 정책 확인 필요
           else BookCat end as ExpCat,
      BookAmt
}

화면 필드와 원천

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

자주 묻는 질문

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

범위와 기준

점검 규칙

숫자와 대사

도입과 운영