Release notes for OIOUBL BIS 3 documents

May 2025

1. OIOUBL General Design Principles 3.0.0.RC

Issue	Description	Type
Document consolidation	A number of design principles, specifications and rules apply across the entire OIOUBL 3 set of Business Interoperability Specifications. Rather than reiterate these in every BIS document, they have now been collected in a single reference, called OIOUBL General Design Principles. In the event of conflict between an individual BIS document and the General Design Principles, the rules and specifications in the General Design Principles prevail, unless it is explicitly noted in the BIS that the divergence is intentional, in which case the rule or specifiation in the BIS prevails. Readers are encouraged to report any conflicts to the Danish Business Authority’s Nemhandel team, so they may be resolved.	BIS document
Shared schematron updates	EN16931 UBL 2.1 validation artifacts have been updated to version 1.3.14.1	EN16931 compliance
	OIOUBL-COMMON-140 and 141 have been moved to OIOUBL-BIL, as they are only applicable to invoices, and merged with existing duplicative invoice-specific rules.	Errata

Issue

Description

Type

Document consolidation

A number of design principles, specifications and rules apply across the entire OIOUBL 3 set of Business Interoperability Specifications. Rather than reiterate these in every BIS document, they have now been collected in a single reference, called OIOUBL General Design Principles.

In the event of conflict between an individual BIS document and the General Design Principles, the rules and specifications in the General Design Principles prevail, unless it is explicitly noted in the BIS that the divergence is intentional, in which case the rule or specifiation in the BIS prevails. Readers are encouraged to report any conflicts to the Danish Business Authority’s Nemhandel team, so they may be resolved.

BIS document

Shared schematron updates

EN16931 UBL 2.1 validation artifacts have been updated to version 1.3.14.1

EN16931 compliance

OIOUBL-COMMON-140 and 141 have been moved to OIOUBL-BIL, as they are only applicable to invoices, and merged with existing duplicative invoice-specific rules.

Errata

2. OIOUBL BIS Billing With Response 3.1.0.RC

Issue	Description	Type
Schematron Changes	Document type codes 393 Factored Invoice and 396 Factored Credit Note are now supported. Factored invoices and credit notes must have PayeeParty. It will typically be the case that PayeeParty is distinct from AccountingCustomerParty, but this is not a schematron requirement.	Restoring an OIOUBL 2 feature.
	For PaymentMeansCode 49 (Direct Debit), PaymentChannelCode is now optional rather than mandatory, to ensure compatibility with Betalingsservice and Leverandørservice.	Errata
	The structure of Address elements is no longer validated, to prevent incomplete, broken or misformatted adresses. Properly structuring address data remains recommended, but service provider feedback was clear that cleaning existing address master data among end users would be a major undertaking, incommensurate with the value added.	Feature request
	InvoiceDocumentReference is now a mandatory component of BillingReference. For this reason, references to credit notes and reminders have been de-supported (but not excluded).	EN16931 conformance
	Duplicative schematron rules merged.	Corrigenda
Syntax documentation changes	TaxCategory is no longer incorrectly listed as supported in InvoiceLine/Price/AllowanceCharge.	Corrigenda
	Example text in the syntax binding page now distinguishes between: Mandatory content for the document (e.g. all OIOUBL 3 invoices are UBL 2.1); Standard content (if no information is provided, invoices should be presumed to be commercial invoices, with invoicetypecode 380); Example content, which has no semantic function, but illustrates the use of the element.	Layout/formatting
	Various minor corrigenda to the text of the syntax documentation, such as restoring daughter fields that were accidentally truncated in the previous version.	Errata/corrigenda

Issue

Description

Type

Schematron Changes

Document type codes 393 Factored Invoice and 396 Factored Credit Note are now supported. Factored invoices and credit notes must have PayeeParty. It will typically be the case that PayeeParty is distinct from AccountingCustomerParty, but this is not a schematron requirement.

Restoring an OIOUBL 2 feature.

For PaymentMeansCode 49 (Direct Debit), PaymentChannelCode is now optional rather than mandatory, to ensure compatibility with Betalingsservice and Leverandørservice.

Errata

The structure of Address elements is no longer validated, to prevent incomplete, broken or misformatted adresses. Properly structuring address data remains recommended, but service provider feedback was clear that cleaning existing address master data among end users would be a major undertaking, incommensurate with the value added.

Feature request

