잔액은 있는데 이력이 없다: 결제에 원장이 필요한 순간

판매자 관리 화면의 셀러 잔액이 100유로였다가 70유로가 되었습니다. 개발자는 "환불 후에 잔액을 수정했다"고 설명합니다. 재무팀은 묻습니다. 어떤 환불이고, 누가 승인했으며, 왜 30유로인가요? 그 답이 대화방에만 있다면, 화면의 숫자는 이미 검증 가능한 결과가 아닙니다. 그저 돈에 대한 누군가의 마지막 의견이 되었을 뿐입니다.

내부 원장은 제품이 채무와 여러 유형의 자금 이동을 관리하는 곳에 필요합니다. 원장의 역할은 금액마다 변경 사유, 관련 당사자, 근거를 보여 주는 것입니다. 아래에서는 운영 모델을 살펴봅니다. 회계 분개 체계, 세무 처리, 보관 요건은 담당 전문가와 별도로 정해야 합니다.

여러분의 잔액은 정확히 무엇을 뜻하는가

화면이 답하겠다고 약속하는 질문에서 시작하세요. "판매자에게 얼마를 지급해야 하는가", "지금 얼마를 지급할 수 있는가", "PSP에 얼마가 있는가"는 서로 다른 값입니다. 이를 한 단어로 부르면 개발팀은 틀렸다고 생각하는 숫자를 고치게 되지만, 실제로 그 숫자들은 서로 다른 질문에 답하고 있습니다.

제안하는 모델은 확정된 채무, 지급 가능성에 대한 제한, 실제 자금 이동을 따로 저장합니다. 보류는 채무를 소멸시키지 않으면서 지급 가능 금액을 줄일 수 있습니다. 전송된 지급 요청도 문서화된 결과가 필요합니다. 각 지표의 정의는 내역과 함께 고객지원팀이 볼 수 있어야 합니다. 어떤 기록이 합계에 들어가고 왜 들어가는지입니다.

복식부기는 가치 이동의 정합성을 점검하는 데 도움이 됩니다. 거래의 차변과 대변이 일치해야 하기 때문입니다. TigerBeetle 문서는 이 원리와 함께, 계정 유형에 따라 증감 부호가 달라진다는 점을 설명합니다. 이것은 통제 장치이지, 경제적 분류가 옳다는 자동 증명은 아닙니다.

100유로짜리 가상의 결제 한 건

마켓플레이스의 합의된 모델이 확정된 결제를 이렇게 배분한다고 합시다. 판매자 몫은 97유로, 플랫폼 수수료는 3유로입니다. PSP는 플랫폼 비용 2유로를 별도로 공제합니다. 학습용 예시이므로 세금, 리저브, 기타 공제는 제외합니다.

이 이벤트들이 끝나면 플랫폼이 PSP에 대해 가진 채권은 98유로입니다. 판매자에 대한 채무는 97유로입니다. 기타 비용 전 플랫폼의 경제적 결과는 1유로입니다. 등식으로 확인할 수 있습니다. 98 = 97 + 1. 판매자 화면에 98이 표시되었다면, PSP에 있는 돈과 판매자에 대한 채무를 섞었을 가능성이 큽니다.

이제 판매자 몫 97유로 중 20유로가 사전에 합의된 근거에 따라 일시적으로 제한됩니다. 지급 가능 금액은 77유로지만, 판매자에 대한 전체 채무는 여전히 97유로입니다. 제한이 풀리면 지급 가능성이 돌아올 뿐, 새로운 매출이 생기지는 않습니다. 제품 모델이 보류를 다르게 해석한다면 계산을 예시에 끼워 맞추지 말고 그 점을 명시적으로 반영해야 합니다.

기록마다 거래 번호, 통화, 근거, 이벤트 발생 시각, 등록 시각, 원 결제와의 연결을 저장하세요. 두 시각은 구분하는 편이 좋습니다. 어제 일어난 일에 대한 메시지가 오늘 도착할 수 있기 때문입니다. 회계 기간 귀속 정책을 합의해 두지 않으면, 야간 배치가 이미 제출된 리포트를 아무도 모르게 바꿔 놓습니다.

정정은 흔적을 남긴다

이 모델에서 잘못된 기록은 흔적을 지우는 대신 연결된 조정 기록으로 바로잡습니다. 사슬을 따라가면 최초 이벤트, 발견된 오류, 승인된 정정이 보입니다. 조정 기록에는 작성자, 사유, 승인이 있습니다. 그래야 다른 직원도 개발자의 개인 채팅에 접근하지 않고 전체 그림을 재구성할 수 있습니다.

하지만 변경 불가능한 로그도 잘못된 데이터를 깔끔하게 보관할 수 있습니다. 결제가 엉뚱한 판매자에게 귀속되었다는 사실을 로그가 스스로 알아차리지는 못합니다. 그래서 거래 귀속 검사, 허용된 상태 전이 검사, PSP 및 은행과의 독립적인 대사가 필요합니다. 합계 일치는 일부 오류를 찾는 데 도움이 되지만, 서로 상쇄되는 두 오류는 전체 합계를 0으로 유지할 수 있습니다.

수동 정정에 대한 운영 규칙은 이렇습니다. 실행 전에 예상 효과를 보여 주세요. 어느 참여자의 어떤 금액이 바뀌는가? 지급 가능 금액은 어떻게 달라지는가? 정정이 다음 리포트에 어떻게 나타나는가? 중요한 작업에는 합의된 권한과 두 번째 직원의 확인을 적용하세요.

센트와 통화도 모델의 일부다

명시적인 환전 거래 없이 유로와 달러를 한 계정에 합치지 마세요. 통화와 금액의 단위(자릿수)를 함께 저장하세요. Stripe API에서 금액은 보통 최소 화폐 단위로 지정하지만, 일부 통화와 지급에는 별도 규칙이 적용됩니다. Stripe 금액 형식 규칙을 보면 일괄적으로 "100을 곱하는" 방식이 왜 위험한지 알 수 있습니다.

자체 모델에서는 정확한 수치 표현 방식과 경계마다의 반올림 규칙을 정하세요. 1유로를 세 참여자에게 나누는 학습용 테스트라면 남는 1센트를 설명할 수 있어야 합니다. 처리 순서에 따라 아무 참여자에게나 그 1센트를 준다면, 재무 결과가 매번 달라지는 불안정한 시스템이 됩니다.

논란이 되는 잔액 하나에서 시작하라

실제 거래 유형 하나를 고르되, 설계에는 인위적 데이터를 사용하세요. 이미 계산된 balance 필드를 읽지 않고 기록만으로 잔액을 재현해 보세요. 그다음 이벤트 중복, 늦게 도착한 리포트, 부분 정정, 지급 가능성 제한을 추가하세요. 여러 직원이 각자 계산해도 설명 가능한 같은 금액이 나온다면, 모델이 작동하기 시작한 것입니다.

대사는 우리 기록이 외부 데이터와 일치하는지에 답합니다. 원장은 애초에 왜 누군가에게 그 금액을 지급해야 한다고 보는지에 답합니다. 두 번째 질문 없이 첫 번째 작업만 하면 매일 숫자를 끼워 맞추는 일로 변하기 쉽습니다.