This document provides guidance for the implementation of Peppol order and despatch advice processes for Finnish retail sector.

Peppol is a network and specification of electronic business transactions. It is used to exchange information between organizations in a structured way. Peppol network is based on the so called four corner model. It means that every end user organization is free to choose their own Peppol service provider without having to consider which service provider their business partners use. Everyone has to connect just once to a Peppol service provider in order to exchange electronic business documents with all other end users in the Peppol network.

Peppol is not a procurement system, a portal or an ERP. It enables different organizations to connect their information systems together and offers a shared digital language for organizations all over the world.

This implementation guide is focused on the data needs of Finnish retail sector. Any rules that apply to the usage of Peppol in general are not changed by this document. This document does not cover all possible scenarios. Please refer to general Peppol BIS guidelines if something is not stated here. For example, all currencies, dates, times, decimals and code lists are to be used as instructed in the general Peppol guidelines.

Change management

This implementation guide was created in a shared effort by Finnish Commerce Federation, SOK, Kesko, Maalarimestarien Oy and the Peppol Authority of Finland (State Treasury).

In case you have questions or there is need to update this implementation guide, please contact State Treasury via email at peppol@valtiokonttori.fi. The State Treasury will contact Finnish Commerce Federation who will in turn gather relevant parties to the update process.

Covered Business Interoperability Specifications

This implementation guide covers three different Business Interoperability Specifications (BIS) used in the Peppol network. They are Order Only, Ordering and Despatch Advice. It is up to the business partners to choose which ones they agree to use. Order Only and Ordering differ from each other regarding the usage of order response transaction. One might be more suitable for some scenarios than the other.

BIS Order Only

BIS Order Only covers the order transaction. The supplier will not respond to the order transaction with an order response. The syntax of the Peppol Order transaction (T01) is covered later in this document.

However, Finnish retailers generally expect to receive a Despatch Advice transaction for the deliveries of the order.

BIS Ordering

BIS Ordering covers order and order response transactions. The supplier must respond to each order with an order response transaction. The order response transaction is used to tell the buyer that the order was received, accepted, declined or accepted partially. Information about delivery dates can be added to the order response.

This implementation guide excludes the usage of Substituted Line Items in the order response transaction. In retail the seller might not be able to tell which two items are similar enough to be substitutes for one another.

The syntaxes of the Peppol Order transaction (T01) and Peppol Order Response transaction (T76) are covered later in this document.

BIS Despatch Advice

BIS Despatch Advice covers the despatch advice transaction. The recipient will not respond to the despatch advice transaction. The despatch advice transaction is used to notify the recipient party that a shipment has been sent. It also conveys information about shipped goods and delivery dates.

There are two ways to use the BIS Despatch Advice: with or without a dedicated Despatch party.

The syntax of the Peppol Despatch Advice transaction (T16) is covered later in this document.

Order

The whole syntax of the Peppol Order transaction (T01) is covered on the Peppol website. This implementation guide does not add any additional elements to the syntax. All general Peppol rules must be followed. It is forbidden to use an element for some other purpose than what it was intended to be used for. Please refer to the general Peppol guidance if some element is not covered in this implementation guide.

Document header level

cbc:ID is the order number, the main identifier for this document. It is a mandatory field.

cbc:OrderTypeCode is used to indicate what kind of order transaction is being sent. The default value is “220”, which means Purchase order. Other options are listed in code list Order type code (UNCL1001 subset) which is mandatory to use if this element is used.

cbc:Note is a document level textual note. It can be used if there is no other explicit place for the information in the document.

cbc:DocumentCurrencyCode contains the default currency of the document. For euros, use “EUR”.

cbc:CustomerReference is used for the store ID related to the order. When given, CustomerReference is expected to be transmitted in the invoice (as BuyerReference in Peppol Invoice).

cbc:AccountingCost is used for automating the posting to accounts at the invoice recipient. When given, AccountingCost is expected to be transmitted in the invoice (as AccountingCost in Peppol Invoice).

cac:ValidityPeriod / cbc:EndDate should be used to indicate for how long an order is valid before it expires. It is not a mandatory element in the syntax, but a validation warning will be displayed if it is not used.

cac:OriginatorDocumentReference / cbc:ID can be used for the originating order number of the store.

Structure of Order transaction

<?xml version=”1.0″ encoding=”UTF-8″?>
<Order xmlns=”urn:oasis:names:specification:ubl:schema:xsd:Order-2″
xmlns:cac=”urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2″
xmlns:cbc=”urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2″>
<cbc:CustomizationID>urn:fdc:peppol.eu:poacc:trns:order:3</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:poacc:bis:order_only:3</cbc:ProfileID>
<cbc:ID>1234567</cbc:ID>
<cbc:SalesOrderID>6412234566</cbc:SalesOrderID>
<cbc:IssueDate>2024-08-14</cbc:IssueDate>
<cbc:OrderTypeCode>220</cbc:OrderTypeCode>
<cbc:Note>Information text for the whole order</cbc:Note>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cbc:CustomerReference>M001</cbc:CustomerReference>
<cbc:AccountingCost>0123456</cbc:AccountingCost>
<cac:ValidityPeriod>
<cbc:EndDate>2024-08-25</cbc:EndDate>
</cac:ValidityPeriod>
<cac:OriginatorDocumentReference>
<cbc:ID>123456</cbc:ID>
</cac:OriginatorDocumentReference>
<cac:Contract>
<cbc:ID>6412345678</cbc:ID>
</cac:Contract>
<cac:ProjectReference>
<cbc:ID>PID33</cbc:ID>
</cac:ProjectReference>
…
</Order>

