정산·월마감
Paddle 지급 보고서와 Lemon Squeezy 주문 CSV·reverse invoice를 각각 월마감 원장에 연결한다.
이 장은 두 서비스를 같은 주제에서 비교한 뒤 두 공급자의 상세 설명을 모두 담습니다. 기능 노출·계약 요율·국가별 결제수단은 계정과 시점에 따라 달라질 수 있으므로 실제 스토어와 각 절의 공식 출처를 확인하세요.
주제별 비교
| 비교 항목 | Paddle | Lemon Squeezy |
|---|---|---|
| 거래 원장 | transaction export와 payout reconciliation report를 쓴다. | Orders CSV와 Order API를 쓴다. |
| 지급 증빙 | remittance advice와 balance movement를 연결한다. | payout dashboard·reverse invoice·은행 입금을 연결한다. |
| 통화 | 거래·balance·payout 통화를 분리한다. | 표시 통화·USD 처리·은행 지급 통화를 분리한다. |
Paddle 상세
핵심 요약
- 고객 결제 통화·Paddle balance currency·payout currency·한국 장부 통화(KRW)가 다를 수 있어, KRW 결제가 바로 KRW 정산으로 들어온다고 가정하면 안 된다.
- Paddle은 일반 payout에 별도 fee를 붙이지 않는다고 설명하지만, 은행·SWIFT·중개은행 wire fee와 balance/payout currency가 다를 때 붙는 최대 1.5% conversion margin이 정산액을 깎는다.
- 월마감은 export → transaction_id·subscription_id 매칭 →
remittance_reference단위 은행 대조 → exception queue → 세무 패키지 보관 순으로 진행한다. - 2026 payout reconciliation report는 balance movement를 원장으로 쓰며
balance_movement_in_balance_currency합계를 remittance advice와 맞춘다. - gross/net revenue, refund·chargeback rate, FX impact, payout delay 등 운영 지표로 수익성과 현금흐름을 점검한다.
- 흔한 실수는 고객 결제 금액과 정산액을 같은 매출로 혼용하거나 은행 수수료와 Paddle 수수료를 합산하는 것이다.
글로벌 결제에서 월마감이 어려운 이유는 결제 통화, Paddle balance currency, payout currency, 한국 장부 통화가 다를 수 있기 때문입니다. 개발팀은 결제 성공만 보면 되지만, 재무팀은 거래·환불·수수료·환율을 같은 기준으로 맞춰야 합니다.
통화 구조
| 층 | 예시 | 설명 |
|---|---|---|
| 고객 결제 통화 | KRW, USD, EUR, JPY | Checkout에서 고객이 보는 통화 |
| Paddle balance currency | USD, EUR, GBP, AUD, CAD | Paddle 계정 잔액 기준 통화 |
| payout/transfer currency | AUD, GBP, CAD, CNY, CZK, DKK, EUR, HUF, PLN, ZAR, SEK, CHF, USD | 실제 계좌·국가 지원 여부 별도 확인 |
| 장부 통화 | KRW | 한국 회계 장부 기준 |
Paddle은 KRW 결제를 받을 수 있지만 balance currency에는 별도 제한이 있습니다. KRW 결제 매출이 바로 KRW 정산으로 들어온다고 가정하면 안 됩니다.
수수료와 payout
Paddle 공식 가격은 Checkout transaction 기준 pay-as-you-go 수수료를 제시합니다. payout 단계에서는 Paddle fee 말고도 은행, SWIFT, 중개은행, 환전 margin이 끼어듭니다. Paddle 도움말을 보면 Paddle은 일반 payout에 별도 payout fee를 붙이지 않는다고 하지만, 은행/결제사업자 비용, 국제 wire fee, balance currency와 payout currency가 다를 때의 최대 1.5% conversion margin은 따로 들어갑니다.
| 항목 | 관리 방법 |
|---|---|
| Paddle transaction fee | transaction export에서 확인 |
| 환불 | refund/adjustment와 원 transaction 연결 |
| chargeback | dispute 상태와 수수료 별도 표시 |
| wire fee | payout reconciliation report와 bank statement 대조 |
| FX | Paddle 환산, 은행 환산, 장부 환율 분리 |
월마감 대사 테이블
Paddle의 현재 payout reconciliation report는 과거 payout_id를 remittance_reference로 변경했습니다.
payout_... 형식의 payout object ID를 webhook에서 보관할 수는 있지만 report의 remittance reference와
같은 필드로 취급하지 않습니다. report는 balance movement 행으로 구성되며 다음처럼 원본 필드와 내부
정규화 필드를 매핑합니다.
| Paddle 원본 | 내부 정규화 | 설명 |
|---|---|---|
remittance_reference | remittance_reference | 은행 송금·remittance advice와 연결하는 지급 참조값 |
balance_movement_date | movement_date | 잔액 변동일. 거래 발생일과 다를 수 있음 |
balance_movement_type | movement_type | transaction, adjustment, rebate, swift fee 등 구분 |
total_gross_in_transaction_currency | gross_amount | 고객 결제 통화의 총액 |
balance_movement_in_balance_currency | balance_movement_amount | balance currency 기준 실제 변동액 |
customer_email | customer_email | CS·내부 주문 매칭 보조 필드 |
| discount metadata | discount_id/code | 할인 원인 분석 |
reason | movement_reason | rebate·fee·adjustment 사유 설명 |
gross_amount, tax_amount, paddle_fee, net_amount 같은 내부 컬럼을 유지해도 되지만 Paddle 원본 컬럼과
계산식, 통화 기준을 데이터 사전에 고정합니다. 서로 다른 transaction currency 금액을 바로 더하지 않습니다.
월마감 절차
- Paddle에서 transaction, adjustment/refund, payout reconciliation report와 remittance advice를 export합니다.
- 내부 주문/구독 DB와
transaction_id,subscription_id로 매칭합니다. - payout reconciliation report는
remittance_reference로 조회하고balance_movement_in_balance_currency합계를 remittance advice와 맞춥니다. 날짜 필터만으로 지급 묶음을 추정하지 않습니다. - remittance advice의 송금액과 은행 입금액을 대조하고 SWIFT·중개은행 비용을 별도 행으로 설명합니다.
- 미매칭 거래, 환불 지연, chargeback, rebate, 수수료 차이를 exception queue에 올립니다.
- reverse invoice, remittance advice, CSV 원본, bank statement를 세무 패키지에 보관합니다.
구체적인 CSV 컬럼, 전표 예시, SQL 체크는 정산 CSV·전표 템플릿을 기준으로 맞춥니다.
운영 지표
| 지표 | 목적 |
|---|---|
| gross revenue by country | 국가별 매출 추이 |
| net revenue after fees | 실제 수익성 |
| refund rate | 환불 정책과 제품 품질 점검 |
| chargeback rate | fraud/CS 리스크 |
| FX impact | 가격·정산 통화 전략 점검 |
| payout delay | 현금흐름 관리 |
2026년 Metrics API는 revenue, MRR, active subscribers, refunds, chargebacks 등 시계열 지표를 제공하지만 회계 원장을 대체하지 않습니다. 경영 지표는 Metrics API, 월마감은 transaction·adjustment·payout reconciliation 원본을 사용합니다.
흔한 실수
- 고객 결제 금액과 Paddle 정산액을 같은 매출 숫자로 혼용합니다.
- 환불 월과 원 결제 월이 달라지는 것을 장부에서 설명하지 못합니다.
- 한국 고객 KRW 결제분을 별도 태그하지 않아 국내 이슈 분석이 어렵습니다.
- Paddle 수수료를 단일 비용으로만 보고 payment method/country별 차이를 놓칩니다.
- bank statement 수수료와 Paddle transaction report 수수료를 같은 항목으로 합산합니다.
참고 자료
- Paddle Help - Is there a fee taken for payouts?
- Paddle Developer - Supported currencies
- Paddle - Pricing
- Paddle Developer - Payout reconciliation report
- Paddle Developer - 2026 payout report improvements
- Paddle Developer - Payout report filters
- Paddle Help - Statements, reverse invoices and remittance advice
- Paddle Developer - Metrics API
Lemon Squeezy 상세
핵심 요약
- KRW는 표시 통화이고 거래 처리는 USD다. 은행 payout에서 원화 전환이 다시 일어날 수 있다.
- 주문 CSV는 주문·세금·USD 금액을 주지만 환불액·플랫폼 수수료·payout 배부를 완성해 주는 보고서는 아니다.
- 공식 지급 안내는 13일 보류, 1일·15일 지급 생성, 14일·28일 지급, 최소 USD 50을 설명한다.
- reverse invoice, payout 대시보드, 은행 입금 내역을 함께 보관해야 한다.
세 층의 통화
| 층 | 예 | 원장에 남길 값 |
|---|---|---|
| 고객 표시 | KRW 스토어 가격·checkout | 표시 통화, 표시액, 환율 |
| 거래 처리 | USD | 주문 subtotal·tax·total, 할인, 환불 |
| 지급·은행 | USD 기반 payout을 은행 선택 통화로 전환 | payout USD, 수수료, 입금 통화·실입금액 |
공식 통화 문서는 거래를 USD로 처리하고 은행 payout의 선택 통화 전환을 설명합니다. 고객이 본 원화 금액을 한국 은행 입금액과 직접 빼면 환율 시점·수수료가 섞입니다.
수수료와 지급 시점
가격표의 일반 플랫폼 요율은 5% + USD 0.50이며 Fees에 따르면 세금 포함 주문 총액을 기준으로 계산하고 국제·PayPal·구독·마케팅 기능별 가산이 있을 수 있습니다. payout 수수료는 수단·지역·통화에 따라 다릅니다. Getting paid는 순매출 13일 보류, 매월 1일·15일 payout 생성, 14일·28일 지급, 최소 USD 50을 안내합니다. 은행 계좌 반영에는 지급 후 1~5일이 걸릴 수 있습니다. USD 50 미만은 pending으로 다음 지급 주기에 이월됩니다.
| 날짜 예시 | 의미 |
|---|---|
| 4일 판매 | 13일 보류 대상 |
| 15일 | 해당 판매를 포함한 payout 생성 예시 |
| 28일 | payout 지급 예시 |
| 이후 | 은행 처리·환전 후 입금 |
환불·분쟁·보류·최소액 미달이면 판매월과 입금월이 달라집니다. 월마감은 발생주의 거래 원장과 현금 입금 원장을 분리합니다.
대사 절차
- Orders 화면에서 CSV를 내보내고 파일 생성 범위·시각·해시를 보관합니다.
identifier또는order_number로 내부 checkout intent·webhook 주문을 매칭합니다.- CSV의 USD cent 금액으로 주문·세금을 집계합니다. 환불액은 CSV 문서의 열 목록에 없으므로 Order API의
refunded_amount_usd·상태와 dashboard에서 별도로 확인합니다. - payout별 reverse invoice에서 지급액을 확인하고, 수수료·보류·차감의 세부 근거는 계정 dashboard·별도 증빙에서 확보합니다. reverse invoice 자체가 주문별 비용 배부를 제공한다고 가정하지 않습니다.
- 은행 입금의 날짜·통화·환율·수취 수수료를 payout과 연결합니다.
- 차이는 환불, chargeback, 지급 보류, 기준일·시간대, 환전으로 분류합니다.
주문 CSV 자체에 일대일 payout ID와 모든 비용 배부가 있다고 가정하지 않습니다. 계정에서 제공되는 자료의 실제 열을 확인하고 필요한 연결표를 내부에서 만듭니다.
월마감 대사식
기초 미지급/보류 잔액
+ 당기 판매자 순액 적립(실제 payout 원장 기준)
- 환불·분쟁·기타 차감(원장에 반영된 금액만)
- 지급 원장 차감액(수수료 포함 여부 확인)
= 기말 미지급/보류 잔액 + 설명 가능한 기간 차이이 식은 내부 지급 대사의 출발점이며 CSV만으로 계산할 수 있는 공식 Lemon Squeezy 산식이 아닙니다. 환불 때 플랫폼 수수료가 반환되는 것으로 가정하지 말고 환불·분쟁 정책과 실제 원장 항목을 확인합니다. 같은 수수료나 환불을 적립액과 차감액에 두 번 넣지 않습니다. 정확한 수익 인식과 계정은 한국 세무·회계의 전문가 검토를 따릅니다.