SAP 수입 관세·부가세 납부 대사 — 신고, 납부, 장부 세 숫자를 한 줄에 놓고 어긋난 건만 찾는 화면

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

수입 통관이 끝나면 같은 돈이 세 곳에 따로 남습니다. 신고서에는 계산된 관세와 부가세가, 납부 자료에는 실제로 낸 금액이, 장부에는 취득원가와 매입세액으로 올라간 금액이 있습니다. 세 숫자가 같아야 하는데 같은지는 월마감 때 사람이 엑셀로 맞춰 봐야 압니다. 이 앱은 신고를 다시 계산해 납부와 장부에 차례로 맞춰 보고, 어긋난 건만 골라 어디부터 보면 되는지 알려 줍니다.

핵심 포인트 여덟 가지

사례로 보는 효과 — 납부는 했는데 장부에 없는 세 건

점검 필요 15건 가운데 금액이 가장 큰 것은 장부 미반영(C05) 세 건입니다. 납부는 확인되는데 회계 전표가 없어서 장부 관세와 매입세액이 납부 금액 전체만큼 모자랍니다. 2026년 9월의 세 번째 신고는 장부 관세가 17,923,433원, 장부 매입세액이 24,196,635원 모자랍니다. 재계산과 납부는 맞기 때문에 납부 단계만 보는 리포트로는 보이지 않고, 장부 단계까지 같은 줄에 놓아야 드러납니다.

원인은 단정하지 않습니다. 화면은 점검 필요로만 표시하고 코드마다 해야 할 조치를 적어 둡니다. 같은 차이라도 환율을 잘못 적용했을 수도, 관세율이 달랐을 수도, 납부 자료가 틀렸을 수도 있어 사람이 자료를 보고 정하는 편이 안전하기 때문입니다.

도입하면 달라지는 것

• 월마감 준비 — 신고 전수를 열어 보던 일이 점검 필요 건만 열어 보는 일로 줄어듭니다.
• 회의의 주제 — “어느 숫자가 맞나”가 아니라 “이 건은 누가 확인할 것인가”를 이야기합니다.
• 단계별 책임 — 납부 차이는 통관 쪽, 장부 차이는 회계 쪽으로 나뉘어 담당이 갈립니다.
• 빠지는 건 없다는 확신 — 아홉 가지 대사가 합계를 스스로 검산하므로 집계에서 새는 금액이 없는지 확인됩니다.

이런 회사에 맞습니다

해외에서 원재료와 부품을 들여오면서 통관 결과를 관세사 자료와 엑셀로 장부와 맞추고 있는 회사, 달러 · 유로 · 엔화 · 위안화처럼 통화가 여러 개라 집계가 번거로운 구매 · 회계팀, 그리고 관세와 매입세액이 장부에 빠짐없이 올라갔는지 확인할 방법이 필요한 조직에 맞습니다.

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

대사 화면에서 가장 비싼 질문은 “이 합계 맞아?” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 두고 전수로 돌렸습니다. 아래는 이 사례 자료의 결과입니다.

아홉 가지 대사 모두 차이 건수가 0입니다. 05~08번에 점검 대상이 있는 것은 등식이 틀려서가 아니라, 납부 차이와 장부 차이를 식에 넣어도 그 차이가 허용 오차를 넘거나 전표가 없는 신고가 그만큼 있다는 뜻입니다. 화면 쪽은 이와 별도로 브라우저 자동화로 확인했습니다 — 조회 조건을 바꿔도 합계가 변하지 않는지, 상세 창의 란 합계가 신고 금액과 같은지를 매번 다시 잽니다.

사용 방법

1. 납부 연월을 넣고 조회를 누릅니다(엔터 키도 됩니다). 통화와 점검 상태로 범위를 좁힐 수 있습니다.
2. 위쪽 요약에서 신고 건수, 과세가격, 납부 관세, 납부 부가세, 점검 필요 건수를 먼저 봅니다.
3. 점검 상태를 점검 필요로 두면 차이가 있는 신고만 남습니다. 건마다 코드와 해야 할 조치가 적혀 있습니다.
4. 궁금한 신고를 누르면 상세 창에서 란별 내역과 납부 · 장부 차이를 봅니다.
5. 월별 대사 · 통화별 · 품목군별 탭에서 같은 자료를 다른 각도로 봅니다.
6. 대사 결과 탭에서 아홉 가지 검산이 모두 통과했는지 확인하고, 필요하면 파일로 내려받아 공유합니다.

점검 판정 규칙

허용 오차 10원, 부가세율 10%, 관세율, 과세환율은 모두 이 사례의 가정값입니다. 판정은 아래 여섯 코드로 나뉩니다.

실행 화면

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

조회하고 좁히기

조회를 누르기 전에도 화면의 틀이 먼저 서 있어서, 처음 여는 사람도 무엇을 고르면 무엇이 채워지는지 먼저 봅니다. 기본 납부 연월은 2026년 9월입니다.

