Your SlideShare is downloading. ×
Comparing ZuGFeRD Syntax with Cross Industry Invoice v2
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Comparing ZuGFeRD Syntax with Cross Industry Invoice v2


Published on

Analisys of two electronic invoice syntaxes, CIIv2 from UN/CEFACT and ZuGFeRD, identifying differences and similarities.

Analisys of two electronic invoice syntaxes, CIIv2 from UN/CEFACT and ZuGFeRD, identifying differences and similarities.

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. >> ZUGFeRD vs Cross Industry Invoice A comparative analysis August 2013
  • 2. What ZUGFeRD claims to be? • A Data Model constraining the CII Data Model • An XML Syntax with three customizations(Basic, Comfort, Extended) • A packaging specification (PDF/A-3 incl.XML) • Governance from DIN (German Institute for Standardization) ZUGFeRD optional fields ZUGFeRD mandatory fields Cross-Industry Invoice
  • 3. Comparing the XSD Syntax  Comparing two electronic invoice Syntaxes  Cross Industry Invoice from UN/CEFACT  ZUGFeRD from AWV 3
  • 4. ZUGFeRD vs CIIv2 - Main findings • From a licensing point of view – ZUGFeRD has a copyright from AWV e.V. • From a Data Model point of view: – Any syntax based on CIIv2 Data Model may not be semantically interoperable with ZUGFeRD. • From a Syntax point of view: – ZUGFeRD is yet another invoice syntax, defined for the German Market – ZUGFeRD syntax is not interoperable with CIIv2 or CIIv3 syntaxes – ZUGFeRD is “derived” from CIIv2 • Mapping from CIIv2 to ZUGFeRD means losing data • Mapping from ZUGFeRD to CIIv2 can be impossible at instance level due to cardinalities (missing fields in ZUGFeRD mandatory in CIIv2) – ZUGFeRD has redefined most UN/CEFACT data types and they do not match – CIIv2 Codelists constrain data types, ZUGFeRD does not restrict values based on coded lists at XSD level.
  • 5. 5
  • 6. XSD Architecture and elements CII v2.0 • Four schemas: – Main, reusable and two data types • Garden of Eden approach – Defines types and entities as reusable elements • More things – 167 lines main schema – 78619 lines reusable schema – 3894 lines qualified + unqualified datatypes ZUGFeRD • Four schemas: – Main, reusable and two data types • Venetian Blind approach – Defines only types as reusable elements • Less things – 35 lines main schema – 272 lines reusable schema – 147 lines qualified + unqualified data types 6
  • 7. XSD architecture models Cross Industry Invoice ISO 15000 CCTS compliant Based on reusable schema modules ZUGFeRD Similar architecture All schemes are rewritten and non interoperable with CIIv2 7 Cross Industry Invoice Schema Reusable Library Schema Qualified Data type Schema Unqualified Data type Schema Codelists Schemes ZUGFeRD Invoice Schema ZUGFeRD Reusable Library Schema ZUGFeRD Qualified Data type ZUGFeRD Unqualified Data type ZUGFeRD Codelists Schemes
  • 8. Unqualified Data Types • ZUGFeRD redefines Unqualified Data Types and there are relevant differences with CIIv2 Unqualified Data Types – Differences in attributes for the data types – There are no attributes defined for Code Type – Only schemeID defined as attribute for IDType – No languageID in Text Type – Differences in code lists to restrict values on attributes of data types: • No currency codes defined in the ISO4273 ZUGFeRD xsd. No restriction on currencies. • Quantity Type UnitCode is restricted by lenght instead of using the UN/CEFACT code list – Missing datatypes • e.g. BinaryObjectType and DateType are not present
  • 9. Qualified Data Types • ZUGFeRD redefines the qualified data type xsd and there are relevant differences with CIIv2 qualified data type: – Redefines CIIv2 qualified data types removing constraints • CurrencyIDType is no longer restricted to the ISO42173 two digits • CountryIDType is no longer restricted to the ISO3166 codelist • DocumentCodeType no longer restricted to D1001 codelist • TaxCategoryCode no longer restricted to 5305 codelist • TaxTypeCode no longer restricted to 5153 codelist – Creates new qualified data types, not restricted • E.g. PaymentMeansCode or FormattedDateTime – Misses many qualified data types from CIIv2 • E.g. AddressTypeCode, InvoiceDocumentCode, PartyRoleCode,…
  • 10. Reusable Aggregate Business Information • ZUGFeRD redefines the Reusable Aggregate Business Information, it is quite different from the CIIv2 reusable library: – It does only define 32 global complex types. CIIv2 library of reusable objects defines 420 global complex types. • Names of complex types do not match: NoteType vs CINoteType • Structure of complex types do not match: – CreditorFinancialAccountType has two elements: IBANID and ProprietaryID, CICreditorFinancialAccountType in CIIv2 has an additional element: AccountName. – NoteType has Content and SubjectCode only, while CIIv2 has Content unbounded, ID and SubjectCode. – Does not define global elements. CIIv2 defines 3704 global elements.
  • 11. Main Invoice Schema • Different elements, different names, different cardinalities • ZUGFeRD: – Main element is called Invoice, type is CBFBUYType – This element has three optional child elements: • SpecifiedExchangedDocumentContext • HeaderExchangedDocument • SpecifiedSupplyChainTradeTransaction • CIIv2 – Main element is called CrossIndustryInvoice, type is CrossIndustryInvoiceType – This element has three mandatory elements and one optional. • CIExchangedDocumentContext (Mandatory) • CIIHExchangedDocument (Mandatory) • CIIHSupplyChainTradeTransaction (Mandatory) • ValuationBreakdownStatement (Optional)
  • 12. Some differences Type Cardinalities Missing elements Naming
  • 13. Code lists Cross Industry Invoice • Uses codelists defined by external bodies bundled into XSD as enumerations (sometimes) • Currency code types follows: <xsd:simpleType name="MeasurementUnitCommonCodeContentType"> <xsd:restriction base="xsd:token"> <xsd:minLength value="1"/> <xsd:maxLength value="3"/> <xsd:enumeration value="05"> <xsd:annotation> <xsd:documentation> <ccts:Name>lift</ccts:Name> </xsd:documentation> </xsd:annotation> </xsd:enumeration> … ZUGFeRD • Has an Excel file with code lists defined • Does not constraint through XSD codelists. • Redefines codelists xsd removing codes: <xs:simpleType name="MeasurementUnitCommonCode ContentType"> <xs:restriction base="xs:token"> <xs:minLength value="1"/> <xs:maxLength value="3"/> </xs:restriction> </xs:simpleType> 13