Royalty Reporting Software.

The components of royalty reporting software

• Rate cards and agreement terms. Every agreement’s grant, licensed marks, product categories, territories, channels, term dates, permitted deductions and their caps, advance schedule, guarantee terms and reporting clause, held as structured, dated data rather than as a PDF someone re-reads each quarter. Amendments are versioned by effective date so a prior period recomputes under the rate that applied when it was filed. On its contract management page, Royalty Reporting describes this as rate card versioning with effective dates, amendment tracking with audit notes, and advance schedules, minimum guarantee terms and audit clauses living alongside the rate card.

• The sales feed and product-to-agreement mapping. Sales, returns and credit memos arrive from the order, ERP or point-of-sale system; the product master says which styles carry which marks; the customer and channel mapping says which rate and which deduction stack apply. Many wrong royalties start here rather than in the arithmetic — a style mapped to the wrong property, a channel left unclassified, a new school never added to an agreement. The system’s job is to make an unmapped or stale line visible before the period closes rather than after the auditor finds it.

• The calculation engine. A rate resolved per transaction by licensor, property, product category, channel, territory, mark type and date, applied to a net sales base built under that agreement’s own deduction stack. A single agreement can carry flat, tiered, category-specific, channel-differentiated, per-unit and greater-of terms at once, and a cooperative mark resolves one sales line to two agreements, each computing on its own base. Royalty Reporting’s royalty calculation page describes per-licensor rate cards that model flat, tiered, mark-type and product-category variation natively, with recompute history preserved at the calculation level.

• Deductions and returns handling. Which deductions the agreement permits, in what order, with what cap, against what base — and, when a unit sold in March comes back in June, a credit attributed to the period and rate of the original sale rather than netted against whatever sold this month. Returns lag is a frequent source of a plausible wrong number in apparel, because the statement total still looks reasonable. Royalty Reporting treats returns lag as a first-class concept: a unit sold in one period and returned in a later one trues up the royalty owed without breaking prior-period statements.

• Minimum guarantee, advance and recoupment tracking. An advance balance drawn down as royalties are earned; a guarantee measured at the boundary the contract sets — contract year, full term, or a cross-collateralized pool of properties; a shortfall that becomes payable when earned royalty does not reach the floor. These are running positions carried between periods, not a period calculation, and how an advance and a guarantee interact is contract-specific. Royalty Reporting’s advance recoupment page describes advance schedules and guarantee terms modeled at the contract level, earned royalties amortizing the balance as sales post, and earn-out position per licensor.

• Statement generation in licensor formats. The statement in each licensor’s mandated layout — line-item granularity by school, team, event or property; the category and channel breakdowns; gratis schedules; attributed adjustments; the certification — in the file format that licensor actually accepts. One calculation becomes a dozen differently shaped submissions, and reformatting is work the arithmetic does not predict. Royalty Reporting’s statement generation page describes per-licensor statement templates, tie-out from statement totals back to the underlying calculations, and statement versions preserved per period.

• Accrual and general-ledger reconciliation. Royalty-reported net sales explained against booked revenue line by line, royalty expense tied to the statement, the accrued payable and any advance asset rolled forward to net due. Contract net sales and GL revenue are computed under different definitions over different populations, so the two are supposed to reconcile, not match. How postings reach the ledger is an integration question to settle against your own accounting system rather than an assumption to make from a feature list.

• Audit trail and recompute history. The original calculation, every recompute, the rate card version in force, the statement version issued and the user activity behind each change, retained for the lookback the audit clause grants — which usually outlives the agreement. A period that cannot be re-performed from its own inputs gets settled on the auditor’s reading of the contract. Royalty Reporting’s audit trail page describes recompute history as immutable — adjustments add to the history rather than overwrite it — with statement versions persisting per period and user-activity logs capturing who changed what and when.

• Multi-licensor and multi-currency. A dozen agreements are not one agreement twelve times over: each carries its own calendar, net-sales definition, statement format and audit cycle. Sales settled outside the contract currency need a stated conversion source and date carried on the line, not applied once at the total. Royalty Reporting’s statement generation page describes multi-licensor reporting periods that do not collide — a March monthly statement to CLC and a Q1 quarterly statement to MLB Properties both generating from the same underlying calculation history.