수출 영세율 매출 대사 점검 — 청구일 환율로 잡은 장부 금액과 선적일 환율로 구한 신고 대상 금액을 맞춰 보고 차이의 원인 후보까지 가르는 수출 신고 점검 화면

개발 배경 — 이 앱을 사용해야 하는 이유

수출 담당자와 세무 담당자가 분기마다 부딪히는 질문은 거의 같습니다. 장부에 영세율로 잡은 수출 매출과 신고하려는 금액이 같은가, 다르다면 어느 건이 왜 다른가, 누가 무엇을 확인해야 하는가. 지금은 이 세 답이 청구 조회 · 전표 조회 · 선적 자료 · 엑셀로 흩어져 있고, 분기 신고 직전에 사람이 한 건씩 맞춰 봅니다.

이 화면은 그 맞춰 보는 일을 한 화면에 올렸습니다. 청구일 환율로 기표한 장부 영세율 매출과, 수출신고 증빙이 연결된 건을 선적일 환율로 다시 구한 신고 대상 금액을 같은 청구 한 건 위에 나란히 놓고, 차이를 귀속 분기 · 환율 · 증빙 연결 · 과세코드 네 갈래의 원인 후보로 가릅니다. 어디까지나 점검 도구입니다. 영세율 적용 여부와 신고 금액의 최종 판단은 회사와 세무 대리인 · 관세사가 하며, 이 글과 화면의 허용 오차 · 환율 · 기준 비율은 모두 샘플 가정값입니다.

핵심 포인트 여섯 가지

같은 청구가 장부와 신고에서 다른 금액이 되는 이유

수출 청구는 외화로 발행되고, 장부는 청구일의 환율로 원화 매출을 기표합니다. 반면 신고 대상 금액은 선적일 기준으로 다시 구하는 경우가 많습니다. 청구일과 선적일이 같은 날이면 두 금액은 같지만, 며칠만 벌어져도 환율이 달라 원화 금액이 갈립니다. 이 화면의 샘플 정책은 장부 금액을 청구 외화 × 청구일 환율, 신고 대상 금액을 신고 연결 외화 × 선적일 환율로 둡니다. 어느 환율을 어느 기준에 쓸지는 회사와 세무 대리인이 정할 일이라 화면에서 바꿔 쓰는 자리로 열어 두었습니다.

청구일과 선적일이 서로 다른 분기에 걸치면 환율 차이보다 큰 문제가 생깁니다. 같은 매출이 장부에서는 한 분기에, 신고 쪽에서는 다음 분기에 잡히기 때문입니다. 이런 건은 합계 차이가 작게 나올 수도 있어 합계만 보면 지나치기 쉽습니다. 그래서 이 화면은 금액 차이와 별개로 귀속 분기가 갈리는지를 먼저 봅니다.

증빙이 연결되지 않은 영세율 매출은 합계에 가려진다

영세율로 기표했지만 수출신고 증빙이 연결되지 않은 건은 신고 대상 금액이 0 이 되어 차이가 청구 금액 전체로 잡힙니다. 반대로 증빙은 있는데 장부 과세코드가 영세율이 아닌 건은 장부 쪽이 0 이 됩니다. 두 경우 모두 금액이 커서 한 번에 눈에 띄지만, 왜 그런지는 합계에서 알 수 없습니다. 이 화면은 각각을 별도 차이 유형으로 세워 몇 건이고 얼마인지 바로 보이게 합니다. 샘플 데이터에서는 이 두 유형이 차이 금액의 대부분을 차지합니다.

사용 방법

