Adoption of UBL in Denmark - business cases and experiences

The optimal ordering, invoicing and payment process

The part of the business case analysis that deals with optimizing payment processes around invoices sent to the public sector states that:

All parts of the business process from ordering to invoicing must be digitized in order to optimize the payment process to its fullest potential.

• A person from the buyers organization (rekvirent) identifies the need for a product or a service
• This person sends an electronic order to an authorized person in the buyers organization
• The authorized person accepts the electronic order
• The authorized person sends the order to the seller’s organization.
• The product or service is delivered to the buyer
• The seller sends an electronic invoice to the buyer’s organization. The invoice is sent to an authorized person for approval. The approved in voice is then sent to a person or a department responsible for payments. Sending the electronic invoice to an authorized person may be avoided if the electronic invoice matches the electronic order and the electronic registration of what has been received. The prerequisite is that there is a match between what has been ordered and what has been received. Not only in numbers but also in quality. In case there is a divergence in the expected and the actual prize, the invoice can still be approved automatically given that the divergence is within a defined tolerance.
• Payment is performed automatically once the invoice has been approved and the book keeping account is cleared.

The manual payment process

The optimization potential with electronic invoicing and workflow support

Instant critical mass through legislation

Denmark will be among the first countries – if not the first – to implement the requirement for electronic invoicing in the public sector in its legislation. On one hand this approach may seem forceful but on the other hand this may be just what is needed in order to achieve critical mass in electronic invoicing in society as a whole. The private sector has a huge incentive to implement electronic invoicing now that the whole public sector is able to receive electronic invoices. The government has provided an infrastructure, an addressing mechanism, a standard has been chosen (UBL) and critical mass is ensured.

The legislative process started in 2003 and a law on “Public sector payments” was enacted by the parliament on December 27th 2003 Law. The law briefly states that the Ministry of Finance is given the authority to publish further statutes detailing the implementation of the law. The law does not mention, “electronic invoicing” per se and the text focuses on the payment processes in the public sector.

The initiative on electronic invoicing was detailed in a statute published by the Ministry of Finance on October 7th 2004 FMstatute. The statute formalizes the requirement that public sector institutions must be able to send and receive electronic invoices by February 1st 2005. The authority to publish statutes on the invoice format was at the same time assigned to the Ministry of Science, Technology and Innovation. The final statute specifying the Danish localized version of UBL was published by the Ministry of Science, Technology and Innovation on November 11th 2004.

Public sector bank account registry

The most central element in implementing effective payment processes in the public sector in Denmark is a shared bank account registry. All public authorities will by September 2005 share a registry of bank account information for all companies and citizens in Denmark. All companies and citizens are required to report which bank account they wish payments from the public sector to be transferred to. The banks will, on behalf of the companies and citizens, do the actual reporting to the registry. Citizens without existing bank accounts will be supplied with an account by the government. The advantage of this approach is that public authorities are not required to maintain payment specific information themselves. All payment advices to the banks will go though the registry and the registry will add the correct bank account information. Existing practices with cash payments, the use of cheques and manual bank transfers from different authorities will be stopped or the practice will at least be limited to a very few institutions.

The keys to the success of this transaction are two well-established registries of citizens and companies. All citizens and legal aliens in Denmark are supplied with a social security number

”CPR-nummer” in Danish. CPR = Central Person Registry.

This number is used as the primary identifier for citizens in the public sector and in some parts of the private sector (namely banks and insurance companies). All companies paying VAT and TAX in Denmark are likewise supplied with a company registration number

”CVR-nummer” in Danish. CVR = Central Company Registry.

. The company registration number is also the primary identifier for companies across the public sector and in some parts of the private sector. Denmark is fortunate in comparison with other countries, that the same identifiers are used across different public authorities. This makes data interchange between authorities much simpler compared to countries where these key identifiers are not shared.

The network infrastructure and addressing mechanism

The network infrastructure for exchanging invoices is based on traditional EDI technology. A network of VANS

VANS – Value Added Network Service

operators handles the delivery of invoices from supplier to buyer. The addressing mechanism uses EAN-location numbers to identify the trading partners.

All public institutions are required by law to be connected to one of the five VANS operators. Private companies wishing to send invoices to the public sector are likewise required to be connected to the VANS-network. The VANS operators share a database of EAN location numbers.