InvoiceDocumentReference is now a mandatory component of BillingReference. For this reason, references to credit notes and reminders have been de-supported (but not excluded).

EN16931 conformance

Duplicative schematron rules merged.

Corrigenda

Syntax documentation changes

TaxCategory is no longer incorrectly listed as supported in InvoiceLine/Price/AllowanceCharge.

Corrigenda

Example text in the syntax binding page now distinguishes between: Mandatory content for the document (e.g. all OIOUBL 3 invoices are UBL 2.1); Standard content (if no information is provided, invoices should be presumed to be commercial invoices, with invoicetypecode 380); Example content, which has no semantic function, but illustrates the use of the element.

Layout/formatting

Various minor corrigenda to the text of the syntax documentation, such as restoring daughter fields that were accidentally truncated in the previous version.

Errata/corrigenda

OIOUBL BIS Billing With Response 3.0.2.RC

Issue	Description	Type
Syntax Bindings	Reminder and Credit Note no longer supported in BillingReference	EN16931 compliance.
	PaymentMeans.PayeeFinancialAccount and PaymentMeans.PayeeFinancialAccount.ID semantic bindings have been updated to clarify that it is the location for FIK account numbers.	Errata/corrigenda
	Address fields no longer supported in most Party elements. (Although the Party element is not excluded, so users are free to include the party element, subject to mutual agreement between sender and receiver.)	Revision based on received feedback
	Numeric fields now distinguish between integer and floating point values.	Clarification
	ApplicationResponse.DocumentResponse.Response.ReferenceID and ApplicationResponse.UBLVersionID are no longer excluded in OIOUBL Invoice Response.	Revision based on received feedback
	ApplicationResponse.UBLVersionID is no longer excluded in OIOUBL Message Level Response.	Revision based on received feedback
	BillingReference.InvoiceDocumentReference was erroneously displaying OIOUBL 2 specifications instead of the updated OIOUBL 3 specifications. This has been updated.	Errata/corrigenda
	A number of fields did not have data types, or had wrong data types. This has been remedied.	Errata/corrigenda
BIS Updates	The BIS Billing Private Without Response profile was inadequately documented. The description has been expanded to explain its function in more detail.	Errata/corrigenda
	Explanation of the meaning and use of Invoice Type Codes has been added.	Clarification
	The MLR and Invoice Response syntax bindings deviate from the general principle that unsupported fields are not excluded, in order to improve compatibility with Peppol. This was not previously documented.	Errata/corrigenda
	A number of data types present in the syntax binding were not present in the BIS. This has been remedied.	Errata/corrigenda
	Certain design elements and principles are shared across all of OIOUBL 3. Rather than repeat each of these in the individual BIS documents, they have been consolidated into a shared BIS covering the entire document set.	Editorial
	Data types have been moved from the individual BIS documents to the shared BIS.	Editorial
	The distinction between supported, unsupported and excluded data elements has been included in the shared BIS. Previously this distinction had been explained only in release notes.	Clarification
	The use of read-mandatory fields has been included in the shared BIS. Previously this had been explained only in release notes.	Clarification
	A description of the structure of the syntax binding documentation has been included in the shared BIS.	Clarification
Schematron changes	OIOUBL-COMMON-126 would erroneously reject documents that included a Contact which did not have a Telephone sub-element. The rule has been updated to apply only when a Telephone element is present in the Contact.	Errata/corrigenda

Issue

Description

Type

Syntax Bindings

Reminder and Credit Note no longer supported in BillingReference

EN16931 compliance.

PaymentMeans.PayeeFinancialAccount and PaymentMeans.PayeeFinancialAccount.ID semantic bindings have been updated to clarify that it is the location for FIK account numbers.

Errata/corrigenda

Address fields no longer supported in most Party elements. (Although the Party element is not excluded, so users are free to include the party element, subject to mutual agreement between sender and receiver.)

Revision based on received feedback

Numeric fields now distinguish between integer and floating point values.

Clarification

ApplicationResponse.DocumentResponse.Response.ReferenceID and ApplicationResponse.UBLVersionID are no longer excluded in OIOUBL Invoice Response.

Revision based on received feedback

ApplicationResponse.UBLVersionID is no longer excluded in OIOUBL Message Level Response.

Revision based on received feedback

BillingReference.InvoiceDocumentReference was erroneously displaying OIOUBL 2 specifications instead of the updated OIOUBL 3 specifications. This has been updated.

Errata/corrigenda

