Skip to end of metadata
Go to start of metadata

This section of the DDEX Knowledge Base contains  version 4.3 of the "Digital Sales Reporting Message Suite Standard"

1 Introduction

This standard was developed by the member organisations of the Digital Data Exchange, LLC (DDEX) and provides a suite of messages that give a uniform mechanism to enable Licensees (typically Digital Service Providers) to report to Licensors (typically Music Rights Societies and/or Record Companies) sales of Products based on Releases, as well as information regarding the revenue generated from the distribution of such Products, to the relevant Licensors of the Releases, the Sound Recordings and/or Music Audio-Visual Recordings (and other Resources) contained in the Releases and the Musical Works embodied in the Sound Recordings and/or Music Audio-Visual Recordings. This standard also provides a uniform invoice message to be sent by a Licensor to a Licensee

Any organisation wishing to implement this (or any other DDEX Standard) is required to apply for an Implementation Licence. The terms of the licence and an application form can be found at

Downloads & Older Versions

 Download/print standard (PDF)

Download/print standard tables  (PDF)  

XML Schema Definition Files  (ZIP)

 The DDEX Data Dictionary ...

... for the Recording Data and Rights Choreography Standard (RDR-C, Version 1.0): Message Structure and AVSs

... for the US Letters of Direction Choreography Standard (LoD, Version 1.0): Message Structure and AVSs

... for the Electronic Release Notification Message Suite Standard (ERN, Version 4.2): Message Structure and AVSs

... for the Musical Work Right Share Notification Choreography Standard (MWN. Version 1.2): Message Structure and AVSs

... for the US Musical Work Licensing Choreography Standard (MWL, Version 1.0): Message Structure and AVSs

... for the Standard for the Communication of Media Enrichment and Description Information (MEAD): Message Structure and AVSs

... f or the Standard for communicating links between Resources and Musical Works (Version 1.1)

... for the Recording Data and Rights Standard (Version 1.4)

... for Release Deliveries using SFTP or Web Service (Version 1.7)

... for the Recording Information Notification (Version 1.1)

... for Work and Share Notifications

... for Works Licensing

2 Scope


 2.1 Introduction
The suite of messages contained in this Standard provides a mechanism for Licensees (typically Digital Service Providers, including Mobile Service Providers and Internet Service Providers (ISPs)) to report to Licensors (typically Music Rights Societies and/or Record Companies) Sales (as defined in Clause 4.1) of Products and/or to report information regarding the revenue generated from Selling Products based on electronic Releases containing Sound Recordings and/or Music Audio-Visual Recordings which embody Musical Works and/or other Resources.

This standard also provides a uniform invoice message to be sent by a Licensor to a Licensee.

 2.2 Organisation of the Document

This DDEX Standard has six clauses and one annexes. Clauses 1 and 2 provide a general introduction and the scope of this Standard. Clause 3 and 4 give a set of normative references as well as terms, definitions and abbreviations that are used in this standard.

Clause 5 provides an overview of the messages, including the choreography of when it is anticipated that each message will be sent and a diagrammatic representation of the content of each message and the relationship between this standard and the DDEX-defined allowed values. Clause 6 then specifies all elements of all messages within this Standard and their descriptions as they appear in the DDEX Data Dictionary. Finally, Annex A then provides a list of all allowed-value sets, including their allowed values and respective definitions as used in this Standard.

 2.3 Release Notes (informative)

2.3.1 Changes between Version 4.3 and 4.2

The main changes in this public draft over version 4.2 are:

  • Support for TIS territory Codes in the Territory and ExcludedTerritoryCode elements;
  • Support for legacy ISO country codes in all places where historic data might be communicated in the Territory and ExcludedTerritoryCode elements;
  • Enhanced support for Audiovisual content such as TV Series, Seasons and Episodes such as sequencing of Episodes and Seasons, provision of composers and other indirect ResourceContributors on Cues, communication of audiovisual duration on Release level;
  • Enhances support for mobile products (for details see Release and Resource Profiles);
  • Additional UseTypes;
  • Making the MessageThreadId in the Message header optional;
  • A flag, HasRightsInDispute, has been added into the MusicalWork composite to allow signalling that the sender has received claims toatalling miore than 100% for that Work.

In addition there are changes to the XML Schema that do not affect the messages created in according with these standards (e.g.: all branches of an XmlChoice element are now mandatory - but each of them remains, in effect, optional).

