사업결합 인수 우발부채 인식·후속측정 점검 — 취득일 인식 요건과 후속 금액, 영업권 조정까지 장부와 맞춰 보는 결산 화면

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

기업을 인수하면 인수 대상이 안고 있던 소송·환경 의무·지급보증·세무 쟁점이 함께 넘어옵니다. 사업결합 기준서는 이 우발부채를 취득일에 부채로 인식할 요건(현재의무이면서 공정가치를 신뢰성 있게 측정할 수 있는가)과 이후 측정 방법을 따로 정해 두었습니다. 결산 때마다 “취득일에 요건대로 인식했나”, “후속 금액을 규칙대로 줄였나”, “바뀐 금액을 영업권 조정과 당기손익 중 맞는 쪽에 반영했나”를 사안마다 평가 파일과 장부로 확인해야 합니다. 이 화면은 그 재계산과 대조를 한 화면에 모읍니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 후속 금액이 11.5억 낮게 남은 소송 사안

검증용 샘플 데이터의 한 건입니다. 취득일 공정가치 18억으로 인식한 소송 사안에서 후속 재계산액은 18억인데 장부 후속 금액은 6.5억이었습니다. 충당부채 기준 금액이 6.5억이라 거기까지 낮춘 것으로 보이지만 실제 사유는 확인 필요입니다. 규칙상 후속 금액은 충당부채 기준 금액과 (최초 인식액 − 누적 수익 인식액) 중 큰 금액이므로 11.5억 차이가 R04 로 걸립니다. 이 화면은 “숫자가 다르다”에서 멈추지 않고 어느 입력값이 재계산에 쓰였는지를 상세 창에서 함께 보여 줍니다.

도입하면 달라지는 것

• 결산 전 점검 — 점검 필요 건만 코드별로 모아 어디부터 볼지 바로 정합니다.
• 설명의 근거 — 상세 창에 인식 요건과 재계산 근거, 장부 변동 내역이 함께 나와 감사 대응 자리에서 그대로 보여 줄 수 있습니다.
• 취득 거래 단위 점검 — 영업권 재계산 차이가 어느 사안에서 왔는지 따라갑니다.
• 검토 자료 — 조회 결과를 CSV 로 내려받아 검토 문서에 붙입니다.

이런 회사에 맞습니다

최근 12개월 안에 기업을 인수해 인수 우발부채를 인식했거나 인식 여부를 판단한 회사, 소송·환경 의무·지급보증·세무 쟁점을 인수하고 사안별로 후속 측정을 관리하는 회계팀, 측정기간 조정과 당기손익 처리를 구분해 설명해야 하는 결산·감사 대응 조직에 맞습니다. 인수 이력이 없는 회사에는 필요하지 않습니다.

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

화면 숫자를 만드는 쪽과 별개로 데이터를 다시 계산해 대조했습니다. 아래는 검증용 샘플 데이터(가상 피취득자 5곳, 우발부채 17건, 두 개 연월)의 결과입니다.

일곱 가지 대사식이 모두 차이 0 입니다. 점검 필요 9건(202608 3건, 202609 6건)은 화면의 점검 기능을 보이려고 의도적으로 넣은 예외이며 위 차이와 따로 셉니다. 이 결과는 샘플 데이터에 대한 것이고, 실제 회사 데이터에서의 결과는 연결 후 다시 확인해야 합니다.

도입 후 쓰는 순서

1. 기준 연월을 확인하고 조회를 누릅니다. 취득 거래·사안 유형·점검 코드·점검 결과는 비워 두면 전체입니다.
2. 요약 숫자로 점검 필요 건수와 대사 차이 건수를 봅니다.
3. 점검 코드로 좁혀 어긋난 건만 모아 봅니다.
4. 행을 눌러 인식 요건과 재계산 근거, 장부 변동을 확인합니다.
5. 취득 거래별·사안 유형별 탭에서 영업권과 유형 단위 차이를 확인합니다.
6. 대사 결과 탭에서 정합성과 장부 점검 대사를 확인하고 CSV 로 내려받습니다.

실행 화면

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

조회와 점검 코드

조회를 누르면 요약 숫자 일곱 개가 먼저 차고 아래에 명세 표가 뜹니다. 점검 필요 건에는 점검 코드가 붙어 있어 정상 건과 바로 구분됩니다. 기준 연월 입력 칸에서 Enter 를 눌러도 조회됩니다.

코드를 고르면 그 코드에 걸린 건만 남습니다. 결산 직전에는 점검 필요 건만 모아 위에서부터 확인하고, 설명이 끝난 건은 정상 건과 구분해 둡니다. 소송 사안의 후속 금액 차이가 이 모습으로 나타납니다.

