Search

RDR-R explained

RDR-R is the standard which defines the standard messages for the communication of revenues generated from the usage of releases and/or resources. Such standard messages are typically sent by a music licensing company to the rights controllers and/or administrators and/or performers that the music licensing company represents for rights in sound recordings and/or music videos, and/or other audio-visual resources containing music, and other revenues that have not been directly attributed to a resource. This standard may also be used by music licensing companies to report revenues from royalties collected to other music licensing companies as part of their bilateral multi-territory rights licensing agreement with respect to the rights they administer.

The RDR-R version 1.1 offers an additional method for communicating such revenues over version 1.0.

The standard contains specifications for three messages. These are the RevenueReport (already available in 1.0), and a combination of the RevenueSummary (new) and/or RevenueDetails (new) messages. The two latter messages together enable the communication of the same data as the RevenueReport. The RevenueReport is a much simpler format. It is up to implementers to determine whether they use just the RevenueReport or the other two messages in combination. This may vary depending on the operational capabilities of the receiving business partner.

This approach avoids having to send both summary data and the detailed breakdown data of several different revenue streams in one message using a multi-block flat-file format. Rather, the same data can now be sent in one message (the RevenueReport message) and, in circumstances where the amount of data in such a message would be significant, be split into more than one file as specified in RDR-R 1.1. This enables a cost-effective and simplified way of sending and receiving standardised revenue information by territory, usage type, allocated party contribution role for either rights controller or contributor, to, for example, royalty departments and if necessary, a summary message to, for example, the finance department. This enables existing business processes to remain unchanged.

Distribution, allocation, statemente

As part of the music licensing companies’ revenue collection and payment process the use of terms such as distribution, allocation and statement are frequently used. Consequently, RDR-R also refers to these terms in cell names such as DistributionDate and StatementType.

RDR-R states that “The header Record only permits a single DistributionDate, therefore a RevenueReport message can only relate to revenue being passed on in a single distribution.”

Where a sender is using the combined RevenueSummary and/or RevenueDetails messages, more than one RevenueDetails message may need to be sent to cover a single distribution. This is because the simplified structure of the messages requires individual messages to be sent, the data contained in which is driven by the values for UseType, StatementType and AllocatedPartyContributionRole.

While each data cell is clearly defined in the standard, it is worth noting that internal processes and terms used may vary between companies. This may also be the case with regard to the specifics of the revenue that is being distributed, because each music licensing company may have its own rules about distribution and allocation of revenue for contributors and rights controllers.

It is therefore recommended to always consult with the implementation partners and confirm with those collecting and paying music licensing companies (see Clauses 4.1 and 5.2.2) directly about the meaning of terms and definitions to avoid communication errors.

While the standard defines the data cells, it is useful to view the three terms distribution, allocation and statement as part of a single process with various steps for the collection, allocation and repatriation of revenue related to neighbouring rights. The aggregation of all these steps is usually called a distribution cycle where a statement forms the final step and is the physical manifestation of the distribution before the paying-out process to rights holders may take place. A statement may consist of one or more RDR-R messages files because of the restrictions of what can be communicated in a single message as mentioned above. A statement shows the revenue collected within a distribution cycle but may not always result in a payment, as the final balance may either be positive or negative depending on previously applied advances, deductions or other adjustments. A positive balance may be paid out after the provision of a statement within a distribution cycle, while a negative balance may be carried forward into the next one.

The following should only be used as clarification to distinguish the three terms from each other in the context of revenue reporting as outlined in the standard.

Distribution refers to the process of identifying collected revenue to the rights holders and performers. After revenue is collected from licensees, the distribution cycle involves the calculation, attribution, notification and finally the payment to these parties according to the relevant distribution rules;
Allocation is the process of dividing collected revenue among qualifying rights holders and performers. This calculation is based on factors such as usage data, proxies, and contractual agreements. Each music licencing company follows specific distribution rules relating to how the revenue is allocated between qualifying rights holders and performers; and
A statement is a detailed report provided to rights holders and performers or their representatives, showing the breakdown of revenue due. It usually contains information such as the usage data of their recordings, the revenue allocated to them, and specifics of the revenue collection, along with any deductions, interest, and taxes. If the statement shows a positive balance, a payment to the rights holder maybe issued.

Simple and two-step scenarios for RDR-R

Simple scenario

