고객이 1,200달러짜리 냉장고를 구매하면서 계산대에서 150달러짜리 3년 연장 보증을 추가합니다. 매장의 POS 시스템은 1,350달러를 계산하고 현금을 입금하며 – 그리고 당신의 장부가 현금 등록기와 동일하다면 – 같은 날 1,350달러를 수익으로 기록합니다.
이것은 잘못되었습니다. 그리고 3년 동안 당신의 재무제표를 왜곡할 수 있는 방식으로 잘못되었습니다.
ASC 606, 즉 미국 기업의 수익 보고 방식을 규율하는 수익 인식 기준에 따르면, 그 150달러의 보증 수수료는 아직 당신의 것이 아닙니다. 당신은 아직 그것을 벌지 못했습니다. 당신은 향후 36개월 동안 수리를 위해 대기하겠다고 약속했으며, 회계 규칙은 당신이 그 약속을 이행할 때에만 그 가치를 인식하도록 합니다 – 3년 동안 매월 조금씩. 오늘 150달러 전액을 수익으로 계상하면 당신의 손익계산서는 당신을 속입니다: 이번 달은 실제보다 좋아 보이고, 다음 35개월은 실제보다 나빠 보입니다.
서비스 계약이 포함된 모든 것을 판매하는 소규모 소매업체(가전제품, 전자제품, 가구, 차량, 심지어 고급 도구까지)는 이 문제에 끊임없이 부딪힙니다. 여기서는 규칙이 실제로 어떻게 작동하는지, 왜 존재하는지, 그리고 은행 대출 신청이나 회계사의 연말 조정 과정에서 발견하는 대신 이를 장부에 어떻게 반영할 수 있는지 설명합니다.
핵심 구분: 두 가지 종류의 보증, 두 가지 종류의 회계 처리
ASC 606은 보증을 두 가지 범주로 나누며, 당신의 보증이 어느 범주에 속하는지에 따라 모든 것이 결정됩니다.
보증형 보증(Assurance-type warranties) 은 단순히 제품이 광고된 대로 작동할 것이라고 약속합니다 – 제조업체의 표준 90일 또는 1년 보증으로 구매 시 무료로 제공됩니다. 이것은 별도로 판매하는 것이 아닙니다. 제품 가격 자체에 포함되어 있습니다. 다른 기준(ASC 460)에 따라 예상 수리 비용을 추정하고 판매를 기록한 당일에 해당 비용에 대한 부채를 선지급하여 회계 처리합니다. 수익 이연은 포함되지 않습니다. 단지 대차대조표에 비용 추정치가 올라갈 뿐입니다.
서비스형 보증(Service-type warranties) 은 다릅니다. 이는 고객이 추가로 비용을 지불하는 보증으로, 제조상의 결함 이상의 것을 보장합니다 – 우발적 손상, 정상적인 마모, 업계 표준을 훨씬 초과하는 보장 범위. 고객이 실제 서비스(시간이 지남에 따라 물품을 수리하거나 교체할 준비가 되어 있는 것)를 구매하기 때문에, 회계는 이를 별개의 수행 의무(separate performance obligation) – 고유한 가격표, 고유한 수익, 고유한 일정이 있는 별개의 약속 – 으로 취급합니다.
냉장고의 연장 보증은 전형적인 서비스형 보증입니다. 고객은 제조업체의 표준 결함 보증을 넘는 보장을 위해 자발적으로 추가 비용을 지불했습니다. 그 150달러는 판매 수익이 아닙니다. 계약 기간 동안 매월 서비스를 실제로 제공할 때까지는 부채, 즉 이연(또는 "미수익") 수익입니다.
어떤 유형인지 확인하는 방법
기준은 세 가지 질문을 제시합니다:
- 법적으로 요구됩니까? 필수 보증은 보증형일 가능성이 더 높습니다 – 선택권을 제공하는 것이 아니라 규칙을 준수하는 것입니다.
- 기간은 얼마나 됩니까? 보장 기간이 해당 제품 카테고리의 일반적인 기간을 넘어 길어질수록, 내장된 보장보다는 유료 서비스처럼 보입니다.
- 실제로 무엇을 보장합니까? 엄격히 "자재 또는 제조 기술의 결함을 수리하겠다"는 것이라면 보증형입니다. 제조 결함 보증이 절대 보장하지 않는 것(엎지름, 떨어뜨림, 일반적인 마모)을 보장한다면 서비스형입니다.
가장 명확한 신호는: 고객이 식별 가능한 추가 가격으로 별도로 구매할 수 있습니까? 그렇다면 – 그리고 계산대에서 150달러를 추가하는 것이 바로 그런 경우입니다 – 당신은 서비스형 보증을 보고 있는 것입니다.
규칙이 존재하는 이유: 수익을 제공된 가치와 일치시키기
이것은 관료적인 사소한 논쟁이 아닙니다. 발생주의 회계의 핵심은 대응(matching)입니다 – 수익은 현금이 실제로 교환된 기간이 아니라, 그 수익을 벌기 위해 실제로 일을 수행한 기간에 표시되어야 합니다.
보증을 판매할 때 실제로 무엇을 판매하는지 생각해 보십시오. 당신은 오늘 수리를 판매하는 것이 아닙니다. 당신은 대기 상태(standing readiness)를 판매하는 것입니다 – 36개월 계약의 14개월째에 무언가 고장 나면 당신이 거기에 있을 것이라는 약속입니다. 당신은 계약이 활성화된 매달 그 약속의 일부를 제공합니다. 첫날에 150달러 전액을 인식하는 것은 아무것도 제공하기 전에 3년 치 서비스를 이미 제공했다고 주장하는 것과 같습니다.
또한 눈치채지 못하고 빠지기 쉬운 왜곡으로부터 당신을 보호합니다: 보증 판매가 부진한 달은 수익 라인을 인위적으로 나쁘게 보이게 하고, 강력한 판촉 달(블랙 프라이데이 연장 보장 판매 등)은 인위적으로 좋게 보이게 만듭니다 – 실제 수리 의무가 전혀 변하지 않았음에도 불구하고 말입니다. 수익을 이연하고 정액 기준으로 인식하면 이러한 잡음을 완화하고, 당신(그리고 당신의 재무제표를 보는 모든 사람 – 대출 기관, 투자자, 미래의 당신 자신)에게 비즈니스의 실제 성과에 대한 훨씬 더 정직한 그림을 제공합니다.
메커니즘: 가격 배분 및 시간 경과에 따른 수익 인식
서비스형 보증을 식별한 후에는 두 가지 추가 단계가 필요합니다.
1단계: 거래 가격 분할
보증이 별도로 가격이 책정되고 판매되는 경우(냉장고 예시에서와 같이 – 냉장고 1,200달러, 보증 150달러, 영수증에 항목별로 표시됨) 이 단계는 쉽습니다. 150달러는 보증 가격입니다.
보증이 하나의 통합 가격(예: "1,300달러 냉장고, 보증 포함" 판촉)으로 번들로 제공되는 경우 더 복잡해집니다. 이제 각 구성 요소가 개별적으로 얼마에 판매되었을지 추정해야 합니다 – 이를 독립 판매 가격(standalone selling price) 이라고 합니다 – 그리고 총 가격을 비례적으로 배분합니다. ASC 606은 이를 위한 세 가지 방법을 제공합니다:
- 조정된 시장 평가(Adjusted market assessment) – 경쟁업체가 유사한 보증에 대해 청구하는 금액을 살펴보고 이를 기준으로 사용합니다.
- 예상 원가에 마진을 더한 방법(Expected cost plus margin) – 보증 의무를 이행하는 데 드는 비용을 추정한 다음 이와 같은 서비스에 대해 일반적으로 원하는 마진을 추가합니다.
- 잔여 접근법(Residual approach) – 제품 가격이 잘 확립되어 있지만 보증 가격이 그렇지 않은 경우, 번들 가격에서 제품의 알려진 독립 판매 가격을 뺍니다. 나머지는 보증에 배분됩니다. 이는 첫 번째 두 가지 방법이 신뢰할 수 있는 숫자를 생성하지 못할 때만 사용하는 차선책입니다.
대부분의 소규모 소매업체의 경우, 보증은 정확히 이 배분 작업을 피하기 위해 계산대에서 별도로 가격이 책정되고 인용됩니다. 번들로 제공하는 경우 회계사와 상의하여 어떤 방법이 적합한지 알아보십시오 – 그러나 기준은 편리해서 선택한 숫자보다는 실제로 관찰 가능한 데이터가 있는 곳에서는 이를 사용할 것을 요구한다는 점을 알아야 합니다.
2단계: 서비스를 제공할 때 수익 인식
보증 가격을 알게 되면, 해당 금액은 판매가 발생하는 순간 대차대조표에 부채(미수익 수익)로 올라갑니다. 그런 다음, 일반적으로 보장 기간 동안 정액 기준으로 매월 실제 수익으로 일부를 이전합니다.
150달러, 36개월 보증은 150 ÷ 36 = 월 4.17달러를 수익으로 인식함을 의미합니다. 일반 텍스트 장부 용어로 판매 자체는 다음과 같이 보일 수 있습니다:
2026-07-20 * "Sale of refrigerator with extended warranty"
Assets:Cash 1,350.00 USD
Income:Sales:Appliances -1,200.00 USD
Liabilities:UnearnedRevenue:Warranty -150.00 USD그리고 나서, 향후 36개월 동안 매월 한 번씩:
2026-08-20 * "Recognize one month of warranty coverage delivered"
Liabilities:UnearnedRevenue:Warranty 4.17 USD
Income:Sales:WarrantyRevenue -4.17 USDPOS 시스템의 기본 "현금 유입, 수익 유출" 논리를 신뢰하기보다는 스크립트로 처리할 수 있는 형식으로 원장을 유지하는 것의 장점은 이런 종류의 반복적이고 공식적인 분개를 자동화하는 것이 사소한 작업이 된다는 것입니다. 판매된 보증당 36개의 거의 동일한 거래를 수동으로 입력하는 것이 아닙니다. 판매가 기록되는 즉시 템플릿에서 생성하고, 월말 마감 시 숫자를 확인하기만 하면 됩니다.
비용 측면도 잊지 마세요
이 중 어느 것도 실제 수리 비용(부품, 인건비, 제3자 수리비)을 다루지 않으며, 이는 여전히 발생 시점에 비용으로 처리됩니다(이연 수익 일정과는 별도로). 잘 운영되는 보증 프로그램은 양쪽 측면을 추적합니다: 계약 기간 동안 정액 기준으로 인식되는 수익과 청구가 들어올 때 인식되는 비용. 시간이 지남에 따라 이 둘을 비교하면 보증 가격 책정이 실제로 수익성이 있는지 알 수 있습니다 – 놀랍게도 보증을 판매하는 소매업체 중 상당수가 장부에서 양쪽의 시점을 혼동하기 때문에 실제로 계산해 본 적이 없는 숫자입니다.
소규모 소매업체가 저지르는 일반적인 실수
첫날 모든 것을 수익으로 계상하기. 이것이 가장 큰 실수이며, 회계가 미수익 수익에 대한 부채 계정이 있는 적절한 계정과목표보다는 POS 시스템의 현금 정산에 의해서만 주도되는 경우 자연스러운 기본값입니다.
모든 보증을 기본적으로 보증형으로 처리하기. 계산대에서 별도로 보이는 가격으로 애드온을 판매하고 있다면 거의 확실히 서비스형입니다 – 장부에 기록하기 더 간단하다고 해서 "제품 보증의 일부일 뿐"이라고 가정하지 마십시오.
제공과 일치하지 않는 일정으로 수익 인식하기. 정액 기준(매월 동일한 금액)이 표준이며 대부분의 보증에 적합합니다. 청구 가능성이 일반적으로 보장 기간의 특정 시점에 급증하지 않기 때문입니다. 그러나 제품 카테고리에 예측 가능한 청구 패턴(예: 계약 후반기에 고장이 집중됨)이 실제로 있는 경우, 해당 패턴을 반영하는 체계적인 방법이 단순한 정액 기준보다 더 정확할 수 있습니다. 정액 기준에서 벗어나기 전에 회계사의 조언을 구하십시오. 정액 기준이 더 안전한 기본값입니다.
고객이 조기 취소하거나 환불받을 때 부분적으로 Earned된 잔액을 추적하지 못하는 것. 고객이 36개월 계약의 10개월째에 제품(및 보증)을 반품하는 경우, 앞으로 수익 인식을 중단하는 것뿐만 아니라 남은 미수익 부채를 취소해야 합니다. 그리고 잔액을 부실하게 추적했다면 이 조정은 혼란스러운 작업이 됩니다.
규모가 작더라도 이것이 중요한 이유
당신은 이렇게 생각할 수도 있습니다: ASC 606은 SEC에 제출하는 상장 기업을 위한 것이지, 직원 5명인 가전제품 매장을 위한 것이 아닙니다. 그럼에도 당신에게 여전히 중요한 두 가지 이유가 있습니다.
첫째, 은행 대출을 신청하거나, 신용 한도를 신청하거나, 투자자를 유치할 때, 재무제표를 검토하는 사람은 그것이 일반적으로 인정된 회계 원칙(GAAP)을 따를 것을 기대할 것입니다. 그리고 "모든 보증 수익을 즉시 인식합니다"는 나머지 숫자에 대한 신뢰를 훼손하는 위험 신호입니다.
둘째, 더 직접적으로 유용한 점은: 외부인 누구도 당신의 장부를 보지 않더라도, 이 것을 올바르게 처리하면 당신의 월별 손익계산서가 비즈니스의 실제 상황을 반영하게 됩니다. 막 대규모 보증 판매 월을 보낸 소매업체는 모든 수익이 한 번에 계상되면 인위적으로 수익성 있어 보입니다 – 바로 다음 부진한 달에 비즈니스의 기반 운영이 전혀 변하지 않았음에도 비즈니스가 어려움을 겪고 있는 것처럼 보일 때까지 말입니다.
첫날부터 재정 정리 유지하기
이연 수익 일정, 부채 계정, 월별 인식 분개는 정확히 검사하고, 템플릿화하고, 감사할 수 있는 기록의 혜택을 받는 반복적이고 규칙 기반의 장부 작업 유형입니다 – 맹목적으로 신뢰해야 하는 블랙박스 원장이 아닙니다. Beancount.io는 재무 데이터에 대한 완전한 투명성과 통제권을 제공하는 일반 텍스트 회계를 제공하며, 스프레드시트에서 수동으로 추적하는 대신 보증 수익 인식과 같은 반복적인 분개를 스크립트로 작성할 수 있는 유연성을 제공합니다. 지금 무료로 시작하고 개발자와 금융에 정통한 사업주들이 일반 텍스트 회계로 전환하는 이유를 확인하십시오.