원장으로 이어지는 CRM

문서별로 살펴보는 흐름

리드-투-캐시(lead-to-cash)는 비유가 아닙니다. 각각 총계정원장에 정해진 영향을 주는 일련의 문서이며, 그중 대부분은 원장에 아무런 영향도 주지 않습니다. 어느 것이 어느 쪽인지 혼동하는 지점에서 돈이 샙니다.

리드는 관심의 기록입니다. 영업기회는 담당자가 부여한 예상 금액과 확률이 붙은 예측 대상입니다. 둘 다 원장에 영향을 주지 않으며, 주어서도 안 됩니다. 견적서는 청약입니다. 가격, 범위, 유효기간을 확정하지만 아무것도 예약하지 않을 수 있습니다. 판매주문은 고객이 그 청약을 승낙한 것입니다. 쌍방의 약정이며 흔히 구매, 일정 수립, 생산의 계기가 되지만, 여전히 회계 분개는 아닙니다. 수익도, 매출채권도 없습니다.

대개 가장 중요한 사건은 인도 또는 용역 완료입니다. 재화나 용역에 대한 통제가 이전되는 시점이기 때문입니다. 청구서는 인식 시점입니다. 매출채권을 차변에, 수익을 대변에 기록하고 매출세액 부채를 계상합니다. 수금은 매출채권을 현금 또는 예금과 상계합니다. 수익을 인식하지 않으며, 이미 존재하는 채권을 결제할 뿐입니다. 대변표(크레딧 노트)는 청구서의 일부 또는 전부를 취소하며, 세금이 부과되었다면 세금도 함께 취소합니다.

이것이 “주문은 청구서가 아니다”라는 원칙의 실무적 형태입니다. 원장에 전기된 문서만 대금이 지급되고, 독촉의 대상이 되며, 연령분석에 나타납니다. 시스템이 판매주문에 대금을 적용하도록 허용하거나, 주문 금액을 인식된 수익과 같은 열에 나란히 보고한다면, 월말 결산이 시작되기도 전에 흐름이 끊어진 것입니다.

• 리드와 영업기회: 파이프라인 기록이며 원장 영향 없음.
• 견적서: 유효기간이 있는 가격 제시이며 원장 영향 없음.
• 판매주문: 쌍방의 약정이며 원장 영향은 없지만 재고, 구매, 일정 수립을 움직임.
• 납품서 또는 용역 완료 확인: 통제 이전의 증거이며 재고와 매출원가를 움직일 수 있음.
• 청구서: 매출채권 차변, 수익 대변, 매출세액 계상. 인식은 여기서 이루어짐.
• 수금: 현금 또는 예금 차변, 매출채권 대변. 수익이 아니라 결제.
• 대변표: 청구 금액과 세금을 취소하고, 기초가 되는 채권을 복원하거나 제각함.

분리가 실제로 초래하는 비용

CRM과 원장이 서로 다른 시스템이라도 첫날에는 극적인 일이 일어나지 않습니다. 피해는 사람들이 조용히 수작업으로 하다가 어느새 그만두는 작은 대사 작업들에 있습니다.

고객 마스터 데이터가 재입력되어, 같은 구매자가 두 가지 표기와 두 가지 결제조건으로 두 번 존재하게 됩니다. CRM에서 견적 가격을 협상해 낮췄는데 청구서는 이전 가격표로 발행되어, 고객이 이의를 제기하거나 누군가 이를 바로잡기 위해 대변표를 발행해야 합니다. 영업 관리자가 승인한 할인은 청구 화면이 전혀 읽지 않는 CRM 필드에만 존재합니다. 수수료는 청구·회수된 금액이 아니라 수주 금액을 기준으로 계산되어, 회사는 아직 인식하지 않았고 때로는 회수하지도 못할 수익에 대해 수수료를 지급합니다. 영업팀은 분기 실적으로 한 숫자를, 재무팀은 다른 숫자를 보고하고, 회의 시간은 차이에 대응하는 대신 그 차이를 설명하는 데 쓰입니다.

이 모든 문제의 뿌리는 같습니다. 한 시스템에 한 번 입력된 값이 수작업이나 가져오기를 통해 다른 시스템에 다시 입력되는 것입니다. 제거해야 할 메커니즘은 불일치가 아니라 재입력입니다.

하나의 고객 레코드, 그리고 매출채권이 먼저 신경 써야 하는 이유

중복 고객은 흔히 영업 데이터 관리 문제로 설명됩니다. 하지만 무엇보다 먼저 매출채권 문제입니다. 신용 노출은 레코드별로 계산되므로, 레코드가 두 개면 아무도 승인하지 않았는데 신용한도가 사실상 두 배가 됩니다. 연령분석도 두 레코드로 나뉘어 어느 쪽도 독촉할 만큼 나빠 보이지 않습니다. 대금은 두 계정에 걸친 청구서를 한꺼번에 결제하는 하나의 송금으로 들어오고, 배분은 수작업으로 해야 합니다.

고객 레코드는 두 부서가 모두 의존하는 필드를 한 번만 보유하고 양쪽이 함께 읽어야 합니다. 법인명과 상호, 세금 등록번호, 신용한도, 결제조건, 지정 가격표, 통화, 청구지 및 배송지 주소, 그리고 구매 담당자와 항상 같지는 않은 수금 담당자가 그것입니다. 사우디아라비아와 걸프 지역 전반에서 세금 등록번호는 있으면 좋은 정보가 아닙니다. 적격 세금계산서의 필수 항목이며, 잘못되었거나 비어 있는 번호로 발행된 청구서는 서식 문제가 아니라 컴플라이언스 문제입니다.

약속하기 전에 이루어지는 신용 관리

