UN/Cefact ISO 20022 XML or/and UN/Cefact CII2?

February 23, 2011  |  Electronic Invoicing, Publications

Invinet Sistemes 230x200This post was originally written by Oriol Bausa as: “¿ISO 20022 Financial Invoice o ebXML CCTS CIIv2? (“ISO 20022 Financial CIIv2 Invoice or ebXML CCTS?) on: http://blog.invinet.org/?p=767.

Oriol Bausa is owner and CEO at Invinet Sistemes


Politically, it is understandable that a standard is recommended by an organization such as UN / CEFACT, which has had the task of facilitating e-business in the world for many years now.

For this reason it is understandable that the E-invoicing Expert Group recommend the UN / CEFACT Cross Industry Invoice version 2 (CII2).  CII2 is a standard but not very useful for practical purposes, as described in this post: http://translate.google.com/translate?hl=nl&sl=auto&tl=en&u=http%3A%2F%2Fblog.invinet.org%2F%3Fp%3D739

However, it is hard to understand that some members of the E-invoicing Expert Group – that originally recommended the UN/CEFACT CIIv2 standaard – are now trying to promote an entirely different standard: the ISO 20022 Financial Invoice.

How is it possible that within UN/CEFACT, the TBG1 group has been working with the CCTS methodology for many years to develop the model bill v.2 CII, while another group of the same organization (TBG5), dedicated to the development of a model called Financial Invoice, are using an entirely different approach, the ISO 20022?

And although politically intended to believe otherwise, the ISO 20022 and CII2 standards have nothing to do with each other, neither technically nor semantically. The mapping between ISO20022 and CII2 is so complicated (or simple) as between any of them and other standards like UBL, Facturae, Svefaktura, ebInterface …

In short, although very well recommended, for an electronic invoicing standard in Europe, it would be desirable to:

1. agree to creating/using a single model bill or abandoning its efforts.
2. recommend the members of the E-invoicing Expert Group to a bit of advice before deciding on a certain standard, and do research to what you recommend also really works.

A pity is also that countries where electronic billing is more advanced, couldn’t wait to have these standards that may have facilitated global interoperability and have already taken an other (proprietary) approach.

[Admin thoughts: In the meantime we see a serious uptake in the use of UBL. So, which will it be: UBL, ISO20022 or CII2? Or all at the same time..]


Related posts


6 Comments


  1. ISO20022 is the natural next step and is based on CIIV2

  2. There is no next step. ISO20022 is not based on CIIv2: ISO20022 and CIIv2 were developed independently from each other within the same body and are no competing. That is why UBL is already miles ahead.

  3. Roberto Cisternino

    CCTS (ISO15000) has moved the interoperability issue from syntax to semantics and this means that to meet BII or CII semantics it takes to join CCTS as well.

    ISO 20022 is not conformant nor compliant with ISO15000 and thus it is not CCTS based like UBL, GS1, PDX, CDX, SAP GDO, etc…

    ISO20022 is a wanderful effort and important result for the banking (e-finance) sector, but it is thousand miles from ISO15000 benefits.

    “Also it is important to note that the INVOICE is a trade document not a finance one.”
    There is a reason why we have a TC68 and a TC154, eh ?

    Anyway we should talk more about complementary usage of ISO20022 (e-finance) and XXX -Language (e-Business) to provide any benefit to the Financial Supply Chain.
    In particular CII is just an Invoice (not a complete language) and ISO20022 requires a more complete e-business language to ensure interoperability on the financial supply chain (e.g. payment, invoicing, reconciliation, …)
    For instance, the “advanced external remittance” case described on ISO20022 guidelines is not supported by CII because there is not a RemittanceAdvice document on CEFACT/XML yet.

    UBL provides full support for the complementary usage of e-business processes with e-finance ISO20022 processes.
    In particular UBL 2.1 has been expecially designed for providing the excellence on this field.

    UBL is always an optimal CCTS implementation and it is also a “Key” standard according the MoU/MG on e-business:
    http://www.itu.int/ITU-T/e-business/mou/MoUMG-standards.html

    According the MoU/MG we should avoid reinventing the wheel… as todays we have the syntax, semantics interoperability innovations, code lists, validation methodologies, all.
    We just need adoption, thus building/using implementation profiles.

    The Europe requires an implementation profile, not another draft…
    Standards are there:

    …with the help of some mathematics:

    + ISO 20022 (Universal Financial Industry Message Scheme)
    + UBL (Universal Business Language)
    = Universal Financial Supply Chain

    Best regards

    JAVEST CEO
    UBL IT LSC founding co-chair
    R.Cisternino

  4. While it’s interesting to see that these discussions around which formats should be supported officially or not, I think in reality this is going to be solved by the market, UBL is now the standard which is in widespread adoption and use across most of Northern Europe with support from the Scandinavian countries, the Dutch Government and with Tradeshift we are now using UBL in more than 150 countries, the genie is out of the bottle and not going back in no matter how much or how long expert groups are thinking about this, one standard already has a huge traction in the market (and the others don’t).

    Luckily UBL is an open standard, supported by OASIS, so we won’t have to fear a return to the proprietary standards of the past. With Tradeshift we actively support the development of open standards in this field, but we are not going to sit around and wait for more committees, we are adding thousand of users to UBL every week.

    Christian Lanng
    CEO, Tradeshift.

  5. Roberto Cisternino

    Good news,
    now the issue is clear enough:

    ISO20022 people are like a sect, they CANNOT use an existing Invoice based on stable third party Standard.

    They MUST use ALWAYS documents on their repository.

    Others… have to be aligned with them.

    So those banks aiming to provide e-invoicing services on the banking channel cannot use UBL nor CII or other CCTS syntaxes.

    Anyway this seems to be not an issue if existing trade and finance standards are used in a complementary way.

    Invoices should travel outside the banking channel, at least for commercial secret reasons.
    By reading ISO20022 there is the evidence the “external remittance advice” is the way for advanced payment/invoice automatic reconciliation.
    UBL RemittanceAdvice and the Invoice are a sample of such complementary use of trade messages with payment ISO20022 messages.
    The ONLY information that is traveling on the banking channel are End-to-End identifiers for reconciliation and reference to trade processes.

    It is not required to have Albert Einstain for using existing standards together.
    How much European money have to be spent again to reach a concrete result ?

    I believe solutions are underway, at least in Europe, and PEPPOL is an excellent sample of how diverse people and countries are building interoperability.
    PEPPOL is providing ***STABILITY*** to the ICT market.
    WHAT does it means ??? It means that Software Houses will have FINALLY a path to follow to upgrade their ICT solutions.
    The rest will be automatic… interoperability, saving money, so on…

    It’s time TO DO, and STOP reinventing the wheel.

    Roberto Cisternino

  6. Oriol writes an interesting article about the differences between standards based on CEFACT CCTS and ISO 20022.

    Directly below Bo Harald then writes: “ISO20022 is the natural next step and is based on CIIV2” – without any clarification.

    From a financial industry point of view, such a step may seem the natural way forward.

    However, from a procurement point of view it must be taken into account that invoicing is never done in isolation; it is always the result of some kind of commitment: a contract, order, etc.

    Additionally, not all invoices are requests for payment. We need to view the invoice document as an instrument that is supporting a wide variety of processes, whereas payment is just ONE of many.

    Örn Kaldalóns
    ICEPRO.