SAP 현금흐름표 이자·배당 분류 점검 — IFRS 18, IAS 7 개정으로 달라지는 이자·배당의 활동 구분을 전표로 다시 계산해 장부와 견준다

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

결산 때마다 현금흐름표에서 되풀이되는 질문이 있습니다. 이자와 배당은 어느 활동에 넣어야 하나, 장부에는 어디에 들어가 있나, 그 금액은 맞게 계산됐나. 지금 이 답은 전표 · 엑셀 · 회사 정책 문서에 흩어져 있습니다. IFRS 18 재무제표 표시와 공시(K-IFRS 제1118호)가 현금흐름표의 이자·배당 구분을 바꾸면서(적용 시기는 2027년 1월 1일 이후 개시하는 회계연도, 조기 적용 허용), 이 세 답을 한 화면에서 먼저 맞춰 보려는 수요가 생겼습니다.

사용 방법

1. 회계연도를 확인하고 필요하면 회사 · 유형 · 장부 구분 · 점검 기준 구분 · 전기일 기간 · 항목명을 골라 조회를 누릅니다. 처음 열면 2026 으로 자동 조회됩니다.
2. 위쪽 요약 여섯 가지에서 재분류 검토 필요와 확인 필요 건수를 먼저 봅니다.
3. ‘항목 구분 점검’ 탭에서 점검 결과가 점검 필요인 줄을 찾고, 줄을 눌러 재계산 금액과 전표 라인을 확인합니다.
4. ‘유형별 합계’에서 이자 지급 · 이자 수취 · 배당 지급 · 배당 수취 어느 유형에서 옮겨 볼 금액이 큰지 봅니다.
5. ‘현금흐름표 구성’에서 영업 · 투자 · 재무활동별 장부 금액과 기준 금액의 차이를 보고, 합계의 차이가 0인지 확인합니다.
6. ‘대사 결과’에서 정합성 대사 다섯 가지가 모두 0건인지 확인한 뒤 CSV 내려받기로 점검 목록을 꺼냅니다.

무엇이 바뀌었나 — 이 앱이 점검하는 기준

IFRS 18 은 IAS 7 현금흐름표의 이자·배당 구분 선택권을 줄였습니다. 이 앱은 아래 기준을 ‘점검 기준 구분’으로 삼아 장부와 견줍니다. 기준서 문구와 회사 정책은 반드시 직접 확인해야 하며, 이 표는 점검 규칙을 설명하는 요약입니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 활동별로 옮겨 볼 금액

이 사례 자료(회사 두 곳, 이자·배당 항목 36건)에서 장부와 점검 기준의 구분이 다른 항목은 9건, 회사 정책으로 먼저 가려야 하는 항목은 2건, 재계산 금액이 현금 금액과 다른 항목은 3건입니다. 회사 1000 은 영업활동 안의 이자·배당 -0.6억 원이 기준에서는 0이 되고, 투자활동 유입이 3.95억 원, 재무활동 유출이 4.5억 원 늘어납니다. 회사 2000 은 영업활동 줄의 장부 금액 34.4억 원이 기준에서는 0이 되어 투자활동 유입 64.8억 원 증가, 재무활동 유출 31.7억 원 증가, 확인 필요 1.3억 원으로 나뉩니다. 숫자 자체를 맞다고 단정하지 않고, 어느 줄을 먼저 열어 볼지를 정하는 도구라는 점이 핵심입니다.

도입하면 달라지는 것

• 결산 준비 — 이자·배당 구분 점검이 전표 내려받기와 엑셀 분류에서 한 화면 조회로 바뀝니다.
• 기준 적용 전 영향 파악 — 개정 기준을 적용하기 전에 활동별로 옮겨 볼 금액을 미리 봅니다.
• 정책 논의의 근거 — 회사 정책으로 가려야 하는 건이 따로 모여 있어 논의할 목록이 분명해집니다.
• 감사 대응 — 항목 단위의 재계산 금액과 전표 라인이 남아 설명 자료를 따로 만들지 않습니다.

이런 회사에 맞습니다

차입금 이자와 배당을 많이 지급하는 제조·유통 회사, 예금·MMF·대여금 이자와 종속기업 배당을 받는 지주 성격의 회사, 그리고 현금흐름표를 영업이익 출발점으로 바꾸는 작업을 앞두고 이자·배당 분류부터 미리 맞춰 보려는 재무회계팀에 맞습니다. 주된 사업활동이 대여·투자인 회사는 회사 정책을 먼저 정해야 하므로 ‘확인 필요’로 별도 점검합니다.

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