A number of fields did not have data types, or had wrong data types. This has been remedied.

Errata/corrigenda

BIS Updates

The BIS Billing Private Without Response profile was inadequately documented. The description has been expanded to explain its function in more detail.

Errata/corrigenda

Explanation of the meaning and use of Invoice Type Codes has been added.

Clarification

The MLR and Invoice Response syntax bindings deviate from the general principle that unsupported fields are not excluded, in order to improve compatibility with Peppol. This was not previously documented.

Errata/corrigenda

A number of data types present in the syntax binding were not present in the BIS. This has been remedied.

Errata/corrigenda

Certain design elements and principles are shared across all of OIOUBL 3. Rather than repeat each of these in the individual BIS documents, they have been consolidated into a shared BIS covering the entire document set.

Editorial

Data types have been moved from the individual BIS documents to the shared BIS.

Editorial

The distinction between supported, unsupported and excluded data elements has been included in the shared BIS. Previously this distinction had been explained only in release notes.

Clarification

The use of read-mandatory fields has been included in the shared BIS. Previously this had been explained only in release notes.

Clarification

A description of the structure of the syntax binding documentation has been included in the shared BIS.

Clarification

Schematron changes

OIOUBL-COMMON-126 would erroneously reject documents that included a Contact which did not have a Telephone sub-element. The rule has been updated to apply only when a Telephone element is present in the Contact.

Errata/corrigenda

3. OIOUBL BIS Reminder with Response 3.0.0.RC

Issue	Description	Type
Initial release candidate	Unlike previous versions of OIOUBL, OIOUBL 3 casts the Reminder as a replacement invoice, with a few restrictions or additional properties. Partly this is to reduce complexity, by allowing re-use of the invoice specification, and partly it is a reflection of the way reminders function in Danish practice. For this reason, this BIS only lists the ways in which the Reminder deviates from an ordinary type of invoice it replaces. Where a feature is not mentioned in this BIS, it operates in the same manner as in an invoice of the invoice type code that it replaces. Note that schematron rules for Reminder follow 380:Commercial Invoice, regardless of the invoice type code of the underlying invoice. The Commercial Invoice schematron should be compatible with all the special invoice cases (except Pro Forma Invoice, which is not a valid subject of a Reminder, as it contains no underlying claim to payment). However, the use of the base rules does mean that special rules (e.g. PayeeParty being mandatory in a Factored Invoice) are not schematron-enforced in Reminders. Reminders should still adhere to these requirements, in order to be semantically valid.	BIS document

Issue

Description

Type

Initial release candidate

Unlike previous versions of OIOUBL, OIOUBL 3 casts the Reminder as a replacement invoice, with a few restrictions or additional properties. Partly this is to reduce complexity, by allowing re-use of the invoice specification, and partly it is a reflection of the way reminders function in Danish practice.

For this reason, this BIS only lists the ways in which the Reminder deviates from an ordinary type of invoice it replaces. Where a feature is not mentioned in this BIS, it operates in the same manner as in an invoice of the invoice type code that it replaces.

Note that schematron rules for Reminder follow 380:Commercial Invoice, regardless of the invoice type code of the underlying invoice. The Commercial Invoice schematron should be compatible with all the special invoice cases (except Pro Forma Invoice, which is not a valid subject of a Reminder, as it contains no underlying claim to payment). However, the use of the base rules does mean that special rules (e.g. PayeeParty being mandatory in a Factored Invoice) are not schematron-enforced in Reminders. Reminders should still adhere to these requirements, in order to be semantically valid.

BIS document

4. OIOUBL BIS Self-Billing with Response 3.0.0.RC

Issue	Description	Type
Initial release candidate	The Self-Billing Invoice (Afregningsbilag for Selvfakturering) is a new profile in OIOUBL 3, that does not exist in OIOUBL 2.1. The Self-Billing Invoice is based on the BIS Billing with Response. For this reason, the BIS only lists the ways in which the Reminder deviates from the OIOUBL BIS Billing with Response. Where a feature is not mentioned in this BIS, it operates in the same manner as in an invoice of the relevant invoice type code.	BIS document

Issue

Description

Type

Initial release candidate

The Self-Billing Invoice (Afregningsbilag for Selvfakturering) is a new profile in OIOUBL 3, that does not exist in OIOUBL 2.1.

