Peppol Transaction Statistics Reporting Process

OpenPeppol AISBL, eDEC v1.0.2

1. Introduction

Transaction Statistics reporting of production data helps OpenPeppol as the Peppol Coordinating Authority (PCA) and Peppol Authorities (PAs) to monitor the operations of the Peppol Network and identify and manage risks and issues within the network. The reporting requirements towards Service Providers (SPs) are divided into two areas: reporting about End User Statistics and reporting about Transaction Statistics. This document will explain and outline the procedures for the Transaction Statistics Reporting. The policy on reporting is stated in Internal Regulations for Use of the Peppol Network.

1.1. Document Structure

This document is structured as follows:

Chapter 1 (Introduction) - provides general information about Transaction Statistics Reporting business process.
Chapter 2 (Reporting Business Process) - provides the reader with information on how to implement the Transaction Statistics Reporting process.
Chapter 3 (Description of selected parts of the transaction) - provides the reader with functional information for the Transaction Statistics Reporting Process.
Chapter 4 (Rules) - provides the reader with information on the business rules to be respected for the Transaction Statistics Reporting Process.
Chapter 5 (Data Types) - provides the details on the used data types in a Transaction Statistics Report.
Chapter 6 (Code Lists) - provides the details on the used code lists in a Transaction Statistics Report.
Chapter 7 (Specification Identifiers) - provides the details on the customization and process identifiers.

1.2. Scope

This document is concerned with clarifying the requirements for ensuring compliance to the Internal Regulations (IR) requirements and provides guidelines for the support and implementation of these requirements. This document will also provide a detailed implementation guideline for the Transaction Statistics Report transaction; to do that, the document sets out the processes and procedure for Transaction Statistics Reporting process including:

Parties and Roles,
Document Structure,
Data gathered,
Reporting rules.

1.3. Audience

OpenPeppol acting as the Peppol Coordinating Authority
- How OpenPeppol will receive the reports.
Service Provider (SP)
- How SPs are to submit their Transaction Statistics Reports to OpenPeppol.

1.4. References

Internal Regulations - Use of Peppol Network v2.0

1.5. Namespaces

The following table lists XML namespaces that are used in this document. The choice of any namespace prefix is arbitrary and not semantically significant.

Prefix	Namespace URI
tsr	`urn:fdc:peppol:transaction-statistics-report:1.0`

1.6. Changelog

Version 1.0.2 (2023-12-11)

Updated the Schematron rules to v1.0.4
Fixed some editorial bugs
Removed the operational statement on the number of calendar days before a reminder is sent
Added a statement, that empty subtotals are not allowed
Extended the country code list based on ISO-3166 to allow the ZZ value
Updated the example in Appendix 1 to be fully consistent

Version 1.0.1 (2023-03-14)

Due to changes in the Peppol Envelope Specification, sending Service Providers are no longer able to report the Subtotal per Service Provider, Dataset Type, Process ID and Country Codes.
- The text of the business rules BR-TSR-22 and BR-TSR-33 were changed
- This implies updated Schematron validation rules (removed rule SCH-TSR-13; added rule SCH-TSR-43)
The semantic model was missing the "Report period start date" and "Report period end date" elements as separate fields

Version 1.0.0 (2022-11-23)

Initial version

2. Reporting Business Process

2.1. Parties and Roles

The following Parties are involved in the creation and submission of an Transaction Statistics Report.

2.1.1. Service Provider (SP)

The reporting Service Provider is mandatory information in each Transaction Statistics Report.

Each SP will:

Collect relevant data, taking care of the accuracy and validity of this data.
Report this data in accordance to this document in a standardized and structured dataset.
Ensure all data for a Reporting Period is reported within the Statistics Report Submitting Period following the end of the Reporting Period.
Note: the Reporting Period and the Statistics Report Submitting Period are defined by OpenPeppol in a separate document.
Transmit the Peppol Transaction Statistics Report document to OpenPeppol in accordance with this specification.

2.1.2. OpenPeppol Operating Office (OO)

OO will:

Automatically check which providers have not submitted their Transaction Statistics Report. This check will be triggered automatically.
Prompt any SPs that have not submitted the Transaction Statistics Report.
Prompting will be done by email and not by eDelivery.
Prompt the PA of the SP if an SP fails to provide full and complete reports. The PA of the SP will be informed to handle this as a non-compliance issue

2.2. Transaction statistics Reporting Process

The following diagrams provide an overview of the key steps when SPs are reporting Transaction Statistics:

Using detailed Archimate notation:

2.2.1. Data Gathering

