은행 거래 명세 자동 분개 점검 — 적요 규칙으로 상대 계정을 정하고 미기표·충돌·중복을 가려내는 월마감 자금 회계

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

월말 자금팀의 일은 은행 거래 명세를 받아 한 줄씩 적요를 읽고 어느 계정으로 분개할지 정하는 것에서 시작합니다. 거래가 수십 건일 때는 눈으로 되지만, 입금자명이 제각각이고 같은 거래처가 여러 계좌로 나뉘고 외화 입금까지 섞이면 “이 건은 기표했나, 계정은 맞나, 같은 거래가 두 번 들어온 것은 아닌가”를 사람이 대조하게 됩니다. 이 앱은 그 대조를 규칙표 한 장으로 옮겨, 규칙이 정한 상대 계정과 제안 분개, 장부 기표와의 차이를 한 화면에 보여 줍니다.

핵심 포인트 여섯 가지

사례로 보는 효과 — 80건 가운데 사람이 봐야 할 건

샘플 은행 거래 80건(2026년 9월, 가상 회사 2곳 · 가상 계좌 6개)을 규칙표 15개(회사 1000)와 14개(회사 2000)에 대어 보면, 60건은 정상입니다(40건은 규칙과 장부 기표가 같고, 20건은 규칙이 계정을 정해 기표만 하면 되는 분개 제안입니다). 나머지 점검 필요 12건 · 확인 필요 8건이 사람이 볼 거래이고, 장부 기표 번호가 비어 있는 미기표는 모두 29건입니다. 80건을 처음부터 읽는 일이 20건을 확인하는 일로 줄어드는 셈입니다. 남은 20건은 아래 네 가지 모양입니다.

점검 필요와 확인 필요는 단정이 아니라 사람이 볼 자리입니다. 회계 처리나 세무상 결론은 이 화면이 내리지 않고, 회사와 감사인 · 세무 대리인이 확인합니다.

점검 코드 — 한 거래가 어떻게 가려지나

판정은 위에서부터 차례로 적용하며, 한 거래에는 하나의 코드만 붙습니다(J04 > J02 > J03 > J05 > J01 > J00).

도입하면 달라지는 것

• 분개 기준의 일원화 — 담당자마다 다르던 “이 적요는 이 계정”이 규칙표 하나로 모입니다. 담당자가 바뀌어도 기준이 남습니다.
• 월마감 확인 시간 — 전 건을 읽는 대신 점검 코드가 붙은 거래만 봅니다.
• 기표 누락과 오기표의 조기 발견 — 미기표와 계정 상이 거래가 마감 전에 목록으로 드러납니다.
• 규칙의 품질 관리 — 한 번도 적중하지 않은 규칙(K02)과 충돌에 자주 관여하는 규칙(K01)이 보여 규칙표를 정리할 근거가 생깁니다.

이런 회사에 맞습니다

매월 은행 거래 명세를 SAP 로 올려 은행 계정을 정리하면서도, 명세 후처리 단계에서 상대 계정을 사람이 고르고 있는 자금팀 · 재경팀에 맞습니다. 하우스 뱅크 계좌가 여럿이고 외화 계좌가 섞여 있어 대조 작업이 늘어난 회사, 그리고 분개 기준을 문서가 아닌 시스템에 남기고 싶은 회사에 특히 그렇습니다.

숫자를 믿을 수 있는가 — 정합성 대사 8건

이 화면에서 가장 비싼 질문은 “합계가 맞나”입니다. 그래서 만드는 쪽에서 대사식을 먼저 세우고 전수로 돌려 결과를 화면의 대사 결과 탭에 그대로 보여 줍니다. 아래는 샘플 자료의 결과이며, 검사 건수 합계 225건에 차이는 0건입니다. 샘플은 가상 은행 · 가상 거래처 · 가정 환율로 만든 것입니다.

점검 코드가 붙은 거래(J02 · J03 · J04 · J05)는 점검 화면이 보여 주려고 일부러 넣은 거래이며 대사 차이와는 별개입니다. 두 숫자를 섞어 읽지 않도록 화면에서도 따로 적었습니다.

실행 화면

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

처음 열었을 때

조회 버튼은 조회조건 영역 안, 입력란들의 가장 오른쪽에 있고 초기화 버튼이 바로 옆에 있습니다. 입력란에서 Enter 키를 눌러도 조회됩니다. 요약 지표는 점검한 거래 80건, 입금 · 출금 합계, 미기표 29건, 제안 분개 차변 합계, 점검 필요 12건, 확인 필요 8건, 대사 차이 0건 순서입니다. 금액은 원 단위이고 외화 거래는 거래일 가정 환율로 환산한 원화이며, 요약의 합계만 백만원 단위입니다.

