재무 계층

(섹션: 운영 및 관리)

1) 목적

재무 계층은 법인 및 지불 흐름에서 원장 계정 및 서명 권한에 이르기까지 누가/어디서/무엇을/어떻게 고려해야하는지에 대한 공식화 된 구조입니다. 다음을 제공합니다

지역/통화 별 통합 회계 및 통합 방법;

예측 가능한 P2P/O2C/R2R/세금 프로세스

권한 관리 및 SoD/규정 준수;

폐쇄 속도 및 감사.

2) 엔티티 분류

법률 기관: 거주, 라이센스, 통화, 부가가치세/세금, 은행 계좌.
사업부 (BU/Tenant): 제품/채널 (카지노, 스포츠 북, 라이브, 결제).

• 수익 (RC): 컨텐츠 제공 업체, 결제 서비스, 확장 시장.
• 비용 (CC): 플랫폼/SRE, 마케팅, 규정 준수, 지원.
• 투자 오브젝트 (계정/프로젝트): 데이터 플랫폼, CNC/에지, 지리 출력.
• 파트너: 공급자, PSP/KYC, 계열사, 애그리 게이터.
• 고객: 운영자/테넌트, 최종 사용자 (원장 골재).
• 계정/지갑: 결제, 에스크로, 청산, 신뢰할 수있는 (양육권).

3) 계정 차트 (CoA) 및 측정

1. 자산 (돈, 플레이어 예금, 미수금, 에스크로, 선불).

2. 부채 (플레이어 잔액, 지연된 수입/보너스, 채권자, 세금 납부).

3. 자본.

4. 수익 (GGR/Rischeir, 커미션, 구독/API 요금).

5. 비용 (컨텐츠 로열티, 처리, 호스팅/탈출).

6. 운영 비용 (마케팅, 급여, 규정 준수, 감사, 법률).

필요한 치수 (치수): '법률 _ 엔터티', '지역', '통화', '제품', '테넌트', 'rc/cc', '프로젝트', '파트너', '계약 _ 버전', 'tax _ rule _ version', 'fx _ 버전'.

4) 원장 스택

• 지불 (승인, 청산, 반품, 청구).
• 지갑/플레이어 (밸런스, 예금, 결론, 보너스 의무).
• 콘텐츠/수익 공유 (라운드/제공 업체, GGR/NetWin, 로열티).
• 제휴 (변환, 귀속, 발생).
• General Ledger (GL) -ETL/Combort를 통한 하위 원장의주기적인 게시물 → 완전성/중복 제어 기능이있는 게시.
• 통합: 회사 간 제거, 이전 가격, 프리젠 테이션 통화로의 이전 (그룹 통화).
• 큐브보고: 관리 쇼케이스 (측정 별 P & L/BS/CF).

5) 통화 및 달력의 계층

법인 수준의 기능 통화, 보고를위한 그룹 통화.
FX 정책: 각 트랜잭션의 코스 소스, TWAP/중앙값, 'fx _ 버전'.
달력: 재무 (4-4-5/ISO), 세금 (국가 별), 운영 (클리어 슬라이스).

6) 권한 매트릭스

서명 한도: 법인/계정/통화 별; 지불/에스크로에 대한 2 개의 서명/M-of-N.
지출 제한: CC/프로젝트 (월/분기) 별 OPEX/CAPEX, 편차 규칙.
수익 계약: 역할 별 할인/리베이트 임계 값.
SoD: "결제를 만듭니다" "계약에 동의합니다" "표시".

7) 재무부와 유동성

계정의 계층: 운영, 청산, 에스크로, 세금, 급여.
현금 풀링: 밴드 별 물리적/표기법; 대출 한도.
투자/준비금: 유동성 캠페인 정책, 계약.
DDS 예측 (13 주): 제품/지역 별 수신, 발신 (로열티, 세금, 자본).

8) 회사 간

그룹 내 서비스: 충전으로 호스팅/플랫폼/라이센스 (비용 + 마크 업).
제거: 그룹 내 소득/비용, 대출/이자.
이전 가격: 정책 및 시장 마크 업 범위; 국가 수준의 문서.
IC 조정: 영수증/서명이있는 월별 합의.

9) 세금 및 규제

간접 (VAT/GST): 모드 온/오프, MOSS/OSS, 서비스 장소.
직접: 법인에 대한 소득 세율, R&D 혜택.
게임/특별 요금: 세그먼트 별 베팅 (카지노/스포츠), 보고.
인증서/RNG/라이센스: 아티팩트 스토리지 요구 사항.
세금 등록기: 하위 원장과 세금 신고서 비교.

10) 수익 인식

카지노 (GGR/Net Gaming Revenue): 인식의 순간-베팅의 라운드/클로징 결과.
커미션/구독/API: 규정/구독시; 이연 소득 → 상각.
프로모션/보너스: 정책 및 GAAP/IFRS에 의한 수익 감소 또는 마케팅.
파산/이연 부채: 미사용 보너스/잔액.

11) 폐쇄 프로세스 및 캘린더

O2C (Order-to-Cash): 인용 → 송장 → 영수증 → 지불 분포.

P2P (Procure-to-Pay) PO → → 음성 영수증 → 지불

R2R (Record-to-Report): 서브 레저에서 게시 → 조정 → 조정 → 보고.
세금: 법인에 대한 선언의 계산/조정/제출.
닫기 캘린더: D + 1 - 서브 리더 차단; D + 3 - IC 조정; D + 5 - 예비 P & L/BS; D + 7 - 관리; D + 10-그룹 보고서.