Reporting Period
- The exact length of a Reporting Period is defined external to this document.
- A Reporting Period starts at 00:00:00 UTC (inclusive) of the first day.
- A Reporting Period ends at 23:59:59 UTC (inclusive) of the last day.
Data
- Only SPs operating a production Peppol Access Point MUST gather this data and transmit a Transaction Statistics Report.
- Only data for the production network MUST be gathered.
- The following information elements need to be gathered for each exchanged Dataset:
  1. Timing of the exchange
  2. Direction of the exchange (incoming or outgoing)
  3. Sending Peppol Service Provider ID
  4. Receiving Peppol Service Provider ID
  5. Peppol Dataset Type ID (Document Type ID) and Process ID
  6. Transport protocol used
  7. Country of sender^*
  8. Country of receiver^**
- Only Dataset exchanges that resulted in a positive transport level acknowledgment (like AS4 Receipts) MUST be included in the Transaction Statistics Report. Transmissions that failed on a network or protocol level MUST NOT to be considered for the report.
- End User Statistics Reports MUST NOT be counted for a Transaction Statistics Report
- Transaction Statistics Reports MUST NOT be counted for a Transaction Statistics Report
- Only the sending SP (C2) MUST count the message as 'outgoing' and only the receiving SP (C3) MUST count the same message as 'incoming'.

^* The Country of sender will be mandatory, once the backing eDEC specification becomes mandatory

^** The Country of receiver can only be determined by the receiving SP (C3)

2.2.2. Data Aggregation

Before the Transaction Statistics Report data is transmitted to OpenPeppol it needs to be aggregated. The aggregation can be performed on any of the above-mentioned source fields.

The following aggregations MUST be provided to be compliant to this specification:

Transport Protocol
Service Provider, Dataset Type ID and Process ID

The following aggregations MAY be provided to be compliant to this specification:

Service Provider, Dataset Type ID, Process ID, Sender Country and Receiver Country

2.2.3. Data Transmission

Frequency
- A Transaction Statistics Report MUST be transmitted once per Reporting Period.
- A Transaction Statistics Report MUST be transmitted within the Statistics Report Submitting Period after the end of the previous Reporting Period.
- The Transaction Statistics Report MUST be transmitted, even if no other Peppol exchange happened in the Reporting Period.
- In case the Transaction Statistics Report of one SP is received multiple times for one Reporting Period, only the latest received document will be processed.
- Transaction Statistics Reports received after the deadline (=the end of the Statistics Report Submitting Period) WILL NOT be processed.
Data
- Only Transaction Statistics Reports on the Production environment MUST be transmitted.
- Each Subtotal key combination MUST NOT occur more than once in a Transaction Statistics Report.
- The data of each Transaction Statistics MUST be reported in the designated elements.
- The Reporting Period MUST be part of the Transaction Statistics Report.
- An identifier uniquely identifying the reporting SP MUST be part of the Transaction Statistics Report.
Network
- Transaction Statistics Reports MUST be transmitted via the Peppol eDelivery Network.
- Only OpenPeppol is allowed to receive Transaction Statistics Reports directly.

3. Description of selected parts of the transaction

Description of selected parts of the Transaction Statistics Report message.

3.1. Header

The element Header contains the reporting period and the ID of the reporting Service Provider.

Example:

<tsr:Header>
  <tsr:ReportPeriod>
    <tsr:StartDate>2022-01-01</tsr:StartDate>
    <tsr:EndDate>2022-01-31</tsr:EndDate>
  </tsr:ReportPeriod>
  <tsr:ReporterID schemeID="CertSubjectCN">POP000360</tsr:ReporterID>
</tsr:Header>

3.1.1. Reporting Period

The element ReportPeriod MUST contain the start date (inclusive) and the end date (inclusive) of the reporting period. Start date and end date elements MUST NOT contain time zone information.

Example (for a monthly Reporting Period):

<tsr:ReportPeriod>
  <tsr:StartDate>2022-01-01</tsr:StartDate>
  <tsr:EndDate>2022-01-31</tsr:EndDate>
</tsr:ReportPeriod>

3.1.2. Reporter Identification

The element ReporterID MUST contain the unique identification of the Service Provider that is providing the data. If the schemeID attribute is set to CertSubjectCN than the value must be the Peppol AP Certificate Subject CN (Common Name). See Reporter Identification Scheme for the full code list.

Example:

<tsr:ReporterID schemeID="CertSubjectCN">POP000360</tsr:ReporterID>

3.2. Total

Defines the total amount of exchanged Datasets in the Reporting Period. The element Total and its child elements MUST be provided for every Transaction Statistics Report.

The element tsr:Total/tsr:Incoming contains the total amount of incoming / received Datasets. Only values ≥ 0 are allowed.

The element tsr:Total/tsr:Outgoing contains the total amount of outgoing / sent Datasets. Only values ≥ 0 are allowed.

Example of a Total element with 23 received and no sent Datasets:

<tsr:Total>
  <tsr:Incoming>23</tsr:Incoming>
  <tsr:Outgoing>0</tsr:Outgoing>