다섯 탭 — 같은 거래를 다섯 방향에서

탭마다 서로 다른 질문에 답합니다. 거래 명세는 “한 건씩 어떻게 판정됐나”, 규칙 적중은 “규칙표가 건강한가”, 계좌별 대사는 “잔액이 맞나”, 제안 분개는 “무엇을 기표하면 되나”, 대사 결과는 “이 화면의 숫자를 믿어도 되나”입니다.

한 번도 걸리지 않은 규칙은 “확인 필요”, 충돌에 관여한 규칙은 “점검 필요”로 표시됩니다. 규칙표를 정리할 때 어디부터 볼지를 정해 주는 탭입니다. 회사 2000 은 임차료 규칙이 없어 규칙이 14개이며, 회사별로 규칙표가 다를 수 있다는 점을 일부러 샘플에 넣었습니다.

장부 잔액과 기말의 차이는 아직 기표되지 않은 거래의 순액과 같아야 합니다. 화면은 그 등식을 계좌마다 확인해 점검 코드(A00 · A01 · A02)로 보여 줍니다. 계좌번호는 앞뒤 일부만 보이는 가상 형식입니다.

이 탭의 줄은 기표 후보일 뿐이며 실제 기표는 표준 화면에서 회사가 합니다. 외화 거래는 외화 금액과 원화 환산 금액이 함께 보이고, 차변 합계는 원화 환산 금액으로만 더합니다.

거래 합계와 계좌 합계, 제안 분개의 차변 · 대변 합계, 규칙 적중 건수와 거래 건수 같은 식이 들어 있습니다. 차이가 하나라도 생기면 요약 지표의 대사 차이 건수가 먼저 바뀌므로, 숫자를 의심하기 전에 이 탭부터 보면 됩니다.

한 건을 자세히 — 거래 상세

“왜 이 계정이냐”는 질문에 화면 안에서 답하려고 만든 창입니다. 규칙이 둘 이상 걸렸다면 우선순위 순으로 모두 나열되어, 어느 규칙이 이겼고 어느 규칙과 부딪쳤는지 보입니다.

조회조건과 좁은 화면, 오류 안내

코드의 첫 글자가 거래(J) · 규칙(K) · 계좌(A) 중 어느 탭에 해당하는지를 정합니다. 그래서 J 코드를 골랐다고 규칙 탭이나 계좌 탭이 텅 비는 일이 없습니다. “전체”를 고르면 조건을 보내지 않습니다.

자금팀은 회의실 화면이나 노트북에서 번갈아 보는 일이 많아 폭에 따라 깨지지 않게 했습니다. 입력란 폭은 내용에 맞게 줄이고, 조회 버튼은 줄바꿈 뒤에도 입력란 바로 옆에 붙습니다.

메타데이터를 읽지 못한 경우 · 요청이 실패한 경우 · 조건에 맞는 자료가 없는 경우를 구분해 적습니다. 조건에 맞는 거래가 없는 것과 서비스가 죽은 것은 사용자에게 전혀 다른 상황이기 때문입니다.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 은행 명세를 올리는 일, 후처리로 기표하는 일, 계정 잔액을 보는 일은 표준이 이미 잘하는 일이라 표준에 맡기고, 표준 화면에서 눈에 잘 띄지 않는 “규칙끼리의 충돌 · 규칙에 걸리지 않는 거래 · 장부와 다른 기표 · 중복”을 한 화면에서 보게 해 주는 쪽으로 만들었습니다.

표준으로 되는 것과 이 앱이 더하는 것

T-code 별 연계 지점

이 앱이 표준 거래의 어느 자리를 이어받는지를 적었습니다. 운영에 올릴 때 “기존 후처리 화면을 없애야 하느냐”는 질문이 나오는데, 없애지 않고 둡니다. 기표와 감사 대응은 표준 거래가 맡는 편이 안전합니다.

이 앱이 하지 않는 일

• 기표 — 제안 분개는 후보이며 전표를 만들지 않습니다.
• 규칙의 정답 판정 — 규칙이 옳은지 기표가 옳은지는 회사가 판단합니다. 화면은 “다르다”는 사실까지만 알립니다.
• 회계 · 세무 결론 — 어느 계정이 맞는지, 세무상 어떻게 처리되는지는 회사와 감사인 · 세무 대리인이 확인합니다(확인 필요).

확장 포인트

