한 고객이 전화를 걸어 명세서에는 $1,240의 자문 수수료가 표시되는데 청구 소프트웨어에서는 $1,180를 청구했다고 나온다며 이유를 묻습니다. 커스터디언 보고서를 확인하고, 이어서 자체 장부를 확인해 보아도 두 숫자가 일치하지 않습니다 — 누군가 잘못을 저질러서가 아니라, 애초에 당신의 장부가 사업 전체를 떠받치는 그 한 가지, 즉 매일 움직이는 타인의 자산에 대한 일정 비율을 추적하도록 설계되지 않았기 때문입니다.
수수료 전용 등록투자자문사(RIA)에게 운용자산(AUM)은 단순한 마케팅 수치가 아닙니다. 이는 수익을 직접 결정하는 요소이며, 작은 시점 차이나 산정 방식의 차이가 누적되면 실질적인 대사(對査) 문제로 이어집니다. 대부분의 RIA 창업자는 회계가 아닌 투자나 재무설계 배경을 가지고 있으며, 규제 당국과 감사인, 고객이 결국 던지게 되는 단 하나의 질문 — "이 수수료는 실제로 어디서 나온 것인가?" — 에 답하도록 설계되지 않은 QuickBooks 파일을 물려받는 경우가 많습니다.
AUM 수수료 수익 기장이 생각보다 어려운 이유
소매업은 판매가 이루어지는 시점에 수익을 인식합니다. 반면 RIA의 수익은 움직이는 목표물과 같습니다. 매초 변동하는 자산 잔액을 기준으로 산정되고, 달력상의 월과는 좀처럼 맞아떨어지지 않는 주기로 청구되며, 자문사가 현금을 손에 쥐기도 전에 제3자인 커스터디언에 의해 공제되는 경우가 많습니다.
세 가지 설계상의 선택이 회사가 감수해야 할 대사 작업의 고통을 결정합니다.
청구 시점: 선불 vs. 후불. 대부분의 RIA는 분기 초에 향후 3개월간 제공될 서비스에 대한 수수료를 산정하여 선불로 청구합니다. 즉, 고객이 분기 중간에 계약을 해지하거나 자산을 이전할 때마다 회사는 일할 계산된 환불금을 지급해야 하며, 이는 단순히 기록해 두고 잊어버릴 수 있는 것이 아니라 추적하고 상환해야 하는 부채입니다. 후불로 청구하는 회사는 환불 문제를 피할 수 있지만 대금을 받기까지 더 오래 기다려야 하며, 급여, 배상책임보험(E&O), 소프트웨어 구독료 등 운영비가 AUM 수수료 입금 시점과 무관하게 매월 지출되어야 한다면 현금 흐름에 부담이 됩니다.
잔액 산정 방식: 특정 시점 vs. 일평균 잔액. 회사는 특정 하루(청구 기간의 첫날 또는 마지막 날)의 계좌 잔액을 기준으로 청구하거나, 기간 전체의 일평균 잔액을 기준으로 청구할 수 있습니다. 이 선택은 결코 중립적이지 않습니다 — 계속 자금을 납입하는 순저축자 고객군의 경우, 기간 말 시점 기준 청구가 평균보다 높은 수수료를 산출하는 경향이 있는 반면, 정기적으로 인출하는 은퇴자 고객군의 경우 일평균 잔액이 기말 잔액보다 높게 나오는 경우가 많습니다. 회사가 어떤 방식을 선택하든, 해당 방식은 고객 계약서에 명시되고 일관되게 적용되어야 합니다. SEC가 실제로 이를 점검하기 때문입니다.
누가, 어떻게 수취하는가. 대부분의 RIA는 고객 자금을 직접 다루지 않기 때문에, 커스터디언(Schwab, Fidelity, Pershing 등)이 각 고객 계좌에서 자문 수수료를 공제한 뒤 이를 일괄로 묶어 자문사의 운영 계좌로 송금합니다. 대사 문제는 바로 이 일괄 송금에서 시작됩니다. 커스터디언의 입금액은 수십, 수백 건의 개별 고객 수수료를 포함한 하나의 총액이며, 그중 단 한 건이라도 계산이 잘못되면 — 잘못된 요율 구간, 가구 합산 오류, 적용되지 않은 수수료 면제 등 — 그 오차는 어느 항목이 원인인지 뚜렷이 드러나지 않은 채 단 한 번의 송금 안에 묻혀버립니다.
수익 인식: 장부상 계상과 실제 수취는 단순한 형식 문제가 아니다
RIA 실무에서 가장 흔한 부기 오류는 수수료 수익을 실제로 획득하고 수취한 날짜가 아니라 청구서가 발행되거나 산정된 날짜에 기록하는 것입니다. 발생주의 원칙(그리고 상장기업에만 국한되지 않고 널리 적용되는 수익 인식 논리)에 따르면, 분기별로 산정되는 AUM 수수료는 해당 기간에 걸쳐 획득되는 대로 인식되어야 하며, 청구서 발행일에 한꺼번에 장부에 반영해서는 안 됩니다.
이 구분이 중요한 이유는 세 가지입니다.
- 손익계산서를 왜곡합니다. 분기 첫날에 분기 전체 수수료를 계상하면 첫째 달은 인위적으로 실적이 좋아 보이고 둘째, 셋째 달은 인위적으로 부진해 보이게 되어, AUM 성장세의 실질적인 둔화를 포착하기가 더 어려워집니다.
- 미수금에 대한 착시를 만듭니다. 수취하기 전에 청구서를 발행하고, 장부가 그 발행 시점을 곧 수익으로 계상한다면 현금 잔고와 보고된 수익이 서로 어긋나게 됩니다. 이 격차는 대출기관이나 인수자가 재무제표를 요구하고 숫자가 은행 명세서와 맞지 않는 순간까지 놓치기 쉽습니다.
- 선불 리테이너를 잘못 처리하게 됩니다. AUM과 무관한 자문에 대해 정액 리테이너나 구독료를 청구하는 수수료 전용 재무설계 회사도 비슷한 문제를 겪습니다. 1년치 재무설계 비용을 선불로 낸 고객은 아직 당신에게 수익을 지불한 것이 아닙니다. 그 현금은 실제로 서비스를 제공하기 전까지는 부채 — 향후 서비스의 형태로 여전히 갚아야 할 미획득 수익 — 입니다. 선수금 전체를 수취 시점에 수익으로 인식하면 수익성이 과대평가되며, 완전히 벌지 않은 돈에 대해 달갑지 않은 세금 고지서를 받을 수도 있습니다.
대부분의 부기 담당자가 놓치는 커스터디 규정 문제
고객 계좌에서 직접 수수료를 공제하는 것은 순전히 운영상의 세부 사항처럼 들리지만, SEC 규정 206(4)-2(커스터디 규정)에 따르면 자문 수수료를 직접 공제할 수 있는 권한 자체가 RIA에게 일종의 "커스터디"를 부여합니다 — 실제로 회사가 그 돈을 물리적으로 보유하지 않더라도 말입니다. 이는 특정 조건이 충족되지 않는 한 추가적인 의무를 발생시킵니다.
실무적으로, 수수료 공제만 하는 대부분의 RIA는 완전 커스터디 회사가 직면하는 비용이 많이 드는 연례 불시 감사를 피할 수 있지만, 이는 모든 조건을 충족할 때만 가능합니다. 즉, 적격 커스터디언이 특수관계자가 아니어야 하고, 고객은 수수료 산정 공식과 그 산정 기준이 된 자산을 명시한 항목별 청구서를 받아야 하며, 자문사는 동일한 청구서 — 또는 이를 검증하기에 충분한 세부 정보 — 를 동시에 커스터디언에게도 발송해야 합니다. 이 단계 중 하나라도 빠뜨리면 실제로 반복적으로 발생하는 SEC 제재의 원인이 되며, 그 시작점은 바로 부기입니다. 청구 워크플로가 항목별 명세서를 자동으로 생성하고 보관하지 않는다면, 매 청구 주기마다 누군가 수작업으로 이를 기억해서 처리해 주기를 바라는 셈입니다.
수수료 산정과 관련된 기록 역시 SEC 규정 204-2의 5년간 장부 및 기록 보관 요건의 적용을 받습니다. 감사인이 특정 고객의 2분기 청구서를 뒷받침하는 수수료 산정 내역을 요청할 때, "아마 저희 청구 소프트웨어에 아직 남아 있을 겁니다"라는 답변은 받아들여지지 않습니다 — 기초가 되는 잔액 데이터, 적용된 수수료 체계, 그리고 그 결과로 나온 청구서 모두가 조회 가능해야 하며 총계정원장까지 추적 가능해야 합니다.
커스터디언 수치와 자사 수치가 실제로 어긋나는 지점
고객(또는 감사인)이 커스터디언 명세서상의 수수료가 회사가 보고한 금액과 왜 다른지 물을 때, 그 불일치는 거의 항상 몇 가지 원인 중 하나입니다.
- 시점 차이. 커스터디언의 공제일과 회사 장부의 인식일이 같은 날이 아닌 경우로, 특히 분기 경계 부근에서 자주 발생합니다.
- 가구 합산. 많은 회사가 고객의 총 가구 자산이 특정 임계값을 넘으면 구간별 할인을 제공하지만, 커스터디언 측에서 가구 설정이 올바르게 구성되어 있지 않으면 계좌별로 개별 수수료를 산정할 수 있습니다.
- 수수료 면제 및 상한. 일회성 우대 면제, 대형 계좌를 위해 협상된 수수료 상한, 여러 계좌에 걸친 혼합 요율 등은 청구 소프트웨어에서는 올바르게 적용하기 쉽지만, 커스터디언의 일괄 입금액을 개별 고객 장부와 대사할 때는 놓치기 쉽습니다.
- 비수탁 자산(Held-Away Assets). 자문사는 자문은 제공하지만 직접 수탁하지는 않는 자산 — 통합 관리 도구로 추적하는 비수탁 401(k) 등 — 에 대해서도 점점 더 많이 수수료를 청구하고 있습니다. 이러한 수수료는 대개 커스터디언의 일괄 공제와는 별도로 지급되며, 청구 워크플로가 통합되어 있지 않으면 잘못된 기간이나 계정에 기록되기 쉽습니다.
해결책은 스프레드시트를 더 많이 만드는 것이 아니라, "발생 수수료", "청구 수수료", "수취 수수료"를 세 가지 별개의 이벤트로 구분하고, 일괄 입금 수준이 아니라 고객 수준에서 대사하는 계정과목 체계와 대사 습관을 갖추는 것입니다. 총 입금액 수준에서만 대사하는 회사는 그 안에 묻혀 있는 개별 고객 오류를 결코 발견하지 못합니다.
수수료 산정만큼 정밀하게 재무 기록을 관리하십시오
RIA의 신뢰성은 고객을 위해서든, 규제 당국을 위해서든, 회사 자체의 의사결정을 위해서든 숫자를 정확하게 맞추는 데 달려 있습니다. Beancount.io를 활용한 플레인 텍스트 회계는 바로 그 원칙을 부기에도 그대로 적용합니다. 모든 수수료 발생, 모든 커스터디언 입금, 모든 고객 수준의 대사가 블랙박스 스프레드시트가 아니라 버전 관리되고 감사 가능한 장부 안에 기록됩니다. 무료로 시작하기에서, 이미 투자 프로세스에서 정밀함을 요구해 온 금융 전문가들이 왜 자신의 장부에도 똑같은 엄격함을 적용하고 있는지 확인해 보세요.