Parties

Buyer Customer Party

The buyer is the legal person or organization acting on behalf of the customer and who buys or purchases the goods or services. (NAD+BY in EDIFACT.)

cbc:EndpointID is used to convey the electronic address of the buyer. The @schemeID is mandatory to be used with the EndpointID element. For Finnish organisations the EndpointID is always an OVT code with scheme ID 0216. Examples of cbc:EndpointID and @schemeID values:

cac:PartyIdentification / cbc:ID can contain an internal ID understood by buyer and/or seller. @schemeID is not mandatory for this field.

cac:PartyName / cbc:Name is the trading name of the party. It does not have to be an official name registered with the Company identification code.

cac:PartyTaxScheme / cbc:CompanyID contains the buyer’s VAT identification code in international format. For Finnish companies this is ‘FI’ + company ID (Y-tunnus) without the dash mark ‘-’. cbc:TaxScheme / cbc:ID should be “VAT”.

cac:PartyLegalEntity / cbc:RegistrationName is the official legal name of the party.

Example of BuyerCustomerParty segment

<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID=”0216″>003712345678</cbc:EndpointID
<cac:PartyIdentification>
<cbc:ID>M001</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Buyer Oy</cbc:Name>
</cac:PartyName>
<cac:PartyTaxScheme>
<cbc:CompanyID>FI12345678</cbc:CompanyID>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:PartyTaxScheme>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Oy Buyer AB</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:BuyerCustomerParty>

Seller Supplier Party

The seller is the legal person or organization acting on behalf of the supplier and who sells goods or services to the customer. (NAD+SE in EDIFACT.)

cbc:EndpointID is used to convey the electronic address of the seller. The @schemeID is mandatory to be used with the EndpointID element. For Finnish organisations the EndpointID is always an OVT code with scheme ID 0216. Examples of cbc:EndpointID and @schemeID values:

cac:PartyIdentification / cbc:ID can contain an internal ID understood by buyer and/or seller. @schemeID is not mandatory for this field.

cac:PartyName / cbc:Name is the trading name of the party. It does not have to be an official name registered with the Company identification code.

cac:PartyLegalEntity / cbc:RegistrationName is the official legal name of the party.

Example of SellerSupplierParty segment

<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID=”0216″>003798765432</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID>S001</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Seller Oy</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cac:Country>
<cbc:IdentificationCode>FI</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Oy Seller Ab</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:SellerSupplierParty>

Originator Customer Party

cac:OriginatorCustomerParty is optional and Finnish retail sector does not expect the message recipient to process it. However, OriginatorCustomerParty may give clarification on the party that is responsible for the creation of the order. The Originator party has delegated the buying process to the buyer party.

cac:PartyIdentification / cbc:ID can be used to convey the store ID. @schemeID is not used for internal identifications (not a mandatory element for OriginatorCustomerParty).

Example of OriginatorCustomerParty segment

<cac:OriginatorCustomerParty>
<cac:Party>
<cac:PartyIdentification>
<cbc:ID>A012</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Originator Store</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:OriginatorCustomerParty>

Accounting Customer Party

cac:AccountingCustomerParty is used to relay the information of the invoice recipient. The invoice must be sent to this party. The supplier must be able to process the information about this party. In Peppol BIS Billing (Invoice) this party is mapped to cac:PayeeParty. (NAD+IV in EDIFACT.)

cbc:EndpointID is the electronic identifier to which the invoice is to be sent. Electronic invoices can be delivered in Peppol, eInvoice or EDIFACT formats. From these options Peppol is preferred because Peppol has the proper message content validation rules, ensuring the recipient receives valid data. For Finnish organisations using Peppol the EndpointID is always an OVT code with scheme ID 0216.

cac:PartyIdentification / cbc:ID can be used to convey the store ID. @schemeID is not used for internal identifications.

Example of AccountingCustomerParty segment

<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID=”0216″>003774433221</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID>L123</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Invoice Receiver</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Mannerheimintie 1</cbc:StreetName>
<cbc:CityName>Helsinki</cbc:CityName>
<cbc:PostalZone>00100</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>FI</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Oy Invoice Receiver AB</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingCustomerParty>

Delivery

Delivery information can be given both at the header and line level. If both levels are used, line level information overrides the header level information for that specific line.

Structure of Delivery segment

<cac:Delivery>
<cac:DeliveryLocation>…</cac:DeliveryLocation>
<cac:RequestedDeliveryPeriod>…</cac:RequestedDeliveryPeriod>
<cac:DeliveryParty>…</cac:DeliveryParty>
<cac:Shipment>…</cac:Shipment>
</cac:Delivery>

Delivery Location

cac:DeliveryLocation / cbc:ID is used for identifying the delivery location. While the use of @schemeID is optional, it should be given when presenting registered identifiers such as GLN code (complete list available at ISO 6523 ICD list). DeliveryLocation can be thought of as “Consignee”. (NAD+CN in EDIFACT.)

Examples of cbc:DeliveryLocation/cbc:ID and @schemeID values:

cbc:Name should be used alongside the GLN code to make the location easier to read for humans.

