Technical requirements

European standard (UBL 2.0)

Universal Business Language (UBL) is a library of standard electronic XML business documents such as purchase orders and invoices. UBL was developed by an OASIS Technical Committee with participation from a variety of industry data standards organizations. UBL is designed to plug directly into existing business, legal, auditing, and records management practices. It is designed to eliminate the re-keying of data in existing fax- and paper-based business correspondence and provide an entry point into electronic commerce for small and medium-sized businesses.

UBL is owned by OASIS and is currently available to all, with no royalty fees. The UBL library of business documents is a well-developed markup language with validators, authoring software, parsers and generators. UBL version 2.0 was approved as an OASIS Committee Specification in October 2006 and version 2.1 is under public review (as of 2012). Version 2.1 is fully backward compatible but adds 33 new document schemas.

UBL traces its origins back to the EDI standards and other derived XML standards. In version 2.0 there are 31 documents covering business needs in the phases of presale, ordering, delivery, invoicing and payment.

Source of above mentioned info: wikipedia

Belgian (e-fff) agreements accompanying the protocol

As described in the previous section, the UBL 2.0 standard is able to cover more than creating an electronic invoice. The signatories of the e-fff protocol have agreed to narrow the scope of the e-fff protocol and not to support all of the available fields that are available in the UBL 2.0 standard.

XML format and embedded pdf object

Every electronic invoice will be represented by one single xml file. Hence one e-invoice equals one xml file. The signatories of the e-fff protocol have additionally agreed to add an embedded pdf object of the invoice to the XML file.

Determination of the fields

The e-fff protocol also provides for both the main and the detailed lines of the invoice, a list of fields to be used for reading and writing.

These fields are indicated as:

  • mandatory (listed in Annex 1 with code M)
  • optional (listed in Annex 1 with code X).

Mandatory fields are necessary for the recognition of electronic invoicing.
Optional fields will necessarily be supported by the users of the protocol to the extent that the user has the appropriate module.

The other fields of the UBL 2.0 standard that are not listed as mandatory or optional in Annex 1, are not supported by the e-fff protocol. 
The protocol supports about 200 fields of the 1.000 available fields in the UBL 2.0 standard. This involves that 800 fields are generally not included in the protocol e-fff for SME’s but should however not preclude third parties to add, use and process these fields in parallel, without officially supported by the members of the e-fff community.

All fields are included in an Excel table (Annex 1) that describes the characteristics of each field and where appropriate reference to external standards (GS1, ISO lists etc..). If necessary, the fields are also commented on the implementation of the e-fff protocol.

Document type (invoice versus credit note)

Ubl Oasis recommends that the total document is always positive regardless of the type of document. Therefore, the total of a credit note must generate positive totals. This recommendation relates to the total of the document but not the detail lines that retain their mix of positive / negative amounts.

Type of document from the issuer application is an invoice:

  • if the total is positive then it generates a document type '380'. Lines retain their sign.
  • if the total is negative, then it generates a document type '381', but the totals in the XML file are set to positive. Lines of which the amount is negative are set to positive in the XML and vice versa.

If the document type from the issuer application is a credit note, then there are 2 cases possible:

  • The issuing application registers the amounts as positive
    • if the total is positive then it generates a document type '381'. Lines retain their sign.
    • if the total is negative, then generating a document type '380', but the totals in the XML file are set to positive. Lines of which the amount is negative are set to positive in the XML and vice versa.
  • The issuing application registers the amounts as negative
    • if the total is positive then it generates a document type '380'. Lines retain their sign.
    • if the total is negative, then generating a document type '381', but the totals in the XML file are set to positive. Lines of which the amount is negative are set to positive in the XML and vice versa

Invoice lines

Header of the invoice versus line details

There are no specific agreements concerning the match between the total in the header of the invoice and the detail lines, mainly because this is by rounding theoretically impossible. The receiver has the responsibility to prevent the possible inconsistency that may arise in this way. Although this control is not mandatory, this seems to be a useful control to be set up in the software.
Deviations between detail and header only apply to amounts, not to other parts of the block TaxTotal, eg the VAT codes used in the detail lines must also appear in the header and vice versa.
A possible control based on the tag “LineCountNumeric” was proposed (control between the value of that tag and the effective number of detail lines), but this is not mandatory.

Rounding / number format

Amounts are mentioned with the number of decimals that match the currency code.
(e.g. EUR = 2 decimals)

Tax codes

International codes specified by UN/EDIFACT (United Nations Directories for Electronic Data Interchange for Administration, Commerce and Transport) are used to preserve the international interoperability.  These codes are accompanied by additional Belgian VAT codes on which the members of the e-fff protocol committed to add these to the e-fff invoice and agreed upon the mapping towards the international codes.
A list of the international codes, see http://www.unece.org/trade/untdid/d07a/tred/tred5305.htm

Code Code description Details
A Mixed tax rate Code specifying that the rate is based on mixed tax.
AA Lower rate Tax rate is lower than standard rate.
AB Exempt for resale A tax category code indicating the item is tax exempt when the item is bought for future resale.
AC Value Added Tax (VAT) not now due for payment A code to indicate that the Value Added Tax (VAT) amount which is due on the current invoice is to be paid on receipt of a separate VAT payment request.
AD Value Added Tax (VAT) due from a previous invoice A code to indicate that the Value Added Tax (VAT) amount of a previous invoice is to be paid.
B Transferred (VAT) VAT not to be paid to the issuer of the invoice but directly to relevant tax authority.
C Duty paid by supplier Duty associated with shipment of goods is paid by the supplier; customer receives goods with duty paid.
E Exempt from tax Code specifying that taxes are not applicable.
G Free export item, tax not charged Code specifying that the item is free export and taxes are not charged.
H Higher rate Code specifying a higher rate of duty or tax or fee.
O Services outside scope of tax Code specifying that taxes are not applicable to the services
S Standard rate Code specifying the standard rate.
Z Zero rated goods Code specifying that the goods are at a zero rate.

Financial (payment) discounts

The tag “PaymentTerms\Amount” is agreed upon to be used for mentioning the amount of financial discounts related to the payment of the invoice. This tag is not mandatory.

XML file naming

The e-fff community recommends to use the following file naming:
efff_BE0123456789_AlphaNumericCharactersFreeOfChoice.xml

Validations

There are no extra validations​​.

Sample files

Sample files can be requested at sabine@forumforthefuture.be. Download from the website will be available soon.

Testing procedures

Anyone who wishes to test their sample XML files can submit these files by mail to sabine@forumforthefuture.be who will distribute these files to the e-fff Community. It is recommended to submit as many different types available (invoices with or without detail lines, credit notes, different tax types, currency, discounts etc..).
After validation of the e-fff Community, the submitter gains compatibility and will be mentioned on the e-fff website.