</tsr:Total>

3.3. Subtotals

Each Transaction Statistics Report contains different subtotals. Each subtotal represents a different view on the transaction statistics data.

The technical representation of the subtotals was designed in a generic way, to allow for future extension without modifying the underlying schema. Each Subtotal element therefore requires a @type attribute that defines the type of the subtotal. The value range is defined by the Subtotal Type code list.

Subtotals without any matching transaction (i.e. if Incoming is 0 and if Outgoing is 0) MUST NOT be part of the Report.

All values in this subchapter are case-sensitive, except stated otherwise.

3.3.1. Subtotal per Transport Protocol

This subtotal is identified by the @type attribute having the value PerTP.

This subtotal requires one Key element with a Meta Scheme ID of TP (Transport Protocol). The schemeID attribute of this Key element MUST have the value Peppol. The value of the Key element MUST be the transport protocol identifier according to the Transport Profiles code list.

Each Transport Protocol MUST be reported in a separate Subtotal element.

The sum all incoming amounts per Transport Protocol MUST match the total incoming amount.

The sum all outgoing amounts per Transport Protocol MUST match the total outgoing amount.

Example of a subtotal per Transport Protocol:

  <tsr:Subtotal type="PerTP">
    <tsr:Key metaSchemeID="TP" schemeID="Peppol">peppol-transport-as4-v2_0</tsr:Key>
    <tsr:Incoming>23</tsr:Incoming>
    <tsr:Outgoing>0</tsr:Outgoing>
  </tsr:Subtotal>

3.3.2. Subtotal per Service Provider, Dataset Type and Process ID

This subtotal is identified by the @type attribute having the value PerSP-DT-PR.

This subtotal requires one Key element with a Meta Scheme ID of SP (Service Provider). The schemeID attribute of this Key element MUST have a value according to the Reporter Identification Scheme code list. The value of the Key element MUST follow the rules of the chosen scheme.
This subtotal requires one Key element with a Meta Scheme ID of DT (Dataset Type). The schemeID attribute of this Key element MUST be the Document Type Identifier Scheme of the exchanged Dataset (usually busdox-docid-qns or peppol-doctype-wildcard). The value of the Key element MUST be the Dataset Type (Document Type) Identifier value of the exchanged Dataset.
This subtotal requires one Key element with a Meta Scheme ID of PR (Process ID). The schemeID attribute of this Key element MUST be the Process Identifier Scheme of the process (Peppol profile) used (usually cenbii-procid-ubl). The value of the Key element MUST be the Process ID value of the process (Peppol profile) used.

Each combination of Service Provider, Dataset Type and Process ID MUST be reported in a separate Subtotal element.

The sum all incoming amounts per Service Provider, Dataset Type and Process ID MUST match the total incoming amount.

The sum all outgoing amounts per Service Provider, Dataset Type and Process ID MUST match the total outgoing amount.

For outgoing messages, only the receiving SP (C3) needs to be counted. For incoming messages, only the sending SP (C2) needs to be counted. The other side must always be the reporting SP that is already part of the Report header data.

Example of a subtotal per Service Provider, Dataset Type and Process ID:

  <tsr:Subtotal type="PerSP-DT-PR">
    <tsr:Key metaSchemeID="SP" schemeID="CertSubjectCN">POP000001</tsr:Key>
    <tsr:Key metaSchemeID="DT" schemeID="busdox-docid-qns">urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1</tsr:Key>
    <tsr:Key metaSchemeID="PR" schemeID="cenbii-procid-ubl">urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</tsr:Key>
    <tsr:Incoming>23</tsr:Incoming>
    <tsr:Outgoing>0</tsr:Outgoing>
  </tsr:Subtotal>

3.3.3. Subtotal per Service Provider, Dataset Type, Process ID and Country Codes

This subtotal is identified by the @type attribute having the value PerSP-DT-PR-CC.

This subtotal requires one Key element with a Meta Scheme ID of SP (Service Provider). The schemeID attribute of this Key element MUST have a value according to the Reporter Identification Scheme code list. The value of the Key element MUST follow the rules of the chosen scheme.
This subtotal requires one Key element with a Meta Scheme ID of DT (Dataset Type). The schemeID attribute of this Key element MUST be the Document Type Identifier Scheme of the exchanged Dataset (usually busdox-docid-qns or peppol-doctype-wildcard). The value of the Key element MUST be the Dataset Type (Document Type) Identifier value of the exchanged Dataset.
This subtotal requires one Key element with a Meta Scheme ID of PR (Process ID). The schemeID attribute of this Key element MUST be the Process Identifier Scheme of the process (Peppol profile) used (usually cenbii-procid-ubl). The value of the Key element MUST be the Process ID value of the process (Peppol profile) used.
This subtotal requires one Key element with a Meta Scheme ID of CC (Country Code) and the schemeID attribute of SenderCountry. The value of the Key element MUST have a value according to the Country Codes code list.
This subtotal requires one Key element with a Meta Scheme ID of CC (Country Code) and the schemeID attribute of ReceiverCountry. The value of the Key element MUST have a value according to the Country Codes code list.

