스토어 대시보드에는 지난주 BNPL(선구매 후결제)로 $9,300을 판매했다고 나옵니다. 은행 계좌에는 $8,412가 입금되었습니다. 사라진 $888은 어디로 간 걸까요? 그리고 매출이 늘었는데 왜 다음 주 입금도 부족해 보일까요?
체크아웃 시 클라나, 어펌, 애프터페이를 사용한다면, 이 차이는 스토어의 버그가 아닙니다. 이는 BNPL 정산을 신용카드 입금과 같은 방식으로 기록할 때 발생하는 예측 가능한 결과입니다. BNPL은 다른 주기로 정산되고, 수수료를 원천에서 차감하며, 환불을 별도 크레딧으로 보내지 않고 향후 지급액에서 공제합니다. 은행 입금액을 수익으로 기록하면 매출이 과소계상되고, 처리 수수료가 숨겨지며, 환불이 이중으로 계산됩니다 — 한 번에 모두 발생합니다.
이 가이드는 BNPL을 깔끔하게 유지하는 총액 정산 방식(gross-settlement method)을 설명합니다: 제공업체별 클리어링 계정 하나, 판매 시점에 총액 기준 수익 인식, 수수료는 별도 비용으로 구분, 그리고 월말에 각 제공업체의 1099-K와 장부를 대사하는 루틴까지.
BNPL이 카드 처리업체처럼 조정되지 않는 이유
카드 처리업체의 경우 리듬은 간단합니다: 고객이 결제하고, 처리업체가 일일 배치를 하며, 하루나 이틀 후 은행에 입금됩니다. 총매출과 수수료를 기록하고, 은행 잔액을 조정하면 끝입니다.
BNPL은 이 리듬을 세 가지 방식으로 깨뜨립니다.
정산이 지연되고 — 각 제공업체가 자체 주기를 운영합니다
클라나는 일반적으로 주 1회 또는 격주로 정산합니다. 어펌은 보통 영업일 기준 며칠 내에 정산하지만 환불과 분쟁에 대비해 롤링 준비금(rolling reserve)을 보유합니다. 애프터페이는 표준 플랜에서 종종 다음 영업일에 정산하며, 환불과 조정액은 자금이 이동하기 전에 차감됩니다. 화요일에 입금되는 현금은 며칠 또는 몇 주 전의 판매에 대한 대가이므로, 입금액은 특정 하루의 매출 보고서와 일치하지 않습니다.
수수료가 원천에서 차감됩니다
BNPL 수수료는 카드에 비해 높으며, 별도 청구 항목으로 볼 수 없습니다. 일반적인 가맹점 수수료율은 어펌 약 3%, 애프터페이 4–6% + 건당 고정 수수료, 클라나는 플랜과 거래량에 따라 약 3.3–6% + 고정 수수료입니다. 수수료는 단순히 입금액에서 빠져 있습니다. 입금액을 매출로 기록하면 모든 주문에서 수수료만큼 수익이 조용히 과소계상됩니다.
환불이 별도 크레딧이 아닌 향후 입금액을 줄입니다
고객이 $200 클라나 주문을 반품하면, 별도 $200 차변을 기록할 수 없습니다. 다음 정산액이 단순히 $200 더 작아질 뿐입니다 — 경우에 따라 원래 수수료를 차감한 후일 수도, 아닐 수도 있습니다. 은행 피드에는 환불이 판매 부진 주와 동일하게 보입니다. 이를 예상하는 시스템이 없으면, 환불은 누군가 클리어링 잔액의 변동을 발견할 때까지 수주 동안 기록되지 않은 채 방치됩니다.
총액 인식 원칙: 판매했으니 총액으로 기록하라
ASC 606에 따르면, 자사 상품을 판매하는 가맹점은 거래의 주체(principal)입니다 — BNPL 제공업체는 판매자가 아닌 결제 및 금융 중개자입니다. 이는 장부에 한 가지 분명한 결과를 가져옵니다: 수익은 주문 총액이며, BNPL 수수료는 수익 차감이 아닌 비용입니다.
이는 카드 처리 방식과 동일합니다. $100 Stripe 판매를 $97.10 수익으로 기록하지 않을 것입니다. $100 수익과 $2.90 처리 수수료를 기록합니다. BNPL도 수수료가 사전 차감되어 도착하더라도 동일한 처리가 필요합니다. 이것이 중요한 세 가지 이유:
- 수익 라인이 비교 가능하게 유지됩니다. 모든 채널을 총액으로 기록하면 채널별 총매출, 전환 가치, 평균 주문 금액이 정확하게 표시됩니다.
- 수수료가 계속 보입니다. 4–6%의 BNPL 수수료는 가장 큰 변동 비용 중 하나입니다. 순입금액에 묻혀 있으면 모든 비용 검토에서 빠져나갑니다. 구분하면 협상하고, 제공업체 간 벤치마킹하고, BNPL이 제공하는 전환율 상승 효과와 비교할 수 있습니다.
- 세금 신고가 대사됩니다. 각 제공업체의 Form 1099-K는 수수료나 환불 조정 없이 총 결제 금액을 보고합니다. 순액 기준 장부는 이러한 양식과 절대 일치하지 않으며, 이는 IRS 통지서를 받는 정확한 불일치입니다.
클리어링 계정 방식, 단계별로
해결책은 BNPL 제공업체별 클리어링 계정 하나를 두는 것입니다 — 아직 정산되지 않았지만 여러분의 돈인 금액을 위한 미니 은행 계좌처럼 작동하는 유동자산 계정입니다. 매출은 총액으로 들어가고, 수수료와 환불은 빠져나가며, 정산 입금액은 잔액을 운영 은행으로 이체합니다. 전체 루틴은 다음과 같습니다.
1. 제공업체별로 클리어링 계정을 하나씩 설정합니다
계정과목표에 다음을 만듭니다:
- 클라나 클리어링 (유동자산)
- 어펌 클리어링 (유동자산)
- 애프터페이 클리어링 (유동자산)
- BNPL 처리 수수료 (비용 — 많은 판매자가 다른 가맹점 수수료와 함께 매출원가에 넣고, 일부는 판매비로 처리합니다. 하나를 선택하고 일관성을 유지하세요)
QuickBooks Online에서는 각 클리어링 계정을 은행 유형 또는 기타 유동자산 계정으로 만들어 조정 화면에 표시되게 합니다. Xero에서는 동일한 이유로 각각을 은행 계좌로 표시합니다. 일반 텍스트 회계에서는 Assets:Receivable:Klarna-Clearing과 같은 자산 계정일 뿐입니다.
여러 제공업체를 하나의 클리어링 계정으로 합치지 마세요. 각 제공업체는 자체 주기와 수수료 체계로 정산하며, 혼합 계정은 어떤 단일 제공업체 보고서와도 조정할 수 없습니다.
2. 주문일에 모든 판매를 총액으로 기록합니다
BNPL 제공업체를 통해 주문이 완료되면, 전체 주문 금액을 즉시 기록합니다 — 정산을 기다리지 마세요:
- 제공업체 클리어링 계정 차변 (주문 총액)
- 판매 수익 대변 (주문 총액)
경제적 논리: BNPL 제공업체가 주문을 승인하고 캡처하는 순간, 고객은 제공업체에게 빚을 지고 제공업체는 여러분에게 빚을 집니다. 그 채권은 현금이 나중에 도착하더라도 첫날부터 실재합니다. 주문일에 기록하면 일일 매출 보고서와 수익 원장이 일치하며, 이는 다른 모든 조정의 기초가 됩니다.
3. 정산 보고서에서 수수료를 비용으로 기록합니다
정산 보고서가 도착하면 총 정산 매출, 차감된 수수료, 공제된 환불, 순 지급액이 항목별로 표시됩니다. 수수료 항목을 명시적으로 기록합니다:
- BNPL 처리 수수료 차변 (수수료 금액)
- 제공업체 클리어링 계정 대변 (수수료 금액)
이것은 은행 입금액에서 역산하는 것이 아니라 제공업체의 정산 보고서에서 해야 합니다. 보고서가 증빙 문서이고, 입금액은 현금 확인일 뿐입니다.
4. 정산 입금액을 이체로 기록합니다
은행 입금액은 수익이 아닙니다 — 수익은 이미 2단계에서 기록되었습니다. 이는 이체입니다:
- 운영 은행 계좌 차변 (순 입금액)
- 제공업체 클리어링 계정 대변 (순 입금액)
기장 후, 클리어링 계정 잔액은 제공업체가 여전히 여러분에게 빚진 금액과 정확히 일치해야 합니다: 승인되었지만 정산되지 않은 매출에서 롤링 준비금을 뺀 금액. 그 잔액이 조정 확인 지표입니다. 제공업체의 미정산 보고서와 차이가 나면 무언가 — 환불, 수수료 변경, 분쟁 — 가 누락된 것입니다.
5. 환불을 원래 판매에 대체하고 수수료를 확인합니다
BNPL 주문을 환불할 때, 들어온 방식 그대로 역분개합니다:
- 환불/반품 차변 (대체수익 계정 또는 환불 부채) (환불 금액)
- 제공업체 클리어링 계정 대변 (환불 금액)
그런 다음 플랜이 원래 수수료를 어떻게 처리하는지 확인합니다. 일부 플랜은 환불된 주문의 수수료를 반환하고, 다른 플랜은 보유합니다. 수수료가 반환되면 정산 보고서에 나타날 때 수수료 크레딧을 기록합니다. 보유되면 그 수수료는 비용 라인에 남습니다 — 반품된 판매의 실제 비용입니다. 어느 쪽이든, 추측하지 말고 정산 보고서를 읽고 결정하세요.
실제 예시
스토어가 한 주 동안 애프터페이로 $10,000을 5% 수수료 + 주문당 $0.30으로 50건 판매했다고 가정합니다 ($15 고정 수수료, $500 비율 수수료, 총 $515). $200 주문 하나가 환불되었고, 애프터페이는 환불 수수료를 보유합니다. 클리어링 계정의 한 주입니다:
| 단계 | 클리어링 계정 변동 | 잔액 |
|---|---|---|
| 50건 판매 총액 기록 | +$10,000 | $10,000 |
| 정산 보고서 수수료 | −$515 | $9,485 |
| 환불 기록 | −$200 | $9,285 |
| 은행 정산 입금 | −$9,285 | $0 |
수익은 $10,000입니다. BNPL 수수료는 $515입니다. 환불은 $200입니다. 은행은 $9,285를 받았고, 매출과 현금 간 $715 차액의 모든 달러가 명명된 항목으로 설명되어 순 입금액에 사라지지 않습니다. 같은 주가 두 정산 주기에 걸쳐 있으면, 유일한 차이는 주말에 0이 아닌 클리어링 잔액이며 — 이는 애프터페이의 미정산 매출 보고서와 정확히 일치해야 합니다.
1099-K 총액 맞추기: 장부와 세금 양식 연결
제3자 정산 기관 자격을 갖춘 각 BNPL 제공업체는 여러분(과 IRS)에게 Form 1099-K를 보냅니다. 이 양식에 대해 대부분의 판매자를 놀라게 하는 두 가지 사실이 있습니다.
첫째, Box 1a는 조정 없이 총액을 보고합니다. IRS에 따르면, 총 지급 금액은 수수료, 환불, 크레딧, 배송비, 할인으로 조정되지 않습니다. 클라나로 $120,000을 처리하고, $6,000 수수료를 지불하고, $4,000을 환불했다면, 1099-K에는 여전히 $120,000이 표시됩니다. 이는 의도된 것입니다: 수수료와 환불은 신고서에서 공제하는 항목이지, 보고된 총액의 차감이 아닙니다.
둘째, 제출 기준은 이전의 높은 기준으로 돌아갔습니다. ‘One Big Beautiful Bill’은 2021년 이전 기준을 소급하여 부활시켰으므로, 제공업체는 일반적으로 총액이 $20,000 초과 및 거래 건수가 200건 초과인 경우에만 1099-K를 제출해야 합니다. 많은 소규모 판매자는 양식을 전혀 받지 못할 것입니다 — 이는 납부 의무에 아무것도 바꾸지 않습니다. 모든 사업 소득은 양식 도착 여부와 관계없이 신고 대상이기 때문입니다.
장부를 총액 기준으로 유지하면 조정은 간단합니다. 제공업체별, 연간:
- 장부에서 해당 제공업체의 BNPL 총매출로 시작합니다.
- 그 숫자는 제공업체의 1099-K Box 1a와 같아야 합니다 (연말의 작은 시점 차이는 정상입니다 — 12월 31일 판매가 1월 2일에 정산되면 올해 장부에 속하지만 내년 양식에 포함될 수 있습니다. 기준 시점을 문서화하세요).
- 수수료는 별도 공제로 표시되고, 환불은 반품/할인으로 표시됩니다. 어느 것도 총수입에 순액으로 포함되지 않습니다.
장부가 순액 기준이면 2단계가 즉시 실패합니다: "매출" 숫자가 Box 1a보다 수천 달러 낮고 항목별 연결이 없습니다. 세무 시즌에 12개월치 정산 PDF에서 그 연결을 다시 만드는 것은 가장 비싼 부기 방법입니다. 클리어링 계정 방식은 매 정산 주기마다 점진적으로 그 연결을 무료로 만듭니다.
BNPL 장부를 망치는 여섯 가지 실수
- 입금액을 수익으로 기록. 가장 흔한 단일 오류입니다. 매출을 과소계상하고, 수수료를 숨기고, 1099-K 불일치를 보장합니다. 수익은 은행 피드가 아닌 매출 보고서에서 주문일에 기록합니다.
- 수수료를 순 입금액에 묻기. BNPL 요율에서는 많은 판매자의 전체 소프트웨어 예산보다 큰 비용 라인을 숨깁니다. 수수료는 최소 월 단위로, 가능하면 정산 단위로 구분하세요.
- 환불 이중 계산. 전자상거래 플랫폼이 이미 환불을 기록했는데, 더 작은 정산 입금액을 감소된 수익으로 또한 기록하면 환불이 두 번 계산됩니다. 환불은 환불일에 클리어링 계정에 대해 한 번만 기록하세요.
- 롤링 준비금 무시. 어펌 방식 준비금은 채권의 일부가 제공업체에 무기한 남아 있음을 의미합니다. 클리어링 잔액의 일부로 추적하여 누락된 현금으로 읽히지 않게 하세요.
- 모든 제공업체에 하나의 클리어링 계정. 다른 주기, 다른 수수료 체계, 다른 환불 규칙. 혼합 계정은 어떤 단일 제공업체 보고서와도 연결할 수 없으므로 오류가 영구히 숨습니다.
- 현금주의 시점 혼동. 현금주의 판매자도 추적 도구로 클리어링 계정이 필요합니다: 매출은 입금 시 인식되지만, 수수료는 같은 기간의 정산 보고서에서 가져와야 합니다. 그렇지 않으면 비용이 입금이 도착하는 달로 조용히 이동합니다.
월간 BNPL 마감 체크리스트
제공업체당 15분, 월 1회로 위의 모든 실패를 방지합니다:
- 해당 월의 모든 매출이 제공업체 클리어링 계정에 총액으로 기록됨
- 모든 정산 보고서 다운로드 및 수수료 비용 기록
- 모든 환불이 클리어링 계정에 기록되고 수수료 처리 확인
- 모든 정산 입금액이 클리어링-은행 이체로 기록
- 클리어링 잔액이 제공업체의 미정산/준비금 보고서와 일치
- 제공업체별 연간 누적 총액이 1099-K 대사용으로 추적
일반 텍스트 장부로 BNPL 조정을 지루하게 유지하기
BNPL 조정은 무엇보다 한 가지 습관을 보상합니다: 경제적 사건이 발생한 날 모든 달러가 명명된 계정에 들어가므로, 정산일은 계시가 아닌 이체가 됩니다. 이 습관은 grep, diff, 버전 관리가 가능한 일반 텍스트 원장일 때 더 쉽게 유지할 수 있습니다. Beancount 구문의 BNPL 판매, 수수료, 정산은 세 개의 투명한 분개입니다 — 블랙박스 은행 규칙도, 미스터리 잔액도 없습니다:
2026-09-10 * "Klarna 주문 #4821" "블루 린넨 이불 세트"
Assets:Receivable:Klarna-Clearing 200.00 USD
Income:Sales:Ecommerce -200.00 USD
2026-09-17 * "Klarna 주간 정산" "수수료 및 지급액"
Expenses:Fees:BNPL 8.58 USD
Assets:Checking:Operating 191.42 USD
Assets:Receivable:Klarna-Clearing -200.00 USD세무 시즌이 오면 제공업체별 총액, 수수료, 환불이 단일 쿼리로 나옵니다 — 1099-K 대사에 필요한 정확한 연결입니다. 이 워크플로우가 잔액 확인과 보고서가 포함된 전체 대시보드에서 어떻게 보이는지 확인하려면 Fava 대시보드를 탐색하거나 문서를 읽고 시작하세요.
재무 관리 간소화하기
BNPL이 실험에서 가장 큰 결제 채널 중 하나로 성장함에 따라, 총매출, 수수료, 환불을 분리되고 조정 가능한 계정에 유지하는 것이 경영 수치와 세금 신고 모두를 정직하게 만듭니다. Beancount.io는 재무 데이터에 대한 완전한 투명성과 통제권을 제공하는 일반 텍스트 회계를 제공합니다 — 블랙박스도, 벤더 종속도 없습니다. 무료로 시작하기 개발자와 재무 전문가들이 일반 텍스트 회계로 전환하는 이유를 직접 확인하세요.