A music licensing company has collected revenue for a resource and/or release for which it has received a claim and wishes to report and pay these revenues to a recording rights controller, typically a record company.

As outlined in figure 1 of Clause 5 there is one file being sent by the music licensing company to the recording rights controller who is the claimant.

The music licensing company in this use case is both the collecting music licensing company and paying music licensing company. There is no claiming music licensing company in this use case.

In RS02 - Allocated Party Summary Record of the standard, the relevant Cells are called CollectingMlcName, PayingMlcName, ClaimingMlcName as well as CollectingMlcAllocatedPartyId, ClaimingMlcAllocatedPartyId and PayingMlcAllocatedPartyId.

In Scenario 1 as outlined above and in figure 1 of Clause 5 the music licensing company therefore populates the following fields:

CollectingMlcName;
PayingMlcName;
CollectingMlcAllocatedPartyId; and
PayingMlcAllocatedPartyId.

Two-step scenario

In this use case as outlined in Figure 2 of Clause 5, there are at least two music licensing companies involved before one or more recording rights controller are being paid.

A music licensing company (A) has collected revenue for a resources and/ or release for which it has received a claim and wishes to report these revenues to the claiming music licensing company (B).

Music licensing company (B) has received a revenue report from a collecting music licensing company (A) and wishes to report these revenues to a recording rights controller.

This typically occurs between two music licensing companies for international collection and payment of royalties. For example, a local music licensing company has collected revenue data from the local broadcasting company as in Scenario 1 and some of the revenues are being claimed by a music licensing company in a different territory for revenue for a recording rights controller there.

In this use case there are two recipients for this transaction as outlined in Figures 2 of Clause 5:

Music licensing company (claiming music licensing company) that made a claim for the Resource and/or Release to the collecting music licensing company;
Recording Rights Controller that made a claim for the resource and/or release to the paying music licensing company (claiming music licensing company).

In Scenario 2 as outlined above and in Figure 2 of Clause 5 the Cells in RS02 would be populated as follows:

RevenueDeclarationMessage 1:

(from MLC A to MLC B)

`CollectingMlcName`	MLC A
`ClaimingMlcName`	MLC B
`PayingMlcName`	MLC A

RevenueDeclarationMessage 2:

(from MLC B to Recording Rights Controller)

`CollectingMlcName`	MLC A
`ClaimingMlcName`	n/a
`PayingMlcName`	MLC B

Minimum data requirement use case for the RevenueDetails message

For a music licensing company to implement the RDR-R standard to report revenues to a rights controller or contributor, a message could be as simple as the one outlined in Table 2. Here only 21 values in a SRS1 Record would be required to communicate revenues for a sound recording without any deductions. A message with such a SRS1 record would then be linked to a separate summary statement (RevenueSummary message).