Each combination of Service Provider, Dataset Type, Process ID, Sender Country and Receiver Country MUST be reported in a separate Subtotal element.

The sum all incoming amounts per Service Provider, Dataset Type, Process ID and Country Code MUST match the total incoming amount.

This subtotal can only be counted by receiving SPs (C3), because only those have the full data available. The outgoing count in this subtotal MUST always be 0.

For incoming messages, only the sending SP (C2) needs to be counted. The other side must always be the reporting SP that is already part of the Report header data.

Example of a subtotal per Service Provider, Dataset Type, Process ID and Country Codes:

  <tsr:Subtotal type="PerSP-DT-CC">
    <tsr:Key metaSchemeID="SP" schemeID="CertSubjectCN">POP000001</tsr:Key>
    <tsr:Key metaSchemeID="DT" schemeID="busdox-docid-qns">urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1</tsr:Key>
    <tsr:Key metaSchemeID="PR" schemeID="cenbii-procid-ubl">urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</tsr:Key>
    <tsr:Key metaSchemeID="CC" schemeID="SenderCountry">AT</tsr:Key>
    <tsr:Key metaSchemeID="CC" schemeID="ReceiverCountry">DE</tsr:Key>
    <tsr:Incoming>23</tsr:Incoming>
    <tsr:Outgoing>0</tsr:Outgoing>
  </tsr:Subtotal>

4. Rules

Transaction Statistics Reporting process rules