2.3.2 Changes between Versions 4.2 and 4.1

Version 4.2 provides the ability to communicate a ReleaseType in the ContainedReleaseSummary composite.

In addition to this, the structure of the XML Schema files has been significantly simplified; this change has, however, no impact in the structure of the messages.

2.3.3 Changes between Versions 4.1 and 4.0

Version 4.1 provides the following changes and new:

  • Adding an IsMainRelease attribute into the Release composite;
  • Adding a AlternativeConversionRate into the SalesToSocietyByTerritory and SalesToRecordCompanyByTerritory.
  • Changing the cardinality of the ArtistRole for artists from 0-∞ to 1-∞;
  • Adding a ConversionRate composite for use in sales reports;
  • Adding a RightsClaimModel into CommercialModelType allowed value set;;
  • Adding PurchaseAsPhysicalProduct into the UseType allowed value set;
  • Adding ClassicalAlbum into the ReleaseType allowed-value set; and
  • Updated list of ISO territory, currency and language codes.

2.3.4 Changes between Versions 4.0 and 3.2

Version 4.0 provides the following changes and new features (all but the first two changes are forward-compatible changes, i.e. a message created in version 3.2 would still validate if checked with a version 4.0 parser):

  • Changed the linking of Release identity between the ContainedReleaseSummary and SalesReport from the use of a ReleaseID (such as a GRid) to the use of an ID/IDREF pair;
  • The same change was also made for the linking of
  • Work identity (between Works and Resources);
  • Resource identity (between Resources and the Releases);
  • Collection identity (between Collections and Resources/Releases); and
  • CueSheet identity (between Cues and Resources);
  • Support signalling a Release and Business Profile through XML Attributes on root level;
  • Simplification of the allowed value sets to communicate CommercialModelType, UseType, UserInterfaceType and DistributionChannelType. Note that some allowed values were deprecated but not yet removed from the standard; these values are marked as being “deprecated” in the data dictionary and DDEX advises that such values will be removed at a future date and therefore recommends against using them;
  • Added a uniform method to indicate that a party ID is an International Standard Name Identifier (ISNI) or DDEX Party ID (DPID);
  • Updated the ISO 4217a list of currencies, including adding AFN, AZN, CLF, COU, CUC, GHS, MGA, MXV, RON, RSD, SDG, TMT, TRY, UYI, VEF, ZWL;
  • Updated of ISO 3166a2 list of countries, including adding MF;
  • Added the ability to provide additional Deal details:
  • PriceConsumerPaidExcSalesTaxInCurrencyOfAccounting;
  • PrimaryResourcePriceConsumerPaidExcSalesTax;
  • PrimaryResourcePriceConsumerPaidExcSalesTaxInCurrencyOfAccounting;
  • RoyaltyRateInCurrencyOfAccounting;
  • AgreedUnitPriceExcSalesTaxInCurrencyOfAccounting;
  • PrimaryResourceAgreedUnitPriceExcSalesTax;
  • PrimaryResourceAgreedUnitPriceExcSalesTaxInCurrencyOfAccounting;
  • DeductionRateInCurrencyOfAccounting;
  • EffectiveUnitRoyaltyRateNetInCurrencyOfAccounting; and
  • ProprietaryFinancialDataInCurrencyOfAccounting;
  • Added the ability to classify a sales transaction as a replacement purchase for a sales transaction reported earlier; and
  • Added a mechanism to communicate allowed value sets from a later version of this standard within the schema defined herein.

In addition there are changes to the ddex.xsd and ddexC.xsd baseline schema files that have been implemented to support other DDEX standards but that do not impact upon version 4.0 of the Digital Sales Reporting Message Suite Standard.

2.3.5 Changes between Versions 3.2 and 3.1.2

Version 3.2 provides the following new features

  • Stand-alone InvoiceMessage;
  • Ability to signal whether a Collection was “complete” as time of the Use;
  • Ability to include a “displaced” MusicalWorkId element on selected Resource composites;
  • Ability to provide multiple names for each Party for allow, for instance, for different spellings and/or character sets;
  • Ability to chapter Audio Resources (e.g. for audio books, Medleys and Potrpotrris);
  • Update of the ReleaseRelationshipType list for increased support for mobile Releases;
  • Addition of QCELP to the AudioCodecTypes; and
  • Various bug fixes on data types and (obvious) mistakes in definitions.