cac:Address tree is used to indicate the delivery address. This can be different from the address in BuyerCustomerParty or AccountingCustomerParty. cac:AddressLine / cbc:Line can be used for a more specific location, such as “Gate 34”.

Example of DeliveryLocation segment

<cac:DeliveryLocation>
<cbc:ID schemeID=”0088″>12345678900</cbc:ID>
<cbc:Name>Name of the warehouse, terminal, store</cbc:Name>
<cac:Address>
<cbc:StreetName>Mannerheimintie 1</cbc:StreetName>
<cbc:CityName>Helsinki</cbc:CityName>
<cbc:PostalZone>00100</cbc:PostalZone>
<cac:AddressLine>
<cbc:Line>Platform 23</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode>FI</cbc:IdentificationCode>
</cac:Country>
</cac:Address>
</cac:DeliveryLocation>

Requested Delivery Period

Unlike the standard approach in EDIFACT transactions, Peppol uses a more complex cac:RequestedDeliveryPeriod structure to represent delivery dates. cbc:StartDate and cbc:EndDate are expected on the message. cbc:StartTime and cbc:EndTime are optional but in some business cases important. If the delivery must be completed on a specific date, the start and end date should be the same.

Example of RequestedDeliveryPeriod segment

<cac:RequestedDeliveryPeriod>
<cbc:StartDate>2024-08-25</cbc:StartDate>
<cbc:StartTime>06:00:00</cbc:StartTime>
<cbc:EndDate>2024-08-25</cbc:EndDate>
<cbc:EndTime>08:00:00</cbc:EndTime>
</cac:RequestedDeliveryPeriod>

Delivery Party

cac:DeliveryParty is the party to whom the goods are delivered. (NAD+DP in EDIFACT.)

cac:PartyIdentification / cbc:ID contains the identification of the delivery party. @schemeID should be used if the identification is based on an official register. Examples of cbc:ID and @schemeID values:

cac:PostalAddress contains the final address for the delivery.

cac:Contact is used for the contact details of the goods recipient. In order to limit the GDPR scope, avoid using personal names, phone numbers and email addresses, if possible.

Example of DeliveryParty segment

<cac:DeliveryParty>
<cac:PartyIdentification>
<cbc:ID>L123</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Delivery recipient store</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Mannerheimintie 1</cbc:StreetName>
<cbc:CityName>Helsinki</cbc:CityName>
<cbc:PostalZone>00100</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>FI</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:Contact>
<cbc:Telephone>+3585401234567</cbc:Telephone>
<cbc:ElectronicMail>info@deliverystore.fi</cbc:ElectronicMail>
</cac:Contact>
</cac:DeliveryParty>

Shipment

The buyer may give shipment instructions for the supplier in cac:Shipment segment. This information may be needed on the physical packaging label as well.

cac:Shipment / cbc:ID is a mandatory element required by UBL when Shipment is used. In Peppol this element is not used. Use value “NA” if you provide any information on the cac:Shipment tree.

cac:TransportHandlingUnit / cbc:ShippingMarks can be used for shipping instructions (such as shipping conditions, shipping zone, route) in a format that is agreed between the buyer and the seller. (For the time being the cardinality of cac:TransportHandlingUnit and cbc:ShippingMarks is 0..1 in Peppol; this could be 0..n).

Example of Shipment segment

<cac:Shipment>
<cbc:ID>NA</cbc:ID>
<cac:TransportHandlingUnit>
<cbc:ShippingMarks>01:138B1:18EJ38:102203755</cbc:ShippingMarks>
</cac:TransportHandlingUnit>
</cac:Shipment>

DeliveryTerms

cac:DeliveryTerms uses Incoterms for fields cbc:ID and cac:DeliveryLocation, unless otherwise agreed between the sender and receiver. cbc:SpecialTerms can be used to indicate some special terms related to the delivery, such as a requirement for refrigeration.

Example of DeliveryTerms segment

<cac:DeliveryTerms>
<cbc:ID>FCA</cbc:ID>
<cbc:SpecialTerms>Special terms</cbc:SpecialTerms>
</cac:DeliveryTerms>

TaxTotal

TaxTotal segment is an optional but recommended segment when AncitipatedMonetaryTotal segment is filled.

cac:TaxAmount is sum of all tax subcategory amounts. This sum is the expected Tax Total on the invoice.

Example of TaxTotal segment

<cac:TaxTotal>
<cbc:TaxAmount currencyID=”EUR”>16.80</cbc:TaxAmount>
</cac:TaxTotal>

AnticipatedMonetaryTotal

AnticipatedMonetaryTotal segment is an optional but recommended segment when order lines have prices.

cac:LineExtensionAmount is the sum of line amounts in the document (net of tax).

cbc:PayableAmount is the amount that is expected to be paid with the invoice.

Example of AnticipatedMonetaryTotal segment

<cac:AnticipatedMonetaryTotal>
<cbc:LineExtensionAmount currencyID=”EUR”>120.00</cbc:LineExtensionAmount>
<cbc:PayableAmount currencyID=”EUR”>136.80</cbc:PayableAmount>
</cac:AnticipatedMonetaryTotal>

Order lines

cbc:Note is a free text element that can be used to tell something about the order line that does not have an explicit place in the message otherwise. This can be, for example, information about an ongoing campaign.

cbc:Quantity is used to indicate the quantity of ordered goods. @unitCode is a mandatory element to indicate the unit of measure. See Appendix A for the usage of unitCode.