1. 조회조건을 입력합니다. 회계연도(필수, 4자리)만 정하면 되고, 거래처 · 통화 · 인코텀즈 · 신고 귀속 분기 · 차이 유형 · 선적일 범위 · 판정은 필요할 때만 고릅니다. 비워 두면 전체입니다.
2. 조회 버튼을 누르거나 입력 칸에서 Enter 키를 누릅니다. 화면을 처음 열면 기본 조건으로 자동 조회됩니다.
3. 요약 지표 여섯 개를 확인합니다. 청구 건수 · 판정 대상 건수 · 점검 필요 건수 · 장부 영세율 매출 · 신고 대상 금액 · 대사 차이 건수입니다.
4. 탭을 옮겨 가며 봅니다. 청구 명세 → 분기별 → 차이 유형별 → 통화별 → 인코텀즈별 → 대사 결과 순서입니다.
5. 표의 행을 눌러 상세 창을 엽니다. 청구 행은 그 건의 상세를, 요약 행은 그 조건에 속한 청구 건 목록을 함께 보여 줍니다. 닫기 버튼이나 ESC 키로 닫습니다.
6. CSV 내려받기를 누르면 지금 보고 있는 탭의 조회 결과가 UTF-8 CSV 로 내려받아집니다.

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

화면을 만들기 전에 대사식을 먼저 세우고, 청구 85건을 원천 칸에서 다시 구해 저장값과 견주었습니다. 결과는 건별 차이 0건이며, 아래 대사식은 모두 화면의 대사 결과 탭에서 직접 확인할 수 있습니다.

위 아홉 개 식의 검사 건수를 모두 더하면 178건이고 차이는 0건입니다. 이와 별도로 의도적 예외 1종을 두었습니다. 선적일이 없는 선수 청구 4건은 신고 대상 금액이 0 이라 장부와 갈리는 것이 정상이므로, 대사 차이 건수에 섞지 않고 건수와 금액(344,230,980원)을 따로 기록합니다. 건별 85건을 원천 칸에서 다시 구해 저장값과 견준 결과도 차이 0건입니다.

무엇으로 만들었나

실행 화면

아래는 검증용 샘플 데이터로 실제 렌더링한 화면 7종입니다. 사용 순서대로 — 처음 연 화면, 점검 필요 건, 분기 · 유형 · 통화 탭, 한 건의 상세, 대사 결과 — 놓았습니다.

처음 열었을 때와 점검 필요 건만 보기

처음 연 화면은 한 번에 많이 보여 주되, 사람이 확인할 건만 추려 보는 길이 바로 옆에 있습니다.

화면 맨 위 안내 문구는 장부 금액과 신고 대상 금액을 어떻게 구하는지 한 번 읽어 두라는 용도입니다. 회계연도 기본값(2026)으로 자동 조회되어 청구 85건 · 판정 대상 81건 · 점검 필요 28건이 요약 지표에 뜨고, 장부 영세율 매출은 13,468.4백만 원, 신고 대상 금액은 13,376.2백만 원입니다. 표 마지막 열이 장부에서 신고 대상을 뺀 차이이며, 선적일이 비어 있는 행은 선수 청구라 신고 대상이 0 으로 나옵니다.

조회조건의 판정을 "점검 필요"로 바꾸고 조회 버튼(또는 Enter)을 누르면 정상 건이 빠지고 사람이 확인할 건만 남습니다. 요약 지표도 같은 조건으로 다시 계산되어 점검 필요 건수와 금액이 함께 바뀝니다. 담당자는 이 목록을 위에서부터 열어 보면 됩니다.

분기 · 차이 유형 · 통화 — 같은 청구를 세 방향으로 다시 모으기

건별 표는 하나지만 질문은 세 가지입니다. 어느 분기가 어긋났나, 무슨 이유가 큰가, 어느 통화에서 빠졌나. 탭만 바꾸면 같은 조회 조건 위에서 답이 나옵니다.

분기마다 장부 건수 · 신고 건수 · 점검 필요 건수와 두 금액, 차이, 차이율이 한 줄에 놓입니다. 샘플에서는 1분기 차이율이 −18.13%, 3분기가 +15.81% 로 반대 방향이라 분기 경계에서 금액이 옮겨 갔음을 짐작할 수 있습니다. 차이율이 ±1.00%(가정값) 이상인 분기는 요약 행이 점검 필요로 표시됩니다. 행을 누르면 그 분기에 속한 청구 건이 상세 창에 열립니다.

유형마다 건수와 두 금액, 차이, 차이 절대값, 전체 차이에서 차지하는 비중을 보여 줍니다. 샘플에서는 신고 증빙 미연결 5건과 과세코드 확인 4건이 차이 절대값 합계의 대부분(각각 약 51%, 46%)을 차지합니다. 금액이 큰 유형부터 확인하면 점검 순서가 정해집니다. 일치로 분류된 53건은 허용 오차 안의 소액 차이만 남은 건입니다.

