SAP 직접법 현금흐름 다차원 분석 — 활동 · 사업부 · 통화로 돌려 보고 간접법과의 차이를 여섯 요인으로 쪼개는 대사 화면

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

결산 때마다 현금흐름표 담당자는 같은 질문을 받습니다. 직접법으로 모은 현금 숫자와 손익에서 출발한 간접법 숫자가 왜 다른가, 그 차이가 시기 문제인가 금액 문제인가 분류 문제인가, 그래서 누가 무엇을 고쳐야 하는가. 지금은 이 세 답이 은행 거래내역 엑셀, 간접법 조정표, 표준 현금 포지션 화면에 흩어져 있어, 숫자를 맞추는 일이 회의 시간의 대부분을 차지합니다.

표준 화면은 은행 계정별 잔액과 전표 라인을 정확하게 보여 줍니다. 이 화면은 그 위에서 “활동별 순현금흐름이 간접법과 얼마나 다른가”, “그 차이 가운데 인식 시기 때문에 생긴 몫이 얼마인가”, “환율 환산 때문에 생긴 몫이 얼마인가”를 한 표에서 답하도록 이어 붙입니다. 표준을 대체하지 않고, 표준이 끊기는 자리를 잇습니다.

핵심 포인트 일곱 가지

사례로 보는 효과

검증용 샘플 데이터(가상 회사 2개 · 가상 사업부 4개 · 통화 5종 · 2026년 1월~9월)에서 회사 전체를 조회하면 유입 600,619.1백만원, 유출 601,102.1백만원, 직접법 순현금흐름은 −483.0백만원입니다. 같은 범위의 간접법 값은 3,118.8백만원이라 직접법이 간접법보다 3,601.8백만원 낮게 나옵니다. 총액만 보면 “어느 쪽이 틀렸나”를 묻게 됩니다.

이 앱은 같은 차이를 여섯 요인으로 가릅니다: 수금 시차 +411.4, 지급 시차 −132.6, 금액 +860.5, 환율 +19.3, 직접법에만 있는 흐름 −6,912.0, 간접법에만 있는 흐름 +2,151.6(단위 백만원)이고 검산 줄은 0 입니다. 가장 큰 몫은 시기나 환율이 아니라 직접법 라인에는 있으나 간접법 조정에는 잡히지 않은 흐름이었습니다. 이것은 원인의 단정이 아니라 점검 대상의 좁힘입니다. 이자 · 배당 · 세금의 활동 구분이나 조정 항목 누락 여부를 확인하는 일은 사람의 몫입니다.

활동별로 내려가면 영업활동은 직접법 17,701.1, 간접법 12,251.8로 5,449.3 차이(+44.5%)이고, 이 차이도 수금 시차 +220.0, 지급 시차 −47.6, 금액 +831.6, 환율 +47.4, 직접법에만 있는 흐름 +2,505.7, 간접법에만 있는 흐름 +1,892.3으로 갈라 맞습니다.

도입하면 달라지는 것

• 결산 현금흐름 점검 — 활동별 · 사업부별 · 통화별 표가 한 화면에서 나와 시트 취합과 캡처가 줄어듭니다.
• 회의의 주제 — “어느 숫자가 맞나” 대신 “직접법에만 있는 흐름을 어떻게 분류할 것인가”를 이야기합니다.
• 다음 결산으로 이어지는 기록 — 변동 사유와 저장한 보기가 남아 같은 설명을 반복하지 않습니다.
• 놓치는 날이 없는 점검 — 규칙에 걸린 숫자가 담당자 대기함에 올라옵니다.

이런 회사에 맞습니다

은행 거래내역으로 현금흐름을 직접 모으면서 결산에서는 손익 기반 간접법 숫자와 맞춰 보는 회사에 맞습니다. 사업부가 여럿이거나 수출입 대금으로 외화 비중이 있어 환율 환산이 차이의 한 요인으로 끼는 회사라면 효과가 더 큽니다. 반대로 거래가 몇 건뿐이라 엑셀 한 장으로 끝나는 회사에는 과합니다. 이 화면은 법정 현금흐름표를 만들지 않으며, 점검과 대사를 돕는 도구입니다.

실행 화면