cbc:PartialDeliveryIndicator is used if backordering is allowed. By default, all ordered goods must be delivered in a single shipment and in this case PartialDeliveryIndicator = ‘false’. It is up to the seller and the buyer to agree if backordering is allowed.

cac:Price indicates the price of the line item by using cbc:PriceAmount and cbc:BaseQuantity elements.

cac:Item provides the item details such as cbc:Description or cbc:Name. The Item structure also contains four types of item identifiers:

• cac:BuyersItemIdentification / cbc:ID is an identifier given by the buyer.
• cac:SellersItemIdentification / cbc:ID is an identifier given by the seller.
• cac:ManufacturersItemIdentification / cbc:ID is an identifier given by the manufacturer.
• cac:StandardItemIdentification / cbc:ID is a standardized identifier. @schemeID is mandatory element to indicate type of the identifier. The standard used must be from the ISO 6523 ICD list. The most common standard identifier is GTIN (EAN), and it gets the value “0160” in @schemeID field.

cac:AdditionalItemProperty structure can be used to convey information that does not have a specific place in the order line. See Appendix B for usage of cac:AdditionalItemProperty.

Example of OrderLine segment (Order transaction)

<cac:OrderLine>
<cbc:Note>Additional information related to the order line</cbc:Note>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:Quantity unitCode=”EA”>50</cbc:Quantity>
<cbc:LineExtensionAmount currencyID=”EUR”>25</cbc:LineExtensionAmount>
<cbc:PartialDeliveryIndicator>false</cbc:PartialDeliveryIndicator>
<cac:Price>
<cbc:PriceAmount currencyID=”EUR”>0.50</cbc:PriceAmount>
<cbc:BaseQuantity unitCode=”EA”>1</cbc:BaseQuantity>
</cac:Price>
<cac:Item>
<cbc:Description>Milk carton</cbc:Description>
<cbc:Name>Milk</cbc:Name>
<cac:BuyersItemIdentification>
<cbc:ID>12345678</cbc:ID>
</cac:BuyersItemIdentification>
<cac:SellersItemIdentification>
<cbc:ID>87654321</cbc:ID>
</cac:SellersItemIdentification>
<cac:StandardItemIdentification>
<cbc:ID schemeID=”0160″>6412345678901</cbc:ID>
</cac:StandardItemIdentification>
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>14</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:ClassifiedTaxCategory>
<cac:AdditionalItemProperty>
<cbc:Name>Storage facility</cbc:Name>
<cbc:Value>SÄILYTETÄVÄ VIILEÄSSÄ</cbc:Value>
<cbc:ValueQualifier>HAN+:264</cbc:ValueQualifier>
</cac:AdditionalItemProperty>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>

Order response

The whole syntax of the Peppol Order Response transaction (T76) is covered in the Peppol website. This implementation guide does not add any additional elements to the syntax. All general Peppol rules must be followed. It is forbidden to use an element for some other purpose than what it was intended to be used for. Please refer to the general Peppol guidance if some element is not covered in this implementation guide.

Document header level

cbc:ID is the order response number, the main identifier for this document. It is a mandatory field.

cbc:SalesOrderID is the seller’s sales order number. It can be useful when troubleshooting.

cbc:IssueDate is the date when the order response was issued.

cbc:OrderResponseCode is used to tell what the response to the order is. Order Response type code (UNCL4343 Subset) code list is used. The possible values are:

• “AB”: Message acknowledgement. No order lines shall be sent. This is an indication that the order has been received but not processed yet. A new order response transaction should be sent after the order has been processed.
• “AP”: Accepted. If the order is accepted with the code AP, no order lines shall be sent. Only header level data which includes a possibility to add Delivery information.
• “RE”: Rejected. If the order is rejected with the code RE, no order lines shall be sent. cbc:Note will be used to clarify the reason behind the rejection.
• “CA”: Conditionally accepted. All order lines shall be sent, even if no changes are made to the specific order line. The business partners need to agree if the orders can be conditionally accepted. Backordering or partial deliveries are not feasible in every situation. Use of Substitute line items is not covered by this implementation guide. It must be agreed by the business partners if they want to allow usage of substituted line items.

cbc:Note may contain supplier’s clarification regarding the order response.

cbc:DocumentCurrencyCode contains the default currency of the document. For euros, use “EUR”.

cbc:CustomerReference should contain the cbc:CustomerReference input from the Order message. For Order response this is optional (customer reference is more important on the invoice message).

cbc:OrderReference / cbc:ID must contain cbc:ID from the Order message.

Structure of Order response transaction

<?xml version=”1.0″ encoding=”UTF-8″?>

<OrderResponse
xmlns=”urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-2″
xmlns:cac=”urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2″
xmlns:cbc=”urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2″>
<cbc:CustomizationID>urn:fdc:peppol.eu:poacc:trns:order_response:3</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:poacc:bis:ordering:3</cbc:ProfileID>
<cbc:ID>7654321</cbc:ID>
<cbc:SalesOrderID>6412234566</cbc:SalesOrderID>
<cbc:IssueDate>2024-08-15</cbc:IssueDate>
<cbc:OrderResponseCode>CA</cbc:OrderResponseCode>
<cbc:Note>Order accepted with a changed delivery date</cbc:Note>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cbc:CustomerReference>M001</cbc:CustomerReference> <!– Store number–>
<cac:OrderReference>
<cbc:ID>1234567</cbc:ID>
</cac:OrderReference>
…
</OrderResponse>