달러 · 유로 · 엔 · 위안마다 청구 외화, 장부 영세율 외화, 신고 연결 외화, 증빙 미연결 외화를 나눠 보여 줍니다. 서로 다른 통화의 외화 금액은 더하지 않으며, 청구 외화가 신고 연결 외화와 증빙 미연결 외화의 합과 같은지는 대사 결과 탭에서 통화별로 검산합니다. 증빙 미연결 외화가 큰 통화(샘플에서는 위안 726,000, 달러 300,500)부터 확인하면 순서가 잡힙니다.

한 건을 열어 보기와 대사 결과

숫자를 의심할 때 내려가는 길과, 숫자가 맞는다는 것을 확인하는 길입니다.

표의 행을 누르면 열리는 상세 창입니다. 이 건은 3월 30일에 청구하고 4월 2일에 선적해서 장부 귀속 분기는 1분기, 신고 귀속 분기는 2분기로 갈려 "귀속 분기 불일치"로 점검 필요가 나옵니다. 환율 차이로 인한 금액 차이는 0 이어서 합계만 보면 정상처럼 보이는 건이라는 점이 요점입니다. 닫기 버튼이나 ESC 키로 닫습니다.

대사 결과 탭은 화면의 숫자가 어긋나지 않는지를 화면 안에서 보여 줍니다. 검사 건수 178건에서 차이 건수는 0건이고, 선적 전 청구 4건은 의도적 예외 행으로 분리되어 차이 건수에 섞이지 않습니다. 대사식 좌변과 우변이 함께 나와 어디가 맞는지 바로 확인할 수 있습니다.

화면 뒤에서 일어나는 일

조회 한 번에 화면은 같은 조회조건으로 여섯 묶음(청구 명세 · 분기별 · 차이 유형별 · 통화별 · 인코텀즈별 · 대사 결과)과 요약 지표를 읽습니다. 요약 지표 중 차이 절대값 합계와 평균 차이율은 합계용 함수로 따로 받습니다. 판정은 건별로 한 번 정해져 저장된 값을 모든 묶음이 같이 쓰기 때문에, 탭을 옮겨도 같은 건이 다른 유형으로 바뀌지 않습니다.

판정 규칙 — 조건에서 사용자 조치까지

한 건에는 아래 순서대로 가장 먼저 해당하는 조건 하나만 적용합니다. 환율 · 허용 오차 · 기준 비율은 샘플 가정값이며, 회사의 정책표로 바꿔 쓰는 자리입니다.

산출과 대사 순서

조회조건

결과 컬럼

파일 구성

앱 폴더/
  index.html · readme.html · Component.js · manifest.json
  controller/  BaseController.js · Main.controller.js
  view/        Main.view.xml · DetailDialog.fragment.xml
  model/       formatter.js · ErrorHandler.js
  css/ · i18n/
  odata/       서비스 선언(metadata.xml) · 서비스 로직(service.js) · 데이터(json/)
  media/       intro.mp4 · intro_poster.jpg

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 청구 · 출하 · 판매오더 · 전표를 보는 일은 표준 화면이 이미 충분하며, 이 화면은 그 값을 장부 기준과 신고 기준으로 다시 맞춰 보는 자리를 채웁니다.

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

T-code 별 연계 지점

기존 화면이나 리포트를 없애야 하나요? 없애지 않습니다. 법정 신고 · 감사 · 세무 신고 대응은 표준 거래와 회사가 쓰는 신고 체계에 그대로 두고, 이 화면은 신고 전에 장부와 신고 대상 금액이 맞는지 미리 점검하는 보조 화면으로 함께 둡니다.

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

S/4HANA 에는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 분석 도구가 있습니다. 이 화면은 그 위치를 대신하지 않고, 영세율 매출 신고 대사라는 한 가지 질문에 맞춘 CDS 뷰와 화면을 더하는 쪽입니다. 구체적인 Fiori 분석 앱 이름은 고객 시스템의 버전과 활성화 상태에 따라 달라 이 글에서는 쓰지 않으며, 확인 필요로 남깁니다. 같은 CDS 뷰 위에 Analysis for Office 시트를 얹어 쓰는 것도 가능합니다.

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