2.3.6  Changes between Versions 3.1.2 and 3.1.1

Version 3.1.2 corrected a bug that made the use of Collections impossible.

2.3.7  Changes between Versions 3.1 and 3.1.1

Version 3.1.1 corrects a few bugs from Version 3.1:

  • The order of the main message elements has been changed to make simple audiovisual Releases easier to ingest. The new order is: Works-Cues-Resources-Collections-Releases-Sales Data;
  • The Duration field within the Video Resource composite has been made mandatory to align with all other linear Resource types;
  • The ability to infom the recipient of a sales report about the type of a Resource when the reported sales were with respect to a Resource (as opposed to a Release) and the resource is identified with a Proprietaryid.

In addition, version 3.1.1 provides these features above version 3.1:

  • Support for providing a rationale why a cue sheet is not provided while the provision of cue sheets is Contractually Mandatory;
  • Support for distinguishing between Sales of DRM-protected and non DRM-protected Releases, lossily coded and losslessly coded Releases, high-definition and standard definition Releases and Releases coded at different bit rates;
  • Support for distinguishing between Sales of promotional and non-proportional Release uses;
  • Support for physical distribution of Releases by providing CarrierType information (a.k.a. configurations); and
  • Alignment of TitleTypes with those provided in Common Works Registration process.

3 Normative References

 Click here to expand...

The following normative documents contain provisions, which through reference in this text constitute provisions of this Standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest version applies.
  • DDEX Data Dictionary Standard. Latest Version
  • DDEX Party Identifier (DPID) Standard. Latest Version
  • IFPI: Global Release Identifier (GRid) Standard. Latest Version
  • CISAC: Musical Work Licence Identifier (MWLI) Standard. Latest Version
    IETF RfC 5646, Tags for Identifying Languages. Latest Version.
  • ISO 639-1988, Code for the representation of the names of languages
  • ISO 3166-1:1997 Codes for the representation of names of countries and their sub-divisions - Part 1: Country codes
  • ISO 3901:2001, Information and documentation – International Standard Recording Code (ISRC)
  • ISO 4217:2001 Codes for the representation of currencies and funds
  • ISO 7064:1983, Data Processing – Check Character Systems
  • ISO 8601:2004, Data elements and interchange formats – Information interchange – Representation of dates and times[1]
  • W3C. XML Schema Part 1: Structures. Second Edition. 2004
  • W3C. XML Schema Part 2: Datatypes. Second Edition. 2004