점검 도구에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 그래서 만드는 쪽에서 대사식을 먼저 세우고 전수로 돌렸습니다. 아래는 이 사례 자료의 결과입니다.

정합성 대사 다섯 가지는 모두 차이 0 이고, 참고 대사의 R07 은 점검 필요 항목을 일부러 남겨 둔 것이라 3건이 나오는 것이 정상입니다. 전기일 조건($filter)은 시작일만, 종료일만, 기간 전체를 걸었을 때 각각 18건 · 18건 · 11건이 나오는지도 확인했습니다.

실행 화면

실제로 돌아가는 화면 7종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 서로 맞춰 보셔도 됩니다. 이 자료는 가상의 값이며, 점검 결과는 ‘점검 필요’ · ‘확인 필요’로만 적었습니다.

처음 열었을 때

조회조건 · 요약 · 결과 표가 한 화면에 세로로 쌓입니다. 맨 위 안내 문구는 이 화면이 개정 기준에 견주는 점검 도구이고 최종 판단은 회사와 감사인이 한다는 점을 항상 보여 줍니다.

처음 열면 조회 버튼을 누르지 않아도 회계연도 2026 으로 자동 조회됩니다. 위쪽 요약은 점검한 항목 수 36, 재분류 검토 필요 9, 확인 필요 2, 재계산 차이 3, 활동별 차이 절댓값 합 14,130.8백만 원, 정합성 대사 차이 0건입니다. 아래 표에서 시설자금 대출 이자는 장부가 영업활동인데 점검 기준은 재무활동이라 ‘점검 필요’로 표시됩니다. 같은 이자 지급이라도 운영자금 대출 이자는 장부와 기준이 모두 재무활동이라 ‘정상’입니다.

조회조건으로 좁히기

회사별, 유형별, 장부 구분별로 좁혀 보고 싶을 때는 조회조건을 씁니다. 항목명은 일부만 넣어도 찾습니다.

조회조건은 회계연도(필수), 회사, 유형, 장부 구분, 점검 기준 구분, 전기일 시작·종료, 항목명, 점검 코드, 점검 결과 열 가지입니다. 요약 지표와 탭 건수는 조건을 바꾸면 함께 바뀝니다. 전기일 기간은 서버가 직접 걸러, 시작일만 넣거나 종료일만 넣어도 맞는 건수가 나옵니다.

유형별 합계와 현금흐름표 구성

같은 36건을 두 가지 방식으로 모읍니다. 유형별 합계는 ‘무슨 돈인가’로, 현금흐름표 구성은 ‘어느 활동에 놓였나’로 모읍니다.

재분류 이동액은 장부의 구분과 점검 기준 구분이 달라 옮겨 볼 금액입니다. 예를 들어 회사 1000 의 이자 지급은 현금 -900,325,000원 가운데 -454,500,000원이 이동 대상이고, 재분류 검토 항목은 2건입니다. 배당 지급은 이동액이 0으로, 장부와 점검 기준이 같은 구분에 있습니다.

차이는 활동 사이를 옮겨 놓은 금액이라 합치면 0이 되어야 합니다. 회사 1000 의 합계는 장부와 기준이 모두 -6,304,200,000원이며 차이 0입니다. 영업활동 줄의 기준 금액이 0인 것은 점검 기준에서 이자·배당이 영업활동에 남지 않기 때문입니다. 회사 2000 에는 ‘확인 필요(정책 판단 대기)’ 줄이 따로 서서, 회사 정책으로 먼저 가려야 하는 건 2개가 활동 구분에 억지로 들어가지 않습니다.

대사 결과

화면이 보여 주는 합계가 맞는지 화면 스스로 대사합니다. 정합성 대사와 참고 대사를 구분해, 차이가 나는 것이 오류인지 의도된 예외인지 읽는 사람이 헷갈리지 않게 했습니다.

좌변과 우변, 검사 건수, 차이 건수, 최대 차이, 대사식이 한 줄에 놓입니다. 항목 현금 합계가 유형별 합계와 같은지(36건), 장부 구분별 합계와 기준 구분별 합계가 항목 합계와 같은지, 재분류 증감 합계가 0인지, 전표 라인 합계가 0인지(72줄)를 봅니다. 재계산 금액과 현금 금액이 다른 항목은 최대 5,000,000원 차이로 3건이 남아 있습니다.

항목 상세

