정기결제 도입 전 고객 동의와 등록 상태, 첫 청구·출금 결과·증빙을 나누는 방법을 청구스 공식 가이드 기준으로 정리합니다.
- CMS 자동이체는 고객 계좌에서 정기적으로 대금을 출금하는 방식입니다. 계좌번호만 받았다고 바로 출금할 수 있는 것은 아닙니다.
- 동의서 확보→등록 완료 확인→청구 설정→출금 결과 확인을 나누세요.
- 청구스는 출금동의 링크와 청구 흐름을 연결하지만, 동의 대기 고객과 출금 실패 고객은 따로 관리해야 합니다.
이미지 크게 보기 자동이체 신청에 계좌번호만 있으면 될까요?
CMS는 사업자가 신청한 대금을 고객 계좌에서 출금하는 수납 방식입니다. 정기적으로 같은 금액을 받는 학원·관리·용역 사업이라도 계좌 정보와 고객 동의가 먼저 갖춰져야 합니다.
청구스 공식 가이드는 고객에게 링크를 보내 계좌 정보 입력과 전자서명을 받는 흐름을 안내합니다. 서명 후 생성되는 출금동의 문서와 등록 상태를 확인하고 나서 수납 일정을 잡으세요. 종이 동의서 방식도 공식 안내에서 확인할 수 있습니다. [근거 1]
구두로 “매달 빼 가세요”라고 들었다는 메모를 등록 완료 표시와 혼동하면 안 됩니다. 담당자는 동의 요청일·서명 완료일·등록 결과를 나눠 기록하고, 등록 전 청구는 다른 수납 방법이 필요한지 정합니다.
도해 크게 보기 사업자와 고객은 각각 무엇을 준비하나요?
먼저 사업자가 CMS 이용 준비를 마쳤는지 확인하세요. 고객 정보 입력 화면이 보이는 것과 실제 출금 요청이 가능한 상태는 다릅니다. 이용 신청 과정과 준비 서류는 현재 계약·심사 안내를 확인해야 합니다.
고객에게는 출금할 계좌와 동의 절차를 안내합니다. 금액, 청구 주기, 문의처도 함께 설명하면 고객이 왜 링크를 받았는지 이해하기 쉽습니다. 개인정보가 담긴 동의 문서를 공개 링크나 공동 게시판에 올리지 마세요. [근거 1]
고객별 관리표에는 계좌번호 전체 대신 내부 식별값을 쓰고 원본은 접근 권한을 제한해 보관하는 편이 좋습니다. 영업 담당자에게 필요한 정보는 동의 여부와 등록 결과이지 고객의 금융정보 전체가 아닙니다.
| 주체 | 첫 출금 전 확인 |
|---|---|
| 사업자 | 이용 신청·출금 가능 상태 |
| 고객 | 계좌 정보·출금 동의 완료 |
| 수납 담당자 | 등록 결과·금액·청구 주기 |
도해 크게 보기 20명에게 월 22만원을 받는다면 어떻게 나누나요?
설명용 가상 사례로 고객 20명의 월 이용료가 각각 22만원이라고 하겠습니다. 청구 예정 총액은 440만원이지만 출금동의를 마치고 등록된 고객은 18명뿐입니다.
등록 완료 18명의 396만원과 동의 대기 2명의 44만원을 분리하세요. 아직 등록되지 않은 44만원까지 자동이체 성공 예상액으로 잡으면 현금 계획이 부풀려집니다.
등록 완료 또한 실제 입금 완료와 다릅니다. 18명 중 출금이 실패한 고객이 생기면 성공 건과 실패 건을 다시 나눠야 합니다. 예시는 고객별 금액이 같고 추가 청구·환불이 없는 조건이며 실제 운영은 계약별 금액을 사용합니다.
| 구분 | 가상 사례 금액 |
|---|---|
| 전체 20명 × 22만원 | 440만원 |
| 등록 완료 18명 × 22만원 | 396만원 |
| 동의 대기 2명 × 22만원 | 44만원 |
도해 크게 보기 매월 25일 출금으로 딱 고정할 수 있나요?
현재 청구스 업데이트 안내는 출금 요청과 영업일 처리를 설명하고, 특정 날짜 고정 출금과 부분 출금의 제한을 알립니다. 달력에 날짜를 적는 것만으로 그날 전액 출금된다고 고객에게 약속하지 마세요. [근거 2]
등록이 완료된 고객을 대상으로 언제 청구하고 언제 요청 결과를 확인할지 정해야 합니다. 휴일, 등록 대기, 실패 결과가 끼어들 수 있으므로 첫 달은 고객에게 처리 시점과 실패 시 연락 방법을 미리 알려 두는 편이 좋습니다.
자동이체 신청 안내와 계약서의 지급기일도 맞춰 보세요. 지급기일은 고객이 돈을 내기로 한 계약상 기한이고 CMS 요청·처리 시점은 수납 절차입니다. 둘을 같은 칸에 적으면 미납 여부를 판단하기 어렵습니다.
도해 크게 보기 잔액이 부족하면 몇 번 다시 시도하나요?
청구스 가이드가 설명하는 재시도는 최초 출금을 합쳐 최대 3번입니다. 첫 실패 뒤 3일 후, 그 뒤 다시 3일 후 재시도하는 흐름이며 요청 시점 기준의 간격과 실제 입금 결과 확인을 구분해야 합니다. [근거 1]
따라서 “첫 출금 후 세 번 더 시도한다”라고 안내하면 횟수가 틀립니다. 계속 실패하면 자동이체만 기다리지 말고 고객에게 잔액·계좌 상태를 확인하고 다른 결제 방법이나 수납 일정을 합의할지 판단하세요.
같은 청구에 대해 고객이 별도 이체를 했다면 재출금 중복 위험도 확인해야 합니다. 청구 상태와 입금 내역을 연결해 검토하되, 화면의 상태가 바뀌었다는 사실만으로 모든 별도 이체가 자동 연결됐다고 가정하지 않습니다.
도해 크게 보기 출금과 세금 증빙은 어떻게 연결하나요?
돈이 들어오는 시점과 세금계산서·현금영수증을 발급해야 하는 시점은 같은 문제가 아닙니다. 공급시기, 거래 유형, 과세·면세 여부에 따라 증빙을 정해야 하며 CMS 결과만 보고 세법상 발급일을 정하면 안 됩니다. [근거 3]
청구스에서 청구·수납·증빙 흐름을 설정하더라도 실제 거래에 맞는 증빙 유형과 발급 설정을 확인하세요. 공식 안내의 자동화 흐름을 활용하는 목적은 담당자가 확인할 건을 줄이는 데 있으며 세무 판단을 대신하는 것은 아닙니다. [근거 1]
월 마감에는 청구 예정액, 실제 수납액, 미납액, 발급 증빙을 대조합니다. 앞의 사례에서 44만원이 동의 대기라고 해서 이미 제공한 과세 용역의 증빙 의무까지 사라지는 것은 아닙니다. 용역 제공 여부와 계약 조건을 따로 봐야 합니다.
도해 크게 보기 청구스 도입 전 마지막으로 확인할 것은?
정기 수납 고객이 많고 동의 요청·청구·결과 확인이 서로 다른 파일에 흩어져 있다면 연결된 흐름을 검토할 만합니다. 반대로 고객마다 금액이나 출금일이 자주 바뀌면 현재 기능 제한이 운영 방식과 맞는지 먼저 확인하세요.
사업자 준비→고객 동의→등록 완료→첫 청구→결과 확인→증빙 대사의 여섯 단계를 실제 담당자 한 명의 동선으로 점검하면 됩니다. “자동이체 도입 완료”보다 어느 단계가 대기인지 보여주는 관리가 중요합니다.
비용도 구분하세요. 청구스 구독료와 CMS 처리 비용은 별개로 확인해야 합니다. 이번 글은 동의·등록 준비에 초점을 맞춘 공식 문서 검토이며 실제 고객 사용 후기나 절감 실험을 한 결과는 아닙니다. [근거 2]
도해 크게 보기 확인한 근거
이 글은 일반적인 이해를 돕는 자료입니다. 실제 적용은 거래 내용과 적용 기준에 따라 달라질 수 있습니다.
검토·수정 이력
2026-10-02 · 전문가 검수 확인 후 발행.