실제 브라우저에서 찍은 화면 32종입니다. 순서는 처음 열었을 때 → 경영 요약 → 축 전환과 범위 → 칸에서 원천 거래까지 → 계산 항목 → 간접법 대비 차이 → AI 분석과 보고서 → AI 에이전트 → 보기 저장과 복원 → 좁은 화면입니다. 화면을 누르면 크게 볼 수 있습니다.

사용 방법

1. 조회 조건 입력 — 필수는 기간 시작 · 기간 끝입니다. 회사는 비우면 전체, 비교 기준은 간접법 또는 없음을 고릅니다. 시작이 끝보다 늦으면 조회하지 않고 안내합니다.
2. 조회 — 조건 영역 오른쪽 끝의 조회 버튼을 누릅니다. 조건 입력 칸에서 Enter 를 눌러도 같습니다. 조회하면 조건 영역이 접히고 한 줄 요약으로 바뀝니다.
3. 요약 확인 — “보는 사람”(경영 · 재무 · 자금 · 회계)을 고르면 문장과 핵심 지표 카드의 초점이 달라집니다.
4. 탭 · 축 이동 — 차원 보관함의 칩을 행 축 · 열 축으로 끌어다 놓거나 눌러 보냅니다. ✕ 로 뺍니다. 이미 읽은 큐브를 다시 묶으므로 서버를 부르지 않습니다.
5. 행 · 셀 클릭으로 상세 — 행을 누르면 오른쪽에 간접법에서 직접법까지의 워터폴과 요인 표가 나오고, 값 칸을 누르면 그 칸을 이루는 원천 라인이 열립니다.
6. 내보내기 — 표 오른쪽 위 CSV 로 현재 표를, 원천 보기 창의 CSV 로 원천 라인을 내려받습니다. 해설은 파워포인트 보고서로 내려받고, 짜 둔 축은 이름을 붙여 저장합니다.

무엇으로 만들었나

화면은 OpenUI5 표준 컨트롤로만 짰고, 데이터는 OData V2 서비스를 모델로 읽습니다. 아래 표는 자리마다 무엇을 쓰고 왜 그렇게 두었는지를 정리한 것입니다.

앱 정보

처음 열었을 때

조회 조건부터 피벗까지가 한 화면에 세로로 쌓입니다. 조건 영역은 접을 수 있어서 축을 짜는 동안에는 펼쳐 두고, 숫자를 볼 때는 접어 둡니다.

경영 요약 — 보는 사람에 따라 달라지는 첫 줄

같은 숫자도 읽는 사람이 다르면 보는 순서가 다릅니다. “보는 사람” 네 가지(경영 · 재무 · 자금 · 회계)가 처음 보이는 측정값과 축 배치, 안내 문장을 바꿉니다.

축 전환과 범위 — 보고 싶은 만큼만

열 축은 두 단계까지, 행 축은 세 단계까지입니다. 값 필터는 차원마다 여러 값을 고를 수 있고, 고른 범위는 표 · 차트 · 요인 분해에 함께 적용됩니다.

칸에서 원천 거래까지

숫자를 의심할 때 가장 빠른 방법은 그 숫자를 만든 거래를 보는 것입니다. 값 칸을 누르면 행 경로와 열 조합이 그대로 조회 조건이 되어 원천 라인이 열립니다.

계산 항목 — 자주 쓰는 합과 비율을 식으로

활동별 흐름의 합이나 지출 비율처럼 자주 쓰는 값은 식으로 정의해 측정값 목록에 둡니다.

간접법 대비 차이 — 같은 표가 대사 자료가 된다

비교 기준을 간접법으로 두면 같은 표가 직접법 · 간접법 · 차이 · 차이율을 보여 주고, 행을 누르면 차이를 여섯 요인으로 가른 워터폴이 나옵니다.

AI 분석과 보고서 — 숫자는 서비스, 문장은 초안

금액과 비율은 서비스가 계산해 근거로 내고, 해설은 그 숫자를 읽어 쓴 초안입니다. 결과는 파워포인트 보고서로 내려받습니다.

AI 에이전트 — 규칙이 곧 받을 사람

사람이 화면을 열지 않아도 감시 규칙을 서비스가 하루 한 번 판정해 대기함에 올립니다.