분석 지표 정의표

CDS 구성 — 기준 표에서 서비스까지

뷰 레이어 구성

SAP 에서 같은 일을 하려면 아래처럼 기준 표 · 기본 뷰 · 큐브 · 분석 쿼리 · 권한 · 서비스의 순서로 나누어 만듭니다. 화면이 읽는 OData 서비스는 맨 아래 서비스 층이 대신합니다.

① 기준 표 — 세금코드 매핑과 정책값

영세율로 볼 세금코드와 허용 오차 · 기준 비율이 정해지는 곳입니다. 코드에 박아 두면 고객사마다 소스를 고쳐야 하므로 표로 빼 두고, 현업이 직접 유지하도록 합니다. 세금코드 값은 고객사마다 다르며 이 글에는 값을 싣지 않습니다.

" ─────────────────────────────────────────────────────────────
" ZEXP_TAXMAP / ZEXP_POLICY — 영세율 판정 기준 표
" 역할 : 어느 세금코드를 영세율로 볼지, 허용 오차와 기준 비율은 얼마인지.
" 나눈 이유 : 기준값이 코드에 있으면 정책이 바뀔 때마다 이송이 필요하다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : '영세율 세금코드 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zexp_taxmap {
  key mandt    : mandt not null;
  key mwskz    : mwskz not null;      " 세금코드
  zero_rated   : abap.char(1);         " X = 영세율로 본다
  valid_from   : abap.dats;
}

@EndUserText.label : '영세율 점검 정책값'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zexp_policy {
  key mandt        : mandt not null;
  key bukrs        : bukrs not null;
  tol_krw          : abap.dec(15,0);   " 허용 오차(원)
  period_rate_pct  : abap.dec(5,2);    " 분기 차이율 기준(%)
  term_need_pct    : abap.dec(5,2);    " 인코텀즈 점검 필요 비율 기준(%)
}

② 기본 뷰 — 청구 한 건의 원천을 한곳에

청구 문서 헤더 · 품목과 판매오더 영업 데이터를 조인해 청구 한 건당 한 행을 만듭니다. 외화 금액은 청구 문서의 통화 기준으로 합산하고, 통화 칸에 통화 의미를 붙여 이후 뷰가 금액을 잘못 더하지 않게 합니다.

" ─────────────────────────────────────────────────────────────
" ZI_ZeroRatedInvoice — 청구 한 건당 한 행
" 역할 : 청구일 · 문서 통화 · 환율 · 인코텀즈 · 외화 금액의 단일 원천.
" 나눈 이유 : 이후 모든 뷰가 같은 청구 정의를 쓰게 한다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수출 영세율 청구 기본'
define view entity ZI_ZeroRatedInvoice
  as select from vbrk
    inner join   vbrp on vbrp.vbeln = vbrk.vbeln
    left outer join vbkd on vbkd.vbeln = vbrp.aubel and vbkd.posnr = '000000'
{
  key vbrk.vbeln          as InvNo,
      vbrk.kunag          as CustId,
      vbrk.fkdat          as InvDate,
      vbrk.waerk          as Curr,
      vbrk.kurrf          as BookRate,
      vbrk.vkorg          as SalesOrg,
      vbkd.inco1          as Incoterms,
      max( vbrp.mwskz )   as TaxCode,       " 청구 품목 세금코드 — 원천 칸은 확인 필요
      vbrk.zz_declno      as DeclNo,        " 수출신고 증빙 번호 — 확장 필드 가정(확인 필요)
      @Semantics.amount.currencyCode: 'Curr'
      sum( vbrp.netwr )   as FcAmt
}
group by vbrk.vbeln, vbrk.kunag, vbrk.fkdat, vbrk.waerk, vbrk.kurrf,
         vbrk.vkorg, vbrk.zz_declno, vbkd.inco1

③ 차원 뷰 — 선적일과 청구의 연결