원인은 단정하지 않습니다. 같은 차이라도 환율이 달랐는지, 관세율을 잘못 적용했는지, 납부가 잘못되었는지는 사람이 자료를 보고 정합니다. 화면은 어디부터 보면 되는지만 좁혀 줍니다.

단계별로 견주기

월마감 때 가장 먼저 보는 화면입니다. 어느 달에 장부 반영이 모자랐는지가 합계로 먼저 드러나고, 그 달의 신고로 내려가면 원인이 되는 건이 나옵니다.

서로 다른 통화의 외화 금액을 더하면 의미 없는 숫자가 나옵니다. 그래서 외화 합계는 통화별 행에만 두고, 전체 합계는 원화 과세가격으로만 냅니다.

관세율이 0%인 전자부품부터 8%인 기계 부품까지 다섯 품목군을 둡니다. 실효 관세율이 가정한 관세율과 다르면 란에 다른 관세율이 적용되었다는 뜻이라 먼저 볼 자리입니다.

한 건을 열어 보고 검산하기

신고 금액이 맞는지는 란에서 갈립니다. 란별 합계가 신고 금액과 다르면 신고서 쪽 문제이고, 같은데 납부가 다르면 납부 쪽 문제입니다. 이 구분이 상세 창 한 곳에서 됩니다.

차이 건수가 0인데 점검 대상이 있는 줄이 있습니다. 합계가 맞는지와 어긋난 건이 있는지는 다른 질문이기 때문에 두 숫자를 따로 적었습니다.

SAP 표준 기능 확장 포인트

이 앱은 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 어디까지가 표준이고 어디서부터 이 앱인지를 먼저 적습니다.

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

T-code 별 연계 지점

운영에 올릴 때 “기존 거래를 없애야 하느냐”는 질문이 꼭 나오는데, 대부분은 없애지 않고 둡니다. 전표를 열어 확인하고 필요하면 고치는 일은 표준 거래가 맡는 편이 안전합니다.

가정한 것과 확인할 것

이 사례에서 가정한 것은 허용 오차 10원, 부가세율 10%, 품목군별 관세율, 통화별 과세환율, 반올림과 절사 방식입니다. 확인이 필요한 것은 신고 · 납부 자료의 표준 SAP 원천, 관세와 매입세액 계정 및 세금코드, 신고 번호를 전표의 어느 필드와 잇는지입니다. 도입할 때 이 목록을 먼저 닫아야 숫자가 실제와 맞습니다.

권한에서 놓치기 쉬운 자리. 집계 화면은 권한이 없어도 합계가 보이는 수가 있습니다. 회사코드 권한이 없는 사람이 전체 합계는 볼 수 있고 상세만 막히면, 뺄셈으로 다른 회사의 숫자를 알아낼 수 있습니다. 집계를 읽는 뷰에도 같은 접근 제어를 걸어야 합니다.

CDS 구성

이 사례의 화면은 샘플 자료를 서비스에서 받아 화면이 집계합니다. 데모라서 되는 일이고, 운영 데이터에서는 집계를 CDS 로 내립니다. 아래는 그때 만드는 뷰의 스케치입니다.

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

뷰 레이어 구성

① 신고 란 기본 뷰 — 란별 원화 과세가격과 관세

신고서의 란 한 줄이 계산의 최소 단위입니다. 외화 과세가격에 과세환율을 곱하고 관세율을 곱하는 일을 이 뷰 한 곳에 둡니다. 반올림 · 절사 방식은 가정이므로 실제 기준으로 바꿔야 합니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 관세 란별 재계산'
define view entity ZI_ImportDutyLine
  as select from ZI_ImportDeclLineBase as L
{
  key L.DeclNo,
  key L.LineNo,
      L.ItemGroup,
      L.Currency,
      @Semantics.amount.currencyCode: 'Currency'
      L.ForeignAmount,
      L.TaxRate,
      /* 원화 과세가격 = 외화 과세가격 × 과세환율 (원 단위 반올림 — 가정) */
      cast( round( L.ForeignAmount * L.TaxRate, 0 ) as abap.curr(18,0) ) as CifKrw,
      L.DutyRatePct,
      /* 란별 관세 = 원화 과세가격 × 관세율 (원 미만 절사 — 가정) */
      cast( floor( round( L.ForeignAmount * L.TaxRate, 0 ) * L.DutyRatePct / 100 ) as abap.curr(18,0) ) as DutyCalc
}

② 신고 헤더 뷰 — 란을 신고 단위로 모으기

란별 값을 신고 한 건으로 합칩니다. 신고 과세가격과 신고 관세는 란의 합이어야 하므로 합계 그대로 쓰고, 부가세는 합계에서 다시 구합니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입신고 재계산 헤더'
define view entity ZI_ImportDutyDecl
  as select from ZI_ImportDutyLine as L
{
  key L.DeclNo,
      sum( L.CifKrw )   as CifKrw,
      sum( L.DutyCalc ) as DutyCalc,
      /* 부가세 과세표준 = 과세가격 + 관세, 부가세 = 과세표준 × 부가세율 (10% — 가정) */
      cast( floor( ( sum( L.CifKrw ) + sum( L.DutyCalc ) ) * 10 / 100 ) as abap.curr(18,0) ) as VatCalc,
      count( * )        as LineCnt
}
group by L.DeclNo