The Self-Billing Invoice is based on the BIS Billing with Response. For this reason, the BIS only lists the ways in which the Reminder deviates from the OIOUBL BIS Billing with Response. Where a feature is not mentioned in this BIS, it operates in the same manner as in an invoice of the relevant invoice type code.

BIS document

5. OIOUBL BIS Message Level Response 3.0.2.RC

Issue	Description	Type
Errata/corrigenda	Update to documentation, on the basis of received feedback. No changes to schematron rules.	Fix version

Issue

Description

Type

Errata/corrigenda

Update to documentation, on the basis of received feedback. No changes to schematron rules.

Fix version

January 2025

6. OIOUBL BIS Billing With Response 3.0.1.RC

Issue	Description	Type
Errata/corrigenda	Update to documentation, on the basis of received feedback. No changes to schematron rules.	Fix version
Data types	Based on feedback regarding the difficulty of designing user interfaces for text fields of unknown length, the OIOUBL syntax documentation now specifies whether text fields are Long or Short Strings. Long String must be no longer than 1024 characters from the UTF-8 set, and may contain line breaks. Short String must be no longer than 64 characters, and may not contain line breaks. Users are encouraged to review these data type definitions, and offer comment if certain fields are impractically defined.	Clarification
	A number of fields did not have data types, this has been remedied.	Errata/corrigenda

Issue

Description

Type

Errata/corrigenda

Update to documentation, on the basis of received feedback. No changes to schematron rules.

Fix version

Data types

Based on feedback regarding the difficulty of designing user interfaces for text fields of unknown length, the OIOUBL syntax documentation now specifies whether text fields are Long or Short Strings. Long String must be no longer than 1024 characters from the UTF-8 set, and may contain line breaks. Short String must be no longer than 64 characters, and may not contain line breaks.

Users are encouraged to review these data type definitions, and offer comment if certain fields are impractically defined.

Clarification

A number of fields did not have data types, this has been remedied.

Errata/corrigenda

7. OIOUBL BIS Message Level Response 3.0.1.RC

Issue	Description	Type
Errata/corrigenda	Update to documentation, on the basis of received feedback. No changes to schematron rules.	Fix version
Data types	Based on feedback regarding the difficulty of designing user interfaces for text fields of unknown length, the OIOUBL syntax documentation now specifies whether text fields are Long or Short Strings. Long String must be no longer than 1024 characters from the UTF-8 set, and may contain line breaks. Short String must be no longer than 64 characters, and may not contain line breaks. Users are encouraged to review these data type definitions, and offer comment if certain fields are impractically defined.	Clarification
	A number of fields did not have data types, this has been remedied.	Errata/corrigenda

Issue

Description

Type

Errata/corrigenda

Update to documentation, on the basis of received feedback. No changes to schematron rules.

Fix version

Data types

Clarification

A number of fields did not have data types, this has been remedied.

Errata/corrigenda

November 2024

8. OIOUBL BIS Billing With Response 3.0.0.RC

While all reasonably practicable effort has been undertaken toward the completeness of the below changelog, OIOUBL 3 is a major revision. Some breaking changes may not have been identified. Users are strongly encouraged to conduct their own comprehensive testing.

