B2B SaaS 구독 청구 월말 대사 체크리스트 2026: invoice부터 payout까지 맞추는 법
B2B SaaS 구독 청구 월말 대사 체크리스트 2026: invoice부터 payout까지 맞추는 법
B2B SaaS 구독 청구의 월말 숫자는 한 화면에서 끝나지 않습니다. billing platform에는 invoice가 있고, payment processor에는 결제와 수수료가 있으며, payout에는 여러 거래가 묶입니다. ERP에는 별도 전표와 고객 코드가 있고 은행에는 최종 입금액과 bank reference만 남을 수 있습니다.
그래서 이번 달 paid invoice 합계 = 이번 달 은행 입금액이라고 바로 비교하면 정상 거래도 차이로 보입니다. invoice 발행일과 결제일, balance 반영일, payout 도착일의 timezone과 cutoff가 다르고, refund·credit·dispute·수수료·환전이 서로 다른 시점에 반영되기 때문입니다.
이 글은 플랫폼을 옮기는 일회성 프로젝트가 아니라 매월 같은 방식으로 반복하는 close 운영에 집중합니다. 이전 작업이 필요하다면 B2B SaaS 구독 청구 플랫폼 이전 체크리스트 2026에서 mapping·dry run·dual run·cutover를 먼저 확인하세요. 플랫폼을 아직 정하지 않았다면 B2B SaaS 구독 관리 플랫폼 비교 2026에서 Stripe Billing·Chargebee·Paddle·Recurly의 역할과 판매자 구조를 비교할 수 있습니다.
이 문서는 운영 통제와 데이터 품질을 위한 일반 체크리스트입니다. 특정 회사의 회계 처리, 세무 신고, 법률 판단이나 매출 인식 기준을 제시하지 않습니다. 계정과 지역, 계약, 결제수단, 통화, ERP 설정에 따른 판단은 회사의 담당자와 필요한 전문가가 별도로 확인해야 합니다.
먼저 결론: invoice에서 은행 입금으로 바로 점프하지 않습니다
월말 대사의 기본 연결은 다음과 같습니다.
[invoice / credit note / refund source ID]
↓
[payment or adjustment ID]
↓
[balance transaction]
↓
[payout ID]
↓
[ERP entry / bank reference]
↓
[exception queue + sign-off]
각 화살표에 안정적인 ID가 있어야 합니다. 고객명, invoice PDF 제목, 금액과 날짜만으로 연결하면 같은 금액의 거래, 부분 결제, 합산 payout, 환전, 분할 환불에서 오매칭이 생깁니다.
월말 close 전에 다음 여섯 가지를 한 페이지에 고정합니다.
- 어느 timezone의 몇 시를 cutoff로 사용할 것인가.
- invoice, payment, balance, payout, bank 각각 어떤 timestamp를 기준으로 삼을 것인가.
- 통화별 원금, 수수료, 환전 금액을 어느 필드로 비교할 것인가.
- 어떤 ID로 플랫폼·processor·ERP·은행 기록을 연결할 것인가.
- 자동 매칭 실패 건을 누가 언제까지 처리할 것인가.
- 누가 어떤 증거를 보고 close 완료에 sign-off할 것인가.
1단계: 네 개의 날짜와 통화를 먼저 고정합니다
한 거래에도 여러 날짜가 존재합니다. invoice가 7월 31일에 발행됐더라도 결제가 8월 1일에 완료되고 payout이 8월 4일에 은행에 도착할 수 있습니다. 세 기록은 서로 모순이 아니라 각기 다른 사건입니다.
| 레이어 | 기준 timestamp 예시 | 월말 질문 |
|---|---|---|
| invoice | created, finalized, due, paid | 이번 close 범위에 포함할 invoice 상태는 무엇인가 |
| payment | attempted, succeeded, failed, refunded | 성공과 실패를 어떤 시점으로 나누는가 |
| balance transaction | available_on, created | processor 잔액에 언제 반영되고 사용 가능해지는가 |
| payout | created, paid, arrival estimate | 어느 payout batch에 포함됐는가 |
| bank | posted date, value date | 실제 입금 reference와 금액은 무엇인가 |
운영 warehouse에서는 원본 timestamp를 UTC로 보존하고, close 기준 timezone을 별도 파생 필드로 만듭니다. 원본 시간을 로컬 시간으로 덮어쓰지 않습니다. 2026-07-31 23:58 UTC와 2026-08-01 08:58 KST가 같은 사건이라는 사실을 재현할 수 있어야 합니다.
통화도 한 열에 섞지 않습니다.
- 고객에게 표시된 presentment currency와 금액
- processor balance currency와 금액
- fee와 fee currency
- conversion rate와 환전 시각
- payout currency와 순액
- 은행 계좌 입금 currency와 실제 금액
환율 차이와 processor fee를 “기타 차이” 한 항목에 넣으면 다음 달에도 같은 예외가 반복됩니다. 원본 금액, 수수료, 환전, 순액을 분리해 원인 코드를 붙입니다.
2단계: source ID부터 payout까지 reconciliation ledger를 만듭니다
대사의 중심은 dashboard가 아니라 거래 연결 ledger입니다. 최소 필드는 다음과 같이 잡을 수 있습니다.
close_period
source_system
customer_id
invoice_id
payment_or_adjustment_id
balance_transaction_id
payout_id
erp_reference
bank_reference
source_currency
source_amount
fee_amount
net_amount
payout_currency
event_timestamp_utc
close_date_local
match_status
exception_code
evidence_url
Stripe Balance report 공식 문서는 balance activity와 payout reconciliation에 사용하는 보고서의 성격을 설명합니다. Stripe payout reconciliation 공식 문서는 자동 payout과 개별 거래를 맞추는 흐름을 확인하는 출발점입니다. API로 가져오는 팀은 Stripe Balance Transactions API의 객체와 필터를 기준으로 원본 ID와 금액, 수수료, 순액을 보존합니다.
여기서 중요한 것은 API 응답을 내부 의미로 임의 번역하지 않는 것입니다. 원본 type, source, currency, amount, fee, net, available_on을 raw 영역에 보존하고, close용 분류는 별도 열로 둡니다. 분류 규칙이 바뀌어도 원본에서 다시 계산할 수 있어야 합니다.
invoice와 payment가 1:1이라고 가정하지 않습니다. 하나의 invoice에 여러 payment attempt가 있을 수 있고, 부분 결제나 일부 refund가 발생할 수 있습니다. 반대로 payout 하나에는 여러 payment, refund, fee, adjustment가 포함될 수 있습니다. 따라서 invoice_id → payout_id를 바로 매핑하는 대신 중간 balance transaction을 연결합니다.
3단계: invoice·payment·refund·credit를 다른 사건으로 대사합니다
월말 표에서 invoice total만 보면 원인을 놓칩니다. 다음 상태를 별도 행 또는 별도 event로 유지합니다.
| 사건 | 보존할 최소 정보 | 잘못된 단축 해석 |
|---|---|---|
| invoice | 발행·확정 시각, 상태, currency, total, amount due | invoice 생성은 곧 현금 입금이다 |
| payment attempt | 시도 ID, 결과, 실패 코드, 처리 시각 | 실패는 곧 churn이다 |
| payment success | payment ID, 연결 invoice, amount, processor | 성공 시각과 payout 시각이 같다 |
| credit note | 원 invoice, 사유, 적용 방식, 금액 | credit는 곧 고객 환급이다 |
| refund | 원 payment, 요청·완료 상태, 금액, processor reference | refund 요청은 즉시 은행 출금 완료다 |
| dispute/adjustment | 원거래, 상태, amount, fee, 결정 시각 | 모두 일반 refund다 |
Chargebee Invoice Transactions 보고서 문서는 invoice와 연결된 transaction 보고를 확인하는 공식 출발점입니다. Chargebee refunds 공식 문서는 refund가 invoice·transaction과 어떻게 연결되는지 검토할 때 참고할 수 있습니다. 실제 export 열과 상태 값은 계정 설정과 현재 제품 문서를 기준으로 다시 확인합니다.
refund와 credit note의 이벤트 경계를 더 세밀하게 설계하려면 B2B SaaS 환불·크레딧 노트 추적 감사 체크리스트를 함께 적용하세요. 결제 실패 후 retry·고객 안내·복구 상태는 B2B SaaS 결제 실패·dunning 자동화 체크리스트로 분리해야 월말 차이를 churn과 섞지 않을 수 있습니다.
4단계: Paddle payout은 MoR 흐름에 맞춰 별도 확인합니다
Paddle을 쓰는 팀은 일반 payment processor와 같은 소유 구조라고 단정하면 안 됩니다. Merchant of Record 구조와 payout 보고서 범위를 기준으로 판매 거래, adjustment, fee, payout을 연결해야 합니다.
Paddle payout reconciliation report 공식 문서는 payout을 구성하는 데이터를 조정하는 보고서 흐름을 설명합니다. 특히 문서의 현재 필드와 보고서 생성 방식이 내부 export job과 맞는지 매월 close 전에 확인합니다.
2026년에는 payout reconciliation 보고서 관련 변경도 공개됐습니다. Paddle payout reconciliation report filters 변경 기록과 payout reconciliation report improvements 변경 기록을 함께 확인하면 필터와 결과 필드의 변경이 내부 파이프라인에 영향을 주는지 점검할 수 있습니다.
공식 changelog를 보는 이유는 새 기능을 홍보하기 위해서가 아닙니다. export schema, filter 의미, 보고서 범위가 바뀌면 전월과 같은 쿼리가 다른 결과를 낼 수 있기 때문입니다. 매월 close evidence에 다음을 남깁니다.
- 사용한 report type과 생성 시각
- 요청 filter와 close period
- export schema 또는 parser version
- 원본 파일 checksum과 보관 위치
- 직전 월 대비 열 추가·삭제 여부
- changelog 확인일과 검토자
5단계: ERP와 bank reference를 마지막 연결점으로 둡니다
billing platform 숫자가 맞아도 ERP import와 은행 입금 연결이 빠지면 월말 대사는 끝나지 않습니다. ERP에는 customer·invoice·payment·fee·refund가 어떤 문서 또는 reference로 들어갔는지 추적 가능한 키를 둡니다.
Chargebee QuickBooks reconciliation 공식 문서는 Chargebee와 QuickBooks 사이에서 결제 대사를 검토하는 제품별 출발점입니다. 이를 모든 ERP와 계정에 그대로 적용하지 말고, 현재 integration과 지원 범위, sync 방향, 수동 조정 절차를 확인하는 데 사용합니다.
Recurly export overview는 Recurly에서 제공하는 export 범위를 확인할 수 있는 공식 자료입니다. export를 받았다는 사실만으로 payout과 은행 입금이 자동 연결되는 것은 아닙니다. export row의 안정적인 ID를 내부 ledger의 ERP·bank reference와 이어야 합니다.
은행 매칭에는 금액만 쓰지 않습니다. 다음 값을 함께 사용합니다.
| 매칭 키 | 용도 |
|---|---|
| payout ID | processor batch와 내부 ledger 연결 |
| bank statement reference | 은행 원본 입금 행 식별 |
| arrival/posted date | cutoff 차이 설명 |
| currency와 net amount | 다통화·환전·fee 검증 |
| destination account | 여러 법인·계좌 오매칭 방지 |
| ERP import batch ID | 재업로드·중복 반영 검증 |
은행 입금액과 payout net이 다르면 바로 수동 분개하지 않습니다. 잘못된 계좌, 중개 수수료, 환전, payout 실패·재시도, 도착일 차이, 중복 import 중 어떤 원인인지 먼저 분류하고 증거를 붙입니다. 회계 처리의 최종 판단은 이 운영 문서 밖에서 담당자가 승인합니다.
6단계: exception queue에는 owner·reason·due date를 강제합니다
월말 대사의 품질은 자동 매칭률보다 미매칭 건이 통제되는가로 판단합니다. 예외를 채팅이나 개인 스프레드시트에 흩어놓지 말고 하나의 queue로 관리합니다.
| 필드 | 예시 |
|---|---|
| exception_id | REC-2026-07-0042 |
| close_period | 2026-07 |
| source IDs | invoice, payment, balance transaction, payout ID |
| reason_code | cutoff, fee, FX, refund pending, missing ID, duplicate import |
| amount/currency | 차이 금액과 통화 |
| owner | Finance Ops, RevOps, Engineering 등 한 명 또는 한 팀 |
| due_date | close sign-off 전 해결 목표 시각 |
| status | open, investigating, proposed, approved, resolved, deferred |
| evidence | 원본 export, query, ticket, 승인 링크 |
| resolution | 재수집, mapping 수정, 다음 period carry 등 |
misc, 기타, 나중에 확인만으로는 저장하지 않습니다. reason code가 없다면 UNCLASSIFIED로 명시하고 due date를 더 짧게 둡니다. deferred 예외에는 다음 period로 넘기는 승인자와 영향 금액을 남깁니다.
금액 tolerance는 통화별·사유별로 정합니다. tolerance 아래라고 행을 삭제하지 말고 자동 승인 규칙과 결과를 기록합니다. 작은 차이가 매달 누적되거나 특정 payment method에 집중되면 parser 또는 rounding 규칙의 결함일 수 있습니다.
7단계: 자동화는 증거 수집과 제안까지, close 승인은 사람이 합니다
자동화하기 좋은 작업은 반복 가능하고 되돌릴 수 있는 작업입니다.
- 공식 API·report에서 원본 데이터를 읽어 immutable storage에 보관
- schema와 row count, checksum 검증
- ID 기반 exact match와 통화별 합계 계산
- 승인된 reason code 규칙으로 예외 후보 분류
- 전월 대비 급증, 누락, 중복, stale exception 알림
- 담당자에게 evidence bundle과 수정 제안 전달
사람 승인이 필요한 경계도 명확히 둡니다.
- source ID가 없는 거래를 유사한 금액과 고객명만으로 병합
- ERP 또는 billing 원본을 수정하거나 삭제
- refund·credit·dispute 상태를 임의로 종결
- unexplained difference를 허용하고 close
- tolerance나 cutoff 정책 변경
- 다음 period로 예외 이월
- 최종 close sign-off
자동화가 ERP에 바로 쓰게 하기보다 proposed match → reviewer approval → apply → post-write verification 단계를 둡니다. webhook이나 report 재처리로 같은 쓰기가 반복되지 않도록 idempotency key와 import batch ID를 사용합니다.
관리자 변경, 수동 매칭, tolerance 변경의 actor·before/after·reason은 B2B SaaS 감사 로그·관리자 변경 추적 체크리스트 기준으로 남길 수 있습니다.
8단계: usage-based billing은 cutoff와 late arrival을 따로 봅니다
사용량 기반 청구는 invoice 금액이 맞더라도 source usage가 틀릴 수 있습니다. 월말에는 다음 네 개의 경계를 분리합니다.
- 제품에서 usage event가 실제 발생한 시각
- collector가 event를 수신한 시각
- billing platform에 전송한 시각
- invoice가 확정된 시각
late arrival, duplicate event, correction, timezone 변환, 단위 변경은 각기 다른 reason code를 사용합니다. invoice 확정 후 도착한 사용량을 조용히 다음 달로 넘기거나 원본 event를 덮어쓰지 않습니다. 정책에 따른 처리 결과와 고객 영향 검토를 exception evidence에 남깁니다.
event ID, meter ID, customer ID, subscription item ID와 invoice line ID를 연결하는 상세 기준은 B2B SaaS 사용량 초과·usage-based billing 추적 감사 체크리스트에서 확인할 수 있습니다.
9단계: sign-off evidence는 다음 달에도 재현 가능해야 합니다
close 완료 메시지만 남기면 검증할 수 없습니다. 월별 evidence bundle에는 다음 항목을 포함합니다.
- close policy version, timezone, cutoff와 대상 통화
- 원본 report/API 추출 시각, filter, schema version, checksum
- invoice·payment·refund·credit·balance·payout 통화별 control total
- ERP import batch와 bank statement reference
- matched·unmatched·deferred 건수와 금액
- exception queue snapshot, owner, due date, resolution
- tolerance 적용 결과와 승인 로그
- 자동화 job version, 실행 결과, 재처리 여부
- reviewer와 approver의 sign-off timestamp
- close 이후 발견된 수정 사항과 다음 달 예방 action
sign-off 역할은 최소한 prepare와 review를 분리합니다. 같은 사람이 데이터를 추출하고 mapping을 수정하고 최종 승인까지 모두 수행해야 한다면 고액·비정상·수동 조정 건만이라도 두 번째 검토자를 지정합니다.
close 뒤에는 원본을 수정하지 않습니다. 수정이 필요하면 새 version과 reason을 남기고 이전 결과와 차이를 비교합니다. evidence URL이 퇴사자의 개인 Drive나 만료되는 dashboard session에만 의존하지 않도록 팀 보관 위치와 접근 권한도 확인합니다.
월말 5일 운영 예시
| 시점 | 실행 항목 | 종료 조건 |
|---|---|---|
| D-2 | schema·integration·changelog·담당자 확인 | 추출 job과 owner 준비 완료 |
| D0 | cutoff snapshot, 원본 export/API 수집 | checksum·control total 저장 |
| D+1 | ID exact match, payout·bank·ERP 연결 | 자동 매칭 결과와 예외 생성 |
| D+2 | exception 조사와 수정 제안 | 고액·미분류 예외 reviewer 배정 |
| D+3 | 수동 승인·재검증·sign-off | 차이와 deferred 항목 승인 완료 |
| D+5 이후 | post-close 변화 감시 | late refund·payout 조정이 다음 queue에 연결 |
조직의 실제 close 일정에 맞게 날짜는 바꿀 수 있지만, 원본 snapshot 전에 수동 수정부터 시작하지 않습니다. close가 끝난 뒤 도착한 refund, dispute, payout adjustment는 기존 evidence를 덮어쓰지 말고 post-close event로 기록합니다.
공개 전 사용할 15개 체크리스트
- close timezone과 cutoff 시각을 문서화했습니다.
- invoice·payment·balance·payout·bank의 기준 timestamp를 분리했습니다.
- 원본 통화·fee·환전·payout 통화를 별도 필드로 보존했습니다.
- source ID에서 balance transaction, payout, ERP, bank reference까지 연결됩니다.
- invoice·payment attempt·refund·credit·dispute를 다른 사건으로 저장합니다.
- payout batch 합계와 구성 transaction을 모두 검증합니다.
- 원본 export/API 결과의 filter·schema·checksum을 남겼습니다.
- integration과 공식 changelog의 변경 여부를 확인했습니다.
- 예외마다 owner·reason·due date·amount·evidence가 있습니다.
- tolerance 아래 차이도 삭제하지 않고 규칙과 결과를 기록합니다.
- 자동화는 match 제안과 증거 수집까지 수행하고 중요한 쓰기는 승인 후 실행합니다.
- usage event의 발생·수신·전송·invoice cutoff를 분리합니다.
- prepare·review·approve 역할과 sign-off timestamp가 남습니다.
- close 이후 수정은 새 version과 reason으로 재현할 수 있습니다.
- 이 운영 대사가 회계·세무·법률·매출 인식 판단을 대신하지 않음을 확인했습니다.
마무리
B2B SaaS 구독 청구 월말 대사는 invoice 합계를 은행 입금액과 한 번 비교하는 작업이 아닙니다. invoice와 payment를 분리하고, balance transaction으로 payout을 구성하며, payout ID를 ERP와 bank reference까지 이어야 차이를 설명할 수 있습니다.
cutoff·timezone·currency를 먼저 고정하고, 예외 큐에는 owner·reason·due date를 강제하십시오. 자동화는 원본 수집, exact match, 이상 탐지와 제안에 사용하고, 불명확한 병합과 최종 close는 사람이 증거를 보고 승인해야 합니다. 이렇게 만든 sign-off bundle은 이번 달 숫자뿐 아니라 다음 달에 같은 문제를 더 빨리 찾는 운영 자산이 됩니다.
함께 보면 좋은 글
- B2B SaaS 구독 청구 플랫폼 이전 체크리스트 2026
- B2B SaaS 구독 관리 플랫폼 비교 2026
- B2B SaaS 결제 실패·dunning 자동화 체크리스트
- B2B SaaS 환불·크레딧 노트 추적 감사 체크리스트
- B2B SaaS 사용량 초과·usage-based billing 추적 감사 체크리스트
- B2B SaaS 감사 로그·관리자 변경 추적 체크리스트
공식 출처
- Stripe – Balance report
- Stripe – Payout reconciliation
- Stripe API – Balance Transactions
- Paddle – Payout reconciliation report
- Paddle Changelog 2026 – Payout reconciliation report filters
- Paddle Changelog 2026 – Payout reconciliation report improvements
- Chargebee – Invoice Transactions report
- Chargebee – Refunds
- Chargebee – QuickBooks reconciliation
- Recurly – Export overview
최종 확인일: 2026-07-16. report 필드, API, export schema, integration, payout 일정은 변경될 수 있으므로 실제 close 전에 계정에 적용되는 최신 공식 문서와 설정을 다시 확인하세요.
About The Author