줄을 누르면 한 항목의 근거가 한 팝업에 모입니다. 점검 필요 줄에서 가장 먼저 여는 화면입니다.

시설자금 대출 이자는 기준 금액 20억 원 × 이율 3.45% × 6개월로 다시 계산한 -34,500,000원이 현금 금액과 같습니다. 그런데 장부는 영업활동이라 ‘구분 재검토 필요’입니다. 아래 전표 라인은 보통예금 -34,500,000원과 이자비용 +34,500,000원 두 줄이며 합계가 0입니다.

서비스 계약

화면이 부르는 OData 주소는 사용 설명서에서 확인합니다. 개발자가 아닌 검토자도 ‘이 화면이 무엇을 읽는가’를 같은 문서에서 볼 수 있습니다.

서비스 이름은 소문자 cfreclass_srv 이고, 조회조건은 $filter, 정렬·페이징은 $orderby · $top · $skip, 총건수는 $inlinecount=allpages 로 받습니다. 보안 검토와 연계 설계에서 가장 먼저 보게 되는 대목이라 화면과 같은 글에 두었습니다.

화면 구성 정리

점검 코드

좁은 화면과 한계

창이 좁아지면 조회조건이 두 줄로 접히고 표는 가로로 스크롤됩니다. 이 사례는 가상의 자료 36건이라 건수가 적습니다. 운영 규모에서는 집계를 CDS 로 내리고 화면은 필요한 줄만 읽어야 하며, 이 부분은 아래 CDS 구성에서 다룹니다.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 현금흐름표를 만드는 표준 기능과 이 앱의 자리를 먼저 나눠 적습니다.

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

T-code 별 연계 지점

이 앱은 표준 거래의 앞뒤에 놓입니다. 점검 필요 줄을 찾는 것은 이 앱에서, 근거를 확인하는 것은 표준 거래에서 합니다.

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

• 항목 매핑 — 어느 계정·전표가 어느 항목과 유형, 장부 구분에 속하는지를 정하는 표입니다. 회사 정책에서 가장 먼저 합의해야 합니다.
• 점검 기준 구분 — 유형별 기준 구분(이자 지급 → 재무 등)은 표로 두어 기준서 해석이 바뀌어도 코드를 고치지 않습니다.
• 주된 사업활동 플래그 — 회사별로 대여·투자가 주된 사업활동인지는 정책 문서에서 정해 입력합니다. 정해지지 않으면 ‘확인 필요’로 남습니다.
• 재계산 입력 — 기준 금액 · 이율 · 적용 기간(또는 주식 수 · 주당 배당금)은 차입·예금 계약 원천에서 가져옵니다. 원천이 없으면 재계산 대상에서 제외하고 그 사실을 화면에 적습니다.
• 권한 — 회사코드와 계정 단위로 읽기 권한을 겁니다. 집계를 읽는 자리에 걸어야 합계로 새지 않습니다.

CDS 구성

이 사례의 화면은 항목 36건을 한 번에 읽어 브라우저에서 보여 줍니다. 데모라서 되는 일이고, 운영 데이터에서는 집계를 CDS 로 내립니다. 아래는 그때 만드는 뷰와 표를 레이어 순서대로 적은 것입니다.

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

뷰 레이어 구성

① 항목 매핑 테이블

어느 항목이 어느 유형이고 장부에서 어느 활동에 놓였는지를 정하는 자리입니다. 코드에 박지 않고 표로 두는 이유는 항목이 늘 때마다 개발자를 부르지 않기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZCFRC_ITEMMAP — 이자·배당 항목 매핑 (투명 테이블)
"  항목이 어느 유형이고, 장부에서 어느 활동으로 놓였는지 정한다.
"  운영에서는 회사 정책 문서를 그대로 옮겨 담는다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '이자·배당 항목 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcfrc_itemmap {
  key mandt    : mandt not null;
  key rbukrs   : bukrs not null;          " 회사코드
  key racct    : racct not null;          " 이자·배당 계정
  item_id      : abap.char(3);            " 항목 번호
  item_name    : abap.char(60);           " 항목명
  flow_type    : abap.char(3);            " IPD 이자지급 · IRC 이자수취 · DPD 배당지급 · DRC 배당수취
  policy_flag  : abap.char(1);            " X = 주된 사업활동이 대여·투자 (회사 정책 확인 필요)
  book_cls     : abap.char(3);            " OPR · INV · FIN — 장부에 놓인 활동
  valid_from   : abap.dats;
  valid_to     : abap.dats;
}

② 기준 구분 규칙 테이블