보기 저장과 복원

짜 둔 축과 필터는 이름을 붙여 저장하고, 기본 보기로 지정하면 화면을 열 때 바로 조회됩니다.

좁은 화면과 한계

좁은 화면에서는 차트가 표 아래로 내려옵니다. 열이 너무 많아지는 조합은 상한 안내로 막습니다.

화면 뒤에서 일어나는 일

조회를 누르면 서비스는 조건에 맞는 직접법 큐브와 간접법 큐브를 한 번 돌려주고, 화면은 그 두 자료를 메모리에 둔 채 축 전환 · 필터 · 차이 모드 · 계산 항목을 모두 브라우저에서 다시 묶습니다. 요인 분해, 해설, 에이전트 판정처럼 판단이 들어가는 계산만 서비스 펑션이 맡습니다. 그래서 같은 범위를 어느 축으로 돌려 봐도 합계가 같고, 화면이 만든 숫자와 서비스가 만든 숫자가 갈라질 자리가 없습니다.

차이 요인 분해와 점검 규칙

직접법 순현금흐름과 간접법 순현금흐름의 차이를 여섯 요인으로 가르며, 합은 항상 총차이와 같습니다. 판정은 점검을 돕는 표시이며 원인이나 회계 처리의 결론을 단정하지 않습니다.

아래는 점검 규칙입니다.

산출과 대사 순서

직접법 큐브와 간접법 큐브를 한 번 읽어 브라우저에서 다시 묶고, 서버가 요인 분해 · 해설 · 에이전트 판정을 계산합니다. 큐브 합계는 원천 라인 합계와 맞춰 봅니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

창 폭이 600px 안팎으로 줄면 조회 조건과 카드가 세로로 쌓이고, 표 오른쪽에 있던 차트가 표 아래로 내려옵니다. 표는 가로로 스크롤되며 차트는 감추지 않습니다. 터치 화면에서는 끌어다 놓기 대신 칩을 눌러 축으로 보냅니다.

파일 구성

index.html · Component.js · manifest.json
controller/   Main.controller.js · BaseController.js
view/         Main.view.xml · fragments/ (값 필터 · 원천 보기 · 변동 사유 · 해설 · 에이전트 · 보기 저장 · 보기 관리)
model/        cube.js(다시 묶기) · chart.js · pptx.js · layout.js · formatter.js · ErrorHandler.js
i18n/         i18n_ko.properties
css/          style.css
odata/        metadata.xml · service.js(서비스 로직) · calc.js(요인 분해 · 해설 · 에이전트 판정) · json/(엔티티셋별 데이터 14개)
readme.html

SAP 표준 기능 확장 포인트 — 표준 T-code 와 어떻게 연계되는지

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다.

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

T-code 별 연계 지점

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

S/4HANA 의 분석 스택(CDS 분석 쿼리, Fiori 분석 앱, Analysis for Office)과 이 앱은 경쟁하지 않고 같은 원천 위에 놓입니다. 아래 “CDS 구성”의 큐브 · 쿼리 뷰를 만들어 두면 표준 분석 도구도 같은 집계를 읽을 수 있고, 이 앱은 그 위에 요인 분해, 해설, 에이전트, 변동 사유 같은 업무 흐름을 얹습니다.

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

분석 지표 정의

CDS 구성

아래 코드는 구조를 보이기 위한 스케치이며, 원천 테이블 · 필드는 운영 구성에 따라 달라지므로 ‘확인 필요’로 표시했습니다.

뷰 레이어 구성

① 매핑 테이블 — 자금 항목을 활동 구분 · 간접법 연계 구분에 묶는 기준

이 표에서 결정되는 것은 “어떤 거래가 영업이고 어떤 거래가 투자인가”입니다. 잉여 현금흐름 같은 계산 항목과 활동별 요인 분해가 모두 이 표를 따릅니다.