Parties

Seller Supplier Party

The seller is the legal person or organization acting on behalf of the supplier and who sells goods or services to the customer. (NAD+SE in EDIFACT.)

cbc:EndpointID is used to convey the electronic address of the seller. The @schemeID is mandatory to be used with the EndpointID element. Examples of cbc:EndpointID and @schemeID values:

cac:PartyIdentification / cbc:ID can contain an internal ID understood by buyer and/or seller. @schemeID is not mandatory for this field.

cac:PartyLegalEntity / cbc:RegistrationName should be used for the official legal name of the party. It is not possible to use the trading name in the order response message.

Example of SellerSupplierParty segment

<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID=”0216″>003798765432</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID>S001</cbc:ID>
</cac:PartyIdentification>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Oy Seller Ab</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:SellerSupplierParty>

Buyer Supplier Party

The buyer is the legal person or organization acting on behalf of the customer and who buys or purchases the goods or services. (NAD+BY in EDIFACT.)

cbc:EndpointID is used to convey the electronic address of the buyer. The @schemeID is mandatory to be used with the EndpointID element. Examples of cbc:EndpointID and @schemeID values:

cac:PartyIdentification / cbc:ID can be used to identify the party. @schemeID is not mandatory for this field.

cac:PartyLegalEntity / cbc:RegistrationName should be used for the official legal name of the party. It is not possible to use the trading name in the order response message.

Example of BuyerCustomerParty segment

<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID=”0216″>003712345678</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID>M001</cbc:ID>
</cac:PartyIdentification>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Oy Buyer AB</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:BuyerCustomerParty>

Delivery

Unlike the standard approach in EDIFACT transactions, Peppol uses a more complex cac:PromisedDeliveryPeriod structure to represent delivery dates. cbc:StartDate and  cbc:StartTime are expected on the message. cbc:EndDate and cbc:EndTime are optional but in some business cases important. If the delivery must be completed on a specific date, the start and end date should be the same. This element can be added even if the order is accepted with the code AP.

The delivery information can also be conveyed at line level cac:PromisedDeliveryPeriod. But only if response code CA is used.

Example of Delivery segment

<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2024-08-30</cbc:StartDate>
<cbc:EndDate>2024-08-30</cbc:EndDate>
</cac:PromisedDeliveryPeriod>
</cac:Delivery>

Order lines

Order lines are only sent if the order is accepted with the code CA.

cbc:Note can be used to convey information that does not have explicit please in the order response transaction.

cbc:LineStatusCode is used to tell if the order line has been accepted or changed in any way. A code list Action code (UNCL1229) must be used. The possible values are:

• “1” Order line is added
• “3” Changed
• “5” Accepted without amendment.
• “7” Not accepted
• “42” Already delivered

cbc:Quantity describes the quantity of items that the supplier promises to deliver. For Quantity, unit of measure must be provided in @unitCode element. See Appendix A for the usage of unitCode.

cbc:MaximumBackorderQuantity must be agreed by the business parties if backorder is allowed. If it is allowed, this element is used to tell the quantity of the goods that will be delivered at a later date.

The price information is optional but can be delivered in the cac:Price structure by using cbc:PriceAmount and cbc:BaseQuantity elements. The retail sector does not accept price changes without negotiations in beforehand.

Compared to the order transaction, the item details are more restricted in the order response.

cac:Item / cbc:Name contains the item name (longer item description is not needed here).

Identification of the goods can be done in three different ways:

• cac:BuyersItemIdentification / cbc:ID is an ID given by the buyer.
• cac:SellersItemIdentification / cbc:ID is an ID given by the seller.
• cac:StandardItemIdentification / cbc:ID is a standardized identifier. @schemeID is a mandatory element to indicate type of the identifier. The standard used must be from the ISO 6523 ICD list code list. The most common standard identifier is GTIN (EAN), and it gets the value “0160” in @schemeID field.

Usage of cac:SellerSubstitutedLineItem is not covered by this implementation guide. The parties must agree beforehand if they which to allow substituted line items.

cac:OrderLineReference / cbc:LineID is a mandatory to be used which links the order response line to the order line.

Example of OrderLine segment (Order response transaction)

<cac:OrderLine>
<cac:LineItem
<cbc:ID>1</cbc:ID>
<cbc:Note>Accepted with a changed delivery date</cbc:Note>
<cbc:LineStatusCode>3</cbc:LineStatusCode>
<cbc:Quantity unitCode=”EA”>50</cbc:Quantity>
<cac:Price>
<cbc:PriceAmount currencyID=”EUR”>0.50</cbc:PriceAmount>
<cbc:BaseQuantity unitCode=”EA”>1</cbc:BaseQuantity>
</cac:Price>
<cac:Item>
<cbc:Name>Milk</cbc:Name>
<cac:BuyersItemIdentification>
<cbc:ID>12345678</cbc:ID>
</cac:BuyersItemIdentification>
<cac:SellersItemIdentification>
<cbc:ID>87654321</cbc:ID>
</cac:SellersItemIdentification>
<cac:StandardItemIdentification>
<cbc:ID schemeID=”0160″>6412345678901</cbc:ID>
</cac:StandardItemIdentification>
</cac:Item>
<cac:OrderLineReference>
<cbc:LineID>1</cbc:LineID>
</cac:OrderLineReference>
</cac:LineItem>
</cac:OrderLine>