Issue	Description	Type
N/A	Initial update of OIOUBL 3 BIS Billing With Response	New
Separation of message level and business level responses	In OIOUBL 2, message and business level responses both used the ApplicationResponse document. OIOUBL 3 has split these into different customization IDs and profiles, to improve clarity regarding choreography and parties. OIOUBL 3 Invoice Response follows the Peppol Invoice Response closely in syntax. However, there is a significant difference in choreography: A Peppol Invoice Response must be sent within three business days of receipt of the invoice. An OIOUBL Invoice Response must be sent without undue delay and no later than the parties to the invoice transaction have mutually agreed (if they have agreed on a deadline).	Breaking
Two-way profiles only	In OIOUBL 2, several profiles were available for sending invoices without being able to receive an invoice response. This is not supported in OIOUBL 3, for business users. All institutional end users are expected and required to receive invoice responses at an endpoint registered to their business. An invoice profile and associated BIS will be published shortly for use by physical persons (who cannot have an endpoint for invoice responses, as this would expose their CPR number to the public). This profile will not be useable for institutional senders. This change is made in anticipation that it will within the lifetime of IT systems deployed today become mandatory to be able to account for the full life cycle of invoices in a structured manner.	Breaking
Interpretations	The OIOUBL 2 documentation indicated which fields were possible to ingest in a structured manner. In OIOUBL 3, this is no longer indicated. Rather, OIOUBL 3 indicates which values must be shown to the end user, because these fields contain information that the recipient of a document will be deemed to have known in the event of a dispute. This means that a number of free text fields, which are not readily ingestible, are marked as read-mandatory, while a number of structured data fields no longer are.	Semantic change
	OIOUBL operates with three different inclusion levels for a data field: Supported fields have semantic definitions that are given in the relevant BIS and syntax documentation. All service providers implementing OIOUBL are expected to be familiar with these field definitions. Excluded fields are listed in the syntax documentation, but not usually in the BIS. These must not be used, and will cause validation errors if included. Unsupported fields are all other data structures that are schema-valid for the underlying UBL, but neither supported nor explicitly excluded. Unsupported fields are not shown in the syntax documentation nor in the BIS. It is permissible for parties to bilaterally agree to the use of unsupported fields, provided the implementation is schema-valid. However, neither end users nor service providers are required or expected to be familiar with these data structures, in the absence of an explicit prior agreement to that effect.	Clarification
	Prior versions of OIOUBL documentation used field definitions that were oriented toward technical implementation in EDI solutions, but did not prioritize making explicit the semantic content of the fields. OIOUBL 3 aims to provide field names and definitions which can be used directly in business user facing interfaces. It is hoped that this will contribute to standardizing the terminology that a user of e-procurement solutions faces across different platforms.	Clarification
Re-mapped fields	Buyer’s reference has been re-mapped from cbc:BuyerCustomerParty.Party.Contact.ID to cbc:BuyerReference	Breaking change - EN16931 conformance
	Excise taxes have been moved from the Tax elements to the AllowanceCharge elements.	Breaking change - EN16931 conformance
Calculation changes	Line level AllowanceCharge now enters into the calculation of the LineExtensionAmount, where before it was purely informative.	Breaking change - EN16931 conformance
	TaxExclusiveAmount was used incorrectly in OIOUBL 2. This has been revised to conform to the Norm.	Breaking change - EN16931 conformance
	Negative credit notes are no longer permitted. Previously this was permitted to support conversion from Peppol Credit Note, but in OIOUBL 3 negative Peppol credit notes should be converted to invoices instead.	Breaking change
	Invoice Due Date is now mandatory for documents where a due date is mandatory. PaymentMeans.PaymentDueDate is prohibited, PaymentTerms.PaymentDueDate is unsupported. PaymentTerms.PaymentDueDate only makes sense when there are multiple payment terms, which is currently unsupported in the Norm. If and when multiple payment terms are permitted, this will be revisited.	Breaking change - EN16931 conformance
	VAT calculations and labeling now follow the EN16931 definitions and calculation logic.	Breaking change - EN16931 conformance
	Only one tax total with tax subtotals may be provided. Tax subtotals are only used for the calculation of VAT in the document currency. The VAT amount in the tax currency is simply the VAT total converted into the tax currency.	Breaking change
	One or more TaxTotal classes must be present on line level.	Breaking change
	Document- and sub-totals now calculated according to the EN16931 calculation logic.	Breaking change - EN16931 conformance
	Use of OrderableUnitFactorRate is not supported under EN16931	Breaking change - EN16931 conformance
	Only one item price discount is supported under EN16931	Breaking change - EN16931 conformance