Table 1. Business rules
RuleID	Requirement (depending, as applicable, on the respective business case)	Validation Level
BR-TSR-01	The Report MUST contain an identification of the specification it conforms to.	XSD SCH-TSR-01
BR-TSR-02	The Report MUST contain an identification of the business process context it appears in.	XSD SCH-TSR-02
BR-TSR-03	The Report MUST contain the reporting period in which the reported data was gathered.	XSD
BR-TSR-04	The Report MUST NOT contain timezone information for the Reporting Period start date and end date.	SCH-TSR-40 SCH-TSR-41
BR-TSR-05	The Report Period start date MUST NOT be after the Report Period end date.	SCH-TSR-42
BR-TSR-06	The Report MUST uniquely identify the reporting Service Provider.
BR-TSR-07	The scheme for identifying the reporting Service Provider MUST follow the "Reporter ID Scheme" code list	SCH-TSR-17
BR-TSR-08	If the Reporter ID scheme is set to "CertSubjectCN", the Reporter ID MUST the CN part of the Peppol AP certificate Subject.	SCH-TSR-18
BR-TSR-09	The Report MUST contain the total amount of outgoing / sent Peppol Datasets in the Reporting Period.	XSD
BR-TSR-10	The Report MUST contain the total amount of incoming / received Peppol Datasets in the Reporting Period.	XSD
BR-TSR-11	The Report MUST contain the amount of outgoing / sent and incoming / received Peppol Datasets in the Reporting Period, aggregated by Service Provider ID, if at least one Peppol Dataset was exchanged.
BR-TSR-12	The sum of all amounts of outgoing / sent Peppol Datasets in the Reporting Period aggregated by Receiving Service Provider ID, MUST match the total amount of outgoing / sent Peppol Datasets.
BR-TSR-13	The sum of all amounts of incoming / received Peppol Datasets in the Reporting Period aggregated by Sending Service Provider ID, MUST match the total amount of incoming / received Peppol Datasets.
BR-TSR-14	The Report MUST contain the amount of outgoing / sent and incoming / received Peppol Datasets in the Reporting Period, aggregated by Dataset Type ID, if at least one Peppol Dataset was exchanged.
BR-TSR-15	The sum of all amounts of outgoing / sent Peppol Datasets in the Reporting Period aggregated by Dataset Type ID, MUST match the total amount of outgoing / sent Peppol Datasets.
BR-TSR-16	The sum of all amounts of incoming / received Peppol Datasets in the Reporting Period aggregated by Dataset Type ID, MUST match the total amount of incoming / received Peppol Datasets.
BR-TSR-17	The Report MUST contain the amount of outgoing / sent and incoming / received Peppol Datasets in the Reporting Period, aggregated by Transport Protocol ID, if at least any Peppol Dataset was exchanged.	SCH-TSR-03
BR-TSR-18	The sum of all amounts of outgoing / sent Peppol Datasets in the Reporting Period aggregated by Transport Protocol ID, MUST match the total amount of outgoing / sent Peppol Datasets.	SCH-TSR-05
BR-TSR-19	The sum of all amounts of incoming / received Peppol Datasets in the Reporting Period aggregated by Transport Protocol ID, MUST match the total amount of incoming / received Peppol Datasets.	SCH-TSR-04
BR-TSR-20	Each Transport Protocol ID, for which data is aggregated, MUST NOT occur more than once.	SCH-TSR-06
BR-TSR-21	The Report MUST contain the amount of outgoing / sent and incoming / received Peppol Datasets in the Reporting Period, aggregated by Sender Country ID and Receiver Country ID, if at least any Peppol Dataset was exchanged.
BR-TSR-22	The sum of all amounts of outgoing / sent Peppol Datasets in the Reporting Period aggregated by Sender Country ID and Receiver Country ID, MUST be 0.
BR-TSR-23	The sum of all amounts of incoming / received Peppol Datasets in the Reporting Period aggregated by Sender Country ID and Receiver Country ID, MUST match the total amount of incoming / received Peppol Datasets.
BR-TSR-24	The Report MUST contain the amount of incoming / received Peppol Datasets in the Reporting Period, aggregated by Sending Service Provider ID, Dataset Type ID and Process ID, if at least one Peppol Dataset was exchanged.	SCH-TSR-07
BR-TSR-25	The Report MUST contain the amount of outgoing / sent Peppol Datasets in the Reporting Period, aggregated by Receiving Service Provider ID, Dataset Type ID and Process ID, if at least one Peppol Dataset was exchanged.	SCH-TSR-07
BR-TSR-26	The sum of all amounts of incoming / received Peppol Datasets in the Reporting Period aggregated by Sending Service Provider ID, Dataset Type ID and Process ID, MUST match the total amount of incoming / received Peppol Datasets.	SCH-TSR-08
BR-TSR-27	The sum of all amounts of outgoing / sent Peppol Datasets in the Reporting Period aggregated by Receiving Service Provider ID, Dataset Type ID and Process ID, MUST match the total amount of outgoing / sent Peppol Datasets.	SCH-TSR-09
BR-TSR-28	Each combination of Sending Service Provider ID and Dataset Type ID, for which data is aggregated, MUST NOT occur more than once.	SCH-TSR-10
BR-TSR-29	Each combination of Receiving Service Provider ID and Dataset Type ID, for which data is aggregated, MUST NOT occur more than once.	SCH-TSR-10
BR-TSR-30	The Report MUST contain the amount of incoming / received Peppol Datasets in the Reporting Period, aggregated by Sending Service Provider ID and Dataset Type ID and Sender Country ID and Receiver Country ID, if at least one Peppol Dataset was exchanged.	SCH-TSR-11
BR-TSR-31	The Report MUST contain the amount of outgoing / sent Peppol Datasets in the Reporting Period, aggregated by Receiving Service Provider ID and Dataset Type ID and Sender Country ID and Receiver Country ID, if at least one Peppol Dataset was exchanged.	SCH-TSR-11
BR-TSR-32	The sum of all amounts of incoming / received Peppol Datasets in the Reporting Period aggregated by Sending Service Provider ID and Dataset Type ID and Sender Country ID and Receiver Country ID, MUST match the total amount of incoming / received Peppol Datasets.	SCH-TSR-12
BR-TSR-33	The sum of all amounts of outgoing / sent Peppol Datasets in the Reporting Period aggregated by Receiving Service Provider ID and Dataset Type ID and Sender Country ID and Receiver Country ID, MUST be 0.	SCH-TSR-43
BR-TSR-34	Each combination of Sending Service Provider ID and Dataset Type ID and Sender Country ID and Receiver Country ID, for which data is aggregated, MUST NOT occur more than once.	SCH-TSR-14
BR-TSR-35	Each combination of Receiving Service Provider ID and Dataset Type ID and Sender Country ID and Receiver Country ID, for which data is aggregated, MUST NOT occur more than once.	SCH-TSR-14

5. Data Types

5.1. Primitive Data Types

Semantic data type content may be of the following primitive types. These primitive types were taken from ISO 15000, Annex A.

Primitive type	Definition
Date	Time point representing a calendar day on a time scale consisting of an origin and a succession of calendar ISO 8601.
Decimal	A subset of the real numbers, which can be represented by decimal numerals.
String	A finite sequence of zero or more characters.

Primitive type

Definition

Date

Time point representing a calendar day on a time scale consisting of an origin and a succession of calendar ISO 8601.

Decimal

A subset of the real numbers, which can be represented by decimal numerals.

String

A finite sequence of zero or more characters.

5.2. Semantic Data Types

The different semantic data types are described in the tables below, where various features such as attributes, format, and decimals as well as the basic type are defined for each semantic data type. They are based on ISO 15000.