선적일을 어느 문서에서 가져올지가 이 화면의 귀속 분기를 결정합니다. 아래는 출하 실제 출고일을 문서 흐름으로 청구에 잇는 스케치이며, B/L 일자를 별도 자료에서 가져오는 고객사는 이 뷰만 바꾸면 됩니다. 문서 흐름의 유형 조건은 고객 시스템에 맞춰 확인이 필요합니다.

" ─────────────────────────────────────────────────────────────
" ZI_ExportShipment — 청구별 선적일(출하 실제 출고일)
" 역할 : 청구 번호에 선적일을 붙인다. 선적 전이면 선적일은 초기값.
" 나눈 이유 : 선적일 원천이 바뀌어도 큐브를 고치지 않게 한다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '청구별 선적일'
define view entity ZI_ExportShipment
  as select from vbfa as flow
    inner join   likp on likp.vbeln = flow.vbelv
{
  key flow.vbeln          as InvNo,        " 후속 문서 = 청구
      min( likp.wadat_ist ) as BlDate      " 실제 출고일 (B/L 일자는 확인 필요)
}
where flow.vbtyp_n = 'M'                   " 후속 문서 유형: 청구 (시스템에 맞춰 확인)
  and likp.wadat_ist <> '00000000'
group by flow.vbeln

④ 큐브 뷰 — 장부 금액과 신고 대상 금액, 판정을 한 번만

이 화면의 계산이 모두 이곳에서 정해집니다. 장부 금액은 청구 외화에 청구일 환율을, 신고 대상 금액은 증빙이 연결된 외화에 선적일 환율을 곱하고, 귀속 분기와 판정을 한 번만 계산해 둡니다. 판정을 쿼리마다 따로 계산하면 같은 청구가 화면마다 다른 유형으로 보일 수 있습니다. 증빙 연결 여부와 증빙 번호의 원천은 시스템마다 달라 확인 필요이며, 아래는 그 값이 확장 필드로 있다고 가정한 스케치입니다.

" ─────────────────────────────────────────────────────────────
" ZI_ZeroRatedRecon — 청구 한 건의 장부 금액 · 신고 대상 금액 · 판정
" 역할 : 두 기준의 원화 금액과 차이, 귀속 분기, 판정을 한 번만 정한다.
" 나눈 이유 : 모든 쿼리가 같은 판정을 읽게 한다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@Analytics.dataCategory: #CUBE
@EndUserText.label: '영세율 매출 대사 큐브'
define view entity ZI_ZeroRatedRecon
  as select from ZI_ZeroRatedInvoice as inv
    left outer join ZI_ExportShipment as shp on shp.InvNo = inv.InvNo
    left outer join zexp_taxmap       as tax on tax.mwskz = inv.TaxCode
{
  key inv.InvNo,
      inv.SalesOrg,
      inv.Incoterms,
      inv.Curr,
      @Semantics.amount.currencyCode: 'Curr'
      inv.FcAmt,
      inv.InvDate,
      shp.BlDate,

      " 귀속 분기 : 청구일 분기와 선적일 분기
      concat( substring( inv.InvDate, 1, 4 ),
        case when substring( inv.InvDate, 5, 2 ) <= '03' then '-Q1'
             when substring( inv.InvDate, 5, 2 ) <= '06' then '-Q2'
             when substring( inv.InvDate, 5, 2 ) <= '09' then '-Q3'
             else '-Q4' end )                       as BookPeriod,

      " 장부 금액 = 청구 외화 × 청구일 환율 (영세율 건만)
      case when tax.zero_rated = 'X'
           then cast( inv.FcAmt * inv.BookRate as abap.dec(17,0) )
           else cast( 0 as abap.dec(17,0) ) end      as BookKrw,

      " 판정 : 위에서부터 먼저 해당하는 조건 하나만
      case when shp.BlDate is null                   then 'EXC'
           when tax.zero_rated is null               then 'TAXCODE'
           when inv.DeclNo = ''                      then 'NODECL'
           else 'OK' end                             as DiffType
}

⑤ 분석 쿼리 — 화면이 읽는 모양으로