Field definitions/data quality	A number of fields are now required to be non-negative. In particular, item net prices are no longer allowed to be negative.	Breaking change - EN16931 conformance
	Invoiced/credited quantities may no longer be 0.	Breaking change
	Empty fields are no longer permitted. All instances of classes and fields must have content.	Breaking change - EN16931 conformance
	Invoice.OrderReference is mandatory when OrderLineReference class is present	Breaking change
	Validation rules for completeness of address information have been substantially tightened. Addresses are now expected to be provided in structured format and fully specified. In particular, tests against historical production data have flagged incomplete DeliveryLocation.Address information. This will cause validation failure in OIOUBL 3.	Breaking change
	A number of fields are now bound to specific or different code lists. In particular, tests against anonymized historical production data have identified the following prohibited practices currently in use: BR-CL-03 currencyID MUST be coded using ISO code list 4217 alpha-3 BR-CL-17 Invoice tax categories MUST be coded using UNCL5305 code list BR-CL-23 Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21 extension OIOUBL-BIL-005 For Danish suppliers the following Payment means codes are allowed: 1, 10, 31, 42, 48, 49, 50, 58, 59, 93 and 97 OIOUBL-BIL-010For Danish Suppliers the PaymentID is mandatory and MUST start with 71#, 73# or 75# (kortartkode) and PayeeFinancialAccount/ID (Kreditornummer) is mandatory and must be exactly 8 characters long, when Payment means equals 93 (FIK) OIOUBL-COMMON-141 MathematicOperatorCode must be either 'multiply' or 'divide' PEPPOL-EN16931-R101 Element Document reference can only be used for Invoice line object	Breaking change
	cac:StandardItemIdentification/cbc:ID requires a schemeID attribute (to specify which standardized taxonomy is used).	Breaking change
	Money amounts must have no more than two decimal places, and exchange rates must have exactly four decimal places.	Breaking change
	When exchange reates are used in an invoices, it’s required to include both calculation rate and mathematic operator code.	Breaking change
	It is no longer permitted to indicate an exchange rate, if only one currency is used in the invoice.	Breaking change
	Line IDs must now be unique to within the document. The schematron validates only to the first 5000 lines of a document, because this validation rule has very bad scaling properties, but the business rule applies to all line IDs in a given document.	Breaking change
	AdditionalDocumentReference may only have SchemeIdentifier for InvoiceObjectIdentifiers.	Breaking change - EN16931 conformance
Allowance/charges	Allowances must now have a reason or a reason code.	Breaking change - EN16931 conformance
Payment	For Danish suppliers PaymentMandate/ID and PayerFinancialAccount/ID are mandatory when payment means is 49	Breaking change
	It is now mandatory to distinguish between the bank branch to which a bank account is registered, and the corporate identity of the bank to which the branch belongs.	Breaking change
	Multiple payment terms not supported under EN16931	Breaking change - EN16931 conformance
	Multiple payment means with different payment means codes not supported under EN16931	Breaking change - EN16931 conformance
	For the sake of backward compatibility, PaymentChannelCode is retained for several PaymentMeansCodes where there is no ambiguity to resolve. This use is permitted, but is considered deprecated and may be removed in future revisions.	Formal notice
Excluded fields	A number of fields have been excluded that were previously permitted. In particular, the Person class is universally banned (for reasons of data protection), and several fields that are duplicative of data structures found elsewhere in the schema have been excluded. For example, UBL contains a payment due date in both PaymentMeans and PaymentTerms, but the one in PaymentMeans has been excluded as duplicative in OIOUBL.	Breaking change
	Fields that were only excluded in OIOUBL 2 to maintain backwards compatibility (because they were introduced in a later UBL version than OIOUBL 2 supported) have been un-excluded.	Breaking change

Issue

Description

Type

N/A

Initial update of OIOUBL 3 BIS Billing With Response

New

Separation of message level and business level responses

In OIOUBL 2, message and business level responses both used the ApplicationResponse document. OIOUBL 3 has split these into different customization IDs and profiles, to improve clarity regarding choreography and parties.

OIOUBL 3 Invoice Response follows the Peppol Invoice Response closely in syntax. However, there is a significant difference in choreography: A Peppol Invoice Response must be sent within three business days of receipt of the invoice. An OIOUBL Invoice Response must be sent without undue delay and no later than the parties to the invoice transaction have mutually agreed (if they have agreed on a deadline).

Breaking

Two-way profiles only

In OIOUBL 2, several profiles were available for sending invoices without being able to receive an invoice response. This is not supported in OIOUBL 3, for business users. All institutional end users are expected and required to receive invoice responses at an endpoint registered to their business.

An invoice profile and associated BIS will be published shortly for use by physical persons (who cannot have an endpoint for invoice responses, as this would expose their CPR number to the public). This profile will not be useable for institutional senders.

This change is made in anticipation that it will within the lifetime of IT systems deployed today become mandatory to be able to account for the full life cycle of invoices in a structured manner.

Breaking

Interpretations

The OIOUBL 2 documentation indicated which fields were possible to ingest in a structured manner. In OIOUBL 3, this is no longer indicated. Rather, OIOUBL 3 indicates which values must be shown to the end user, because these fields contain information that the recipient of a document will be deemed to have known in the event of a dispute. This means that a number of free text fields, which are not readily ingestible, are marked as read-mandatory, while a number of structured data fields no longer are.

Semantic change

