결제조건 자금비용 반영 수익성 점검 — 결제조건이 길고 입금이 늦은 거래의 자금비용을 청구마다 반영해 공헌이익이 얼마나 줄어드는지 확인하는 수익성 분석

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

영업은 결제조건을 길게 주고 계약을 따옵니다. 재무는 입금이 늦어지면 독촉을 합니다. 그런데 그 청구가 결국 이익을 얼마나 남겼는지는 어느 쪽에서도 한 번에 보이지 않습니다. 공헌이익은 매출에서 변동비만 빼고, 돈이 들어올 때까지 묶인 자금의 비용은 다른 보고서나 엑셀로 따로 계산하기 때문입니다. 이 화면은 그 자금비용을 청구 한 줄마다 약정 기간분과 지연 기간분으로 나눠 붙이고, 자금비용을 뺀 공헌이익률로 다시 점검합니다.

핵심 포인트 여덟 가지

사례로 보는 효과 — 공헌이익률 14.47%가 13.39%가 되는 과정

검증용 샘플의 판정 대상 청구 64건(입금 미완료 4건 제외)을 합치면 매출액은 194.76억원, 공헌이익은 28.18억원(공헌이익률 14.47%)입니다. 여기서 자금비용 2.09억원을 빼면 자금비용 반영 공헌이익은 26.08억원, 반영 후 공헌이익률은 13.39%입니다. 자금비용은 약정 기간분 1.77억원과 지연 기간분 0.32억원으로 나뉘고, 공헌이익의 약 7.4%에 해당합니다. 전체로는 1.08%p 가 빠진 정도지만, 조건별로 보면 차이가 큽니다.

120일 후 지급 조건은 공헌이익률 11.68% 에서 반영 후 10.00% 로 내려가고, 판정 대상 13건 중 9건이 점검 필요입니다. 반면 30일 후 지급 조건은 16.00% 에서 15.54% 로 거의 그대로입니다. 청구 하나를 보면 120일 조건의 한 건은 공헌이익률 7.17% 에서 반영 후 5.85% 로 내려가고 자금비용이 공헌이익의 18.39% 를 차지합니다. 매출액과 공헌이익률만 봤다면 “거래가 이어지고 있다”로 끝났을 숫자입니다. 다만 이 표시는 점검 필요일 뿐, 단가 협상 문제인지 조건 설정 문제인지는 화면이 판단하지 않고 확인 순서만 정해 줍니다. 점검 필요 17건의 내역은 공헌이익률 미달 8건, 자금비용 비중 초과 6건, 입금 지연 3건입니다.

도입하면 달라지는 것

• 결제조건 협상의 근거 — “조건을 길게 줘도 되는가”를 매출이 아니라 반영 후 공헌이익률로 이야기합니다.
• 회수 관리의 우선순위 — 입금이 30일 이상 늦은 청구와 자금비용 비중이 큰 청구를 먼저 확인합니다.
• 고객·조건 비교 — 같은 지표가 결제조건 4종·고객 12곳으로 합산되어 부담이 큰 자리가 한눈에 보입니다.
• 숫자를 믿는 근거 — 8개 대사식과 의도적 예외가 화면에 그대로 나와 “이 숫자 맞아?”에 바로 답할 수 있습니다.

실행 화면

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

조회하고 걸러내기

조회조건은 회계연도·결제조건·고객·청구일 범위·점검 결과이고, 조회 버튼은 조건 영역 오른쪽 끝에 있습니다. 회계연도 입력 칸에서 Enter 키를 눌러도 조회됩니다. 요약 지표는 입금 미완료 청구 4건을 빼고 판정 대상 64건으로 더합니다.

점검 필요는 세 가지입니다. 반영 후 공헌이익률이 기준(9.00%)에 못 미치는 청구, 자금비용이 공헌이익의 13.00% 이상인 청구, 약정 입금기한보다 30일 이상 늦게 입금된 청구입니다. 표시는 원인을 단정하지 않고 확인 순서만 정해 줍니다.

요인과 요약

매출액 − 변동비 = 공헌이익, 공헌이익 − 약정 기간 자금비용 − 지연 기간 자금비용 = 자금비용 반영 공헌이익이 되도록 맞춰 두었고, 구성비와 산식 칸이 함께 있어 숫자가 어디서 나왔는지 바로 읽힙니다. 이 합은 대사식 R07·R08 로 전수 검증합니다.

30·60·90·120일 조건을 같은 지표로 견줍니다. 점검 필요 비율이 35% 이상이거나 반영 후 공헌이익률이 기준에 못 미치면 그 결제조건을 점검 필요로 표시합니다.

결제조건과 고객은 같은 청구 판정 행을 서로 다른 축으로 합산한 것이라 두 요약의 반영 후 공헌이익 합계는 같습니다(대사식 R05·R06).

근거까지 내려가기

데모를 신청하신 고객께 공개되는 내용입니다

CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.

데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.

데모 신청하기Google 계정으로 로그인

데모를 신청하신 고객께 공개되는 내용입니다

CDS 뷰 구성, 데이터 모델, 점검 · 산출 규칙처럼 실제 구현에 가까운 상세 설계는 이 앱의 데모를 신청하신 고객께만 보여 드리고 있습니다. 양해 부탁드립니다.

데모를 신청해 주시면 확인 후 바로 열람할 수 있도록 열어 드리고, 이미 신청하셨다면 신청하신 Google 계정으로 로그인하시면 이 자리에 내용이 표시됩니다.

데모 신청하기Google 계정으로 로그인

SAP 표준 기능 확장 포인트

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

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

표준 기능과 이어 쓰는 순서

1. 화면에서 점검 필요 청구를 고릅니다. 결제조건·고객 요약으로 부담이 큰 자리를 먼저 찾습니다.
2. 합계를 표준 수익성 보고서(KE30)와 맞춰 봅니다. 합계가 어긋나면 기간·조회 범위부터 확인합니다.
3. 개별 항목(KE24)과 청구 문서(VF03)로 내려가 매출과 변동비의 원천 전기를 확인합니다.
4. 고객 개별 항목(FBL5N)에서 입금일과 반제 내역을, 잔액(FD10N)에서 미입금 청구의 남은 금액을 확인합니다.

표준에 없는 자리

청구마다 자금비용을 걷어낸 판정과 약정 기간·지연 기간 구분은 표준에 없습니다. 이 화면이 그 계산을 하고, 계산에 쓴 가정(연 자금비용률 4.50%, 판정 기준 9.00%·13.00%·30일, 요약 행 기준 35%)을 모두 샘플 값으로 밝혀 둡니다. 운영에서는 이 가정을 회사 기준에 맞춰 정해야 하며, 그 결정이 도입에서 가장 큰 일입니다.

OData 서비스 계약

화면은 manifest 에 선언한 상대 경로의 OData V2 서비스 하나만 부릅니다. 서비스 이름은 소문자 termprofit_srv 이고 엔티티셋 5개(InvoiceSet · FactorSet · TermSet · CustSet · ReconSet)와 펑션 2개(GetMinNetRate · GetMaxNetRate)를 노출합니다. 조회조건은 모두 $filter 로, 정렬·페이징은 $orderby · $top · $skip 으로 보내고 총건수는 $inlinecount=allpages 로 받습니다. 날짜 범위 조건은 서비스가 직접 처리합니다.

CDS 구성

자주 묻는 질문

도입 상담과 데모에서 받는 질문을 세 묶음으로 나눠 적었습니다.

기준과 산식

화면과 데이터

표준 기능과 운영