침수된 지하실의 물을 빼내고, 젖은 석고보드를 뜯어내고, 3주간 복구팀을 투입한 뒤 주택 소유자의 보험사에 14,200달러짜리 청구서를 제출한다. 90일 후, 9,600달러짜리 수표가 계좌에 입금되지만 — 원래의 Xactimate 견적서를 꺼내 한 줄 한 줄 눈을 찌푸리며 대조해보지 않는 이상, 팀의 누구도 그 차액이 나중에 받을 감가상각 유보금인지, 손해사정인이 삭제한 항목인지, 아니면 자체 청구서의 실수인지 말해줄 수 없다.
이 차액은 예외적인 상황이 아니다. 복원 사업을 운영하는 데 있어 지극히 정상적인 상태이며, 수많은 수해·곰팡이·화재 복원 업체가 건별로는 수익성이 있어 보이면서도 만성적인 현금 부족에 시달리는 이유이기도 하다. 견적, 청구서, 입금액은 서로 다른 세 프로세스에서 생성되는 세 가지 다른 숫자이며, 장부가 이 중 하나만 추적한다면 어떤 건이 실제로 돈을 벌고 있는지 손쓸 수 없을 때까지 알 방법이 없다.
복원 프로젝트를 거치며 돈이 실제로 어떻게 흐르는지, 그리고 장부가 보험 손해사정 소프트웨어가 아니라 현실과 일치하도록 유지해주는 계정과목 체계와 대사(reconciliation) 습관을 살펴본다.
Xactimate가 청구서와 당신 사이에 끼어드는 이유
Xactimate는 거의 모든 주택 보험사가 손해액을 산정할 때 사용하는 견적 플랫폼이며, 대부분의 복원 업체도 이를 사용한다 — 좋아서가 아니라, 청구서가 Xactimate의 항목 코드, 단가, 표준화된 수량이라는 언어를 쓰지 않으면 손해사정인이 지급을 승인하기 전에 자신들의 견적과 청구서를 수작업으로 대조해야 하기 때문이다. 이 마찰은 매출채권 회수에 몇 주를 더 얹는다.
실질적인 효과는 이렇다. 매출은 그 작업을 완료하는 데 실제로 든 비용으로 정해지지 않는다. 견적 담당자와 보험사 손해사정인 사이의 범위·가격 협상이 도달한 지점에서 정해지며, 이 숫자는 이미 작업을 시작한 뒤에도 위로(추가 견적) 또는 아래로(범위 삭감) 움직일 수 있다.
그래서 복원 회계는 단순히 "청구했다"와 "받았다"만 추적해서는 안 된다. 첫날부터 건당 세 가지 숫자를 별도로 추적해야 한다.
- 승인된 작업 범위(RCV) — 보험사가 Xactimate를 통해 서면으로 지급을 약속한 금액.
- 실제 발생 비용 — 인건비, 장비 사용일수, 자재, 하도급업체, 폐기물 반출.
- 실제 수금액 — 거의 한 번에 들어오는 법이 없고, 첫 수표가 승인된 작업 범위와 정확히 일치하는 경우도 거의 없다.
RCV, ACV, 그리고 신입 복원 부기 담당자를 늘 헷갈리게 하는 감가상각 유보금
대부분의 주택 보험 약관은 재조달가액(Replacement Cost Value, RCV) 기준으로 지급하지만, RCV를 선지급하지는 않는다. 주택 소유자(또는 직접 청구 건이라면 복원 업체)가 처음 받는 수표는 실제현금가치(Actual Cash Value, ACV)로, RCV에서 노후 자재의 감가상각분을 뺀 금액이며 많은 약관에서는 인건비 감가상각분까지 뺀다. RCV와 ACV의 차이를 **회수 가능 감가상각(recoverable depreciation)**이라 부르며, 보험사는 수리 작업이 실제로 완료되었음을 증명할 때까지 이를 안전장치로 유보한다.
즉 하나의 작업이 하나의 승인된 범위에 대해, 서로 다른 금액으로, 몇 달 간격을 두고 두 번의 별도 지급을 발생시킨다.
- 1차 수표(ACV): 흔히 재건축이 시작되기 전에, 주택 소유자의 공제액(deductible)을 뺀 금액으로 조기 지급된다.
- 2차 수표(회수 가능 감가상각): 완료 청구서나 완료 확인서를 제출한 후에만 지급되며 — 애초에 해당 약관이 그 감가상각분을 회수 가능하게 설계한 경우에만 지급된다. 일부 오래되었거나 보장 수준이 낮은 약관은 ACV만 지급하며, 이 경우 그 감가상각 차액은 영영 들어오지 않고 주택 소유자가 부담하거나, 애초에 청구서가 RCV보다 적은 금액이었다면 처음부터 청구할 수 없는 돈이었다.
ACV 수표를 그 건의 전액 결제로 장부에 기록하면, 실제로 회수 가능한 채권인 회수 가능 감가상각분이 미기재된 채 방치되어 잊어버리기 쉬운 상태에서도 그 건을 완전히 수금된 것처럼 보이게 된다. 이를 별도로 추적하지 않는 복원 업체는 사실상 돈을 테이블 위에 놓아둔 채 방치하는 것과 같다. 그 돈이 여전히 받을 돈이라는 사실을 알아채는 것이 아무의 업무도 아니기 때문이다.
해결책: 회수 가능 감가상각을 나중에 처리할 매출이 아니라, 견적이 승인되는 순간 그 자체의 매출채권 항목으로 기록한다. 건당 다음의 간단한 세 계정 구조로 처리할 수 있다.
Accounts Receivable:Insurance:ACV— 작업 시작 시점에 발생 예정Accounts Receivable:Insurance:Depreciation Holdback— 완료 시점에 발생 예정, 후속 조치 대상으로 표시Accounts Receivable:Homeowner:Deductible— 직접 수금하며, 절대 할인하거나 면제하지 않음(아래 참고)
추가 견적: 승인된 범위가 최종 범위가 아닌 이유
수해·화재 작업은 최초 견적서가 예상한 그대로 끝나는 경우가 거의 없다. 벽을 열어보니 바닥재까지 젖어 있거나, 완화(mitigation) 팀이 손해사정인이 미처 보지 못한 걸레받이 뒤 곰팡이를 발견하면, 추가 견적(supplement) — 추가 작업을 하기 전에 보험사 승인을 받기 위해 제출하는 수정 또는 추가 항목 견적 — 을 제출하게 된다.
추가 견적은 종합건설업자(general contractor) 개념의 변경 지시서(change order, 고정가 계약에서 고객이 승인한 범위 변경)와는 다르다. 이는 피해가 발생했을 당시 그 자리에 없었고 승인할 의무도 없는 제3자와의 재협상이다. 이 차이는 장부에서 세 가지 방식으로 중요하다.
- 추가 매출은 승인되기 전까지 인식하지 않는다. 추가 피해를 조사하거나 처리하는 데 든 비용은 지출하는 순간 실재하는 비용이지만, 그것을 충당할 매출은 보험사가 서명할 때까지 조건부다. 제출 시점(승인 시점이 아니라)에 추가 견적 매출을 기록하면, 추가 견적이 일부 거절되는 순간까지 그 건의 수익성이 실제보다 부풀려 보인다.
- 추가 견적은 원래 범위에 합치지 말고 별도 항목으로 추적한다. 여러 건에 걸쳐 승인된 범위 대비 실제 비용 마진을 비교할 때, 요청 금액의 60%만 승인된 추가 견적이 세 건 있는 작업은 애초에 최초 견적 자체가 잘못됐던 작업과는 다른 이야기를 들려준다. 이를 뒤섞으면 어느 견적 담당자가 최초 청구 범위를 과소 산정하고 있는지 알 수 없게 된다.
- 일부 항목에서는 실제 마찰을 각오해야 한다. 일부 보험사와 손해사정인은 추가 견적 가격, 특히 인건비 항목과 간접비·이윤(overhead & profit) 비율에 대해 강하게 반발한다. 3,400달러로 제출한 추가 견적이 2,100달러로 승인되는 것은 부기 오류가 아니라 정상적인 결과이며, 승인 결과가 돌아오는 순간 작업원가 보고서는 요청 금액이 아니라 승인된 금액을 반영해야 한다.
계정과목 체계: 완화 작업과 재건축은 항상 분리한다
수해 완화(추출, 건조, 제습, 모니터링)와 재건축(석고보드, 바닥재, 도장, 몰딩)은 한 회사 로고를 달고 있을 뿐 사실상 서로 다른 사업이며, 이 둘의 매출과 비용을 뭉뚱그리는 것이 복원 업체 대표가 어떤 작업이 수익성이 있는지 알 수 없게 되는 가장 흔한 원인이다.
전형적인 마진 구조는 다음과 같으며, 그 격차가 상당히 크다.
| 서비스 라인 | 매출총이익률 |
|---|---|
| 수해 완화 | 70–80% |
| 곰팡이 제거 | 55–70% |
| 화재 피해 완화 | 50–65% |
| 재건축/재시공 | 30–40% |
고마진 완화 단계와 저마진 재건축 단계가 뒤섞인 작업은 통합 손익계산서에서 "그런대로 괜찮은" 혼합 마진으로 보이지만, 실제로는 재건축팀이 인건비 비중이 큰 작업에서 손익분기점에 근접해 운영되고 있다는 사실을 가려버린다. 계정과목 체계(대부분의 복원 업체는 QuickBooks Online에서 클래스나 작업 추적 기능으로 이를 운영한다)에 각 단계별로 클래스나 태그 — Mitigation, Reconstruction, Contents/Pack-Out, Mold — 를 설정하고 모든 매출·비용 항목에 적용하면, 두 단계에 걸친 작업이라도 하나의 혼합된 숫자가 아니라 두 개의 뚜렷한 마진으로 보고된다.
각 단계 내에서는 건마다 실제로 달라지는 비용 항목을 추적한다.
- 인건비 — 단순한 팀 단위 총비용이 아니라 기술자별로 추적한다. 가동률(청구 가능 시간 대비 총 지급 시간)은 대부분의 복원 업체가 계산하지 않지만 마땅히 계산해야 할 지표 중 하나이기 때문이다.
- 장비 사용일수 — 제습기, 송풍기, 공기청정기는 Xactimate 가격 체계상 장비 사용일수 단위로 보험사에 청구되므로, 내부 비용 추적도 뭉뚱그린 "장비비" 항목이 아니라 동일한 일 단위로 맞춰야 한다. 그렇지 않으면 그 건의 건조 기간(따라서 장비 매출)이 실제로 투입한 장비와 일치하는지 알 수 없다.
- 자재 및 하도급업체 — 청구 근거가 되는 승인된 항목에 직접 매핑되어야 하는 재건축 단계 비용.
- 폐기·처리 수수료 — 개별적으로는 소액이지만 합산하면 무시할 수 없고, 견적서 대비 항목별로 관리하지 않으면 미청구된 채 누락되기 쉽다.
현금흐름 격차: 30일이 아니라 30~90일짜리 매출채권으로 예산을 짜라
일반적인 소상공인 현금흐름 조언은 청구서가 30일 안에 결제된다고 가정한다. 복원업은 그렇게 돌아가지 않는다. 보험사는 작업 완료 후 지급까지 통상 30~90일이 걸리는 반면, 급여, 장비 할부금, 하도급업체 대금은 보험사의 결제 시점과 무관하게 평소의 주간 또는 월간 주기대로 지급해야 한다. 진행 중인 작업들이 있는 상태에서 이 격차는 예외가 아니라 구조적인 문제다 — 성장하는 복원 업체가 서류상으로는 수익성이 있으면서도 현금이 바닥나는 이유가 바로 여기에 있다.
다음 세 가지 관행이 이를 위기로 번지지 않게 막아준다.
- 청구일이 아니라 예상 수금일을 기준으로 13주 단위 순환 현금 예측을 한다. 보험사의 과거 평균 처리 기간이 80일이라면, 오늘 청구한 작업은 예측표의 4주차가 아니라 12주차에 나타나야 한다.
- 매출채권 연령을 지급 주체별로 추적한다. 총액만 볼 것이 아니라 — 보험사가 갚아야 할 ACV, 보험사가 갚아야 할 감가상각 유보금, 주택 소유자가 갚아야 할 공제액은 각기 다른 속도로 노화하며 각기 다른 후속 조치(손해사정인에게 전화할지, 주택 소유자에게 전화할지)가 필요하다.
- 작업을 따내기 위해 주택 소유자의 공제액을 할인하거나 조용히 면제해주지 않는다. 현금흐름에 나쁠 뿐 아니라, 보험사에는 전액을 청구하면서 주택 소유자에게는 계약된 공제액보다 적게 청구하는 행위는 일부 주에서 보험 사기에 해당할 수 있다. 작업 비용 대부분을 지불하는 당사자에게 실제 비용을 왜곡해서 알리는 셈이기 때문이다. 공제액 부담을 덜어주고 싶다면 문서화된 분할 납부 계획을 제시하되, 청구서에서 조용히 지워버리지는 말라.
세 가지 숫자를 건별로 대사하기
최소한 모든 작업 파일(실물이든 회계 시스템 안이든)은 아무것도 다시 계산하지 않고도 다음 세 가지 질문에 답할 수 있어야 한다.
- 보험사가 승인한 금액은 얼마인가?(최초 Xactimate 범위 + 승인된 모든 추가 견적)
- 실제로 지출한 금액은 얼마인가?(단계별 인건비, 장비 사용일수, 자재, 하도급 비용)
- 실제로 수금한 금액과 아직 미수금인 금액은 얼마이며, 누구에게 받을 돈인가?(수령한 ACV, 대기 중인 감가상각 유보금, 수금 또는 미수 상태인 공제액)
이 세 숫자가 세금 신고철에 기억을 되짚어 재구성하는 것이 아니라 하나의 작업 기록 안에서 승인과 지급이 이뤄질 때마다 갱신된다면, 팀이 철수한 지 석 달 뒤에야 그 건이 손해였다는 사실을 알게 되는 일도, 아무도 표시해두지 않아 여전히 받을 돈인 회수 가능 감가상각 수표를 테이블 위에 남겨두는 일도 없어진다.
재무 관리를 단순하게
보험 주도 매출 — 승인된 범위, 실제 비용, 시차를 둔 수금 — 을 대사하는 일은 스프레드시트나 작업 단계별 마진을 염두에 두고 만들어지지 않은 범용 회계 소프트웨어에서 길을 잃기 딱 좋은 종류의 추적 작업이다. Beancount.io는 재무 데이터에 대한 완전한 투명성과 통제권을 제공하는 평문(plain-text) 회계를 제공하며, 모든 거래를 작업, 단계, 지급 주체별로 태그할 수 있는 유연성을 갖췄다. 무료로 시작하기에서 개발자와 금융 전문가들이 왜 평문 회계로 갈아타고 있는지 확인해 보라.