OIOUBL operates with three different inclusion levels for a data field:
Supported fields have semantic definitions that are given in the relevant BIS and syntax documentation. All service providers implementing OIOUBL are expected to be familiar with these field definitions.
Excluded fields are listed in the syntax documentation, but not usually in the BIS. These must not be used, and will cause validation errors if included.
Unsupported fields are all other data structures that are schema-valid for the underlying UBL, but neither supported nor explicitly excluded. Unsupported fields are not shown in the syntax documentation nor in the BIS. It is permissible for parties to bilaterally agree to the use of unsupported fields, provided the implementation is schema-valid. However, neither end users nor service providers are required or expected to be familiar with these data structures, in the absence of an explicit prior agreement to that effect.

Clarification

Prior versions of OIOUBL documentation used field definitions that were oriented toward technical implementation in EDI solutions, but did not prioritize making explicit the semantic content of the fields. OIOUBL 3 aims to provide field names and definitions which can be used directly in business user facing interfaces. It is hoped that this will contribute to standardizing the terminology that a user of e-procurement solutions faces across different platforms.

Clarification

Re-mapped fields

Buyer’s reference has been re-mapped from cbc:BuyerCustomerParty.Party.Contact.ID to cbc:BuyerReference

Breaking change - EN16931 conformance

Excise taxes have been moved from the Tax elements to the AllowanceCharge elements.

Breaking change - EN16931 conformance

Calculation changes

Line level AllowanceCharge now enters into the calculation of the LineExtensionAmount, where before it was purely informative.

Breaking change - EN16931 conformance

TaxExclusiveAmount was used incorrectly in OIOUBL 2. This has been revised to conform to the Norm.

Breaking change - EN16931 conformance

Negative credit notes are no longer permitted. Previously this was permitted to support conversion from Peppol Credit Note, but in OIOUBL 3 negative Peppol credit notes should be converted to invoices instead.

Breaking change

Invoice Due Date is now mandatory for documents where a due date is mandatory. PaymentMeans.PaymentDueDate is prohibited, PaymentTerms.PaymentDueDate is unsupported. PaymentTerms.PaymentDueDate only makes sense when there are multiple payment terms, which is currently unsupported in the Norm. If and when multiple payment terms are permitted, this will be revisited.

Breaking change - EN16931 conformance

VAT calculations and labeling now follow the EN16931 definitions and calculation logic.

Breaking change - EN16931 conformance

Only one tax total with tax subtotals may be provided. Tax subtotals are only used for the calculation of VAT in the document currency. The VAT amount in the tax currency is simply the VAT total converted into the tax currency.

Breaking change

One or more TaxTotal classes must be present on line level.

Breaking change

Document- and sub-totals now calculated according to the EN16931 calculation logic.

Breaking change - EN16931 conformance

Use of OrderableUnitFactorRate is not supported under EN16931

Breaking change - EN16931 conformance

Only one item price discount is supported under EN16931

Breaking change - EN16931 conformance

Field definitions/data quality

A number of fields are now required to be non-negative. In particular, item net prices are no longer allowed to be negative.

Breaking change - EN16931 conformance

Invoiced/credited quantities may no longer be 0.

Breaking change

Empty fields are no longer permitted. All instances of classes and fields must have content.

Breaking change - EN16931 conformance

Invoice.OrderReference is mandatory when OrderLineReference class is present

Breaking change

Validation rules for completeness of address information have been substantially tightened. Addresses are now expected to be provided in structured format and fully specified. In particular, tests against historical production data have flagged incomplete DeliveryLocation.Address information. This will cause validation failure in OIOUBL 3.

Breaking change

A number of fields are now bound to specific or different code lists. In particular, tests against anonymized historical production data have identified the following prohibited practices currently in use:
BR-CL-03 currencyID MUST be coded using ISO code list 4217 alpha-3
BR-CL-17 Invoice tax categories MUST be coded using UNCL5305 code list
BR-CL-23 Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21 extension
OIOUBL-BIL-005 For Danish suppliers the following Payment means codes are allowed: 1, 10, 31, 42, 48, 49, 50, 58, 59, 93 and 97
OIOUBL-BIL-010For Danish Suppliers the PaymentID is mandatory and MUST start with 71#, 73# or 75# (kortartkode) and PayeeFinancialAccount/ID (Kreditornummer) is mandatory and must be exactly 8 characters long, when Payment means equals 93 (FIK)
OIOUBL-COMMON-141 MathematicOperatorCode must be either 'multiply' or 'divide'
PEPPOL-EN16931-R101 Element Document reference can only be used for Invoice line object

