B2B SaaS payout 예외 triage 체크리스트 2026, 실패·도착 지연·bank reference 누락을 분리하는 기준

B2B SaaS에서 결제가 성공했는데도 정산금이 예상한 날에 보이지 않으면, 곧바로 “정산 누락”이라고 결론 내리기 쉽습니다. 하지만 payout에는 생성, 처리, 실패, 취소, 은행 도착처럼 서로 다른 상태가 있고, 공급사 화면의 payout ID와 은행 명세서의 reference가 늦게 연결될 수도 있습니다. payout이 만들어졌다는 사실과 은행에 입금됐다는 사실은 같은 상태가 아닙니다.

이 글은 월말 전체 대사나 ERP 분개를 설명하는 글이 아닙니다. B2B SaaS 구독 청구 월말 대사 체크리스트가 invoice·payment·refund·fee·payout을 큰 흐름으로 맞추는 범위라면, 여기서는 그 과정에서 발견된 payout 예외를 어떤 큐로 보내고 어떤 증거가 모이면 닫을지에만 집중합니다. 결제 장애 복구 전체 절차는 B2B SaaS 결제 공급사 장애 대응 체크리스트와 구분합니다.

Stripe와 Paddle은 payout 상태와 관련 보고서·API를 제공하지만, Chargebee나 Recurly 같은 구독·청구 플랫폼이 항상 은행으로 돈을 보내는 payout 주체인 것은 아닙니다. 따라서 “모든 공급사의 payout 상태 필드가 같다”고 일반화하지 말고, 실제 계정의 processor·Merchant of Record·은행 연결 구조를 먼저 확인해야 합니다. 결제 오케스트레이션 플랫폼 비교처럼 라우팅·vault·reconciliation 제품을 고르는 문제도 이 글의 직접 범위가 아닙니다.

이 글은 회계·세무 자문, 자금 입금 보장, 특정 공급사의 SLA 보증을 제공하지 않습니다. 실제 지급 일정, reserve·hold, 통화 변환, 은행 영업일과 계정 권한은 계약과 공급사 공식 문서를 기준으로 확인하십시오.

먼저 payout 예외를 네 가지로 나눕니다

“입금이 안 됐다”는 문의 하나를 한 상태로 저장하면 조사 담당자가 매번 같은 API와 은행 명세서를 다시 확인하게 됩니다. 최소한 다음 네 가지를 별도 상태로 나누는 것이 출발점입니다.

failed와 paid_but_not_arrived를 같은 “재시도 대상”으로 처리하면 중복 지급이나 중복 문의를 만들 수 있습니다. 반대로 bank_reference_missing을 실패로 보면 실제 입금이 된 거래를 다시 지급 대상으로 오인할 수 있습니다. 상태명은 공급사의 원문 상태를 그대로 복사하기보다, 원문 상태와 내부 triage 상태를 각각 보존하십시오.

1. 원문 payout과 내부 예외 행을 연결합니다

예외 triage의 첫 단계는 금액 합계가 아니라 한 payout을 다시 찾을 수 있는 식별자입니다. 다음 필드를 내부 예외 행에 보존하는 편이 좋습니다.

• 공급사 payout_id와 원문 상태
• 연결된 balance·transaction·fee·adjustment의 원문 ID
• payout 통화와 금액, 수수료가 별도로 표시되는지 여부
• 생성 시각, 상태 변경 시각, 예상 도착일, 실제 도착 확인 시각
• processor 또는 Merchant of Record 계정 식별자
• destination 계정의 안전한 축약값과 은행 statement 기간
• 내부 exception_id, 최초 감지 시각, 마지막 조회 시각
• 담당 owner, 다음 확인 시각, 상태 변경 사유

고객 이름이나 은행 계좌번호를 예외 큐의 기본 키로 쓰지 마십시오. 이름은 변경될 수 있고, 같은 금액의 payout이 여러 개일 수 있습니다. 계좌·고객 정보는 필요한 최소한만 제한된 영역에 보관하고, 일반 운영 화면에는 축약 식별자와 payout ID만 노출하는 방식이 안전합니다.

2. failed는 재시도보다 실패 원인을 먼저 분류합니다

실패한 payout을 보았을 때 자동 재시도를 먼저 실행하면 안 됩니다. 공급사가 실패한 payout을 자동 재시도하는지, 수취 계좌 수정 후 새 payout을 만들어야 하는지, support case가 필요한지는 제품과 계정 설정에 따라 다릅니다. Stripe의 Payouts API 공식 문서는 payout 객체와 상태·필드 확인의 출발점이고, 실제 재시도·취소 가능 여부는 현재 계정과 공식 안내를 다시 확인해야 합니다.

다음처럼 실패 원인과 후속 조치를 분리해 기록합니다.

실패 사유를 단순히 retry=true로 저장하지 말고, 재시도 가능 여부, 마지막 시도 시각, 새 payout 생성 여부, 중복 방지 키를 별도로 남깁니다. 자동화가 있더라도 “새 payout을 만들었다”와 “기존 payout이 성공했다”를 같은 결과로 닫지 않아야 합니다.

3. in_transit와 paid_but_not_arrived를 시간으로 구분합니다

처리 중인 payout과 지급 완료 후 은행에서 찾지 못한 payout은 조사 시작점이 다릅니다. in_transit에서는 공급사 상태와 예상 도착일을 먼저 보고, paid_but_not_arrived에서는 지급 완료 시각 이후의 은행 명세서·value date·수취 계좌·통화 범위를 확인합니다.