12) 통제, 감사 및 확률

코드 별 정책: 트랜잭션 템플릿, 제한, 승인 경로 (Git/CI).
영수증: 합의 서명 (제휴사, 제공자, 지불), Merkle 섹션의 레지스터.
CoA 변경/서명 권한 등록: WORM 로그, DSSE.
조정: 은행/지갑, IC, subledzhery → GL, GL → otchetnost.
외부/내부 감사-아티팩트 액세스, 샘플 제어.

13) 데이터 모델 (단순화)

'엔터티' '{id, 국가, 라이센스 [], 함수 _ 통화}'

'bu' '{id, 엔티티 _ id, 제품, 테넌트}'

'계정' '{coa _ 코드, 이름, 유형, 상위 _ 코드}'

'차원' '{이름-> 값}'

'subledger _ entry' '{id, source, whileat. _ at, 통화, 금액, fx _ version, dims {}, 수령 _ hash, 서명}'

'gl _ entry' '{id, posted _ at, dr _ secret, cr _ secret, 금액, 통화, dims {}, source _ ids []}'

'ic _ congress' '{엔티티 [], 마크 업, 용어}'

'Authority _ rule' '{scope, limited, m _ of _ n, ttl}'

'bank _ Account' '{entities _ id, iban, 통화, 서명자 [], 한계}'

'tax _ rule' '{관할권, 유형, 요율, 유효 _ from, 버전}'

14) RACI (핵심 영역)

15) 측정 및 SLO

가까운 시간: D + 7 관리, D + 10 그룹 (규정 준수 목표 95% 이상).
조정 속도: 99 이상. 서브 레지저의 9% 가 불일치없이 종료되었습니다> X.
IC 일치: 100% IC 쌍이 D + 5에 닫힙니다. 열기 - <0. 매출의 5%.
현금 예측 정확도 (4-не): MAPE λ10-15%.
늦은 포스팅: <0. "소프트 클로즈" 후 1%.
감사 아티팩트: 청구서 완전성 중요한 흐름의 경우 99%.

16) 대시 보드

그룹/법률 단체: P & L/BS/CF, 통화 효과, 세금, 계약.
운영: 제품, 로열티, 처리/탈출, LTV/CAC 별 GGR/NetWin.
재무부: 현금 인출/현금 인출, 수령 가능한 수취인/수취인, 계좌 한도, 상대방 위험.
결산: 조정 상태, IC- 매트릭스, 게시 오류, SLA 명령.
제어: 제한 트리거링, SoD 위반, 서명 로그.

17) 위험 및 반 패턴

법인 간 중복 CoA/측정 → 보고 불가능 성.
IC 프로세스 부재 → "행맨" 및 기간 종료시 수동 조정.
무제한 서명 권한/M-out-N → 운영/사기 위험.

(PHP 3 = 3.0.6, PHP 4)

아티팩트가없는 수동 게시물 → 감사 복원력.
플레이어의 의무 혼합 및 자금 → 규제 위반.

18) 구현 점검표

1. CoA 및 측정 라이브러리를 정규화하십시오. 저장소에 전념하십시오

2. 엔티티 계층 및 BU/테넌트 관계, RC/CC를 정의하십시오.
3. 하위 원장 (지불/지갑/컨텐츠/계열사) 및 게시 흐름을 GL로 설정하십시오.
4. FX/Tax 버전 및 통합/번역 정책을 입력하십시오.
5. 지불/에스크로에 대해서는 Authority Matrix, SoD 및 M-of-N을 설명하십시오.
6. 재무부 조직: 계좌 카드, 현금 풀링, 13 주 예측.
7. IC 프로세스 및 TP 정책 시작; 영수증과 매월 조정.
8. 닫기 달력 수정; 조정 및 경고를 자동화하십시오.
9. 코드 정책 사용 및 WORM 변경 로그 (CoA/제한/서명) 사용.
10. 대시 보드 구축: Close, Treasury, IC, Revenue, Control.

19) iGaming/fintech의 특성

플레이어/지갑: 잔액 및 보너스 의무-별도의 책임 계정.
GGR/로열티: 서명 된 보고서에서 콘텐츠 제공 업체와 월간 조정.
지불/요금 환급: 채널/ASN 별 PSP 수수료 계정, 반품 제공.
제휴: 서명 된 웹 후크를 통한 귀속; 분쟁 기간 동안 에스크로.
라이센스/규제 기관: 개별 법인/계정, 지역보고 및 아티팩트 저장.

20) FAQ

국가별로 다른 CoA가 필요합니까?
단일 그룹 CoA + 로컬 매핑 (로컬 계정 → 그룹) 이 더 좋습니다.

코스 및 세금 버전을 어디에 저장해야합니까?

버전이 포함 된 별도의 참조 영역에서; (PHP 3 = 3.0.6, PHP 4)

폐쇄 속도를 높이는 방법?
자동 점검, "소프트 클로즈", D + 1 서브 리더 차단, 표준화 된 조정, "템플릿 외부의 수동 게시물 없음" 정책.

지불을 통제하는 방법?
M-of-N 서명, 결제/일/계정 제한, 역할 분리, 은행 영수증 및 GL 일치.

요약: 금융 계층은 관리 회사의 골격입니다: 정규화 된 CoA 및 치수, 통합 된 하위 원장 및 통합, 명확한 권한 및 한계, FX/세금 버전 규율 및 입증 가능한 인공물. 한 번만 빌드하고 제품, 지역 및 파트너간에 빠른 폐쇄, 투명한 제어 및 확장 성을 얻으십시오.