③ 납부 자료 뷰 — 원천 확인 필요

납부 자료는 관세사 · 세관이 제공하므로 표준 SAP 원천이 정해져 있지 않습니다. 아래는 올려 둔 자료를 읽는 자리의 모양일 뿐이며, 어디서 읽을지는 도입할 때 확정해야 합니다.

@EndUserText.label: '수입 관세·부가세 납부 자료'
define view entity ZI_ImportPayment
  as select from zimp_payment    /* 납부 자료 적재 테이블 — 실제 원천은 확인 필요 */
{
  key decl_no  as DeclNo,
      pay_date as PayDate,
      duty_paid as DutyPaid,
      vat_paid  as VatPaid
}

④ 장부 반영 뷰 — 관세와 매입세액 계정 합계

장부 쪽은 표준 테이블에서 읽습니다. 신고 번호를 전표의 어느 필드와 이을지(참조, 지정 등)는 회사 운영 방식에 따라 다르고, 계정과 세금코드도 확정이 필요합니다. 필드 이름은 View Browser(F2170)에서 실제 이름을 확인해야 합니다.

@EndUserText.label: '수입 관세 장부 반영'
define view entity ZI_ImportBook
  as select from bseg as I
    inner join   bkpf as H on  H.bukrs = I.bukrs
                           and H.belnr = I.belnr
                           and H.gjahr = I.gjahr
{
  key H.xblnr as DeclNo,            /* 신고 번호를 참조 필드에 넣는 운영을 가정 — 확인 필요 */
      H.belnr as BookDocNo,
      H.budat as PostDate,
      /* 관세 계정 / 매입세액 계정 — 계정 번호는 회계팀과 확정 */
      sum( case when I.hkont = '관세계정'   then I.dmbtr else 0 end ) as DutyBook,
      sum( case when I.hkont = '매입세액계정' then I.dmbtr else 0 end ) as VatBook
}
group by H.xblnr, H.belnr, H.budat

⑤ 대사 뷰 — 세 숫자와 두 차이

재계산, 납부, 장부를 한 줄에 놓고 차이를 한 번만 정의합니다. 화면이 따로 뺄셈을 하지 않으므로 어느 화면에서 봐도 차이가 같습니다.

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수입 관세 납부 대사'
define view entity ZC_ImportDutyRecon
  as select from ZI_ImportDutyDecl as D
    left outer join ZI_ImportPayment as P on P.DeclNo = D.DeclNo
    left outer join ZI_ImportBook    as B on B.DeclNo = D.DeclNo
{
  key D.DeclNo,
      D.CifKrw,
      D.DutyCalc,
      P.DutyPaid,
      P.DutyPaid - D.DutyCalc  as DutyDiffPay,     /* 납부 차이 = 납부 − 재계산 */
      B.DutyBook,
      B.DutyBook - P.DutyPaid  as DutyBookDiff,    /* 장부 차이 = 장부 − 납부 */
      D.VatCalc,
      P.VatPaid,
      P.VatPaid - D.VatCalc    as VatDiffPay,
      B.VatBook,
      B.VatBook - P.VatPaid    as VatBookDiff
}

⑥ 점검 판정 — 여섯 코드를 한 곳에서

판정 조건을 화면이 아니라 뷰에 둡니다. 허용 오차 10원은 가정값이라 상수로 한 번만 적습니다. 코드는 앞선 것이 먼저 걸립니다.

define view entity ZC_ImportDutyCheck
  as select from ZC_ImportDutyRecon as R
{
  key R.DeclNo,
      case
        when abs( R.DutyDiffPay ) > 10                          then 'C01'
        when abs( R.VatDiffPay )  > 10                          then 'C02'
        when R.DutyBook is null and R.DutyPaid is not null      then 'C05'   /* 장부 미반영 */
        when R.DutyBookDiff <> 0                                then 'C03'
        when R.VatBookDiff  <> 0                                then 'C04'
        when abs( R.DutyDiffPay ) between 1 and 10              then 'C06'   /* 단수 차이(정보) */
        else '  '
      end as CheckCode
}

⑦ 접근 제어 — 회사코드 단위

집계 화면은 권한이 없어도 합계가 보이는 수가 있습니다(회사코드 필드는 대사 뷰에 더해야 합니다). 합계를 읽는 뷰에도 같은 제어를 걸어야 뺄셈으로 권한 밖 숫자를 알아내는 길이 막힙니다.

@EndUserText.label: '수입 관세 대사 접근 제어'
@MappingRole: true
define role ZC_ImportDutyRecon {
  grant select on ZC_ImportDutyRecon
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

규모에 따라 달라지는 것

자주 묻는 질문

도입 상담과 데모에서 나올 만한 질문들을 네 묶음으로 적었습니다.

데이터와 계산

화면과 조작

점검 판정

도입과 운영