SAP 법인카드 청구현황 조회 — 청구서 한 장에서 카드별 출금까지
카드사가 보내 준 월 청구내역을 카드별로 묶어 출금 규모를 먼저 잡고, 명세에서 금액 구성을 확인하는 화면입니다.
법인카드 정산에서 담당자가 확인할 것은 두 가지입니다. 카드사가 청구한 금액이 어떻게 구성됐는가, 그리고 그 금액이 어느 카드에서 나왔는가입니다.
국내 사용분은 결제원금에 부가세가 포함되고, 해외 사용분은 현지 통화 금액을 환산한 뒤 환가료가 붙습니다. 성격이 다른 두 금액이 한 청구서에 섞여 들어오기 때문에, 카드사가 보내 준 명세를 그대로 나열하면 카드별로 얼마가 청구됐는지 읽기 어렵습니다. 전송 레이아웃 28개 항목을 그대로 담되 위에 카드별 집계를 두어 전체를 먼저 잡고 명세로 내려가도록 OpenUI5 화면으로 확장한 것이 이 앱입니다. 실제 구동 화면 5종을 함께 공개합니다.
카드사 전송 레이아웃을 그대로 이어받은 부분
- 건별 키 — 신용카드 매출관리번호(
DEMA_COLL)를 그대로 유지해 카드사 원본과 대조 가능 - 금액 항목 —
SETT_PRIN·CHARGE·INTEREST·VAT·SALE_AMT·TOTAL구성 그대로 - 가맹점 정보 —
MERC_SOCNO·MERC_NAME·MERC_REPR·MERC_TEL·MERC_ADDR1/2·MCCNAME - 해외 사용 —
FORE_USE·ACKDOLLAR·LOCAL_CURRENCY로 현지 통화 금액 유지
| 항목 | 내용 |
|---|---|
| 업무 영역 | 재무회계(FI-GL) · 법인카드 청구 정산 |
| Namespace | zui5.cardbill |
| 셸 구조 | 조회조건 영역(우측 조회) + 카드별 집계 + 청구 명세, 집계 행 선택 시 명세 필터 |
| 화면 수 | 조회 화면 1개 (집계 · 명세 2단 구성) |
| 데이터 | 청구 명세 96건 (28개 필드) · 카드 5매 |
| 성격 | 조회형(Read-Only) — 적재와 전표 생성은 인터페이스·표준이 담당 |
| UI 테마 | sap_horizon 단일 적용 |
실제 화면 5종 둘러보기
청구월만 넣고 조회하면 카드별 집계와 전체 명세가 함께 나옵니다 → 사용 구분으로 해외 건만 걸러 보고 → 카드 행을 선택해 그 카드의 명세로 좁혀 들어갑니다.
아래는 실제로 앱을 실행해 기능을 눌러 가며 캡처한 화면입니다. 이미지를 클릭하면 원본 크기로 확대됩니다.
조작 방법
- 청구 연월을 YYYYMM 형식(예: 202608)으로 넣습니다. 기본값은 시스템 일자의 전월이며, 6자리가 아니면 조회를 중단하고 안내합니다.
- 카드를 지정하지 않고 조회하면 그 달에 청구된 전체 카드가 집계로 나옵니다. 여기서 출금 규모를 먼저 잡습니다.
- 사용 구분을 해외로 바꾸면 환가료가 붙은 건만 남습니다. 국내 건과 정산 성격이 달라 따로 보는 편이 빠릅니다.
- 카드별 집계에서 카드 행을 선택하면 조회조건의 Card No 가 채워지고 명세가 그 카드로 좁혀집니다.
- 조회조건 입력필드에서 Enter 를 눌러도 바로 조회됩니다. 청구월을 바꿔 가며 훑을 때 손이 마우스로 가지 않습니다.
- 결과는 집계 CSV 와 명세 CSV 두 가지로 내려받습니다. UTF-8 BOM 이 붙어 엑셀에서 한글이 깨지지 않습니다.
청구금액 구성 판정
판정의 뼈대는 식 하나입니다. 카드사가 청구한 금액은 결제원금에 부대비용을 더하고 할인을 뺀 값입니다.
총 청구금액 = 결제원금 + 봉사료 + 환가료 − 청구할인
TOTAL SETT_PRIN CHARGE INTEREST SALE_AMT
국내 (FORE_USE = N) 결제원금 = 공급가액 + 부가세 환가료 없음
해외 (FORE_USE = Y) 결제원금 = 현지 액면금액 × 환율 부가세 없음, 환가료 발생
승인금액 CACL_AMT = 해외는 현지 액면금액, 국내는 결제원금
| 구분 | 통화 | 부가세 | 환가료 | 결제원금 산출 |
|---|---|---|---|---|
국내 FORE_USE = N | KRW | 공급가액의 10% | 없음 | 공급가액 + 부가세 |
해외 FORE_USE = Y | USD · JPY · EUR | 없음 | 원금의 일정률 | 현지 액면금액 × 환율 (10원 단위) |
금액이 맞지 않으면 무엇을 의심하나
총 청구금액이 식과 어긋나면 카드사 전송 파일에서 부대비용 항목이 누락됐거나, 할부·분할 청구 건이 섞여 원금이 나뉘어 들어온 경우입니다. 해외 건이라면 환율 적용 시점(승인일·매입일·청구일)이 달라 현지 액면금액 × 환율과 결제원금이 벌어지기도 합니다. 명세에서 해당 매출관리번호를 찾아 전송내역키로 원본을 대조합니다.
카드 청구 처리 5단계
카드 한 건은 사용에서 결제까지 아래 순서로 흘러갑니다. 이 화면이 다루는 지점은 4단계이며, 앞 단계의 값이 그대로 따라 들어옵니다.
| 단계 | 처리 | 이 화면과의 관계 |
|---|---|---|
| 1. 사용 | 카드 사용일에 가맹점에서 결제 | 카드사용 일자(USEDATE) · 가맹점 정보 |
| 2. 승인 | 카드사 승인 처리, 승인번호 발급 | 승인번호(ACKNO) · 승인금액(CACL_AMT) |
| 3. 매입 | 가맹점 매입 접수, 매출관리번호 부여 | 매출관리번호(DEMA_COLL) — 건별 고유 키 |
| 4. 청구 | 월 단위로 묶어 법인에 청구 | 이 화면의 조회 기준 — 청구월 · 청구일자 |
| 5. 결제 | 지정 계좌에서 출금 | 결제은행 · 결제계좌 · 결제일자(SETT_DATE) |
승인과 매입 사이에 시차가 있어 사용일이 전월이어도 청구는 이번 달에 잡힐 수 있습니다. 그래서 조회 기준은 사용월이 아니라 청구월입니다.
조회조건
| 필드 | 필수 | 설명 |
|---|---|---|
회사코드 Bukrs | 필수 | 변경 못함. 로그인 사용자 → 사번 → 사원 Vendor 순으로 기본값 결정 |
청구 연월 Billmon | 필수 | YYYYMM. 기본값은 시스템 일자 전월 |
카드번호 CardNum | 선택 | 카드 목록에서 선택. 비우면 전체 카드 |
사용 구분 ForeUse | 선택 | 전체 / 국내 / 해외 |
회사코드는 변경할 수 없습니다. 기본값은 로그인 사용자 ID로 사번을 찾고(USR21 · ADCP), 그 사번으로 사원 Vendor 의 회사코드를 찾아(LFB1) 채우는 순서로 결정됩니다.
결과 컬럼
카드별 청구 집계
| 컬럼 | 의미 · 표시 |
|---|---|
| 카드번호 · 사용자 · 부서 | 키 컬럼. 좌측 고정 |
사업장번호 BusiNumb | 카드가 등록된 사업장 |
| 건수 · 해외 | 청구 건수와 그중 해외 사용 건수 |
| 결제원금 · 부가세 · 환가료 · 청구할인 | 구성 항목별 합계, 우측정렬 |
총 청구금액 Total | 카드별 청구 합계 — 결제 계좌에서 빠져나갈 금액 |
| 결제은행 · 결제계좌 | 출금 계좌 |
청구 명세 — 전송 레이아웃 28항목
| 컬럼 | 의미 · 표시 |
|---|---|
매출관리번호 DemaColl | 건별 고유 키. 카드사 원본 대조 기준 |
카드번호 CardNum | 마스킹 형식 |
해외사용 여부 ForeUse | 국내 / 해외 — 금액 구성이 갈리는 기준 |
법인 사업자번호 BzSocno · 사업장번호 BusiNumb | 법인 단일값 · 카드 등록 사업장 |
카드사용 일자 UseDate | 실제 결제한 날 |
총 청구금액 Total | 결제원금 + 봉사료 + 환가료 − 청구할인 |
승인금액(현지) AckDollar · 승인번호 Ackno | 해외 건 액면금액 · 카드사 승인번호 8자리 |
가맹점 MERC_* | 사업자번호 · 상호 · 대표자 · 전화 · 주소1 · 주소2 |
업종명 MccName | 비용 계정 결정 참고 |
청구일자 DemaDate | 카드사 청구 확정일 |
| 결제은행 · 결제계좌 · 결제일자 | 출금 정보 |
| 결제원금 · 봉사료 · 환가료 · 부가세 | 구성 항목, 우측정렬 |
승인금액 CaclAmt · 청구할인 SaleAmt | 해외는 현지금액 · 차감 항목 |
통화 LocalCurrency · 전송내역키 Billidno | 현지 통화 · 카드사 전송 단위 키 |
SAP 표준 기능 매핑
카드 데이터 적재와 전표 생성은 표준이 담당합니다. 이 화면은 적재된 청구내역을 읽어 카드별 집계와 가맹점 관점을 더해 확장합니다.
| 표준 | 역할 | 이 화면에서의 확장 |
|---|---|---|
| 카드사 인터페이스 | 전송 파일 수신 · 청구내역 테이블 적재 | 적재된 내역을 청구월 · 카드 단위로 모아 집계 관점 제공 |
FB60 · F-43 | 카드 비용 전표 입력 | 전표 입력 전에 청구 구성과 가맹점 정보를 확인하는 단계 |
FBL3N 관점 | G/L 계정 라인아이템 조회 | 계정 라인 나열 대신 카드 × 사용 구분으로 집계해 정산 중심으로 재구성 |
USR21 · ADCP · LFB1 | 사용자 · 사번 · 사원 Vendor | 회사코드 기본값 결정 경로 |
| 부가세 신고 연계 | 매입세액 집계 | 가맹점 사업자번호 · 업종 · 부가세를 명세에 표시해 공제 대상 판단 지원 |
도입 시 확인이 필요한 부분
카드사 전송 레이아웃은 카드사마다 다릅니다. 항목명과 자릿수, 해외 건의 환율 적용 기준이 달라지므로 실제 도입 때는 인터페이스 규격서와 수신 주기를 함께 확인해 적재 테이블 구조를 정합니다. 법인카드 사용자 등록과 조회 권한 범위(재무팀 · 카드 사용자 본인)도 프로젝트 표준에 맞춰 조정합니다.
참고 CDS 뷰
운영 서비스로 연결할 때는 청구내역에 카드 마스터와 사용자 정보를 붙여 카드 단위로 서빙하는 뷰를 제안합니다.
@AbapCatalog.sqlViewName: 'ZCCARDBILL'
@EndUserText.label: '법인카드 청구현황 (Z)'
define view Z_C_CARD_BILL
as select from ztfia0030 as Bill
{
key Bill.bukrs as Bukrs,
key Bill.billmon as Billmon,
key Bill.dema_coll as DemaColl,
Bill.card_num as CardNum,
Bill.fore_use as ForeUse,
Bill.bz_socno as BzSocno,
Bill.busi_numb as BusiNumb,
Bill.usedate as UseDate,
Bill.merc_name as MercName,
Bill.mccname as MccName,
Bill.sett_prin as SettPrin,
Bill.charge as Charge,
Bill.interest as Interest,
Bill.vat as Vat,
Bill.sale_amt as SaleAmt,
// 총 청구금액 = 결제원금 + 봉사료 + 환가료 - 청구할인
Bill.sett_prin + Bill.charge + Bill.interest - Bill.sale_amt as Total,
Bill.local_currency as LocalCurrency,
Bill.ackdollar as AckDollar,
Bill.sett_bank as SettBank,
Bill.sett_date as SettDate
}
매핑 이해를 돕기 위한 참고용 설계입니다. 실제 도입 시에는 카드사 레이아웃과 사용자 등록 체계에 맞춰 조정합니다.
OpenUI5 구성
| 기능 | 사용 컨트롤 |
|---|---|
| 화면 골격 | sap.m.Page + 조회조건 영역 · 집계 패널 · 명세 패널 |
| 조회조건 | sap.m.Input · sap.m.ComboBox · sap.m.RadioButtonGroup — 우측 끝에 조회 |
| 카드별 집계 | sap.ui.table.Table — 행 선택 시 명세 필터 연동(cellClick) |
| 청구 명세 | sap.ui.table.Table — 28컬럼, 키 3개 고정, 컬럼 재정렬 허용 |
| 해외 건 강조 | RowSettings.highlight · sap.m.ObjectStatus |
| 요약 표시 | sap.m.MessageStrip · sap.m.ObjectStatus — 청구일 · 결제일 |
| CSV | Blob + UTF-8 BOM — 집계 · 명세 2종 |
집계와 명세를 한 화면에 둔 이유
명세 28개 컬럼만 펼치면 어느 카드가 얼마인지 읽으려고 좌우로 훑어야 합니다. 반대로 집계만 보면 어떤 가맹점에서 쓴 건인지 알 수 없습니다. 위에 카드별 집계, 아래에 명세를 두고 집계 행을 선택하면 명세가 그 카드로 좁혀지도록 연결해 전체에서 개별로 내려가는 흐름을 한 화면에서 끝내도록 했습니다.
파일 구성
| 경로 | 역할 |
|---|---|
manifest.json | 앱 디스크립터 — 앱 ID(zui5.cardbill) · ko 로케일 · sap_horizon |
Component.js | 선택조건 모델 · 결과 모델 초기화 |
view/Main.view.xml | 조회화면 + 카드별 집계 + 청구 명세(28컬럼) |
controller/Main.controller.js | 조회 · 사용구분 전환 · 카드 드릴다운 · CSV 2종 |
model/ModelMock.js | localdata JSON 읽기 — 청구월 · 카드 · 사용구분 필터, 카드별 집계 |
model/formatter.js | 금액 · 현지통화 · 일자 · 청구월 · 해외구분 · 주소 포맷터 |
i18n/i18n_ko.properties | ko 로케일 리소스 |
localdata/cardbill.json | 청구 명세 96건 (28개 필드) |
카드사 레이아웃이 바뀌어도 ModelMock 과 포맷터, i18n 세 파일만 손보면 화면 로직은 그대로 씁니다.
검증 결과
화면 구성에 쓴 데이터는 카드 5매의 한 달치 청구내역을 국내·해외 비율과 부대비용 규칙에 맞춰 생성한 것입니다.
| 데이터 | 규모 | 구성 |
|---|---|---|
| 청구 명세 | 96행 | 카드 5매 × 한 달치. 국내 79건 · 해외 17건 |
| 카드별 집계 | 5행 | 카드 단위 건수 · 구성 항목별 합계 |
| 총 청구금액 | 23,775,070원 | 결제원금 23,752,620 · 부가세 940,800 · 환가료 67,000 · 할인 50,950 |
| 검증 항목 | 결과 |
|---|---|
| 총 청구금액 = 결제원금 + 봉사료 + 환가료 − 청구할인 | 통과 |
| 국내는 원화·부가세 존재 / 해외는 외화·부가세 0·현지금액 보유 | 통과 |
| 해외 결제원금 = 현지 액면금액 × 환율 (10원 단위) | 통과 |
| 환가료는 해외에만 · 봉사료는 국내에만 | 통과 |
| 승인금액 = 해외는 현지금액, 국내는 결제원금 | 통과 |
| 카드번호 · 사업장번호가 마스터와 일치 · 법인 사업자번호 단일 | 통과 |
| 카드사용 일자 청구월 내 · 청구일자 < 결제일자 | 통과 |
| 가맹점 정보 6항목 보유 · 승인번호 8자리 | 통과 |
| 매출관리번호 중복 없음 · 청구할인 < 결제원금 | 통과 |
| 화면 렌더링 — 실브라우저 조회 → 사용구분 전환 → 드릴다운 실동작 후 캡처 | 5/5 |
| 테마 런타임 확인 | sap_horizon |
카드번호·가맹점·금액은 모두 검증용 데이터이며, 카드번호는 마스킹 형식(5433-01**-****-1102)을 따랐습니다.
자주 묻는 질문
조회 기준이 사용월이 아니라 청구월인 이유는?
카드 사용과 카드사 청구 사이에는 승인·매입 처리 시차가 있습니다. 월말에 쓴 건은 다음 달 청구서에 실릴 수 있어 사용월로 조회하면 실제 출금될 금액과 맞지 않습니다. 결제 계좌에서 빠져나갈 금액을 확인하는 화면이므로 카드사가 확정한 청구월을 기준으로 잡았습니다.
해외 건에 부가세가 없는데 정상인가요?
정상입니다. 국내 가맹점 결제는 공급가액에 부가세가 붙어 매입세액공제 대상이 되지만, 해외 사용분은 국내 부가세 과세 대상이 아닙니다. 대신 원화 환산 과정에서 환가료가 붙습니다. 두 금액은 성격이 달라 집계에서도 각각 표시합니다.
카드별 집계를 따로 둔 이유는?
청구 명세는 카드사 레이아웃을 그대로 담아 28개 컬럼입니다. 이것만 펼치면 어느 카드에서 얼마가 나왔는지 읽으려고 좌우로 훑어야 합니다. 위에 집계를 두면 출금 규모를 한눈에 잡고, 확인이 필요한 카드만 골라 명세로 내려갈 수 있습니다.
가맹점 사업자번호와 업종명은 왜 표시하나요?
매입세액공제 대상 여부와 비용 계정을 판단하는 근거이기 때문입니다. 접대성 업종이나 공제 제외 업종은 같은 금액이라도 처리가 달라집니다. 전표를 입력하기 전에 업종과 가맹점을 확인하면 부가세 신고 단계에서 되돌아오는 일이 줄어듭니다.
SAP 표준 기능과 어떻게 이어지나요?
카드사 전송 파일 수신과 적재는 기존 인터페이스가 담당하고 결과는 청구내역 테이블에 그대로 남습니다. 이 화면은 그 데이터를 청구월과 카드 단위로 모아 구성 항목별 집계와 가맹점 관점을 얹은 조회 전용 화면이며, 비용 전표 생성은 표준 트랜잭션이 담당합니다.