[1] Information on ISO 8601 can be found in Annex D of Part 2 (Datatypes Second Edition) of the XML Schema standard (

4 Terms and Abbreviations

 4.1 Terms and Definitions

For the purposes of this Standard, the following terms should be read as having the meanings specified here:

Contractually Mandatory

An entity in a DDEX Message that has the technical cardinality of 0-1 or 0-n but that is mandatory when a DDEX message is sent in a specific commercial context.

Contractually Mandatory fields may, however, be mandatory when a DDEX message is sent in a specific commercial context. In such circumstances, a message is deemed conformant only if and when it contains all the “contractually mandatory” fields as agreed by Message Sender and Message Recipient.

Digital Service Provider (DSP)

A Digital Service Provider (DSP), a Party making Releases available to Consumers or other DSPs over a public Telecom network. This includes MSPs (Mobile Service Providers) and ISPs (Internet Service Providers). 


A Party that is granted a Licence in respect of rights in one or more Creations, by a Licensor. The Licensee may be a human being or other legal person or corporate entity. The Licensee may or may not be the Message Sender or Message Recipient of a message in a specific information exchange defined by a DDEX Standard.


A Party that grants a Licence in respect of rights in one or more Creations to one or more Licensees in accordance with the authorities it has been granted to do so by one or more Rights Controller(s), Rights Administrator(s) (where applicable), Licensing Agent(s) (where applicable) or Rights Holder(s). The Licensor may be a human being or other legal person or corporate entity. The Licensor may or may not also be the Rights Controller, the Rights Administrator, the Licensing Agent or the Rights Holder in the Creation(s) that are the subject of the Licence granting the rights. The Licensor may or may not be the Message Sender or Message Recipient of a message in a specific information exchange defined by a DDEX Standard.

Musical Work

A Work intended to be perceivable as a combination of sounds, with or without accompanying text.

Any words that are intended to be expressed with a MusicalWork (often termed Lyrics) form part of that MusicalWork; not all MusicalWorks have Lyrics.
A MusicalWork may be expressed and fixed to become part of a SoundRecording or a Video Recording, or may be used to create notated music (sheet music, scores, instrumental parts) or sound generation codes (such as MIDI files).
In some cases, the MusicalWork comes into existence simultaneously with its expression. This is common in extemporised forms such as jazz music.


A Manifestation of a Release (or another Resource) which is made available to Consumers, by sale, loan or other means. The attributes of a Release in its digital manifestation as a Product may be technical (e.g., the codec or bit rate); a mode of distribution (e.g., downloading or streaming); or a commercial term (e.g., price).


A Release is an abstract entity representing a bundle of one or more Resources compiled by an Issuer. The Resources in Releases are normally primarily sound recordings or music audio-visual recordings, but this is not invariably the case. The Release is not itself the item of trade (or “Product”). Products have more extensive attributes than Releases; one Release may be disseminated in many different Products.


A digital fixation of an expression of an abstract Work (such as a sound recording, a video, an image, software or a passage of text). Resources are individual assets that make up a Release. Typical Resources are sound recordings, video clips and cover art images.


Distribution of a product to end consumers. For the avoidance of doubt, the term “sales” includes all forms of distribution of products, whether revenue was generated, or not and, where revenue is generated, regardless of the business model used to do so.


 4.2 Abbreviations

AMEPAutomated Message Exchange Protocol
ACAAppointed Certification Agency
AVSAllowed Value Set
BPBusiness Profile

Confédération internationale des sociétés d'auteurs et compositeurs, the International Confederation of Societies of Authors and Composers (see

CACertification Agency
CTConformance Tester
DAWDigital Audio Workstation

Digital Data Exchange

DSIGDigital Signature
DSPDigital Service Provider (incudes Mobile Service Providers)
DSRDigital Sales Reporting
ERNElectronic Release Notification
FTPFile Transfer Protocol (FTP specifically includes SFTP)
GRidGlobal Release Identifier
HTTPHypertext Transport Protocol  (HTTP specifically includes HTTPS)
HTTPSSecure Hypertext Transport Protocol
IECInternational Electrotechnical Commission (see
ISOInternational Organisation for Standardisation (see
MIMEMultipurpose Internet Mail Extensions
MWLMusical Works Licensing
MWNMusical Works Notification

Multi-Record-Block Variant

PCAPrivate Certification Agency
PDFPortable Document Format
RESTREpresentational State Transfer
RINRecording Information Notification

Single-Record-Block Variant

TISTerritory Information System (a CISAC Standard)
TLSTransport Layer Security
UGCUser-generated content
URLUniform Resource Locator
XMLeXtensible Markup Language
XSDXML Schema Definition
W3CWorld Wide Web Consortium (see
WSWeb Service

5 Message Overview

 5.1 Namespace

The full namespace for the XML Schema document for this Standard is

All messages developed within DDEX are based upon a common set of elements and their definitions. These are contained in the DDEX Data Dictionary available from

 5.2 Allowed-value Sets

All messages defined in this standard make intensive use of allowed-value sets. These allowed value sets are shared between all DDEX standards and DDEX provides a XML Schema Definition file for all of these allowed values. These values are also contained in the DDEX Data Dictionary available from

The full namespace for the XML Schema document for the allowed-value sets is

DDEX may regularly extend this list of allowed-value sets. Any such extensions to this list are issued on a date later than the date on which this Standard is issued form part of this Standard. Thus the list of allowed-value sets provided in Table 2 contains the list of allowed-value sets valid on the data of issuance of this Standard.

 5.3 Message Choreography

Figure 2 below shows the choreography of processes that the Main Profile of the Digital Sales Reporting Message Suite enables.

Figure 1 — Choreography of the Digital Sales Reporting Message Suite

Table 1 below summarises the point in the relevant business processes when each message is sent. The table also indicates who sends which message to whom and which of the messages are defined in this Standard.

Table 1 — Messages in the Digital Sales Reporting Message Suite

Message Name

Initiating Event





Sale or distribution of Releases, and/or the generation of revenues related to the sale or distribution of Releases

Licensee, typically a DSP

Release Creator, typically a Record Company



Licensee, typically a DSP; or a Release Creator, typically a Record Company

Licensor, typically a Music Rights Society



Receipt of a sales report

Licensor, typically a Music Rights Society or Release Creator, typically a Record Company

Licensee, typically a DSP

 5.4 Message Content Overview (informative)

The two messages in the Digital Sales Reporting Message Suite contain similar information as depicted below in Figure 3. The differences lie mostly in additional information provided in the SalesReportToSocietyMessage message. The main differences are highlighted in red (for information that is only part of the society message) and green (for information that is only part of the record company message) in the diagram below.

The data element names shown in Figure 3 are not the formal names used in the messages as the diagram is intended to provide a quick overview of the data to be provided within the messages. Specifically, it does not show which elements are optional. The diagram is not normative. Also note that one XML Attribute, LanguageAndScriptCode, is only shown on the top-level (message) composites. This attribute is, in fact, present on all composites or elements that might benefit from being coded in different languages and/0r scripts. If placed on a composite, its value applies to all sub-elements (and, potentially, overrides a different LanguageAndScriptCode “further up”. If placed on an element its value applies only to that element. The LanguageAndScriptCode is provided in accordance with IETF RfC 4646.

Figure 2 — Information content in the Sales Report Messages

Figure 3 — Information content in the InvoiceMessage 

 5.5 Describing Exploitations of Releases (informative)

In DDEX Messages MessageSenders can use five allowed value sets to describe how Releases can be (or have been) exploited. They are:
  • ReleaseType
  • UseType;
  • CommercialModelType;
  • ConsumerInterfaceType; and
  • DistributionChannelType.

The ReleaseType categorises the Release from the point of view of the ReleaseCreator. For example, a ReleaseCreator may create a Release for use as a RingbackTone on a mobile phone. This is distinct from the UseType which describes what a Consumer is allowed to do with a Release. For example, a Release created as a “normal” digital Album, might be used as a RingTone.

The third dimension, the Commercial Model type describes how Consumers pay for the Release, whether the transactions are based on subscriptions or whether the Consumer pays directly for each Release received.

The final two dimensions can be used to describe the devices on which Consumers consume (e.g. a portable device or a games console) the Releases and through what type of conduit they receive the Releases (e.g. a radio broadcast or the Internet). It is important to know that in many cases such detail will not be required and, thus, ConsumerInterfaceType and DistributionChannelType are optional fields in the messages.

6 Message Definition

 6.1 Introduction (informative)
This Clause contains an overview for each of the three messages in the Digital Sales Report Message Suite in a tabular form. The Standard comprises three messages:

The hierarchical structure of the messages is provided through indentation in the tables below. On the MessageHeader for example, the PartyName is a child of Sender. Thus, a Sender contains a PartyName (plus a PartyId). A second example from the Message Header is the MessageAuditTrail that contains MessageAuditTrailEvents which, in turn, contains a MessagingPartyDescriptor and a DateTime element. All elements that have subelements are printed in bold. The MessageAuditTrailEvents element also shows a second structural feature of the Message Summary: the cardinality. In the case of MessageAuditTrailEvents the entry "1-n" means that each MessageAuditTrail contains one or more MessageAuditTrailEvents. Other possible cardinality entries are: "1" (for: exactly one), "0-1" (for none or one) or "0-n" (for none to multiple). Elements shown in italics are represented in the XML Schema as XML Attributes. In several places within the messages, the Message Sender may need to make a choice between using two or more XML elements. These instances are marked in the tabular representation of the messages below with the keyword XmlChoice. This keyword is not part of the messages; instead exactly one of the “branches” below the XmlChoice keyword has to be used.

In addition to the tabular description of the message, which should always be read in conjunction with the XML Schema, additional conformance rules, which go beyond XML Schema validation, are provided where necessary. The general conformance rules for all messages within this Standard are provided in Clause 6.2.

Specific business processes between sender and recipient may require even further conformance rules. These are, however, not part of the Standard and will need to be agreed by the business partners. Rules relating to the authority of business partners to unilaterally change the Message Standard in this way are set out in the current version of the Procedures for the Development and Maintenance of DDEX Standards which forms part of the overall governance of the DDEX Standards.

The syntax as well as the semantics of the various elements in the messages is provided in this Clause. They are taken from the current version of the DDEX Data Dictionary as defined through, and maintained in accordance with, the DDEX Data Dictionary Standard.

 6.2 General Conformance Rules

6.2.1 Schema Validation

A message is conformant to this specification only when it validates against the set of XML Schema files accompanying this standard.

6.2.2 Allowed Value Lists

The allowed values are listed, defined and provided through the DDEX Data Dictionary Standard in accordance with its latest version. Other values are not possible unless by using the mechanism described below:

This Standard does not explicitly list allowed values. The XML Schema files – as provided in Annex A – contain the allowed values at the time of writing of this Standard. Some of the allowed value sets contain a provision to either use a User Defined Value instead of a DDEX-defined value (in that case the MessageSender has to select the value “UserDefined” from the AVS and provide its own value in the XML attribute “UserDefinedValue”) or to augment a DDEX-defined value (in that case the MessageSender may not select the value “UserDefined” from the AVS but shall provide its additional information in the XML attribute “UserDefinedValue”). In either case the Namespace attribute shall be used to indicate where the UserDefinedValue is defined and maintained.

6.2.3 Allowed Values for Namespace Attributes

The Namespace attributes can be used to allow message parties to use proprietary value lists.

The allowed values for the Namespace attributes which is recommended to be used is the DDEX Party Identifier of the party controlling the proprietary allowed value, as defined in, and administered in accordance with the latest version of the DDEX Party ID Standard.

6.2.4 Indicating Unknown Values

When the sender of a message is required to provide a data element but cannot do so, the following values shall be entered:

  • In fields of type xs:string: “#unknown#” ;
  • In fields of type xd:date: “9999-01-01”;
  • In fields of type xs:datetime: “9999-01-01T99:01:01”; and
  • In fields of type xs:duration: “PT99H01M01S”.

The circumstances under which such behaviour is permissible may be limited in the specific business relationship between message sender and message recipient.

6.2.5 Contractually Mandatory

The messages defined in this standard contain fields with cardinality “0-1” or “0-n”. Therefore these fields are from the standard’s point of view, optional. Such fields may, however, be mandatory when a DDEX message is sent in a specific commercial context.

In such circumstances, a message is deemed conformant only if and when it contains all the “contractually mandatory” fields as agreed by MessageSender and MessageRecipient.

6.2.6 Schema Version

The only valid value for this field is "dsr/43".

 6.3 SalesReportToRecordCompanyMessage

The tabular rendering of the messages is provided in a separate document. See the blue box here.





 6.4 SalesReportToSocietyMessage

The tabular rendering of the messages is provided in a separate document. See the blue box here.




 6.5 InvoiceMessage

The tabular rendering of the messages is provided in a separate document. See the blue box here.





Evaluation Licence for DDEX Standards



Subject to your compliance with the terms and conditions of this Agreement, DDEX™ grants you a limited, nonexclusive, non-transferable, non-sublicenseable, royalty-free licence solely to reproduce, distribute within your organisation, and use the DDEX standard specifications (“DDEX Standards”) solely for the purpose of your internal evaluation. You may not make any commercial use of the DDEX Standards under this agreement. No other licences are granted under this agreement.

No representations or warranties (either express or implied) are made or offered by DDEX with regard to the DDEX Standards. In particular, but without limitation, no representations or warranties are made in relation to:

  1. The suitability or fitness of the standards for any particular purpose;
  2. The merchantability of the standards;
  3. The accuracy, completeness, relevance or validity of the standards; or
  4. The non-infringement of any third party intellectual property rights related to the DDEX Standards.

Accordingly, DDEX and/or its members shall not be liable for any direct, indirect, special, consequential or punitive loss or damages howsoever arising out of or in connection with the use of the standards. IN THE EVENT THAT ANY COURT OF COMPETENT JURISDICTION RENDERS JUDGEMENT AGAINST DDEX AND/OR ITS MEMBERS NOTWITHSTANDING THE ABOVE LIMITATION, THE AGGREGATE LIABILITY TO YOU IN CONNECTION WITH THIS AGREEMENT SHALL IN NO EVENT EXCEED THE AMOUNT OF ONE HUNDRED U.S. DOLLARS (US$ 100.00).

Users of the DDEX Standards are cautioned that it is subject to revision. Users are recommended to use the latest versions, which are available at The use of outdated versions of the standards is not recommended but may be required by agreement between implementers in particular cases.