유형별로 점검 기준 구분이 무엇인지 적는 표입니다. 기준서 해석이 바뀌면 이 표만 고칩니다. 회사 정책으로 가려야 하는 건은 기준 구분을 비워 두어 ‘확인 필요’로 흐르게 합니다.

" ────────────────────────────────────────────────────────────────
"  ZCFRC_RULE — 유형별 점검 기준 구분
"  IPD → FIN, DPD → FIN, IRC → INV, DRC → INV
"  정책 플래그가 켜진 항목은 이 표를 타지 않고 '확인 필요'로 간다.
"  ※ 기준서 문구와 회사 정책은 반드시 직접 확인한다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '유형별 점검 기준 구분'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcfrc_rule {
  key mandt    : mandt not null;
  key flow_type: abap.char(3) not null;
  exp_cls      : abap.char(3);            " 점검 기준 구분
  valid_from   : abap.dats;
  rule_note    : abap.char(120);
}

③ 전표 라인 뷰

ACDOCA 에서 이자·배당 계정의 현금 라인만 뽑아 항목 매핑과 붙입니다. 상대 라인(이자비용 등)까지 함께 읽어 항목 상세의 전표 라인을 만듭니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CfrcLine — 이자·배당 전표 라인
"  ACDOCA 의 라인을 항목 매핑과 붙여 항목 번호를 단다.
"  필드 이름은 릴리스·환경에 따라 다르므로 View Browser(F2170)로 확인 필요.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '이자·배당 전표 라인'
define view entity ZI_CfrcLine
  as select from acdoca as j
  inner join zcfrc_itemmap as _map
    on  _map.rbukrs = j.rbukrs
    and _map.racct  = j.racct
{
  key j.rldnr                 as Ledger,
  key j.rbukrs                as CompanyCode,
  key j.gjahr                 as FiscalYear,
  key j.belnr                 as AccountingDocument,
  key j.docln                 as LedgerLine,
      _map.item_id            as ItemId,
      _map.flow_type          as FlowType,
      _map.policy_flag        as PolicyFlag,
      _map.book_cls           as BookCls,
      j.racct                 as GLAccount,
      j.budat                 as PostingDate,
      @Semantics.amount.currencyCode : 'Currency'
      j.hsl                   as Amount,
      j.rhcur                 as Currency
}
where j.rldnr = '0L'                       " 선도원장 — 확인 필요

④ 항목 집계 뷰 — 장부 구분과 기준 구분

항목 한 줄에 장부 구분과 점검 기준 구분을 함께 달고, 점검 코드를 계산하는 자리입니다. 화면의 ‘항목 구분 점검’ 탭이 읽는 뷰입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CfrcItem — 항목 구분 점검 (장부 구분 vs 점검 기준 구분)
"  현금 금액 = 현금 라인 합계. 재계산 금액은 별도 원천에서 붙는다.
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '이자·배당 항목 구분 점검'
define view entity ZI_CfrcItem
  as select from ZI_CfrcLine as L
  left outer join zcfrc_rule as R
    on R.flow_type = L.FlowType
{
  key L.FiscalYear,
  key L.CompanyCode,
  key L.ItemId,
      L.FlowType,
      L.PolicyFlag,
      L.BookCls,
      // 정책 플래그가 켜진 항목은 기준 구분을 정하지 않는다 → 확인 필요
      case when L.PolicyFlag = 'X' then cast( '' as abap.char(3) )
           else R.exp_cls end                           as ExpCls,
      @Semantics.amount.currencyCode : 'Currency'
      sum( case when L.GLAccount like '11%' then L.Amount else 0 end ) as CashAmt,
      max( L.PostingDate )                              as PostDate,
      L.Currency
}
group by L.FiscalYear, L.CompanyCode, L.ItemId, L.FlowType,
         L.PolicyFlag, L.BookCls, R.exp_cls, L.Currency
" 점검 코드(C00·C01·C03·C09)는 이 뷰 위의 소비 뷰에서 case 로 계산한다.

⑤ 활동별 구성 뷰

