One ledger, many nodes
Multi-brand revenue is not naturally tidy. A single transaction can belong to a location, roll up to a region, and owe a royalty to the brand. The platform's answer is one shared ledger: every amount is recorded once, with its hierarchy context attached, and splits are expressed as additional ledger entries — never as exports someone reconciles later.
How a split flows
- Record. The transaction lands on the ledger with its brand and location context.
- Evaluate. Split policy attached to the relevant nodes — brand royalty, region share, location retention — is applied to the recorded amount.
- Post. Each split produces its own ledger entry, linked to the source transaction and the policy version that produced it.
- Review. Operators and finance reviewers read the chain from either direction: from a transaction to its splits, or from a node's totals back to the entries behind them.
Split policy is configuration inside the brand's boundary, reviewed like any other financial control. Changing a split ratio changes future entries; history is never rewritten.
Failure posture
The ledger fails safely. When the financial path for a transaction is unclear — missing policy, ambiguous context — the entry is held for operator review rather than posted on a guess. This matches the platform's broader rule for automated royalty & fee tracking: automated when the path is clear, loudly paused when it is not. How the metering side of that ledger is signed and chain-verified is documented at royalty metering & the ledger.
What one ledger removes
The end-of-month stitch. When brand, region, and location totals come from the same entries the transactions produced, there is nothing to reconcile between systems — only exceptions to review inside one.
Boundary
This page describes structure, not terms. No rates, percentages, or contractual splits appear here; those live in your agreements and your authenticated console.