• An invoice is sent to a VANS-operator
• The VANS-operator looks up the EAN-location number in a database
• The invoice is perhaps sent to another VANS-operator
• The invoice is sent to a public authority

Scanning of paper invoices by scanning companies

The potential for saving money on a more effective invoice handling process has several preconditions. First of all – if the business process is reengineered from a traditional manual handling of invoices to the electronic counterpart – it is essential that all invoices are made electronic such that two business processes are not maintained in parallel.

It is evident that all private companies selling products and services to the public sector are not capable of sending electronic invoices. “The baker” at the corner delivering bread to a kindergarten is unlikely to be capable of sending electronic invoices. This problem was tackled by establishing two so called “scanning agencies”. All paper-based invoices are sent to one of the two “scanning agencies” where a subset of the invoice is scanned automatically and an electronic invoice is generated. A scanned image of the original invoice is embedded in the electronic invoice in a base64 encoded element. The “scanning agency” is connected to a VANS-operator like any other supplier to the public sector.

The only difference to the baker at the corner is that a new address is written at the envelope and an EAN location number must be indicated on the invoice itself.

The service of the “scanning agencies” is free to companies with a net turnover of less than 2 million Euros

15 million DKK

. Other companies and public institutions must pay approximately one Euro per invoice.

“Strong” and “weak” XML schemas

One inherent issue that one has to deal with when using international standards like UBL is the fact that most data types are relatively weak in their validation. For instance – the format of a zip code varies a lot between different countries. A zip code in Denmark consists of 4 digits. In XML Schema it is relatively easy to create a data type that will do a “strict” validation making sure that the content of a ZipCode element consists of exactly 4 digits. Alternately, the data type could be an enumeration containing all legal zip codes in Denmark. None of these solutions would have any value outside Denmark and thus the need for “weak data types” in the UBL vocabulary.

Having the normative UBL schemas is important in order to make sure messages can be exchanged between business partners in different countries. In a scenario like that in Denmark invoices are only exchanged in within the country. The legislation has spelled out the use of various Identifiers. For instance, a seller must be identified through an 8-digit company registration number in the CompanyTaxIdentifier element.

In other words – the XML schemas supplied by the UBL TC cannot take advantage of the ability to do a strict validation in XML schema. As a consequence of this two different version of the Danish localized schemas were developed: One set of schemas based on the “weak” UBL schemas (called “lax” schemas) and one set of schemas where the data types have been further restricted to perform stricter validation (called “strict” schemas).

The legislation only refers to the “lax” schemas and the “strict” schemas are only provided as “tools” which the National IT and Telecom Agency has made available for developers to test that the messages generated by their systems conform to the legislation.

XML schemas can go a long way in regards of validation, but the technology cannot express all the rules of integrity that the legislation contains. Thus XML schemas cannot replace the checking of integrity rules that a programmer can code. However, other schema languages like Schematron can go even further that XML schema.

Validation with Schematron

In order to check as many integrity rules as possible, a third validation tool was developed using Schematron. This tool allows contingent validation. Integrity rules regarding internal contextual dependencies between elements and/or attributes that cannot be expressed in XML Schema are expressed in Schematron.

Normative parser reference in online validator

Putting up a syntax wall in the VANS-network

Public authorities and private companies have been positive

The initiative on introducing electronic invoicing has been well received by all parts of the public and private sector. Even companies and authorities that have had considerable implementation difficulties have never questioned the need for such an initiative. The criticism that the initiative received concerned both the overall implementation schedule and the fact that the national standard was not based on UBL version 1.0, but a localized version of UBL 0.7.

Allow implementers 6 months to implement, test and deploy

Implementers were basically only given two and a half months to develop, test and deploy the necessary software to the public institutions and the private institutions invoicing them. The Ministry of Finance was well aware that this schedule was very “optimistic” as it was expressed in public statements. When launching a standard like UBL in the public sector with thousands of institutions and thousands of suppliers, all the legislation work and the necessary localization of international standards and specifications should be “frozen” at least 6 months prior to launch. A detailed plan for how implementations can be tested should be ready. Furthermore, it would have been advantageous to have had a six month gap between the requirement for public institutions to receive electronic invoices and the requirement that they only receive electronic invoices. This would have given developers responsible for producing invoicing systems the chance to test compatibility with the reception systems that would already have been established.

Make reference implementations and validation tools available

One of the most successful tools that was developed to support the implementation of the UBL invoice document, was an online validation tool.