To better illustrate what this would look like while maintaining the standard message structure (see Clause 7.9; https://rdrr.ddex.net/recording-data-and-rights-revenue-reporting/7-record-type-definitions/7.9-srs1-%E2%80%93-single-record-revenue-summary-record-(revenuesummary-message)/ ), Table 1 shows the full set of data Cell definitions, data type, cardinality as published in the RDR-R standard, along with examples. Those cells for a Record that are not required for the reporting of sound recordings to a rights controller have been shaded out.

The given use case does not include any contractual/mandatory fields that would be driven by bilateral agreements between business partners, which may include additional data sets such as UsageType, UsageSourceName and RevenuePoolName for example.

A RevenueDetails message sent from music licensing company to music licensing company for sound recordings may look the same as outlined in Table 2. For a message where the StatementType is Contributor however, the bare minimum data set looks slightly different. This also applies to the communication of details about revenues not directly attributable to a resource, which is done using a message where the ResourceType is None. Equally, the data set for sound recordings in audio-visual resources will require different data points all together.

Further details for those requirements are outlined in the standard and further implementation guidance can be acquired by contacting the DDEX Secretariat or directly from the implementation partners.

The following table lists all the Record types for the communication of detailed data about all types of revenues that have been generated (such as for a sound recording and/or music video, and/or an audio-visual resource or release containing music and/or revenues not directly attributable to a resource), reported to a music licensing company or a rights controller.

Those Cell names that have been shaded out are not required to be populated for the use case described above:

RevenueDetails message from music licensing company to rights controller, usually a record company;
StatementType: RightsController;
ResourceType: SoundRecording;
Includes ISRC as per point 3 above;
Per territory and UsageType; and
Sent without an accompanying RevenueSummary message.

Table 2 - SRD1 – Single Record Revenue Details Record (RevenueDetails message)

Cell Name		Field Definition
1	RecordType	The type of the Record which shall always contain the value SRD1.
2	RecordId	The Identifier of this single record revenue retails record which shall be specific to the RevenueDetails.
3	CurrencyOf Accounting	The currency in which the values in the revenue Cells are accounted (represented by an ISO 4217 CurrencyCode).
4	NetRevenueIn CurrencyOf Accounting	The revenue generated from the licensing of sound recordings, music videos and/or audio-visual resources containing music in the CurrencyOfAccounting. This amount is the aggregate of the net revenue amounts that appear in the relevant revenue Cells.
5	SummaryRecordId	The identifier of the SRS1 Record to which this Record provides details to. This Cell is mandatory if a RevenueSummarymessage has been sent.
6	StatementType	The description of the type of the revenue details data being provided in this RevenueDetails message. If a RevenueSummary message has been sent, this Cell will be the same as the SummaryType of the SRS1 Record with the RecordId given by the SummaryRecordIdCell.
7	CollectingMlcName	The name of the collecting music licensing company (for music licensing company to music licensing company to payee use cases).
8	PayingMlcName	The name of the paying music licensing company.
9	ClaimingMlcName	The name of the claiming music licensing company.
10	ClaimingMlc AllocatedPartyId	A proprietary identifier allocated by the claiming music licensing company to the party to whom the relevant revenue has been allocated. This is preceded by a namespace identifier in the syntax ns::id.
11	PayingMlc AllocatedPartyId	A proprietary identifier allocated by the paying music licensing company to the party to whom the relevant revenue has been allocated. This is preceded by a namespace identifier in the syntax ns::id.
12	AllocatedPartyIPN	The International Performer Number allocated to the party to whom the relevant revenue has been allocated. An IPN is an 8-digit integer.
13	AllocatedPartyISNI	The International Standard Name Identifier allocated to the party (whether a legal entity or natural person) to whom the relevant revenue has been allocated.
14	AllocatedParty FullName	The complete name of the party, in its normal form of presentation to whom the relevant revenue has been allocated. This can be a record company if the value in the SummaryType Cell is RightsController, or a party that has contributed to the resource if the value in the SummaryType is Contributor.
15	ResourceType	The type of the resource (sound recordings, music videos and/or audio-visual resource containing music) to which the revenue which is the subject of this Record is allocated. If this Record needs to communicate other types of revenue not directly attributable to a resource the ResourceType should be None.
16	AudioVisualType	The type of audio-visual resource to which is determined by the nature of the content of the audio-visual resource. This Cell is mandatory if the ResourceType is Video.
17	RevenueAllocationType	The functional nature of the audio-visual resource to which revenue has been allocated. This Cell is mandatory if ResourceType is Video.
18	ISRC	The ISRC (International Standard Recording Code as defined in ISO 3901) for the sound recording or music video. An ISRC comprises four parts: two characters, followed by three alphanumeric characters, then two digits and five digits.
19	ISAN	An identifier of the audio-visual resource allocated in accordance with the International Standard Audio-visual Number as defined in ISO 15706.
20	EIDR	An identifier of the audio-visual resource allocated in accordance with the Entertainment Identifier Registry.
21	Proprietary ResourceId	A proprietary identifier allocated by the music licensing company that is the sender of the message to the resource to which the relevant revenue has been allocated. This is preceded by a namespace identifier in the syntax ns::id. Provision of a ProprietaryResourceId is mandatory if there is no ISRC provided.
22	ResourceTitle	The title of the resource if provided. This Cell is mandatory if ResourceType is not None.
23	ResourceSubTitle	A descriptor which is supplementary to, but not contained within, a Title.
24	SeriesTitle	The title of the series of which the audio-visual resource is a part.
25	SeasonNumber	The number of the season of the series of which the audio-visual resource is a part.
26	EpisodeNumber	The number indicating the order of the episodes within a season (if available) or series.
27	Genre	The genre of the work.
28	Resource DisplayArtistName	The name of the display artist of the resource to which the relevant revenue has been allocated as notified to the music licensing company that is the sender of the message by the relevant rights controller. This Cell is mandatory if ResourceType is SoundRecording or MusicVideo.
29	HasMadeFeatured Contribution	A flag indicating whether the party to whom the relevant revenue has been allocated is considered to have made a prominently featured contribution (=true) or not (=false).
30	HasMadeContracted Contribution	A flag indicating whether the party to whom the relevant revenue has been allocated made the contribution to the resource under an exclusive contract with the initial producer (=true) or not (=false).
31	AudioVisual ContributorName	The name of a contributor to the audio-visual resource. This information is purely for the purpose of helping to identify the resource to which revenue has been allocated. This Cell does not specify the party to whom revenue has been allocated for a contribution to the resource. The order of the individual data elements in AudioVisualContributorNameand AudioVisualContributorRole Cellsshall be the same so that the recipient is able to relate them correctly. This Cell is mandatory if a AudioVisualContributorRole is provided.
32	AudioVisual ContributorRole	The description of the roles(s) of the contributor in the AudioVisualContributorName Cell. The number and order of the individual data elements in the AudioVisualContributorName and AudioVisualContributorRole Cells shall be the same so that the recipient is able to relate them correctly. A value in this Cell is mandatory if a AudioVisualContributorName is provided.
33	AllocatedPartyC ontributionRole	The description of the role(s) of the party to whom revenue has been allocated for a contribution to the resource. If multiple roles are to be communicated, multiple SRD1 records must be provided.
34	AllocationShare Percentage	The percentage of gross revenue allocated to the AllocatedPartyFullName in relation to the resource. If the value in the SummaryType Cell is RightsController, the provision of a value in this Cell is mandatory and relates to a record company’s ownership share in that resource. If the value in the SummaryType Cell is Contributor, the provision of a value in this Cell is optional and the percentage of gross revenue is allocated to the AllocatedPartyFullName in relation to the AllocatedPartyContributionRole if provided. A quarter share is represented by “25” (and not 0.25).
35	ICPN	The ICPN used as proxy for identification of the release. An ICPN comprises 12 or 13 digits, depending on whether it is an EAN (13) or a UPC (12). 14 character ICPNs are also permitted.
36	ReleaseCatalog Number	The catalogue number of the release assigned by the issuing record company.
37	AudioVisual ProductionDate	The date when the audio-visual resource was produced, in the ISO 8601 format: YYYY[-MM[-DD]].
38	AudioVisual CreationDate	The date when the audio-visual resource was created, in the ISO 8601 format: YYYY[-MM[-DD]].
39	TerritoryOf RevenueGeneration	The territory in which the revenue was generated. This Cell is mandatory unless ResourceType is None.
40	UseType	A type of usage that a licensee of the relevant music licensing company has made of the resource and for which the revenue has been generated. If multiple UseTypes are to be communicated, multiple SRD1 records must be provided.
41	LicenseeName	The name of the licensee of the relevant music licensing company whose output has generated the revenue.
42	LicenseeId	The PartyId of the licensee the relevant music licensing company.
43	UsageSourceName	The name of the source of usage reporting that has been used to allocate revenue to the resource.
44	UsageSourceId	The PartyId of the UsageSource.
45	AllocationGuidance	A description of the nature of changes that may have occurred to the resource to which the revenue has been allocated. For example, a resource may have been a previously unidentified recording, or a resource was in conflict and this is solved, or the rights controller of a resource has changed).
46	UsageStartDate	The date of the start of the usage period to which the revenue which is the subject of the Record relates, in ISO 8601 format. This is a string with the syntax YYYY[-MM[-DD]]. This Cell is mandatory if ResourceType is not None.
47	UsageEndDate	The date of the end of the usage period to which the revenue which is the subject of the Record relates, in ISO 8601 format. This is a string with the syntax YYYY[-MM[-DD]]. This Cell is mandatory if ResourceType is not None.
48	Recipient RevenueType	A description of the type of revenue that indicates on behalf of whom the revenue was collected. This Cell is mandatory if ResourceType is not None.
49	RevenueSourceType	A type of revenue earned by the resource, according to the way the revenue is generated. This Cell is mandatory if ResourceType is not None.
50	RevenuePoolName	A description of the type of licensee, whether a single licensee or multiple licensees, which forms the source of the revenue being allocated.
51	BasisFor RevenueAllocation	A description of the nature of the data used to determine the distribution of revenue, for example a usage log or a full census.
52	UnitTypeFor RevenueAllocation	The basis applied to each unit of usage as part of the process of revenue allocation which is the subject of this Record. It is possible to have mixed types within a RevenueReportmessage.
53	UnitRate	The rate applied to each unit of usage in the CurrencyOfAccounting.
54	Usages	The number of units of usage of the resource.
55	Reallocation FromNonQualifying Performance	Revenue allocated to a performance which does not qualify for equitable remuneration and is re-allocated to the rights controller.
56	CollectingMlc GrossAmount	The gross amount of revenue collected by the collecting music licensing company's in the CurrencyOfAccounting.
57	PayingMlc GrossAmount	The gross amount of revenue being paid by the paying music licensing company's gross amount in the CurrencyOfAccounting.
58	CollectingMlc Commission	The collecting music licensing company's amount of commission or administrative fee(s) in the CurrencyOfAccounting. This amount is deducted from the CollectingMlcGrossAmount and is therefore a negative number. An adjustment to commission or administrative fee(s), which will be added to the CollectingMlcGrossAmount, can be expressed by using a positive number.
59	PayingMlcCommission	The paying music licensing company's amount of commission or administrative(s) fee in the CurrencyOfAccounting. This amount is deducted from the PayingMlcGrossAmountand is therefore a negative number. An adjustment to commission or administrative fee(s), which will be added to the PayingMlcGrossAmount, can be expressed by using a positive number.
60	CollectingMlcSocialCulturalDeduction	The collecting music licensing company's social and cultural deduction amount in the CurrencyOfAccounting. This amount is deducted from the CollectingMlcGrossAmount and is therefore a negative number. An adjustment to social and cultural deduction(s) to the CollectingMlcGrossAmount can be expressed by using a positive number.
61	PayingMlcSocialCulturalDeduction	The paying music licensing company's social and cultural deduction amount in the CurrencyOfAccounting. This amount is deducted from the PayingMlcGrossAmountand is therefore a negative number. An adjustment to the social and cultural deduction(s) to the PayingMlcGrossAmountcan be expressed by using a positive number.
62	CollectingMlc AdministrationCost Deduction	The collecting music licensing company's deduction for administration costs in the CurrencyOfAccounting. This amount is deducted from the CollectingMlcGrossAmount and is therefore a negative number. An adjustment of the administrative costs to theCollectingMlcGrossAmount can be expressed by using a positive number.
63	PayingMlc AdministrationCost Deduction	The paying music licensing company's deduction for administration costs in the CurrencyOfAccounting. This amount is deducted from the PayingMlcGrossAmountand is therefore a negative number. An adjustment to the administrative costs to thePayingMlcGrossAmount can be expressed by using a positive number.
64	CollectingMlcOther Deduction1	The collecting music licensing company's other deduction amount in the CurrencyOfAccounting. This amount is deducted from the CollectingMlcGrossAmount and is therefore negative numbers. An adjustment of the other deduction to the CollectingMlcGrossAmount can be expressed by using a positive number.
65	CollectingMlcOther DeductionType1	The type of deduction specified in the CollectingMlcOtherDeduction1 Cell. A value in this Cell is mandatory if there is a value in the CollectingMlcOtherDeduction1 Cell.
66	PayingMlcOther Deduction1	The paying music licensing company's other deduction amount in the CurrencyOfAccounting. This amount is deducted from the PayingMlcGrossAmountand is therefore negative numbers. An adjustment of the other deduction to the PayingMlcGrossAmount can be expressed by using a positive number.
67	PayingMlcOther DeductionType1	The type of deduction specified in the PayingMlcOtherDeduction1 Cell. A value in this Cell is mandatory if there is a value in the PayingMlcOtherDeduction1Cell.
68	CollectingMlcOther Deduction2	The collecting music licensing company's other deduction amount in the CurrencyOfAccounting. This amount is deducted from the CollectingMlcGrossAmount and is therefore negative numbers. An adjustment of the other deduction to the CollectingMlcGrossAmount can be expressed by using a positive number.
69	CollectingMlcOther DeductionType2	The type of deduction specified in the CollectingMlcOtherDeduction2 Cell. A value in this Cell is mandatory if there is a value in the CollectingMlcOtherDeduction2 Cell.
70	PayingMlcOther Deduction2	The paying music licensing company's other deduction amount in the CurrencyOfAccounting. This amount is deducted from the PayingMlcGrossAmountand is therefore negative numbers. An adjustment of the other deduction to the PayingMlcGrossAmount can be expressed by using a positive number.
71	PayingMlcOther DeductionType2	The type of deduction specified in the PayingMlcOtherDeduction2 Cell. A value in this Cell is mandatory if there is a value in the PayingMlcOtherDeduction2Cell.
72	CollectingMlcOther Deduction3	The collecting music licensing company's other deduction amount in the CurrencyOfAccounting. This amount is deducted from the CollectingMlcGrossAmount and is therefore negative numbers. An adjustment of the other deduction to the CollectingMlcGrossAmount can be expressed by using a positive number.
73	CollectingMlcOther DeductionType3	The type of deduction specified in the CollectingMlcOtherDeduction3 Cell. A value in this Cell is mandatory if there is a value in the CollectingMlcOtherDeduction3 Cell.
74	PayingMlcOther Deduction3	The paying music licensing company's other deduction amount in the CurrencyOfAccounting. This amount is deducted from the PayingMlcGrossAmountand is therefore negative numbers. An adjustment of the other deduction to the PayingMlcGross Amount can be expressed by using a positive number.
75	PayingMlcOther DeductionType3	The type of deduction specified in the PayingMlcOtherDeduction3 Cell. A value in this Cell is mandatory if there is a value in the PayingMlcOtherDeduction3Cell.
76	CollectingMlcOther Deduction4	The collecting music licensing company's other deduction amount in the CurrencyOfAccounting. This amount is deducted from the CollectingMlcGrossAmount and is therefore negative numbers. An adjustment of the other deduction to the CollectingMlcGrossAmount can be expressed by using a positive number.
77	CollectingMlcOther DeductionType4	The type of deduction specified in the CollectingMlcOtherDeduction4 Cell. A value in this Cell is mandatory if there is a value in the CollectingMlcOtherDeduction4 Cell.
78	PayingMlcOther Deduction4	The paying music licensing company's other deduction amount in the CurrencyOfAccounting. This amount is deducted from the PayingMlcGrossAmountand is therefore negative numbers. An adjustment of the other deduction to the PayingMlcGrossAmount can be expressed by using a positive number.
79	PayingMlcOther DeductionType4	The type of deduction specified in the PayingMlcOtherDeduction4 Cell. A value in this Cell is mandatory if there is a value in the PayingMlcOtherDeduction4Cell.
80	CollectingMlc OtherDeduction5	The collecting music licensing company's other deduction amount in the CurrencyOfAccounting. This amount is deducted from the CollectingMlcGrossAmount and is therefore negative numbers. An adjustment of the other deduction to the CollectingMlcGrossAmount can be expressed by using a positive number.
81	CollectingMlc OtherDeductionType5	The type of deduction specified in the CollectingMlcOtherDeduction5 Cell. A value in this Cell is mandatory if there is a value in the CollectingMlcOtherDeduction5 Cell.
82	PayingMlcOther Deduction5	The paying music licensing company's other deduction amount in the CurrencyOfAccounting. This amount is deducted from the PayingMlcGrossAmountand is therefore negative numbers. An adjustment of the other deduction to the PayingMlcGrossAmount can be expressed by using a positive number.
83	PayingMlcOther DeductionType5	The type of deduction specified in the PayingMlcOtherDeduction5 Cell. A value in this Cell is mandatory if there is a value in the PayingMlcOtherDeduction5Cell.
84	CollectingMlc Interest	The collecting music licensing company's interest amount in the CurrencyOfAccounting. This amount is added to the CollectingMlcGrossAmountand is therefore a positive number. An adjustment of the interest to the CollectingMlcGrossAmount can be expressed by using a negative number. This Cell is mandatory if a value is provided in the CollectingMlcInterestWithholdingTaxCell.
85	PayingMlcInterest	The paying music licensing company's interest amount in the CurrencyOfAccounting. This amount is added to the PayingMlcGrossAmount and is therefore a positive number. An adjustment of the interest to the PayingMlcGrossAmount, can be expressed by using a negative number. This Cell is mandatory if a value is provided in the PayingMlcInterestWithholdingTaxCell.
86	CollectingMlcInterestWithholdingTax	The collecting music licensing company's withholding tax amount for the deduction due to interest in the CurrencyOfAccounting. This amount is deducted from the CollectingMlcGrossAmount and is therefore a negative number. An adjustment, which will be added to the gross amount, can be expressed by using a positive number.
87	PayingMlcInterestWithholdingTax	The paying music licensing company's withholding tax amount for the deduction due to interest in the CurrencyOfAccounting. This amount is deducted from the gross amount and therefore a negative number. An adjustment, which will be added to the gross amount, can be expressed by using a positive number.
88	CollectingMlcRoyaltyWithholdingTax	The collecting music licensing company's withholding tax amount for the deduction due to royalties in the CurrencyOfAccounting. This amount is deducted from the gross amount and therefore a negative number. An adjustment, which will be added to the gross amount, can be expressed by using a positive number.
89	PayingMlcRoyaltyWithholdingTax	The paying music licensing company's withholding tax amount for the deduction due to royalties in the CurrencyOfAccounting. This amount is deducted from the gross amount and therefore a negative number. An adjustment, which will be added to the gross amount, can be expressed by using a positive number.
90	CollectingMlcOtherWithholdingTax	The collecting music licensing company’s withholding tax amount, which may be a cumulative amount that cannot be split up into more specific tax amounts or an amount of a specific type other than interest or royalty tax. This amount is given in the CurrentOfAccounting. This amount is deducted from the CollectingMlcGrossAmount and is therefore a negative number. An adjustment, which will be added to the gross amount, can be expressed by using a positive number.
91	PayingMlcOtherWithholdingTax	The paying music licensing company’s withholding tax amount, which may be a cumulative amount that cannot be split up into more specific tax amounts or an amount of a specific type other than interest or royalty tax. This amount is given in the CurrentOfAccounting. This amount is deducted from the PayingMlcGrossAmount and is therefore a negative number. An adjustment, which will be added to the gross amount, can be expressed by using a positive number.
92	CollectingMlcVAT	The VAT amount of the collecting music licensing company in the CurrencyOfAccounting. This amount is added to the CollectingMlcGrossAmount and is therefore a positive number. An adjustment, which will be subtracted from the gross amount, can be expressed by using a negative number.
93	PayingMlcVAT	The VAT amount of the paying music licensing company in the CurrencyOfAccounting. This amount is added to the PayingMlcGrossAmount and is therefore a positive number. An adjustment, which will be subtracted from the gross amount, can be expressed by using a negative number.
94	NetAmount	The final amount of revenue due following all deductions and/or additions to the relevant music licensing company’s gross amount in the CurrencyOfAccounting