Breaking change

cac:StandardItemIdentification/cbc:ID requires a schemeID attribute (to specify which standardized taxonomy is used).

Breaking change

Money amounts must have no more than two decimal places, and exchange rates must have exactly four decimal places.

Breaking change

When exchange reates are used in an invoices, it’s required to include both calculation rate and mathematic operator code.

Breaking change

It is no longer permitted to indicate an exchange rate, if only one currency is used in the invoice.

Breaking change

Line IDs must now be unique to within the document. The schematron validates only to the first 5000 lines of a document, because this validation rule has very bad scaling properties, but the business rule applies to all line IDs in a given document.

Breaking change

AdditionalDocumentReference may only have SchemeIdentifier for InvoiceObjectIdentifiers.

Breaking change - EN16931 conformance

Allowance/charges

Allowances must now have a reason or a reason code.

Breaking change - EN16931 conformance

Payment

For Danish suppliers PaymentMandate/ID and PayerFinancialAccount/ID are mandatory when payment means is 49

Breaking change

It is now mandatory to distinguish between the bank branch to which a bank account is registered, and the corporate identity of the bank to which the branch belongs.

Breaking change

Multiple payment terms not supported under EN16931

Breaking change - EN16931 conformance

Multiple payment means with different payment means codes not supported under EN16931

Breaking change - EN16931 conformance

For the sake of backward compatibility, PaymentChannelCode is retained for several PaymentMeansCodes where there is no ambiguity to resolve. This use is permitted, but is considered deprecated and may be removed in future revisions.

Formal notice

Excluded fields

A number of fields have been excluded that were previously permitted. In particular, the Person class is universally banned (for reasons of data protection), and several fields that are duplicative of data structures found elsewhere in the schema have been excluded. For example, UBL contains a payment due date in both PaymentMeans and PaymentTerms, but the one in PaymentMeans has been excluded as duplicative in OIOUBL.

Breaking change

Fields that were only excluded in OIOUBL 2 to maintain backwards compatibility (because they were introduced in a later UBL version than OIOUBL 2 supported) have been un-excluded.

Breaking change

9. OIOUBL BIS Message Level Response 3.0.0.RC

Issue	Description	Type
N/A	Initial update of OIOUBL 3 BIS Message Level Response	New
Separation of message level and business level responses	In OIOUBL 2, message and business level responses both used the ApplicationResponse document. OIOUBL 3 has split these into different customization IDs and profiles, to improve clarity regarding choreography and parties. OIOUBL 3 Message Level Response follows Peppol Message Level Response closely, with the significant exception that the OIOUBL 3 MLR distinguishes between validation errors (use MLR-Network to report to the sending service provider in C2) and semantic errors that are not caught by schema- or schematron validation (use MLR to report to the sending party’s business system in C1).	Breaking
Mandatory support for message level responses at business and service provider level	In OIOUBL 2, it is possible to send documents without being able to receive an application response. In OIOUBL 3 this is no longer the case. In OIOUBL 3, it is mandatory for all senders to be able to receive MLRs at two endpoints: A business level endpoint, corresponding to the business level sender (C1), and a service provider technical endpoint (C2). This is to ensure that documents can be repudiated for syntax and semantic errors in a provable and authoritative manner.	Breaking

Issue

Description

Type

N/A

Initial update of OIOUBL 3 BIS Message Level Response

New

Separation of message level and business level responses

In OIOUBL 2, message and business level responses both used the ApplicationResponse document. OIOUBL 3 has split these into different customization IDs and profiles, to improve clarity regarding choreography and parties.

OIOUBL 3 Message Level Response follows Peppol Message Level Response closely, with the significant exception that the OIOUBL 3 MLR distinguishes between validation errors (use MLR-Network to report to the sending service provider in C2) and semantic errors that are not caught by schema- or schematron validation (use MLR to report to the sending party’s business system in C1).

Breaking

Mandatory support for message level responses at business and service provider level

In OIOUBL 2, it is possible to send documents without being able to receive an application response. In OIOUBL 3 this is no longer the case.

In OIOUBL 3, it is mandatory for all senders to be able to receive MLRs at two endpoints: A business level endpoint, corresponding to the business level sender (C1), and a service provider technical endpoint (C2). This is to ensure that documents can be repudiated for syntax and semantic errors in a provable and authoritative manner.

Breaking