여기서 “지연”을 단순한 달력 날짜로 계산하지 않는 것이 중요합니다. 공급사와 은행의 영업일, timezone, 공휴일, 통화, 계좌 국가가 다를 수 있기 때문입니다. 내부에는 다음 시각을 분리해 기록하십시오.

created_at → status_changed_at → expected_arrival_at → bank_value_date → observed_at

expected_arrival_at을 지나지 않은 in_transit를 실패로 승격하지 말고, 지나간 뒤에도 payout 상태가 변하지 않으면 arrival_delay 예외를 생성합니다. 반대로 paid 상태라는 이유만으로 은행 입금을 확정하지 말고, 은행 명세서의 reference·금액·통화·value date를 연결할 때까지 paid_but_not_arrived를 유지합니다.

Stripe의 Payout reconciliation 공식 문서는 payout과 구성 balance transaction을 연결하는 보고 흐름을 확인하는 데 유용합니다. Stripe Balance report 공식 문서도 balance activity와 payout 관련 보고서의 범위를 확인하는 출발점입니다. Paddle을 Merchant of Record로 사용하는 경우에는 Paddle payout reconciliation report의 보고서 생성·필드·범위를 현재 문서와 계정 설정에 맞춰 별도로 확인하십시오.

4. bank reference 누락은 매칭 규칙의 문제로 분리합니다

입금은 확인됐지만 bank reference가 payout ID와 다르게 표시되거나, 여러 payout이 하나의 입금으로 묶이면 자동 매칭이 실패할 수 있습니다. 이때 금액과 날짜가 비슷하다는 이유만으로 억지로 연결하지 않습니다. 다음 순서로 후보를 좁힙니다.

1. 동일한 destination 계정과 통화만 남깁니다.
2. 은행 value date와 공급사의 payout 처리·도착 시각 범위를 비교합니다.
3. 금액은 gross, fee, net 중 어느 값인지 확인합니다.
4. 한 입금에 여러 payout이 묶이는 batch 가능성을 확인합니다.
5. 은행 reference, payout ID, batch ID, statement row를 함께 보존합니다.
6. 자동 매칭이 안 되면 manual_match_required로 보내고 승인자·근거·확인 시각을 기록합니다.

amount_match만으로 close하지 마십시오. 같은 금액의 payout, 환전으로 인한 net 차이, 수수료 공제, 부분 지급, 이전 기간의 late arrival이 모두 있을 수 있습니다. 매칭 결과에는 exact, batch, manual, unresolved 같은 방식과 confidence를 함께 보존하면 이후 규칙을 개선하기 쉽습니다.

5. 예외 큐의 owner와 SLA를 정합니다

예외 큐가 있어도 owner와 다음 확인 시각이 없으면 단순한 목록에 머뭅니다. 금액 크기만으로 우선순위를 정하지 말고 상태·도착 지연·고객 영향·재시도 위험을 함께 사용합니다.

SLA는 “몇 시간 안에 입금 보장”으로 쓰지 말고, 몇 시간 안에 어떤 증거를 다시 확인할지로 정의하십시오. 공급사나 은행이 제공하지 않는 지급 확정 시간을 임의로 약속하면 고객 지원과 재무 운영 모두에 잘못된 기대를 만듭니다.

공개 전·후 점검표

• [ ] failed, in_transit, paid_but_not_arrived, bank_reference_missing을 별도 상태로 구분했습니다.
• [ ] payout 원문 ID와 내부 exception_id를 연결했습니다.
• [ ] 생성·상태 변경·예상 도착·은행 value date·관찰 시각을 분리했습니다.
• [ ] 실패 payout을 자동 재시도하기 전에 중복 생성 가능성을 확인합니다.
• [ ] payout 주체와 upstream billing platform을 구분했습니다.
• [ ] 금액 일치만으로 은행 입금을 확정하지 않습니다.
• [ ] owner, next check, SLA, close evidence를 예외 행에 남깁니다.
• [ ] 고객·은행 민감정보는 공개 문서와 일반 운영 화면에서 최소화했습니다.
• [ ] 실제 상태·필드·지급 일정은 현재 공급사 공식 문서와 계약을 재확인합니다.

마무리

payout 예외 triage의 목적은 “입금이 늦다”는 문장을 더 빨리 닫는 것이 아닙니다. 공급사 payout 상태, 처리 시각, 은행 명세서, 예외 owner와 다음 확인 근거를 하나의 사건으로 연결하되, 아직 확인되지 않은 상태를 성공이나 실패로 과장하지 않는 것입니다.

월말 전체 대사에서는 payout이 여러 거래를 묶는 최종 단계로 보일 수 있지만, 예외 큐에서는 실패·이동 중·지급 완료 후 미도착·reference 누락을 서로 다른 조사 문제로 다뤄야 합니다. 이 경계를 지키면 중복 지급을 막고, 실제 입금은 됐지만 자동 연결만 실패한 건을 불필요하게 재처리하는 위험도 줄일 수 있습니다.

공식 출처

• Stripe Payouts API
• Stripe Payout reconciliation
• Stripe Balance report
• Paddle Payout reconciliation report
• Paddle Transactions API
• Chargebee Standard Invoice Transactions
• Chargebee QuickBooks reconciliation
• Recurly Export overview

최종 확인일: 2026-08-07. 공급사 API, payout 상태, 지급 일정, 보고서 필드는 변경될 수 있으므로 실제 운영 전에 해당 계정에 적용되는 최신 공식 문서와 설정을 다시 확인하세요.