큐브를 그대로 노출하지 않고 화면에서 쓰는 필터와 정렬, 표시 주석만 붙인 쿼리 뷰를 둡니다. 회계연도는 필수 필터로 걸어 전 기간을 한 번에 읽는 일을 막습니다. 분기별 · 통화별 · 인코텀즈별 묶음은 같은 큐브를 다른 그룹으로 읽는 쿼리를 따로 둡니다.

" ─────────────────────────────────────────────────────────────
" ZC_ZeroRatedQuery — 청구 명세 화면용 쿼리
" 역할 : 필터 · 정렬 · 표시 주석. 계산은 큐브에서 이미 끝났다.
" 나눈 이유 : 화면 요구가 바뀌어도 계산 로직은 건드리지 않는다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '영세율 청구 명세'
@Metadata.allowExtensions: true
define view entity ZC_ZeroRatedQuery
  as projection on ZI_ZeroRatedRecon
{
      @UI.lineItem: [{ position: 10 }]
  key InvNo,
      SalesOrg,
      @UI.lineItem: [{ position: 20 }]
      @Consumption.filter: { selectionType: #SINGLE, multipleSelections: true }
      Incoterms,
      @UI.lineItem: [{ position: 30 }]
      Curr,
      @UI.lineItem: [{ position: 40 }]
      InvDate,
      @UI.lineItem: [{ position: 50 }]
      BlDate,
      @UI.lineItem: [{ position: 60 }]
      BookKrw,
      @UI.lineItem: [{ position: 70 }]
      @Consumption.filter: { selectionType: #SINGLE, multipleSelections: true }
      DiffType
}

⑥ 접근 제어 — 판매 조직 단위로

권한은 집계 단계에 겁니다. 상세 단계에만 걸면 합계에서 남의 몫이 뺄셈으로 드러납니다. 아래 권한 객체는 청구 문서의 판매 조직 권한을 쓰는 예이며, 고객사의 권한 설계에 맞춰 확인이 필요합니다.

" ─────────────────────────────────────────────────────────────
" ZC_ZeroRatedQuery — DCL
" 역할 : 판매 조직 권한이 있는 청구만 읽게 한다.
" 나눈 이유 : 전사 합계와 자기 몫의 차이로 남의 숫자가 드러나지 않게.
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '영세율 청구 명세 권한'
@MappingRole: true
define role ZC_ZeroRatedQuery {
  grant select on ZC_ZeroRatedQuery
    where ( SalesOrg ) = aspect pfcg_auth( V_VBRK_VKO, VKORG, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩 — 화면이 부르는 서비스

쿼리를 서비스로 노출하는 마지막 층입니다. 화면의 앱 설정에는 서비스 주소가 상대 경로 하나로 적혀 있어, 운영에서는 Binding 을 게시한 뒤 이 주소만 바꾸면 됩니다.

" ─────────────────────────────────────────────────────────────
" ZUI_ZeroRatedService — Service Definition
" 역할 : 화면이 읽는 묶음을 한 서비스로 노출한다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label: '영세율 매출 대사 서비스'
define service ZUI_ZeroRatedService {
  expose ZC_ZeroRatedQuery as ZeroRatedInvoice;
}
" Service Binding : OData V2 - UI 로 만들어 게시한다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 코드가 아니라 합의입니다.

운영 데이터로 갈 때

청구가 해마다 수만 건을 넘기면 먼저 막히는 곳은 판정이 아니라 조인입니다. 회계연도를 필수 조건으로 두고, 청구일 기준 범위를 좁혀 읽게 하며, 출하 · 청구 연결 뷰는 미리 집계해 두는 쪽을 검토합니다. 응답 시간 기준은 고객사와 정해야 하며 이 글은 수치를 약속하지 않습니다. 샘플 85건에서의 응답은 운영 규모를 대표하지 않습니다.

자주 묻는 질문

도입 전에 가장 많이 나오는 질문을 숫자와 산식 · 화면과 사용 · 표준 SAP 와의 관계 · 도입과 운영으로 묶었습니다. 이 글은 점검 도구를 소개하며 영세율 적용 여부나 신고 금액의 판단을 대신하지 않습니다.

숫자와 산식

화면과 사용

표준 SAP 와의 관계

도입과 운영