도입할 때 손이 가는 곳은 셋입니다. 첫째 규칙표 — 키워드와 우선순위, 상대 계정을 회사가 정합니다. 둘째 환율 — 샘플은 거래일 기준 가정 환율을 쓰며, 운영에서는 회사가 정한 환율 유형을 따라 원화를 환산해야 합니다(표준 환산 방식과의 대응은 확인 필요). 셋째 점검 코드의 조치 문구 — 회사의 업무 용어에 맞춰 고칩니다.

CDS 구성

이 사례의 화면은 샘플 80건을 브라우저가 들고 판정합니다. 데모라서 되는 일이고, 운영 데이터에서는 판정을 서비스(CDS)로 내립니다. 아래는 그때 만드는 뷰들을 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 테이블 · 뷰 이름은 릴리스와 환경에 따라 다르므로 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다. 규칙표는 고객이 정하는 테이블이며, 표준 검색 문자열 규칙과의 대응은 확인 필요입니다.

뷰 레이어 구성

① 규칙표

모든 판정이 이 표에서 갈립니다. 키워드가 어떤 적요를 잡고 어느 계정으로 보내는지, 둘이 겹치면 누가 이기는지를 정하는 자리라 도입에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 규칙을 바꿔도 과거 판정이 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  ZPJV_RULEMAP — 적요 키워드 → 상대 계정 규칙표 (투명 테이블)
"  회사가 정하는 표이므로 코드에 박지 않고 전송(TR)으로 옮긴다.
"  Priority 숫자가 작을수록 먼저 이긴다. 같은 숫자에서 계정이 갈리면 충돌.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '은행 명세 분개 규칙표'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zpjv_rulemap {
  key mandt    : mandt not null;
  key bukrs    : bukrs not null;          " 회사코드
  key rule_no  : abap.char(4) not null;   " R01 ...
  keyword      : abap.char(40);           " 적요에 들어 있는지 볼 문구
  dir          : abap.char(1);            " I 입금 · O 출금 · B 둘 다
  gl_acct      : saknr;                   " 상대 계정
  priority     : abap.int4;
  valid_from   : abap.dats;
  valid_to     : abap.dats;
}

② 은행 거래 한 줄

명세 헤더와 항목을 한 번 읽어 일자 · 적요 · 금액 · 통화를 한 줄로 모읍니다. 이후 모든 뷰는 이 뷰만 봅니다. 적요가 어느 필드에 실리는지는 명세 형식에 따라 다르므로 확인이 필요합니다.

@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #NOT_REQUIRED
@EndUserText.label                   : '은행 거래 한 줄(스케치)'
define view entity ZI_BankLine
  as select from febep as i
    inner join   febko as h
      on h.kukey = i.kukey
{
  key h.bukrs                       as CompanyCode,
  key i.kukey                       as StatementKey,
  key i.esnum                       as ItemNo,
      h.hbkid                       as HouseBank,
      h.hktid                       as AccountId,
      i.budat                       as PostingDate,
      i.vwezw                       as Memo,       " 적요(사용 목적) — 필드는 확인 필요
      i.kwaer                       as Currency,
      @Semantics.amount.currencyCode : 'Currency'
      i.kwbtr                       as Amount
}

③ 규칙 적중

적요에 규칙 키워드가 들어 있는 (거래, 규칙) 쌍을 모두 남깁니다. 여기서 우선순위로 하나만 고르면 충돌이 사라지므로 일부러 거르지 않습니다.

@EndUserText.label : '규칙 적중 쌍(스케치)'
define view entity ZI_BankRuleHit
  as select from ZI_BankLine as l
    inner join   zpjv_rulemap  as r
      on  r.bukrs = l.CompanyCode
      and instr( l.Memo, r.keyword ) > 0          " 문구 포함 여부
      and l.PostingDate between r.valid_from and r.valid_to
{
  key l.CompanyCode,
  key l.StatementKey,
  key l.ItemNo,
  key r.rule_no       as RuleNo,
      r.priority      as Priority,
      r.gl_acct       as ProposedAccount,
      r.dir           as RuleDirection
}

④ 판정 — 우선순위 · 충돌 · 미적중

가장 작은 우선순위만 남기고, 그 우선순위에서 상대 계정이 둘 이상이면 충돌로 표시합니다. 적중이 하나도 없으면 미적중입니다. 계정을 임의로 고르지 않는다는 원칙이 이 뷰에 들어 있습니다.