Despatch advice

The whole syntax of the Peppol Despatch Advice transaction (T16) is covered in the Peppol website. This implementation guide does not add any additional elements to the syntax. All general Peppol rules must be followed. It is forbidden to use an element for some other purpose than what it was intended to be used for. Please refer to the general Peppol guidance if some element is not covered in this implementation guide.

Document header level

cbc:ID is the despatch advide number, the main identifier for this document. It is a mandatory field.

cbc:IssueDate is the date when the despatch advice was issued.

cbc:Note is a document level textual note. It can be used if there is no other explicit place in the document for it.

cac:OrderReference / cbc:ID Should not be provided on header level. OrderReference is to be provided at Despatch line level.

Structure of Despatch Advice transaction

<?xml version=”1.0″ encoding=”UTF-8″?>
<DespatchAdvice
xmlns=”urn:oasis:names:specification:ubl:schema:xsd:DespatchAdvice-2″
xmlns:cbc=”urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2″
xmlns:cac=”urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2″>
<cbc:CustomizationID>urn:fdc:peppol.eu:poacc:trns:despatch_advice:3</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:poacc:bis:despatch_advice:3</cbc:ProfileID>
<cbc:ID>123654</cbc:ID>
<cbc:IssueDate>2024-08-25</cbc:IssueDate>
<cbc:IssueTime>12:05:10</cbc:IssueTime>
…
</DespatchAdvice>

Parties

Despatch Supplier Party

Despatch Supplier Party – The Despatch Party is the person or organization who provides (despatch) the goods or services. The role is carried out by the supplier or on behalf of the supplier. Despatch Party is sometimes known as the Consignor. (NAD+CZ in EDIFACT.)

cbc:EndpointID is used to convey the electronic address of the buyer. The @schemeID is mandatory to be used with the EndpointID element. Examples of cbc:EndpointID and @schemeID values:

cac:PartyIdentification / cbc:ID  can be the same as EndpointID or it can be an internal identifier. PartyIndentification’s @schemeID is not mandatory.

cac:PartyLegalEntity / cbc:RegistrationName is the official legal name of the party.

Example of DespatchSupplierParty segment

<cac:DespatchSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID=”0216″>003798765432</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID>S001</cbc:ID>
</cac:PartyIdentification>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Oy Seller Ab</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:DespatchSupplierParty>

Delivery Customer Party

Delivery Customer Party – Consignee information. The Consignee is the person or organization to which the products will be shipped and who is taking possession. The role is carried out by the customer or on behalf of the customer. (NAD+CN in EDIFACT.) This should match DeliveryLocation in Order message.

cbc:EndpointID is used to convey the electronic address of the buyer. The @schemeID is mandatory to be used with the EndpointID element. Examples of cbc:EndpointID and @schemeID values:

cac:PartyIdentification / cbc:ID  can be the same as EndpointID or it can also be an internal identifier (PartyIndentification’s @schemeID is not mandatory)

cac:PartyLegalEntity / cbc:RegistrationName is the official legal name of the party.

Example of DeliveryCustomerParty segment

<cac:DeliveryCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID=”0216″>003774433221</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID>L123</cbc:ID>
</cac:PartyIdentification>
<cac:PostalAddress>
<cbc:StreetName>Mannerheimintie 1</cbc:StreetName>
<cbc:CityName>Helsinki</cbc:CityName>
<cbc:PostalZone>00100</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>FI</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Oy Delivery Recipient Store AB</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:DeliveryCustomerParty>

Buyer Customer Party

Buyer Customer Party – The buyer is the legal person or organization who buys or purchases the goods or services. The role is carried out by the customer or on behalf of the customer. (NAD+BY in EDIFACT.)

BuyerCustomerParty on despatch advice message should be the same as order message’s BuyerCustomerParty.

cac:PartyIdentification / cbc:ID can contain an internal ID understood by buyer and/or seller. @schemeID is not mandatory for this field. If EDI identifier is used for party identification, schemeID should be used.

cac:PartyName / cbc:Name is the name of the party.

cac:PostalAdress is optional for Buyer Customer Party in despatch advice.

Example of BuyerCustomerParty segment

<cac:BuyerCustomerParty>
<cac:Party>
<cac:PartyIdentification>
<cbc:ID>M001</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Buyer Oy</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:BuyerCustomerParty>

Seller Supplier Party

SellerSupplierParty of despatch advice message should be the same as order message’s SellerSupplierParty. However, the sender of the despatch advice knows the seller supplier party better than the buyer so the information on the despatch advice should be more reliable. (NAD+SE in EDIFACT.)

cac:PartyIdentification / cbc:ID can contain an internal ID understood by buyer and/or seller. As the PartyIndentification’s  is not mandatory the code can also be an internal code such as store ID.@schemeID is not mandatory the code can also be an internal code such as store ID.

cac:PartyName / cbc:Name is the name of the party.

cac:PostalAdress is optional for Buyer Customer Party in despatch advice.

Example of SellerSupplierParty segment

<cac:SellerSupplierParty>
<cac:Party>
<cac:PartyIdentification>
<cbc:ID>S001</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Seller Oy</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:SellerSupplierParty>

Shipment (header level)

cbc:ID is used for identifying the shipment.