" ─────────────────────────────────────────────────────────
" ZCFD_ITEMMAP : 자금 항목 매핑
" 역할  : 자금 항목(회사별) → 활동 구분(A 영업 · B 투자 · C 재무) · 간접법 연계 구분
" 이유  : 활동 구분은 회사의 자금 항목 체계에서 정해지므로 코드가 아니라 데이터로 둔다
" ─────────────────────────────────────────────────────────
@EndUserText.label : '자금 항목 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcfd_itemmap {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key item       : abap.char(4) not null;
  activity       : abap.char(1);   " A 영업 · B 투자 · C 재무
  dir            : abap.char(1);   " I 유입 · O 유출
  ind_rs         : abap.char(2);   " OT 일치 · DL 늦음 · EA 이름 · UP 직접법에만 · LO 간접법에만
  item_text      : abap.char(40);
}

② 기준 뷰 — 직접법 라인을 한 모양으로

원천 라인을 읽어 활동 구분과 간접법 연계 구분을 붙이는 첫 단계입니다. 원천 테이블과 필드는 운영 구성에 따라 달라지므로 확인이 필요합니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '직접법 현금흐름 기준'
define view entity ZI_CfdFlowBase
  as select from acdoca as a
  inner join zcfd_itemmap as m
    on  m.bukrs = a.rbukrs
    and m.item  = /* 확인 필요: 자금 항목을 어느 필드에서 도출하는지 */ a.racct
{
  key a.rldnr, key a.rbukrs, key a.gjahr, key a.belnr, key a.docln,
  a.budat                        as PostDate,
  a.rhcur                        as Waers,
  m.activity                     as Activity,
  m.dir                          as Dir,
  m.ind_rs                       as IndRs,
  @Semantics.amount.currencyCode : 'Waers'
  a.wsl                          as AmtFc,    " 외화 금액
  a.hsl                          as AmtKrw    " 원화 금액(확인 필요: 현지 통화)
}

③ 차원 뷰 — 값 필터의 목록

화면의 값 필터 창이 읽는 목록입니다. 키와 텍스트를 같은 뷰에서 내보내 보관함의 이름과 필터 목록이 어긋나지 않게 합니다.

@EndUserText.label : '사업부'
@ObjectModel.resultSet.sizeCategory : #XS
define view entity ZI_CfdBu
  as select from tka02 as k      " 확인 필요: 사업부를 어느 마스터에서 도출하는지
{
  @ObjectModel.text.element : ['BuName']
  key k.gsber as Bu,
  @Semantics.text : true
  k.bezei     as BuName
}

@EndUserText.label : '자금 항목'
define view entity ZI_CfdItem
  as select from zcfd_itemmap as m
{
  @ObjectModel.text.element : ['ItemText']
  key m.item  as Item,
  m.item_text as ItemText,
  m.activity  as Activity
}

④ 큐브 — 기간 · 회사 · 사업부 · 자금 항목 단위 집계

화면이 한 번에 읽는 직접법 큐브입니다. 분석 지표 정의와 같은 식으로 유입 · 유출 · 순현금흐름을 집계합니다.

@Analytics.dataCategory : #CUBE
@EndUserText.label : '직접법 현금흐름 큐브'
define view entity ZI_CfdFlowCube
  as select from ZI_CfdFlowBase as b
{
  key substring(b.PostDate, 1, 6)  as Period,
  key b.rbukrs                     as Bukrs,
  key b.Bu, key b.Item, key b.Waers, key b.Cpty,
  key b.Activity, key b.Dir, key b.IndRs as Rs,
  @Aggregation.default : #SUM
  sum( case b.Dir when 'I' then b.AmtKrw else 0 end )   as Inflow,
  @Aggregation.default : #SUM
  sum( case b.Dir when 'O' then b.AmtKrw else 0 end )   as Outflow,
  @Aggregation.default : #SUM
  sum( case b.Dir when 'I' then b.AmtKrw else -b.AmtKrw end ) as Flow,
  @Aggregation.default : #SUM
  count( * )                                            as Cnt
}
group by substring(b.PostDate,1,6), b.rbukrs, b.Bu, b.Item, b.Waers, b.Cpty, b.Activity, b.Dir, b.IndRs

⑤ 간접법 큐브 — 같은 모양의 산출 값

간접법 값은 손익에서 출발해 비현금 항목과 운전자본 증감을 조정해 만듭니다. 그 조정의 원천은 회사마다 다르므로 확인이 필요합니다.