변동과 집계

장부가 어떤 줄들을 거쳐 기말 금액이 되었는지를 한 줄씩 봅니다. 재측정 줄에는 처리 구분(영업권 조정·당기손익)이 붙어 있어 R05 점검의 근거가 됩니다.

우발부채 차이는 영업권 재계산으로 이어지므로 취득 거래 단위로 한 번 더 모읍니다. 차이가 있는 취득 거래는 판정 칸에 점검 필요가 뜹니다.

어떤 유형의 사안에서 차이가 많은지 한눈에 봅니다. 유형별 합계는 건별 합계와 같아야 하며, 그 일치는 대사 탭에서 다시 확인합니다.

상세·대사·좁은 화면

명세 표의 행을 누르면 열립니다. 현재의무·측정 가능 여부, 충당부채 기준 금액, 누적 수익 인식액이 재계산 식과 함께 보여 설명 자리에서 그대로 근거로 씁니다.

정합성 대사는 화면 숫자끼리 맞는지, 장부 점검 대사는 장부와 재계산이 맞는지를 봅니다. 두 종류의 차이를 섞지 않고 따로 세웠습니다.

창이 좁아지면 표는 가로로 밀어 보고 요약 숫자는 줄바꿈으로 내려갑니다. 기능을 숨기지 않습니다.

SAP 표준 기능 확장 포인트

이 화면은 SAP 표준을 대체하지 않습니다. 전표와 잔액은 표준 거래로 확인하고, 표준에 없는 재계산과 대조만 이 화면이 맡습니다. 어디까지가 표준이고 어디서부터 이 화면인지를 먼저 적습니다.

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

T-code 별 연계 지점

기준서 요구사항과 이 화면

점검 코드 판정 순서

한 건에 코드 하나만 붙으며 아래 순서대로 먼저 해당하는 코드를 씁니다.

CDS 구성

이 사례의 화면은 샘플 데이터를 서비스가 돌려줍니다. 운영에서는 원장과 평가자료를 CDS 로 읽어 같은 모양의 응답을 만들면 화면 코드는 그대로 씁니다. 아래 코드는 스케치입니다. 필드·뷰 이름은 릴리스와 환경에 따라 다르므로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 하며, 확인이 필요한 자리는 주석에 적었습니다.

뷰 레이어 구성

① 입력 테이블 — 판단 값의 공급처

현재의무 여부와 충당부채 기준 금액처럼 표준 원천이 없는 값을 받는 자리입니다. 어느 테이블에 둘지는 회사 사정에 따라 달라지므로 확인 필요입니다.

@EndUserText.label : '인수 우발부채 평가 입력'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #ALLOWED
define table zacl_eval {
  key mandt      : mandt not null;
  key bukrs      : bukrs not null;
  key cont_no    : abap.char(10) not null;   " 우발부채 번호
  acq_no         : abap.char(10);            " 취득 거래 번호
  acq_date       : abap.dats;                " 취득일
  cont_type      : abap.char(4);             " LAW ENV GUAR TAX WARR
  present_ob     : abap.char(1);             " 현재의무 Y/N (회사 판단)
  fv_ok          : abap.char(1);             " 공정가치 측정 가능 Y/N (회사 판단)
  @Semantics.amount.currencyCode : 'zacl_eval.waers'
  init_fv        : abap.curr(23,2);          " 취득일 공정가치
  @Semantics.amount.currencyCode : 'zacl_eval.waers'
  ias37_amt      : abap.curr(23,2);          " 충당부채 기준 금액
  @Semantics.amount.currencyCode : 'zacl_eval.waers'
  cum_income     : abap.curr(23,2);          " 누적 수익 인식액
  status         : abap.char(8);             " OPEN / RESOLVED
  waers          : waers;
}

② 원장 라인 뷰

우발부채 계정의 라인을 읽습니다. 계정 범위는 회사마다 달라 확인 필요입니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '우발부채 계정 원장 라인'
define view entity ZI_AclJournalItem
  as select from I_JournalEntryItem as _Item
{
  key _Item.CompanyCode,
  key _Item.FiscalYear,
  key _Item.AccountingDocument,
  key _Item.LedgerGLLineItem,
      _Item.GLAccount,
      _Item.PostingDate,
      _Item.DebitCreditCode,
      @Semantics.amount.currencyCode : 'Currency'
      _Item.AmountInCompanyCodeCurrency as Amount,
      _Item.CompanyCodeCurrency         as Currency
}
where _Item.Ledger = '0L'          -- 확인 필요: 고객사 원장 구성
  and _Item.GLAccount between '0000290000' and '0000290999'  -- 확인 필요: 우발부채 계정 범위

