Client Onboarding
General
This section covers the onboarding of a client who already has:
- Works registered with one or more collecting societies
- Signed publishing contracts with defined shares and terms
- Historical royalty imports that have already been processed and paid
This is the most complex onboarding scenario. The goal is to bring melino into sync with the real-world state of the catalogue without re-triggering actions that have already happened (re-registering works, re-sending statements, re-processing payments).
Recommended Onboarding Sequence
The entity dependency chain must be respected — you cannot create a Contract before its Partner and Works exist, and you cannot import data before Implates are configured.
Step 1 ── Company publishing configuration
Step 2 ── Editions
Step 3 ── Publishing Partners
Step 4 ── Participants & Composers
Step 5 ── Works (with participants and shares)
Step 6 ── Catalogues
Step 7 ── Implates + Explates
Step 8 ── Publishing Contracts (backdated, with opening balances)
Step 9 ── Historical Imports (as closed/locked records)
Step 10 ── Historical Statements (locked, not re-sent)
Step 11 ── Validate current-state alignmentStep 1 — Company Publishing Configuration
Before anything else, configure the Company's Publishing tab. This defines the vocabulary the rest of the module uses.
- Add all Contract Types that appear in the client's existing contracts.
- Add all Distribution Channels present in the client's historical sales data (Streaming, Download, Physical, Sync, etc.).
- Add all Configurations (Exclusive, Non-exclusive, etc.).
- Add all Publishing Sources (one per data-sending partner).
- Enter Society Credentials if CWR submissions will be made.
Why first?
Contract types, channels, and configurations are referenced in contracts and import mappings. Defining them first avoids having to retroactively fix references.
Step 2 — Editions
Create the Editions (imprints) that the client's works belong to, and assign IP Name Numbers.
- If the client operates under a single imprint, one Edition is enough.
- If sub-publishers are involved, create a hierarchy with the main publisher as the parent Edition.
Step 3 — Publishing Partners
Create a Publishing Partner record for every entity that has either sent royalty data to the client or received payments.
Questions to ask the client:
- Do you have a complete list of all partners (distributors, sub-publishers, societies) you've worked with?
- Which partners are income sources only, which are payees only, and which are both?
- Do you have bank details for all payees? (If not, Partners can be created without bank details and completed later — but Statements cannot be fully processed until bank details are present.)
Key fields to confirm per Partner:
- The correct Currency (historical data may mix currencies)
- Publishing Type (distributor, society, licensee, etc.)
- Term Category (quarterly, semi-annual, annual — must match the historical statement cadence)
- Minimum Payout threshold
Step 4 — Participants
Create Participant records for all composers, lyricists, and publishers who appear on works. These must exist before Works can be created with correct share allocations.
Watch out for:
- The same person appearing under slightly different names across different sources (e.g. "John Smith" vs "J. Smith" vs "Smith, John"). Decide on the canonical name before import.
- Publishers who are also Partners — the same entity may need both a Participant record (for work shares) and a Publishing Partner record (for financial settlement).
Step 5 — Works
This is typically the largest data migration task. Works can be entered manually or bulk-imported via Excel.
For bulk import:
- Prepare the Excel file using the Works import template (max 10 MB per file; split large catalogues).
- Include ISWC for every Work that has one — this prevents duplicates if Works are later re-encountered in import files.
- Include GEMA/society work numbers if the client has them — this is critical for matching incoming royalty rows to the correct Work.
- Assign Participants and shares during import where possible.
After import, verify:
- Total shares per Work sum to 100% across all Participants.
- All ISWCs are correctly formatted.
- Work Status is set appropriately (existing registered Works should be Active, not Draft).
- IP Publishing Info Chain territories are correctly defined for Works with complex sub-publishing arrangements.
CWR note
Do NOT trigger a CWR export for Works that are already registered with societies. Doing so would generate NWR (New Work Registration) messages that conflict with existing records. If corrections are needed, use the REV (Revision) message type instead — and only after confirming the society's current record.
Step 6 — Catalogues
Group Works into Catalogues that mirror the structure used in the client's existing contracts.
- If a contract covers "the entire catalogue as of date X", create a Catalogue snapshot as of that date.
- If contracts cover specific named catalogues, replicate those exactly.
- Catalogues are not automatically updated when new Works are added — if a contract is meant to cover "all future works", you will need to update the Catalogue manually each period or assign Works directly to the Contract instead.
Step 7 — Implates and Explates
- Create one Implate per unique partner file format encountered in the historical data.
- Work from actual historical files — map each column header exactly as it appears (including spaces, special characters, and encoding).
- Mark as optional any columns that appear in some files but not others from the same partner.
- Create at least one default Explate that matches the statement format the client has been sending to their partners.
- If the client has been sending different formats to different partners, create one Explate per format.
- Set the correct column widths and number formats — partners who receive statements in a specific format will notice and flag differences.
Step 8 — Publishing Contracts
Create Contracts using the dates, shares, and terms from the signed agreements.
Critical fields for historical Contracts:
| Field | Guidance |
|---|---|
| Valid From | Use the actual contract start date — do not default to today |
| Valid Until | Enter the actual expiry date, or leave blank for open-ended contracts |
| Signing Date | Record the actual signed date |
| Opening Balance | Use this to carry forward any unrecouped advances or pre-existing balances from before the melino migration |
| Advances | Enter only advances that have NOT yet been fully recouped at the time of migration |
| Active | Set to active only for contracts that are still in force |
Questions to resolve per Contract:
- What is the unrecouped advance balance at the migration cutoff date?
- Are there any contracts where shares have changed over the life of the contract? (melino stores one set of terms per Contract — if rates changed, create separate Contract records for each rate period, with non-overlapping Valid From / Valid Until dates.)
- Are there any contracts with minimum guarantee clauses or special recoupment rules that need to be reflected in the terms?
Step 9 — Historical Imports
Decision point: full history or cutoff date?
This is the most important strategic decision in the onboarding:
| Approach | When to use | Trade-offs |
|---|---|---|
| Full history | Client wants a complete audit trail in melino | More work; requires all historical files; all imports must be validated and locked |
| Cutoff date | Client only needs melino for ongoing periods | Faster; but no historical lookup in melino — use Opening Balances on Contracts to carry forward pre-migration state |
| Hybrid | Import the last 1–2 years for reference; use opening balances for older history | Practical middle ground for most clients |
If importing historical data:
- Import files in chronological order, oldest first.
- Set each Import's Year and Term to the actual period the data covers.
- After validation, mark each Import as Checked and Paid (since these have already been settled).
- Set Accountable = false on Imports that should NOT feed into new statement calculations (i.e., already-settled periods).
Exchange rates
Historical imports were processed at the exchange rate at the time — use the actual historical rate, not the current one. Inconsistent rates will make the financial reconciliation unreliable.
Suspended/disputed rows in historical data:
- Rows that were disputed and resolved in the old system should be imported as resolved — do not leave them in a disputed state in melino.
- Rows that were permanently excluded (e.g. a territory the client didn't have rights for) should either be excluded from the import file or marked as resolved disputes with a note.
Step 10 — Historical Statements
For accounting periods that have already been closed and paid:
- Generate the Statement in melino for the period.
- Verify the totals match the client's records from the old system.
- Mark the Statement as Sent with the actual historical send date.
- Lock the Statement immediately — this prevents any accidental recalculation.
Do not export and re-send historical Statements to partners. The lock status is for internal record-keeping only.
Step 11 — Validation Checklist
Before going live with the first active period in melino, run through these checks:
- All Works have an ISWC (or a documented reason why one is absent)
- All Works have Participants with shares that sum to 100%
- All Contracts have correct Valid From / Valid Until dates with no gaps or overlaps
- Opening balances on Contracts match the pre-migration advance ledger
- All historical Imports covering the cutoff period are marked Checked + Paid
- All historical Statements are Locked
- At least one active Implate exists per Partner who will send new data
- At least one Explate is set as Default
- Company publishing configuration covers all channels, configurations, and contract types that will appear in new data
- All Publishing Partners have their Term Category set — this determines which period the next Import will be assigned to
Key Risks & Edge Cases
Works with no ISWC
If historical import files reference works only by title or by a society-specific number (e.g. GEMA Werknummer), you need a reliable matching key. Without an ISWC, the same work might be created twice. Before import, map every title in the historical files to a melino Work ID and include that mapping in the Implate.
Share changes over the contract lifetime
If a contract's royalty rate changed partway through (e.g. rate increased after an advance was recouped), there is no single Contract record that represents the full history accurately. The cleanest approach is to create two Contract records: one for the old rate period (marked inactive, with correct Valid Until), and one for the new rate (with a Valid From matching the change date). Historical Imports should reference the Contract that was active during their period.
Multi-currency historical data
If the client received income in multiple currencies over the years and the exchange rates used were not consistently recorded, the converted totals in melino may not match the client's original records. Agree on a rate source before migration (e.g. ECB monthly average) and apply it consistently.
Advances partially recouped before migration
Recoupment history prior to the cutoff date should be collapsed into the Opening Balance on the Contract (a single net figure), rather than re-entering every individual advance and deduction. Only advances that are still outstanding at cutoff should be entered as Advance records.
Works registered but never generating income
Some works in the client's catalogue may be registered but have never appeared in any import file. These should still be created in melino (they may generate income in the future), but they will not appear in any historical statement. No special handling is needed — they simply will not match any import rows.
Contracts that have already expired
Expired contracts should still be created in melino with their correct dates and marked inactive. They are needed to correctly calculate historical statements for the periods they covered. Without them, melino cannot compute historical payouts.
Partners with no structured file format (ad-hoc reports)
Some partners send royalty reports as unstructured PDF or custom Excel files with no consistent column layout. For these:
- Consider using Use Without Implate on a case-by-case basis, with manual data entry.
- Or standardise the partner's file format going forward and accept that historical data will need to be manually entered or summarised as an opening balance.
Statements that were disputed and re-issued
If a historical statement was disputed by a partner and subsequently corrected and re-issued, import both the original and the corrected version. Lock the original and mark the corrected one as the active record. Add notes to both explaining the relationship.