Table 3 - SRD1 – Bare minimum data points per record for the describe use case

Cell Name		Data Type	Example
1	RecordType	Fixed String	SRD1
2	RecordId	String	SRD1_0000001
3	CurrencyOfAccounting	AVS: CurrencyCode	GBP
4	NetRevenueInCurrencyOfAccounting	Decimal	222946.35
6	StatementType	AVS: SummaryType	RightsController
8	PayingMlcName	String	MLC Company X
11	PayingMlcAllocatedPartyId	PartyID	PADPIDA2008120501W::RRH01234
14	AllocatedPartyFullName	String	Record Company Y
15	ResourceType	AVS: ResourceType_RDR	SoundRecording
18	ISRC	String	GBBAD1501120
21	ProprietaryResourceId	String::String	PADPIDA2008120501W::MyTrackId:30261973
22	ResourceTitle	String	Roll over Beethoven
28	ResourceDisplayArtistName	String	DYNAMIC DUET
34	AllocationSharePercentage	Decimal	33.33
39	TerritoryOfRevenueGeneration	AVS: AllTerritoryCode	DE
46	UsageStartDate	Date	2014-12-31
47	UsageEndDate	Date	2014-12-31
48	RecipientRevenueType	AVS: RecipientRevenueType	PerformerOnlyRevenue
49	RevenueSourceType	AVS: RevenueSourceType	PaymentFromUnclaimedRevenue
57	PayingMlcGrossAmount	Decimal	20000
94	NetAmount	Decimal	20000

RDR-R explained

Simple scenario

Two-step scenario

RevenueDeclarationMessage 1:

RevenueDeclarationMessage 2:

Table 2 - SRD1 – Single Record Revenue Details Record (RevenueDetails message)

Table 3 - SRD1 – Bare minimum data points per record for the describe use case

Other essential reading

Statements for Contributor and RightsController revenues

The importance of ISRCs

NetAmount and NetRevenueInCurrencyOfAccounting

ProductionDate vs. CreationDate

Search