③ 건별 재계산 뷰 — 최초 인식과 후속 금액

규칙을 이 뷰에서 한 번만 정의합니다. 화면과 CDS 가 같은 식을 쓰는지가 대조의 전제입니다.

define view entity ZI_AclContingent
  as select from zacl_eval as e
{
  key e.bukrs   as CompanyCode,
  key e.cont_no as ContNo,
      e.acq_no, e.cont_type, e.status,
      /* 최초 인식 재계산액 */
      case when e.present_ob = 'Y' and e.fv_ok = 'Y'
           then e.init_fv else cast( 0 as abap.curr(23,2) ) end   as CalcInit,
      /* 후속 재계산액 : 진행 중이면 두 금액 중 큰 금액, 해소면 0 */
      case when e.status = 'RESOLVED' then cast( 0 as abap.curr(23,2) )
           when e.ias37_amt > ( case when e.present_ob = 'Y' and e.fv_ok = 'Y'
                                     then e.init_fv else 0 end - e.cum_income )
           then e.ias37_amt
           else ( case when e.present_ob = 'Y' and e.fv_ok = 'Y'
                       then e.init_fv else 0 end - e.cum_income ) end as CalcSub
}

④ 점검 코드 판정

화면과 같은 우선순위(R01, R02, R03, R06, R04, R05, I00)로 씁니다. 장부 금액 컬럼은 원장 라인을 합산한 값이라고 가정하며 확인 필요입니다.

-- 점검 코드 : 먼저 해당하는 조건을 쓴다 (장부 금액 LedgInit, LedgSub 은 원장 합산)
case
  when CalcInit >  0 and LedgInit = 0                         then 'R01'
  when CalcInit =  0 and LedgInit <> 0                        then 'R02'
  when CalcInit >  0 and LedgInit <> CalcInit                 then 'R03'
  when status = 'RESOLVED' and LedgSub <> 0                   then 'R06'
  when LedgSub <> CalcSub                                     then 'R04'
  when ChgAmt <> 0 and LedgChgTo <> CalcChgTo                 then 'R05'
  else 'I00'
end as CheckCode

⑤ 처리 구분 — 측정기간과 변동 원인

기대 처리 구분은 두 조건을 모두 만족할 때만 영업권 조정입니다. 12개월 기준은 기준서 원문으로 재확인 필요입니다.

-- 측정기간 안인가 : 취득일 + 12개월 >= 기준 연월 말일 (12개월은 확인 필요)
dats_add_months( e.acq_date, 12, 'NONE' ) >= $session.system_date   as InMeasure,
-- 기대 처리 구분
case when ChgReason = 'FACT'            -- 취득일 존재 사실에 관한 새 정보
      and InMeasure  = 'X'
     then 'GOODWILL' else 'PROFIT' end                              as CalcChgTo

⑥ 취득 거래별 영업권 재계산

define view entity ZI_AclAcquisition
  as select from ZI_AclContingent as c
    inner join zacl_acq as a on a.acq_no = c.acq_no
{
  key c.acq_no,
      sum( c.CalcInit )                                     as CalcInit,
      sum( c.LedgInit )                                     as LedgInit,
      /* 이전대가 - 우발부채 제외 순자산 공정가치 + 최초 인식 재계산액 */
      a.cons - a.net_ex + sum( c.CalcInit )                 as CalcGw,
      a.cons - a.net_ex + sum( c.LedgInit )                 as LedgGw
}
group by c.acq_no, a.cons, a.net_ex

⑦ 권한 — DCL

합계를 읽는 뷰에도 같은 권한을 걸어야 건별 값을 못 보게 해도 합계로 새지 않습니다.

@EndUserText.label : '우발부채 점검 권한'
@MappingRole : true
define role ZI_ACLCONTINGENT {
  grant select on ZI_AclContingent
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

서비스 쪽은 위 뷰를 ContSet · MovSet · AcqSet · TypeSet · ReconSet 다섯 엔티티셋으로 노출하고, 화면은 manifest 의 데이터 소스 상대 경로가 가리키는 서비스를 읽습니다. 서비스를 바꿔도 화면 코드는 그대로입니다.

자주 묻는 질문

도입 상담에서 자주 나오는 질문을 네 묶음으로 적었습니다.

대상과 기준

숫자와 판정

화면과 조작

도입과 운영