When used in an instance of an invoice, each data element will contain data. In the below tables this is identified as the "content". Whenever a business term is used this term shall always have content and therefore the content is always mandatory.

5.2.1. Country Code

Country Codes are identifiers designed to identify countries. Country Codes must be coded according to the ISO-3166-1 Alpha-2 encoding.

See code list on Country Codes for details.

Table 2. CountryCode.Type
Component	Use	Primitive Type	Example
Content	Mandatory	String	`AT`

5.2.2. Identifier

Identifiers (IDs) are keys that are issued to uniquely identify something.

The use of the attributes is specified for each information element.

Table 3. Identifier.Type
Component	Use	Primitive Type	Example
Content	Mandatory	String	`example-value`
Scheme identifier	Conditional	String	`example-scheme`

5.2.3. Text

Text is the actual wording of anything written or printed. Line breaks in the text may be present, and any line breaks should be preserved and respected by the receiver’s system

Table 4. Text.Type
Component	Use	Primitive Type	Example
Content	Mandatory	String	`Here is my example text`

5.2.4. Date

Dates shall be in accordance to the "Calendar date complete representation" as specified by ISO 8601, in the format YYYY-MM-DD.

Date values MUST NOT include timezone information.

Table 5. Date.Type
Component	Use	Primitive Type	Example
Content	Mandatory	Date	2022-11-04

6. Code Lists

6.1. Country Codes

Country Codes are identifiers designed to identify countries. Country Codes must be coded according to the ISO-3166-1 Alpha-2 encoding.

Document location	`tsr:TransactionStatisticsReport/tsr:Subtotal/tsr:Key[@metaSchemeID="CC"]`
Source code list	Country Codes code list

Document location

tsr:TransactionStatisticsReport/tsr:Subtotal/tsr:Key[@metaSchemeID="CC"]

Source code list

Country Codes code list

6.2. Document Type Identifiers

Document Type Identifiers (aka Dataset Type Identifiers) are used to uniquely identify the type of a Peppol business document instance.

Document location	`tsr:TransactionStatisticsReport/tsr:Subtotal/tsr:Key[@metaSchemeID="DT"]`
Source code list	Document Type Identifiers (latest version)

Document location

tsr:TransactionStatisticsReport/tsr:Subtotal/tsr:Key[@metaSchemeID="DT"]

Source code list

Document Type Identifiers (latest version)

6.3. Process Identifiers

Process Identifiers define the orchestrations in which business documents are exchanged. A Process Identifier Value is referenced in a Peppol specification as "profile identifier" *.

Document location	`tsr:TransactionStatisticsReport/tsr:Subtotal/tsr:Key[@metaSchemeID="PR"]`
Source code list	Process Identifiers (latest version)

Document location

tsr:TransactionStatisticsReport/tsr:Subtotal/tsr:Key[@metaSchemeID="PR"]

Source code list

Process Identifiers (latest version)

6.4. Reporter Identification Scheme

Reporter Identification Schemes are used to identify the Service Provider inside the Transaction Statistics Report.

Document location	`tsr:TransactionStatisticsReport/tsr:Header/tsr:ReporterID/@schemeID tsr:TransactionStatisticsReport/tsr:Subtotal/tsr:Key[@metaSchemeID="SP"]/@schemeID`
Source code list	Reporter ID Scheme code list

Document location

tsr:TransactionStatisticsReport/tsr:Header/tsr:ReporterID/@schemeID tsr:TransactionStatisticsReport/tsr:Subtotal/tsr:Key[@metaSchemeID="SP"]/@schemeID

Source code list

Reporter ID Scheme code list

6.5. Subtotal Key Meta Scheme

The Subtotal Key Meta Scheme defines the type of a single key in a subtotal.

Document location	`tsr:TransactionStatisticsReport/tsr:Subtotal/tsr:Key/@metaSchemeID`
Source code list	Subtotal Key Meta Scheme code list

Document location

tsr:TransactionStatisticsReport/tsr:Subtotal/tsr:Key/@metaSchemeID

Source code list

Subtotal Key Meta Scheme code list

6.6. Subtotal Type

The Subtotal Type determines the kind of aggregation that is contained in a subtotal element. It determines the amount and types of keys for a subtotal.

Document location	`tsr:TransactionStatisticsReport/tsr:Subtotal/@type`
Source code list	Subtotal Type code list

Document location

tsr:TransactionStatisticsReport/tsr:Subtotal/@type

Source code list

Subtotal Type code list

6.7. Transport Profiles

Transport Profiles are used to uniquely identify the technical protocol profile with which the data exchange happens.

Document location	`tsr:TransactionStatisticsReport/tsr:Subtotal/tsr:Key[@metaSchemeID="TP"]`
Source code list	Transport Profiles (latest version)

Document location