장부 구분과 기준 구분을 활동별로 두 번 모읍니다. 활동 사이를 옮기기만 하므로 두 합계가 같아야 하고, 정책 판단 대기 건은 별도 줄로 갑니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CfrcStmt — 현금흐름표 구성 (활동별 장부 금액 vs 기준 금액)
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '활동별 이자·배당 구성'
define view entity ZI_CfrcStmt
  as select from ZI_CfrcItem
{
  key FiscalYear,
  key CompanyCode,
  key case when ExpCls = '' then 'CNF' else BookCls end   as LineType,
      count( * )                                           as ItemCnt,
      @Semantics.amount.currencyCode : 'Currency'
      sum( CashAmt )                                       as BookAmt,
      Currency
}
group by FiscalYear, CompanyCode, BookCls, ExpCls, Currency
" 기준 금액 쪽은 ExpCls 로 묶어 같은 모양으로 만든 뒤 union 한다.
" 합계 줄은 두 금액이 같아야 한다 — 대사식 R03 이 매번 확인한다.

⑥ 소비 뷰와 OData 노출

화면이 읽는 이름과 정렬 기본값을 여기서 정합니다. 서비스 이름은 소문자 cfreclass_srv 로 맞췄습니다.

" ────────────────────────────────────────────────────────────────
"  ZC_CfrcItem — 소비 뷰 (UI 가 읽는 이름)
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '이자·배당 분류 점검'
@OData.publish                    : false
@Metadata.allowExtensions         : true
define view entity ZC_CfrcItem
  as projection on ZI_CfrcItem
{
  key FiscalYear  as Gjahr,
  key CompanyCode as Bukrs,
  key ItemId,
      FlowType,
      PolicyFlag,
      BookCls,
      ExpCls,
      CashAmt,
      PostDate
}
" 서비스 정의: define service CFRECLASS_SRV { expose ZC_CfrcItem as ItemSet; ... }
" 서비스 바인딩: OData V2 - UI, 이름은 소문자 cfreclass_srv 로 맞춘다.

⑦ 권한 — DCL

회사코드 단위로 읽기 권한을 겁니다. 집계 뷰에 걸어야 합계로 새지 않습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CfrcItem — 접근 제어(DCL)
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '이자·배당 항목 — 회사코드 권한'
@MappingRole       : true
define role ZI_CFRCITEM {
  grant select on ZI_CfrcItem
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}
" 실제 권한 오브젝트와 필드는 환경에 따라 다르므로 확인 필요.

⑧ 대사 뷰 — 화면 합계를 DB 에서 다시 잰다

운영에서는 화면 합계와 DB 합계를 같은 식으로 매번 비교해, 어긋나면 화면에 먼저 알립니다.

" ────────────────────────────────────────────────────────────────
"  ZI_CfrcRecon — 정합성 대사 (R01 : 항목 현금 합계 = 유형별 합계)
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label                : '이자·배당 정합성 대사'
define view entity ZI_CfrcRecon
  as select from ZI_CfrcItem as I
{
  key I.FiscalYear                         as Gjahr,
  key cast( 'R01' as abap.char(3) )        as ReconNo,
      sum( I.CashAmt )                     as LeftAmt,
      count( * )                           as CheckCnt
}
group by I.FiscalYear
" 우변은 유형별 합계 뷰의 총계이며, 차이 건수는 두 값이 다르면 1 로 센다.

OData 서비스 구성

서비스 이름은 모두 소문자 cfreclass_srv 입니다. 조회 · 생성 · 수정 · 삭제와 함수 호출은 앱 안의 service.js 엔진이 처리하고, 전기일 조건은 이 엔진이 직접 걸러 $orderby · $top · $skip · $inlinecount 까지 응답에 반영합니다. 테스트용 목 서버는 test/ 폴더에만 있습니다.

운영 전환에서 정할 항목

• 항목 매핑 합의 — 어느 계정이 어느 항목인지, 장부에서 어느 활동으로 놓았는지. 재무회계팀이 가장 먼저 정합니다.
• 회사 정책 확인 — 주된 사업활동이 대여·투자인지. 정해지기 전에는 ‘확인 필요’로 둡니다.
• 재계산 원천 — 차입·예금·배당 계약 정보의 위치와 갱신 주기.
• 원장과 기간 — 선도원장 외 병렬 원장을 쓰는지, 비교 기간을 몇 개로 볼지.
• 권한 기준 — 회사코드 · 계정 단위로 누가 어디까지 보는지.
• 배치 주기 — 결산 기간 동안 매일 돌릴지, 마감 직전에만 돌릴지.

자주 묻는 질문

도입 상담과 데모에서 받을 만한 질문들을 네 묶음으로 나눠 적었습니다. 기준서 해석과 회계 판단은 회사와 감사인의 몫이며, 아래 답은 이 앱이 어떻게 점검하는지를 설명합니다.

기준과 범위

화면과 숫자

SAP 연계

운영과 한계