@Analytics.dataCategory : #CUBE
@EndUserText.label : '간접법 현금흐름 큐브'
define view entity ZI_CfdIndCube
  as select from ZI_CfdIndBase as p      " 확인 필요: 손익 · 운전자본 · 비현금 조정에서 만든 뷰
{
  key 'I0'                         as Version,
  key p.Period, key p.Bukrs, key p.Bu, key p.Item,
  key p.Waers, key p.Cpty, key p.Activity, key p.Dir, key p.Rs,
  @Aggregation.default : #SUM  p.Flow     as Flow,
  @Aggregation.default : #SUM  p.Inflow   as Inflow,
  @Aggregation.default : #SUM  p.Outflow  as Outflow
}

⑥ 분석 쿼리 — 화면이 읽는 문

표준 분석 도구에서도 같은 큐브를 열 수 있게 쿼리를 둡니다. 회사와 기간을 필수 조건으로 두어 전량 조회를 막습니다.

@Analytics.query : true
@EndUserText.label : '직접법 현금흐름 쿼리'
define view entity ZC_CfdFlowQuery
  as select from ZI_CfdFlowCube
{
  @AnalyticsDetails.query.axis : #ROWS     Activity,
  @AnalyticsDetails.query.axis : #ROWS     Item,
  @AnalyticsDetails.query.axis : #COLUMNS  Period,
  @Consumption.filter : { mandatory : true, selectionType : #INTERVAL }
  Period,
  @Consumption.filter : { selectionType : #SINGLE, multipleSelections : true }
  Bukrs,
  Bu, Waers, Cpty,
  Flow, Inflow, Outflow, Cnt
}

⑦ 권한 — 집계 단계의 DCL

권한은 큐브를 읽는 입구에 겁니다. 드릴스루 창에만 걸면 합계에서 자기 몫을 빼서 남의 숫자를 추정할 수 있기 때문입니다.

@EndUserText.label : '직접법 현금흐름 권한'
@MappingRole : true
define role ZC_CfdFlowQuery_DCL {
  grant select on ZC_CfdFlowQuery
    where ( Bukrs ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' )
      and ( Bu )    = aspect pfcg_auth( ZCFD_BU, GSBER, ACTVT = '03' );   " 확인 필요: 권한 오브젝트
}

⑧ 서비스 정의와 바인딩

마지막으로 OData V2 로 게시합니다. 화면이 읽는 엔티티셋 이름이 여기서 정해집니다.

@EndUserText.label : '직접법 현금흐름 서비스'
define service ZUI_CfdFlow {
  expose ZI_CfdFlowCube   as CubeSet;
  expose ZI_CfdIndCube    as PlanSet;
  expose ZI_CfdBu         as DimBu;
  expose ZI_CfdItem       as DimItem;
}

" 서비스 바인딩: ZUI_CfdFlow_O2 — 바인딩 유형 OData V2 - UI, 게시 후 서비스 URL 을 화면 설정에 넣는다

운영 시점에 해야 할 일

아래 항목은 코딩이 아니라 합의입니다. 합의가 끝나면 기술 작업은 위 코드를 운영 원천에 맞춰 고치고 서비스를 게시하는 일입니다.

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

리포트에서 가장 비싼 질문은 “이 숫자 맞아?”입니다. 만드는 쪽에서 대사식을 먼저 세워 전수로 돌린 결과입니다.

대사식 13종 합계 16,330건을 검사했고 차이는 0건, 의도적 예외도 0건입니다. 화면의 순현금흐름 −483.0백만원은 검증 스크립트 결과(−482,972,654원)와 같습니다. 간접법에만 있거나 직접법에만 있는 흐름은 대사 오류가 아니라 요인으로 분류됩니다.

운영 데이터로 갈 때

화면은 샘플 서비스로 검증했습니다. 운영에서는 서비스 뒤의 원천을 위 CDS 로 교체하고, 화면 설정의 서비스 주소만 바꿉니다. 처음에는 기존 엑셀과 병행하며 합계를 맞춰 보고, 활동 구분 매핑과 간접법 연계 구분 규칙을 합의한 뒤 범위를 넓히시길 권합니다.

자주 묻는 질문

도입 상담과 데모에서 자주 받는 질문을 네 묶음으로 적었습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영