tsr:TransactionStatisticsReport/tsr:Subtotal/tsr:Key[@metaSchemeID="TP"]

Source code list

Transport Profiles (latest version)

7. Specification Identifiers

In the table below you will find the values to be used as the specification identifier and the business process type for this profile

Type Element CustomizationID Process ID

Type	Element `CustomizationID`	Process ID
Transaction Statistics Report	`urn:fdc:peppol.eu:edec:trns:transaction-statistics-reporting:1.0`	`urn:fdc:peppol.eu:edec:bis:reporting:1.0`

Transaction Statistics Report

urn:fdc:peppol.eu:edec:trns:transaction-statistics-reporting:1.0

urn:fdc:peppol.eu:edec:bis:reporting:1.0

XML example representation

<tsr:CustomizationID>urn:fdc:peppol.eu:edec:trns:transaction-statistics-reporting:1.0</tsr:CustomizationID>
<tsr:ProfileID>urn:fdc:peppol.eu:edec:bis:reporting:1.0</tsr:ProfileID>

Full Peppol Document Type identifier

urn:fdc:peppol:transaction-statistics-report:1.0::TransactionStatisticsReport##urn:fdc:peppol.eu:edec:trns:transaction-statistics-reporting:1.0::1.0

8. Appendix 1 (non-normative)

The following example report represents a valid example message. This example represents the data for a Service Provider that both sent and received documents within a Reporting Period.

