AWS Marketplace 매출이 증가하는데도 은행 피드가 여전히 inexplicably 작게 보일 수 있습니다. 이것이 반드시 가격 문제는 아닙니다. 종종 보고 문제입니다: 고객이 특정 날짜에 청구되고, AWS가 나중에 인보이스를 수금하며, 수수료가 차감되고, 세금이 다른 시나리오로 처리될 수 있으며, 결과 현금은 이후 은행 명세서에 도착합니다.
AWS Marketplace를 통해 판매하는 소프트웨어 회사의 경우, 예금은 판매 자체가 아니라 여러 이벤트의 최종 결과입니다. 신뢰할 수 있는 장부 관리 프로세스는 총거래를 보존하고, 마켓플레이스 수수료와 세금 처리를 기록하고, 환불을 추적한 다음, 순 지급액을 은행과 조정합니다. 이러한 레이어가 분리되면 마진, 매출, 수취채권, 현금 예측을 훨씬 더 신뢰할 수 있게 됩니다.
AWS Marketplace 예금이 매출과 같지 않은 이유
가장 흔한 실수는 각 은행 예금을 판매 수익으로 기록하는 것입니다. 이 지름길은 네 가지 질문을 숨깁니다:
- 고객이 실제로 무엇을 구매했으며, 어떤 오퍼로 구매했는가?
- AWS가 등록 수수료로 얼마를 차감했는가?
- 세금이 AWS에 의해 징수되었는가, 징수되어 판매자에게 전달되었는가, 아니면 판매자가 계산하고 납부해야 하는가?
- 이 특정 예금을 구성하는 인보이스, 환불, 크레딧, 이전 기간 활동은 무엇인가?
AWS Marketplace 보고는 이러한 질문에 답하는 데 필요한 구성 요소를 제공합니다. 수금 및 지급 대시보드는 총매출, 총환불, 등록 수수료, 등록 수수료 환불, 판매자 세금 몫, AWS 세금 몫, 판매자 순매출, 지급 세부 정보를 구분합니다. 또한 운영 보고서를 회계 기록에 연결하는 데 사용할 수 있는 인보이스 ID, 오퍼 ID, 계약 ID, 거래 참조, 은행 추적 ID를 제공합니다.
결과는 중요한 회계 원칙입니다: 거래 수준에서 경제 활동을 기록한 다음, 예금을 조정 대상으로 사용하십시오. 현금은 돈이 이동했다는 증거입니다. 왜 이동했는지를 설명하기에는 충분한 증거가 아닙니다.
마켓플레이스 흐름을 위한 계정과목표 구축
모든 고객에 대해 별도 계정이 필요하지는 않지만, 플랫폼 활동을 계속 보이게 할 수 있는 충분한 구조가 필요합니다. 유용한 출발점은 다음과 같습니다:
매출 및 매출 차감 계정
- AWS Marketplace 총매출
- AWS Marketplace 환불 및 크레딧
- 할인 또는 계약 양보 (총 보고 금액에 이미 반영되지 않은 경우)
SaaS 계약 기간에 걸쳐 매출을 인식하는 경우, 마켓플레이스 청구 이벤트를 매출 인식 일정과 분리하여 유지하십시오. 마켓플레이스 인보이스 날짜와 서비스 기간은 동일한 회계 날짜가 아닐 수 있습니다.
클리어링 및 대차대조표 계정
- AWS Marketplace 수취채권 또는 미지급 수금
- AWS Marketplace 지급 클리어링
- 고객 예금 또는 이연 수익 (해당되는 경우)
- 환불 지급 또는 환불 클리어링
- 판매세 또는 VAT 지급 (세금 프로세스에서 요구하는 경우 관할 구역별로 분리)
비용 및 공제 계정
- AWS Marketplace 등록 수수료
- 등록 수수료에 부과되는 VAT 또는 기타 세금 (해당되는 경우)
- 리셀러가 포함된 오퍼에 대한 채널 파트너 또는 도매 비용
- 지급과 결제 사이에 발생하는 은행 수수료 또는 외환 차이
정확한 계정 이름보다 일관성이 더 중요합니다. 장부 관리 시스템은 "이번 달에 발생한 총 Marketplace 매출은 얼마이고, 미지급 금액은 얼마이며, 플랫폼이 보유한 금액은 얼마인가?"라는 질문에 단일 순 예금에서 답을 재구성하지 않고도 답할 수 있게 해야 합니다.
단일 Marketplace 총액이 아닌 오퍼 수준 차원 사용
AWS Marketplace에는 공개 오퍼, 프라이빗 오퍼, 엔터프라이즈 계약, SaaS 계약, 사용량 기반 제품, 채널 파트너 프라이빗 오퍼가 포함될 수 있습니다. 이들의 가격, 시기, 수수료, 세금, 갱신 행동이 다를 수 있습니다.
판매 또는 분개 가져오기 프로세스에서 최소한 다음 차원을 추적하십시오:
- 제품 이름 및 제품 ID
- 오퍼 ID 및 오퍼 공개 여부
- 계약 ID
- 고객 또는 지불자 식별자
- 인보이스 ID 및 인보이스 날짜
- 사용 기간 시작 및 종료 날짜
- 통화
- 판매자 또는 중개 법인 (해당되는 경우)
오퍼 ID는 특히 가격 분석에 유용합니다. 하나의 프라이빗 오퍼에 협상된 할인 또는 다른 지불 일정이 포함된 경우, 이를 공개 목록 매출과 결합하면 건강한 오퍼가 수익성이 없어 보이거나 실제로 약한 오퍼를 숨길 수 있습니다.
계약 ID는 계약 연속성에 유용합니다. 업그레이드, 갱신 또는 수정은 기존 인보이스가 변경되지 않은 채로 미결제 지불 조건을 대체할 수 있습니다. 이는 현재 계약의 변경이 장부의 이력을 자동으로 다시 쓰지 않는다는 것을 의미합니다.
분개 패턴: 총액 먼저, 현금 나중에
다음 예제는 흐름을 보여주기 위해 간단한 숫자를 사용합니다. 공개 SaaS 오퍼가 한 기간에 $10,000의 총 청구액을 생성하고 적용되는 등록 수수료가 3%라고 가정합니다. 지금은 세금, 환불, 외환 효과를 무시합니다.
청구 또는 수익 인식 단계에서 다음을 기록합니다:
차변 AWS Marketplace 수취채권 10,000
대변 AWS Marketplace 매출 10,000등록 수수료가 인식되거나 정산에서 차감될 때:
차변 AWS Marketplace 등록 수수료 비용 300
대변 AWS Marketplace 수취채권 300AWS가 잔액을 수금하고 지급할 때:
차변 AWS Marketplace 지급 클리어링 9,700
대변 AWS Marketplace 수취채권 9,700은행 예금이 나타날 때:
차변 운영 은행 계정 9,700
대변 AWS Marketplace 지급 클리어링 9,700실제 장부에서 분개 시기는 매출 인식 정책, 회계 기준, 법인, 세금 처리에 따라 달라집니다. 패턴이 중요한 이유는 수수료를 계속 보이게 하기 때문입니다. $9,700 예금만 매출로 기록하면 총매출이 과소 계상되고 등록 수수료가 설명할 수 없는 수익 감소로 사라지게 됩니다.
AWS의 등록 수수료 일정은 제품 및 오퍼 유형에 따라 다릅니다. 예를 들어, AWS는 SaaS, 서버 제품, 데이터 오퍼, 프라이빗 오퍼, 채널 파트너 프라이빗 오퍼, 전문 서비스에 대해 다른 표준 요율을 문서화합니다. 회계 자동화에 하나의 백분율을 하드코딩하지 마십시오. 보고된 수수료 금액을 가져오고 보고된 백분율을 확인용으로 유지하십시오.
세금을 추측이 아닌 식별할 시나리오로 취급
마켓플레이스 세금 처리는 구매자의 세금 주소, 제품 유형, 판매자 위치, 마켓플레이스 촉진자 규칙에 따라 달라집니다. 청구 이벤트 데이터는 최소한 세 가지 광범위한 패턴을 구분할 수 있습니다:
- AWS가 세금을 징수하고 납부합니다. 이는 AWS 세금 몫 이벤트로 표시되며 판매자에게 지급되는 금액을 증가시키지 않습니다.
- AWS가 세금을 징수하고 판매자의 정산에 포함하며, 판매자가 이를 납부합니다. 이는 판매자 세금 몫 이벤트로 표시됩니다.
- AWS가 세금을 계산하거나 징수하지 않으며, 판매자가 계산하고 납부할 책임이 있습니다.
이러한 패턴은 서로 바꿔 쓸 수 없습니다. 세금 금액이 단지 정보 제공용이고 판매자 잔액에 영향을 미치지 않는 경우, 이를 매출이나 현금에 추가하지 마십시오. 세금이 판매자에게 지급되는 경우, 이를 매출이 아닌 세금 지급 계정으로 처리하십시오. AWS가 징수하지 않은 세금에 대해 판매자가 책임이 있는 경우, 자체 인보이스 또는 세금 엔진을 통해 부채를 생성하고 Marketplace 예금 외부에서 조정하십시오.
세금 증거를 거래와 함께 보관하십시오. 구매자 지역, 제품, 오퍼, 인보이스, 세금 몫 유형, 금액, 신고 관할 구역 또는 해당 필드가 포함된 보고서 참조를 저장하십시오. 거래 수준 지원이 없는 세금 요약은 방어하기 어렵고 수정하기 어렵습니다.
환불 및 크레딧을 원래 오퍼에 조정
환불은 단순히 음수 은행 예금이 아닙니다. 총매출을 역분개하고, 등록 수수료를 부분적으로 역분개하고, 세금 금액을 줄이고, 향후 지급을 변경할 수 있습니다. AWS는 판매자 워크플로의 일부에서 환불을 청구 조정이라고 하며, 취소가 이미 발행된 인보이스를 반드시 취소하지는 않습니다.
모든 환불 또는 크레딧에 대해 다음을 캡처하십시오:
- 원래 인보이스 ID
- 청구 기간
- 제품 ID 및 오퍼 ID
- 계약 또는 구독자 참조
- 환불 금액 및 사유
- 등록 수수료와 세금 몫도 역분개되었는지 여부
- 조정이 인보이스, 수금 또는 지급된 날짜
그런 다음 조정을 원래 거래에 사용된 동일한 매출, 수수료, 세금 계정에 적용하십시오. 모든 환불을 일반 "환불 비용" 계정에 게시하면 제품 마진이 왜곡되고 매출 보고서가 AWS의 총액 및 순액 필드와 일치하지 않게 됩니다.
계약 취소는 특별한 주의가 필요합니다. 취소는 계약 상태를 변경하는 반면, 청구 조정은 인보이스를 변경하거나 자금을 반환합니다. 둘 다 필요한 경우 두 작업을 모두 추적하고 영향을 받는 인보이스 라인에 연결하십시오.
월별 지급 조정을 기계적으로 만들기
예금이 이상해 보일 때만 보고서를 다운로드하는 대신 반복 가능한 마감 체크리스트를 사용하십시오.
1. 보고 기간 고정
마감이 인보이스 날짜, 사용 기간, 수금 날짜 또는 지급 날짜를 기준으로 할지 선택하십시오. 이들은 다른 관점입니다. 한 달의 지급 보고서에는 이전에 청구된 인보이스가 포함될 수 있고, 같은 달의 매출 보고서에는 아직 수금되지 않은 인보이스가 포함될 수 있습니다.
2. 상세 보고서 가져오기
인보이스, 오퍼, 계약, 총매출, 환불, 수수료, 세금, 통화, 지급 상태, 지급 날짜, 은행 추적 필드를 가져오십시오. 원래 보고서 파일 또는 불변 내보내기 참조를 보존하십시오.
3. 거래 참조로 그룹화
거래 참조 ID 또는 관련 청구 이벤트 식별자를 사용하여 하나의 거래 패밀리에 속하는 인보이스, 수수료, 세금, 환불, 지급 행의 이중 계산을 방지하십시오. 스프레드시트 피벗 또는 작은 스크립트 가져오기는 중복 라인 항목을 빠르게 노출할 수 있습니다.
4. 미지급 잔액을 미결 수취채권에 연결
수금 대시보드는 수금 및 지급된 자금과 미결 및 미지급 인보이스를 분리합니다. 미지급 잔액을 AWS Marketplace 수취채권과 비교하십시오. 모든 지연을 은행 문제로 취급하지 말고 지불 조건, 고객, 오퍼, 인보이스 연령별로 오래된 잔액을 조사하십시오.
5. 순 지급액을 은행과 일치
보고서의 지급 금액과 은행 추적 ID를 은행 예금과 일치시키십시오. 금액이 다른 경우, 플러그를 게시하기 전에 ACH 타이밍, 통화 변환, 실패한 지급, 환불 활동, 수수료 인보이스 또는 잔액 조정을 확인하십시오.
6. 오퍼별 예외 검토
비정상적으로 높은 환불, 긴 수금 시간, 음수 순매출, 예상치 못한 세금 몫 또는 예상 계약 조건과 다른 등록 수수료 비율이 있는 오퍼를 찾으십시오. 이는 단순한 장부 정리가 아닌 운영 신호입니다.
숫자를 신뢰할 수 없게 만드는 일반적인 실수
예금을 총매출로 게시
이것은 수수료를 숨기고 매출-현금 조정을 불가능하게 만듭니다. 클리어링 계정을 사용하고 총액-순액 다리를 기록하십시오.
고객 인보이스 날짜와 현금 날짜 혼합
이것은 인위적인 월별 변동성을 만들고 수취채권을 잘못 표시할 수 있습니다. 인보이스, 수금, 지급, 서비스 기간 날짜를 구분하여 유지하십시오.
모든 세금 몫 필드를 세금 지급으로 취급
일부 세금 금액은 AWS가 징수하고 납부하며 잔액에 영향을 미치지 않습니다. 거래 유형과 관할 구역별로 분류하십시오.
프라이빗 오퍼 및 수정 무시
프라이빗 오퍼는 협상된 가격과 지불 일정을 가질 수 있습니다. 오퍼 및 계약 식별자를 저장하여 갱신 또는 수정이 잘못된 제품 코호트에 병합되지 않도록 하십시오.
일반 환불 계정 사용
원래 매출, 수수료, 세금 구성 요소를 적절히 역분개하십시오. 환불은 원래 거래를 설명해야 하며, 단순히 다른 곳에서 이익을 줄이는 것이 아닙니다.
은행 피드를 진실의 원천으로 삼기
은행은 정산을 확인할 수 있지만, 어떤 고객, 오퍼, 인보이스, 세금 시나리오 또는 등록 수수료가 현금을 생성했는지 알 수 없습니다. 은행을 Marketplace 보고서에 대해 조정하십시오. 그 반대가 아닙니다.
조정을 관리 보고서로 전환
분개가 구조화되면 제품 및 오퍼별 유용한 운영 지표를 계산하십시오:
- 총 Marketplace 청구액
- 등록 수수료 및 환불 후 순매출
- 오퍼별 환불 비율
- 인보이스에서 수금 및 지급까지 평균 일수
- 연령 버킷별 미지급 수취채권
- 총매출 대비 마켓플레이스 수수료 비율
- 판매자를 위해 징수된 세금 대 AWS가 납부한 세금
- 통화 및 고객 세그먼트별 현금 전환
대시보드는 이러한 추세를 보여줄 수 있으며, 기본 일반 텍스트 원장은 계산을 감사 가능하게 유지합니다. Beancount를 사용하는 경우 각 거래를 인보이스, 오퍼 또는 보고서 식별자에 연결하면 이후 검토가 훨씬 빨라집니다. Fava와 같은 시각화 레이어는 원본 기록을 블랙박스로 만들지 않고 잔액과 차원을 탐색하는 데 도움이 될 수 있습니다. 기술 사용자는 문서에서 가져오기 및 조정 워크플로를 표준화할 수 있는 자연스러운 장소를 찾을 수 있습니다.
재무 관리 간소화
모든 예금이 총매출, 수수료, 세금, 환불, 오퍼로 추적될 수 있으면 AWS Marketplace를 더 쉽게 관리할 수 있습니다. Beancount.io는 투명하고 버전 관리되며 AI 준비된 일반 텍스트 회계를 제공하므로 판매 채널이 늘어나도 재무 데이터를 계속 검토할 수 있습니다.