원장은 고객이 얼마를 빚지고 있는지, 얼마나 연체되었는지 이미 알고 있습니다. 연령분석은 청구서가 전기되는 순간 존재합니다. 문제는 영업 담당자가 자신의 행동을 바꿀 수 있는 순간, 즉 재무팀이 조건을 거절한 후가 아니라 조건을 제시하기 전에 그것을 볼 수 있느냐입니다.

피해야 할 패턴은 익숙합니다. 연체된 청구서가 여러 건 있는 고객이 연장된 결제조건을 제안받고, 그 조건으로 거래가 성사되며, 재무팀은 조건을 철회해 관계를 손상시키거나 아무도 승인하지 않은 노출을 받아들여야 하는 처지에 놓입니다. 그 시점에서 어느 결과도 재무의 결정이 아닙니다. 영업 담당자에게 잔액을 보여 주지 않은 데 따른 결과일 뿐입니다.

시스템이 하나라면 구조는 간단합니다. 현재 잔액, 구간별 연체 잔액, 신용한도, 남은 한도가 고객 계정과 견적 화면에 표시됩니다. 한도를 초과하는 주문은 승인이 필요하며, 그 승인은 복도에서 합의되는 것이 아니라 주문에 기록됩니다. Skyline Nexus가 이렇게 작동하는 이유는 CRM과 매출채권 원장이 같은 고객 계정을 읽기 때문이며, 따라서 영업팀에 보이는 노출은 그 사본이 아니라 재무팀이 보고 있는 바로 그 잔액입니다.

인식 시점은 CRM 데이터 안에 있습니다

IFRS 15에 따르면 수익은 수행의무를 이행할 때, 즉 약속한 재화나 용역에 대한 통제가 고객에게 이전될 때 인식합니다. 이는 인도처럼 한 시점일 수도 있고, 유지보수 계약이나 단계별 건설 프로젝트처럼 기간에 걸친 것일 수도 있습니다. 기준서는 또한 거래가격을 계약 내 별도의 수행의무에 배분하도록 요구합니다.

이 모든 것을 결정하는 정보는 상거래 문서 안에 있습니다. 무엇을 약속했는지, 계약에 구별되는 산출물이 묶여 있는지, 각각 언제 인도되거나 수락되었는지, 무엇을 무엇에 대해 할인했는지가 그것입니다. CRM이 계약 및 인도 데이터를 보유하는데 회계 시스템이 이를 전혀 보지 못한다면, 누군가 기간 말에 스프레드시트로 이를 재구성하고 감사 추적은 그 스프레드시트에서 끝납니다. 주문 라인에 수행의무가 담기고 인도 기록에 날짜가 담기면, 이연 및 인식 일정은 기억에 의존해 재구성되는 것이 아니라 문서로부터 도출됩니다.

파이프라인은 예측이고, 수익은 사실입니다

가중 파이프라인은 성사될 수 있는 거래를 확률로 조정한 추정치입니다. 인식된 수익은 원장이 해당 기간에 벌어들였다고 말하는 금액이며 감사할 수 있습니다. 둘은 서로 다른 질문에 답하며, 결코 하나의 숫자로 제시되어서는 안 됩니다.

연결된 시스템은 둘을 합치지 않습니다. 둘 사이를 추적할 수 있게 해 줍니다. 파이프라인 숫자에서 그 뒤의 영업기회로, 그것이 된 주문으로, 그 주문이 만들어 낸 청구서로, 그리고 수금된 현금으로 이어 갈 수 있습니다. 이 경로가 있어야 예측을 개선할 수 있습니다. 과거에 주문 금액이 얼마나, 어느 정도의 기간을 거쳐 청구된 수익으로 전환되었는지 측정하고, 이를 두고 논쟁하는 대신 예측 방법을 조정할 수 있습니다.

무엇을 공유해야 하는가, 그리고 월말 결산은 어떻게 달라지는가

공유한다는 것은 모든 것을 복사한다는 뜻이 아닙니다. 한 번만 존재하면서 두 부서가 함께 읽는 정해진 레코드 집합, 그리고 재입력 없이 문서를 다음 단계로 넘기는 정해진 이벤트 집합을 뜻합니다.

월말의 효과는 범위가 좁고 구체적입니다. 모든 청구서가 같은 시스템의 주문에서 생성되었으므로 연령분석이 완전합니다. 영업팀이 말하는 수익과 시산표의 수익은 같은 숫자입니다. 숫자가 하나뿐이기 때문입니다. 이연수익은 누군가 관리하는 일정표가 아니라 인도 기록으로 뒷받침됩니다. 수수료는 원장 데이터로 계산된 청구 또는 회수 금액을 기준으로 발생합니다. 대변표는 취소 대상 청구서와 연결되어, 분쟁이 “수금이 느리다”는 느낌이 아니라 숫자로 드러납니다. Skyline Nexus가 CRM, 판매, 재고, 회계를 하나의 데이터베이스에 두는 이유가 여기에 있습니다. 청구서는 해당 주문에서 생성되고, 수금은 결제 대상 청구서에 적용됩니다.

• 고객 마스터: 식별 정보, 세금 등록번호, 신용한도, 결제조건, 가격표, 통화, 주소.
• 청구서가 실제로 사용할 가격표와 세금 처리 방식을 갖춘 제품 및 서비스 마스터.
• 승인된 할인과 승인자를 메모가 아니라 문서에 저장.
• 재입력 없이 청구서 라인으로 이어지는 주문 라인.
• 인식 시점을 결정하는 인도일과 수락일.
• CRM 화면에서 조회할 수 있는 실시간 매출채권 잔액과 연령분석.
• 원래의 영업기회와 연결된 청구서, 수금, 대변표 참조번호.