<?xml version="1.0" encoding="UTF-8"?>
<TransactionStatisticsReport xmlns="urn:fdc:peppol:transaction-statistics-report:1.0">
  <CustomizationID>urn:fdc:peppol.eu:edec:trns:transaction-statistics-reporting:1.0</CustomizationID>
  <ProfileID>urn:fdc:peppol.eu:edec:bis:reporting:1.0</ProfileID>
  <Header>
    <ReportPeriod>
      <StartDate>2023-12-01</StartDate>
      <EndDate>2023-12-31</EndDate>
    </ReportPeriod>
    <ReporterID schemeID="CertSubjectCN">POP000360</ReporterID>
  </Header>
  <!-- Totals -->
  <Total>
    <Incoming>27</Incoming>
    <Outgoing>23</Outgoing>
  </Total>
  <!-- SubTotals per Transport Protocol -->
  <!-- Sum per TP must match TotalCount -->
  <Subtotal type="PerTP">
    <Key metaSchemeID="TP" schemeID="Peppol">peppol-transport-as4-v2_0</Key>
    <Incoming>27</Incoming>
    <Outgoing>23</Outgoing>
  </Subtotal>
  <!-- SubTotals per Service Provider, Dataset Type and Process ID -->
  <!-- Sum must match TotalCount -->
  <Subtotal type="PerSP-DT-PR">
    <Key metaSchemeID="SP" schemeID="CertSubjectCN">POP000001</Key>
    <Key metaSchemeID="DT" schemeID="busdox-docid-qns">urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1</Key>
    <Key metaSchemeID="PR" schemeID="cenbii-procid-ubl">urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</Key>
    <Incoming>2</Incoming>
    <Outgoing>0</Outgoing>
  </Subtotal>
  <Subtotal type="PerSP-DT-PR">
    <Key metaSchemeID="SP" schemeID="CertSubjectCN">POP000001</Key>
    <Key metaSchemeID="DT" schemeID="busdox-docid-qns">urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1</Key>
    <Key metaSchemeID="PR" schemeID="cenbii-procid-ubl">urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</Key>
    <Incoming>13</Incoming>
    <Outgoing>11</Outgoing>
  </Subtotal>
  <Subtotal type="PerSP-DT-PR">
    <Key metaSchemeID="SP" schemeID="CertSubjectCN">POP000001</Key>
    <Key metaSchemeID="DT" schemeID="busdox-docid-qns">urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-2::OrderResponse##urn:fdc:peppol.eu:poacc:trns:order_response:3::2.1</Key>
    <Key metaSchemeID="PR" schemeID="cenbii-procid-ubl">urn:fdc:peppol.eu:poacc:bis:ordering:3</Key>
    <Incoming>12</Incoming>
    <Outgoing>0</Outgoing>
  </Subtotal>
  <Subtotal type="PerSP-DT-PR">
    <Key metaSchemeID="SP" schemeID="CertSubjectCN">POP000002</Key>
    <Key metaSchemeID="DT" schemeID="busdox-docid-qns">urn:oasis:names:specification:ubl:schema:xsd:Order-2::Order##urn:fdc:peppol.eu:poacc:trns:order:3::2.1</Key>
    <Key metaSchemeID="PR" schemeID="cenbii-procid-ubl">urn:fdc:peppol.eu:poacc:bis:ordering:3</Key>
    <Incoming>0</Incoming>
    <Outgoing>12</Outgoing>
  </Subtotal>
  <!-- SubTotals per Service Provider, Dataset Type, Process ID and Country Codes -->
  <!-- Sum of incoming must match TotalCount -->
  <Subtotal type="PerSP-DT-PR-CC">
    <Key metaSchemeID="SP" schemeID="CertSubjectCN">POP000001</Key>
    <Key metaSchemeID="DT" schemeID="busdox-docid-qns">urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1</Key>
    <Key metaSchemeID="PR" schemeID="cenbii-procid-ubl">urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</Key>
    <Key metaSchemeID="CC" schemeID="SenderCountry">BE</Key>
    <Key metaSchemeID="CC" schemeID="ReceiverCountry">DE</Key>
    <Incoming>2</Incoming>
    <Outgoing>0</Outgoing>
  </Subtotal>
  <Subtotal type="PerSP-DT-PR-CC">
    <Key metaSchemeID="SP" schemeID="CertSubjectCN">POP000001</Key>
    <Key metaSchemeID="DT" schemeID="busdox-docid-qns">urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1</Key>
    <Key metaSchemeID="PR" schemeID="cenbii-procid-ubl">urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</Key>
    <Key metaSchemeID="CC" schemeID="SenderCountry">DE</Key>
    <Key metaSchemeID="CC" schemeID="ReceiverCountry">AT</Key>
    <Incoming>4</Incoming>
    <Outgoing>0</Outgoing>
  </Subtotal>
  <Subtotal type="PerSP-DT-PR-CC">
    <Key metaSchemeID="SP" schemeID="CertSubjectCN">POP000001</Key>
    <Key metaSchemeID="DT" schemeID="busdox-docid-qns">urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1</Key>
    <Key metaSchemeID="PR" schemeID="cenbii-procid-ubl">urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</Key>
    <Key metaSchemeID="CC" schemeID="SenderCountry">DE</Key>
    <Key metaSchemeID="CC" schemeID="ReceiverCountry">DE</Key>
    <Incoming>9</Incoming>
    <Outgoing>0</Outgoing>
  </Subtotal>
  <Subtotal type="PerSP-DT-PR-CC">
    <Key metaSchemeID="SP" schemeID="CertSubjectCN">POP000001</Key>
    <Key metaSchemeID="DT" schemeID="busdox-docid-qns">urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-2::OrderResponse##urn:fdc:peppol.eu:poacc:trns:order_response:3::2.1</Key>
    <Key metaSchemeID="PR" schemeID="cenbii-procid-ubl">urn:fdc:peppol.eu:poacc:bis:ordering:3</Key>
    <Key metaSchemeID="CC" schemeID="SenderCountry">DE</Key>
    <Key metaSchemeID="CC" schemeID="ReceiverCountry">AT</Key>
    <Incoming>7</Incoming>
    <Outgoing>0</Outgoing>
  </Subtotal>
  <Subtotal type="PerSP-DT-PR-CC">
    <Key metaSchemeID="SP" schemeID="CertSubjectCN">POP000001</Key>
    <Key metaSchemeID="DT" schemeID="busdox-docid-qns">urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-2::OrderResponse##urn:fdc:peppol.eu:poacc:trns:order_response:3::2.1</Key>
    <Key metaSchemeID="PR" schemeID="cenbii-procid-ubl">urn:fdc:peppol.eu:poacc:bis:ordering:3</Key>
    <Key metaSchemeID="CC" schemeID="SenderCountry">DE</Key>
    <Key metaSchemeID="CC" schemeID="ReceiverCountry">DE</Key>
    <Incoming>5</Incoming>
    <Outgoing>0</Outgoing>
  </Subtotal>
</TransactionStatisticsReport>

9. Appendix 2 (non-normative)

The following example report represents a valid example message. This example represents a message in case no transmissions were performed within a Reporting Period.

<?xml version="1.0" encoding="utf-8"?>
<TransactionStatisticsReport xmlns="urn:fdc:peppol:transaction-statistics-report:1.0">
  <CustomizationID>urn:fdc:peppol.eu:edec:trns:transaction-statistics-reporting:1.0</CustomizationID>
  <ProfileID>urn:fdc:peppol.eu:edec:bis:reporting:1.0</ProfileID>
  <Header>
    <ReportPeriod>
      <StartDate>2023-12-01</StartDate>
      <EndDate>2023-12-31</EndDate>
    </ReportPeriod>
    <ReporterID schemeID="CertSubjectCN">POP000360</ReporterID>
  </Header>
  <!-- Totals -->
  <Total>
    <Incoming>0</Incoming>
    <Outgoing>0</Outgoing>
  </Total>
  <!-- No Subtotal because they would all contain only zeroes -->
</TransactionStatisticsReport>