cbc:Information is used to convey any information as free text that does not have an explicit place in the document tree otherwise.

Weights, Volumes and Quantities should be provided at the despatch line level.

cac:Consignment / cbc:ID is the identifier for the consignment (shipment).

cac:CarrierParty / cac:PartyIdentification / cbc:ID and cac:CarrierParty / cac:PartyName are optional but may be required by the buyer. The use of cac:Person should be avoided in order to reduce GDPR scope.

cac:ShipmentStage is not used.

cac:Delivery contains the estimated delivery date and time. In contrast to convention in EDIFACT transactions Peppol uses a more complex ﷟HYPERLINK “https://docs.peppol.eu/poacc/upgrade-3/syntax/DespatchAdvice/cac-Shipment/cac-Delivery/cac-EstimatedDeliveryPeriod/”cac:EstimatedDeliveryPeriod tree. , cbc:StartTime, cbc:EndDate and cbc:EndTime can be provided. If the delivery is required to be completed on a specific date, the StartDate and EndDate should be the same.cbc:StartDate, cbc:StartTime, cbc:EndDate and cbc:EndTime can be provided. If the delivery is required to be completed on a specific date, the StartDate and EndDate should be the same.

cac:Delivery also contains information about the despatch: when and where the shipment was made from. cbc:ActualDespatchDate, cbc:ActualDespatchTime and cac:DespatchAddress are used for this purpose. This information is mandated by the Finnish authorities for example on animal products.

Example of Shipment segment

<cac:Shipment>
<cbc:ID>67890</cbc:ID>
<cbc:Information>Additional information related to the shipment</cbc:Information>
<cac:Consignment>
<cbc:ID>09876</cbc:ID>
<cac:CarrierParty>
<cac:PartyIdentification>
<cbc:ID schemeID=”0216″>003712348679</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Carrier Oy</cbc:Name>
</cac:PartyName>
</cac:CarrierParty>
</cac:Consignment>
<cac:Delivery>
<cac:EstimatedDeliveryPeriod>
<cbc:StartDate>2025-08-25</cbc:StartDate>
<cbc:StartTime>06:00:00</cbc:StartTime>
<cbc:EndDate>2025-08-25</cbc:EndDate>
<cbc:EndTime>08:00:00</cbc:EndTime>
</cac:EstimatedDeliveryPeriod>
<cac:Despatch>
<cbc:ActualDespatchDate>2025-08-25</cbc:ActualDespatchDate>
<cbc:ActualDespatchTime>07:00:00</cbc:ActualDespatchTime>
<cac:DespatchAddress>
<cbc:ID schemeID=”0088″>12345678900</cbc:ID>
<cbc:StreetName>Mannerheimintie 1</cbc:StreetName>
<cbc:CityName>Helsinki</cbc:CityName>
<cbc:PostalZone>00100</cbc:PostalZone>
<cac:AddressLine>
<cbc:Line>Platform 23</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode>FI</cbc:IdentificationCode>
</cac:Country>
</cac:DespatchAddress>
</cac:Despatch>
</cac:Delivery>
</cac:Shipment>

Despatch line

cbc:ID is used for identifying the despatch line.

cbc:Note is a general free-form text for the despatch line. This element may contain notes or any other similar information that is not contained explicitly in another structure.

cbc:DeliveredQuantity indicates the quantity that is despatched in the despatch line. @unitCode is a mandatory element to indicate the unit of measure. See Appendix A for the usage of unitCode.

cbc:OutstandingQuantity is not used as partial deliveries are not covered by this implementation guide. If partial deliveries are to be used, the seller and buyer must agree to it beforehand.

cac:OrderLineReference / cbc:LineID contains the line identifier in Order message (cac:OrderLine / cac:LineItem / cbc:ID). This must be provided when the despatch advice is based on electronic order. However, if the despatch line is not generated by an electronic oder, cbc:LineID should be “NA” as this is a mandatory element in Peppol.

cac:OrderLineReference / cac:OrderReference / cbc:ID contains the order identifer in Order message (cbc:ID). This must be provided when the despatch advice is based on electronic order. However, if the despatch line is not generated by an electronic oder, this field can be left out.

Structure of DespatchLine segment

<cac:DespatchLine>
<cbc:ID>1</cbc:ID>
<cbc:DeliveredQuantity unitCode=”EA”>50</cbc:DeliveredQuantity>
<cac:OrderLineReference>
<cbc:LineID>1</cbc:LineID>
<cac:OrderReference>
<cbc:ID>1234567</cbc:ID>
</cac:OrderReference>
</cac:OrderLineReference>
…item…
…shipment…
</cac:DespatchLine>

Item

cbc:Name describes the short name of the item (product). This field is mandatory.

Three different identifiers can be given to an item:

• cac:BuyersItemIdentification / cbc:ID is an identifier given by the buyer.
• cac:SellersItemIdentification / cbc:ID is an identifier given by the seller.
• cac:StandardItemIdentification / cbc:IDis a standardized identifier. @schemeID is a mandatory element to indicate the identification scheme. The standard used must be from the ISO 6523 ICD list code list. The most common standard identifier is GTIN (EAN), and it gets the value “0160” in @schemeID field.

cac:CommodityClassification is not needed as the information about item classification is expected to be in the buyer’s master data systems.

cac:AdditionalItemProperty is used for representing many kinds of data. See Appendix B for usage of cac:AdditionalItemProperty.