@EndUserText.label : '거래별 판정(스케치)'
define view entity ZI_BankJudge
  as select from ZI_BankLine as l
    left outer join ZI_BankBestPriority as p        " 거래별 최소 Priority
      on  p.CompanyCode  = l.CompanyCode
      and p.StatementKey = l.StatementKey
      and p.ItemNo       = l.ItemNo
{
  key l.CompanyCode,
  key l.StatementKey,
  key l.ItemNo,
      p.BestPriority,
      p.AccountCount,                                " 그 우선순위의 서로 다른 계정 수
      case
        when p.BestPriority is null then 'J04'       " 어느 규칙에도 안 걸림 — 확인 필요
        when p.AccountCount > 1     then 'J02'       " 규칙 충돌 — 점검 필요
        else                             'MATCH'     " 장부 대조는 다음 뷰에서
      end                           as JudgeStep
}

⑤ 장부 기표와 대조

명세 거래에 짝이 되는 장부 기표를 붙이고, 규칙 제안 계정과 견주어 J00 · J01 · J03 을 정합니다. 장부에서 어느 라인을 “짝”으로 볼지는 환경에 따라 다르므로 아래 조건은 틀로만 읽어야 합니다(확인 필요).

@EndUserText.label : '명세와 장부 기표 대조(스케치)'
define view entity ZI_BankBookMatch
  as select from ZI_BankJudge as j
    left outer join I_JournalEntryItem as b          " 은행 계정 라인의 상대 라인
      on  b.CompanyCode = j.CompanyCode
      and b.DocumentReferenceID = j.StatementKey     " 연결 키 — 환경별 확인 필요
{
  key j.CompanyCode, key j.StatementKey, key j.ItemNo,
      b.AccountingDocument         as BookDocument,
      b.GLAccount                  as BookAccount,
      case
        when j.JudgeStep <> 'MATCH'          then j.JudgeStep
        when b.AccountingDocument is initial then 'J01'   " 미기표 → 분개 제안
        when b.GLAccount = j.ProposedAccount then 'J00'   " 장부와 일치
        else                                      'J03'   " 장부 계정 상이 → 점검 필요
      end                          as CheckCode
}

⑥ 계좌별 잔액 대사

기초 + 입금 − 출금 = 기말, 장부 잔액 ± 미기표 순액이 같아야 합니다. 이 등식을 뷰에서 한 번 정의하면 화면과 감사 자료가 같은 숫자를 봅니다. 통화가 다른 금액은 더하지 않으므로 통화를 키에 둡니다.

@EndUserText.label : '계좌별 잔액 대사(스케치)'
define view entity ZI_BankAcctRecon
  as select from ZI_BankBookMatch as m
{
  key m.CompanyCode,
  key m.AccountId,
  key m.Currency,                                      " 통화가 다르면 더하지 않는다
      sum( case when m.Direction = 'I' then m.Amount else 0 end ) as InAmount,
      sum( case when m.Direction = 'O' then m.Amount else 0 end ) as OutAmount,
      sum( case when m.CheckCode = 'J01'
                then case when m.Direction = 'I' then m.Amount else -m.Amount end
                else 0 end )                           as UnpostedNet
}
group by m.CompanyCode, m.AccountId, m.Currency

⑦ 제안 분개 쿼리와 권한

미기표(J01)와 장부 상이(J03) 거래마다 차변 · 대변 두 줄을 내보냅니다. 외화는 원화 환산 금액을 따로 두고, 차변 합계는 원화 환산 금액으로만 더합니다. 권한은 명세를 읽는 뷰 자리에 걸어야 집계 합계로 남의 회사 숫자가 새지 않습니다.

@EndUserText.label : '제안 분개(스케치)'
@Analytics.query : true
define view entity ZC_BankJvProposal
  as select from ZI_BankBookMatch as m
{
  key m.CompanyCode, key m.StatementKey, key m.ItemNo,
      m.CheckCode,
      case m.Direction when 'I' then m.HouseBankAccount else m.ProposedAccount end as DebitAccount,
      case m.Direction when 'I' then m.ProposedAccount else m.HouseBankAccount end as CreditAccount,
      @Semantics.amount.currencyCode : 'Currency'
      m.Amount,
      m.Currency,
      m.AmountInCompanyCurrency        " 환산 방식은 회사 정책 — 확인 필요
}
where m.CheckCode in ( 'J01', 'J03' )

" ── DCL ─────────────────────────────────────────
@EndUserText.label : '명세 조회 권한'
@MappingRole : true
define role ZI_BANKLINE {
  grant select on ZI_BankLine
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

운영 전환에서 정해야 할 것

자주 묻는 질문

도입 상담과 데모에서 받은 질문을 정리했습니다. 규칙과 판정, 숫자와 대사, 운영과 도입 세 묶음입니다.

규칙과 판정

숫자와 대사

운영과 도입