cac:ItemInstance / cbc:ManufactureDate is used for the manufacturing date of the item on the despatch line. The field is not applicable for all products. For certain products it is important information.

cac:ItemInstance / cbc:BestBeforeDate is used for best before date of the item on the despatch line. The field is not applicable for all products. For certain products it is important information.

cac:ItemInstance / cbc:SerialID is used for the item’s serial number. The field is not applicable for all products. For certain products it is important information.

cac:LotIdentification / cbc:ExpiryDate is used for the expiry date of the items on the despatch line. The field is not applicable for all products. For certain products it is important information.

Example of Item segment

<cac:Item>
<cbc:Name>Milk</cbc:Name>
<cac:BuyersItemIdentification>
<cbc:ID>12345678</cbc:ID>
</cac:BuyersItemIdentification>
<cac:SellersItemIdentification>
<cbc:ID>87654321</cbc:ID>
</cac:SellersItemIdentification>
<cac:AdditionalItemProperty>
<cbc:Name>Storage facility</cbc:Name>
<cbc:Value>SÄILYTETÄVÄ VIILEÄSSÄ</cbc:Value>
<cbc:ValueQualifier>HAN+:264</cbc:ValueQualifier>
</cac:AdditionalItemProperty>
<cac:AdditionalItemProperty>
<cbc:Name>Calculation net</cbc:Name>
<cbc:Value>0.50</cbc:Value>
<cbc:ValueQualifier>PRI+AAA</cbc:ValueQualifier>
</cac:AdditionalItemProperty>
<cac:ItemInstance>
<cbc:ManufactureDate>2024-08-24</cbc:ManufactureDate>
<cbc:BestBeforeDate>2024-09-10</cbc:BestBeforeDate>
<cbc:SerialID>4558784</cbc:SerialID>
<cac:LotIdentification>
<cbc:ExpiryDate>2024-09-12</cbc:ExpiryDate>
</cac:LotIdentification>
</cac:ItemInstance>
</cac:Item>

Shipment (line level)

cac:Shipment / cbc:ID can be left as “NA” if there is no other valid identifier available. This field is mandatory when Shipment structure is filled on despatch line level.

cac:TransportHandlingUnit / cbc:ID should contain the Serial Shipping Container Code (SSCC). GS1 uses “PALLET” for this packaging level.

Values to be used for cbc:TransportHandlingUnitTypeCode are listed in Appendix C.

The weight and volume must be stated on cac:MeasurementDimension tree. (Change request for adding net values are pending.)

cac:TransportHandlingUnit may contain 0..n packages. cac:Package / cbc:ID should contain the package identifier, such as Transbox code. Values to be used for cbc:PackagingTypeCode are listed in Appendix C. GS1 uses “CASE” for this packaging level.

Example of Shipment segment

<cac:Shipment>
<cbc:ID>NA</cbc:ID>
<cac:TransportHandlingUnit>
<cbc:ID>00164000000000000010</cbc:ID>
<cbc:TransportHandlingUnitTypeCode>PE</cbc:TransportHandlingUnitTypeCode>
<cbc:HazardousRiskIndicator>false</cbc:HazardousRiskIndicator>
<cac:MeasurementDimension>
<cbc:AttributeID>AAB</cbc:AttributeID>
<cbc:Measure unitCode=”KGM”>50</cbc:Measure>
</cac:MeasurementDimension>
<cac:Package>
<cbc:ID>22000196</cbc:ID>
<cbc:PackagingTypeCode>BX</cbc:PackagingTypeCode>
</cac:Package>
</cac:TransportHandlingUnit>
</cac:Shipment>

Appendix A: Quantity/@unitCode Usage

In Peppol, the unit code of line-item quantity must follow UN/ECE’s code list Recommendation 20, including Recommendation 21 codes – prefixed with X (UN/ECE). As this list is very large, Finnish retail sector recommends using this subset of values.

For possible expansion of this list, see short list in Sweden first.

Appendix B: AdditionalItemProperty Usage

The retail sector needs to transmit several item level fields that are not covered by Peppol explicitly. This data can be transmitted in AdditionalItemProperty field. In Peppol, AdditionalItemProperty has two mahdatory fields: cbc:Name and cbc:Value. As cbc:Name should be a human-readable field, cbc:ValueQualifier should be given in order to ensure machine-readibility. Finnish retail sector uses value qualifiers that are derived from EDIFACT.

When the unit code of value is not self-explanatory, cbc:ValueQuantity and cbc:ValueQuantity@unitCode can be used. This typically applies to measures and currencies. For the sake of readability, these two fields are not listed in the table below.

List of agreed value qualifiers in AdditionalItemProperty is below:

Appendix C: Packaging Types

The retail sector uses these codes for identifying packaging types in cbc:TransportHandlinUnitTypeCode and cbc:PackagingTypeCode (if needed). This list follows Recommendation 21 (UN/ECE).

This list needs to be verified / extended in the future updates of the implementation guide.

Example files

Example XML files can be downloaded here.

The examples include 2 scenarios.

Scenario 1: An order is made and it is accepted and delivered as a whole

• Order
• Order Response
• Despatch Advice

Scenario 2: An order is made, but the delivery date is changed on the order response. Then the order is delivered as a whole on the changed delivery date.

• Order
• Order Response with changed delivery date
• Despatch Advice with changed delivery date