Our e-invoice trainings, which can also be more solution-centered workshops around special tasks can  be held in our office in Frankfurt, in your office, or online. They usually consist of a general and a technical part. The generic part usually contains topics like

  • Legal and compliance Details
    The european legal situation for e-orders and e-invoices, in particular in Germany for B2G invoices
    • GoBD Details
      In Germany, all processes and tools for sending, processing and receiving e-invoices have to comply to the GoBD.
    • Auditing requirements Details
      The auditing requirements of the GoBD vis a vis tools to store e-invoices, their processes, their backups and their as well as their unalterability
    • Invoice retention Details
      How long invoices have to be made available before their archival
    • Procedural documentation Details
      The requirements of the GoBD as regards to procedural documentation e.g. of the decision if the XML or the PDF-part of an invoice be processed
    • VAT regulations Details
      Why and how the legislation of identical copies (Inhaltsgleiche Mehrstücke) affected Factur-X/ZUGFeRD
    • EU/2014/55 Details
      Directive EU/2014/55 of the European Commision was the start of a unified requirement vis a vis all European member countries to be able to process electronic invoices
    • EN16931 Details
      CEN EN16931-1 – EN16931-5 is the standard to aid EU/2014/55. We will have a look e.g. at the eligible syntaxes and the calculation rules.
    • E-Government-Gesetz Details
      The german E-Government-Gesetz is the german ratification of EU/2014/55 and additionally to enforcing the authorities to accept e-invoices, it also prohibits most vendors to further send paper invoices
    • E-Rechnungs-VO Details
      The E-Rechnungs-Verordnung aids the E-Government-Gesetz and e.g. established deadlines until when the migration has to take place.
    • E-Rechnungen international Details
      We’ll have a look at special requirements of certain countries, e.g. digital signature (Hungary) or Rappenrundung (Switzerland)
    • Gross price definition Details
      In germany, gross is often translated as Brutto, including VAT that conflicts with the definition in EN16931, CII and UBL where gross is more of a basic list price, without VAT
    • Substitutional scans Details
      The GoBD imposes certain requirement on the processes and tools if paper invoices are to be destroyed after their scan.
    • Invoice Recognition and ZUGFeRD Details
      We cover the topic if and how potentially incomplete OCRs can still build a valid Factur-X file and if profiles are upwards compatible.
  • History and generic info Details
    How the standards have evolved and what are their purposes
    • EDI, EDIFACT and APERAK Details
      Electronic Data Interchange, EDI, combines the meaning of a format with the addressing and exchange of a protocol. Despite being more complex, EDI is much older than XML based e-invoicing, and still in use today. The introduction of (international) e-invoicing standards in germany in fact dates back to the 1977 introduction of EDIFACT.
    • APERAK Details
      The XML Application error and acknowledgement messages
      can be used to signal acceptance or rejection of invoices
    • unstructured vs structured invoices Details
      Unstructured invoices are human-readable (e.g. image files, TIFF, PDF even with OCR layer), structured invoices are machine readable (e.g. XML files). Unstructured invoices are generally easier to obtain, e.g. by scanning paper invoices, but they can not be processed automatically.
    • UN/CEFACT vs UBL Details
      UBL was initiated by the UN/CEFACT but later replaced by it’s own standard. There are slight differences between OASIS UBL and UN/CEFACT, their extentability, their governance, and their institutions.
    • ZUGFeRD v1 Details
      In 2014 ZUGFeRD defined how to embed XML in PDF to get a hybrid invoice, both structured and unstructured at the same time. PDF/A was selected as the carrier, a customized UN/CEFACT CII/2013b for the data and three subsets („profiles“) were defined.
    • ZUGFeRD v2 Details
      ZUGFeRD version 2~=Factur-X version 1 switched UN/CEFACT CII from a customized 2013b to a unchanged 2016b version, introduced first two more profiles and renamed one. Later, in v2.1.1, the concept of reference profiles were conceived.
    • Factur-X Details
      Factur-X 1 started as a french fork of ZUGFeRD 2 led by the FNFE. The „Factur-X namespace“ soon also became the recommended name(space?) for ZUGFeRD.
    • Order-X Details
      Order-X is the sister standard to Factur-X, with in PDF embedded XML of orders instead of invoices. Process-wise it also supports proposal and acceptance of changes. For this purpose, UN/CEFACT CrossIndustryOrder 2020b is used, the embedded file is called Order-X.xml.
    • CIDA Details
      GS1 and BVL are working on electronic despatch advices based on UN/CEFACT Cross Industry Despatch Advice, crossing the gap between orders and invoices
    • unit codes and other codelists Details
      The different lists of the different standards for eligible attribute values have been centralized by the CEF, who republish them as excel. They are binding for EN16931, i.e. not only CII but also UBL.
    • XRechnung Details
      The XRechnung is the requirements specification of the german government vis a vis electronic invoices. XML-wise they are mapped to CII and UBL and it makes certain attributes mandatory, e.g. the postal address of the receiver and a seller contact as well as the governmental routing number „Leitweg-ID“. Due to political reasons cash discounts are handled using a proprietary format, not XML. Validators exist and they can be uploaded to different portals. This lesson als clarifies Business Term IDs and how to find them (and cardinalities) in ZUGFeRD’s technical appendix.
    • CIUS vs additional data Details
      Core Invoice Usage Specifications, CIUS, like the german XRechnung, can make optional attributes mandatory, Andreas Starke’s additional data can cater additional structured attributes for electronic invoices.
    • Industry recommendations Details
      E.g. the Deutsche Bahn or the construction industry has published requirements vis á vis Xrechnung respective ZUGFeRD files, and the french Chorus Pro has published requirements both for french B2G as well as for french B2B invoices.
    • PEPPOL Details
      PEPPOL is a international EDI organization, based on UBL messages and the AS/4 protocol, which implement a four-corner model for their paying customers.
    • E-invoicing vs e-Billing Details
      E-Billing, in Germany for amounts <150 Eur, allow amounts with VAT which could otherwise not be expressed, e.g. 20,20 Eur @ 19%. However,
    • Document types Details
      Apart from usual invoices, sometimes there might be need for reminders (not in scope), credit notes, or corrected invoices.

and technical topics can contain e.g.

  • Tools
    • SDKs Details
      Open Source SDKs for C++, Java, Python and PHP are covered
    • Open Source tools Details
      Open source tools for Metadata and schema validation
    • Libraries Details
      Which free libraries can be used to make software e.g. Factur-X ready
    • Software stack/Creation tools Details
      Free software and editors which perform e.g. schema validation for XML authoring
    • Consuming applications Details
      Free open source private banking software and e-invoice viewers
    • Validators Details
      Free software to re-calculate invoices and check their formal correctness
    • Miscellaneous Details
      E.g. text editors, hex editors and diff tools for XML authoring
  • XML Details
    XRechnung and Factur-X/ZUGFeRD consist of XML files, this convers XML’s validity, in general, tools to validate, address, mix and transform XML and gives an intro to the two most important XML formats for electronic invoices, UN/CEFACT Cross Industry Invoice (used for Factur-X/ZUGFeRD and XRechnung) and UBL (used for XRechnung and Peppol)
    • Basics Details
      Basics for XML in general: Charsets and general validity
      • Well-formedness Details
        Describes how XML is a hierarchical format and what all XML files must and must not have, as well as a authoring tool to ensure that
      • Schema Details
        Schema files also allow to specify which format e.g. attributes should take, e.g. that the total amount has to consist of numbers with two decimals.
      • UTF8 Details
        Unicode is the most important international character encoding for XML, UTF8 is a 8 bit representation that comes with certain peculiarities, e.g. a possible Byte Order Mark
      • Namespaces Details
        Namespaces are used to blend XML documents together
    • UN/CEFACT CII, CIO and CIDA Details
      UN/CEFACT CII is a standard used for electronic invoices, the „MUG“ has been determined as it’s european subset. For orders, CIO can be used. The current version, schema file, the root, the basic elements and the basic namespaces are described.
    • UBL Details
      UBL is another XML invoice standard. Alternative XML structures and why they are deprecated are discussed (e.g. OpenTrans, FinInvoice). Here as well the current version, schema file, the root, the basic elements and the basic namespaces are described.
    • Xpath Details
      Xpath is a standard used to find, address and aggregate XML elements and attributes. Apart from being useful to find invoice data, it plays an important role when transforming XML (with XSLT) and when validating XML (using schematron)
      • Evaluation Details
        Simple Xpath queries and how to run them on a sample document
      • Validators Details
        How and why Schematron uses Xpath to be able to specify tests/validations on XML files
    • XSLT Details
      XSL transformations allow to transform any XML file in one format into anotther file in the same, or a different format
      • Saxon Details
        Saxon is a powerful open source engine to apply XSLT
      • Apache FOP Details
        Apache FOP can be used to generate PDF from a particular XML format, called „Formatting Objects“ (FO), so a XML file can be translated into PDF
    • Schematron Details
      Schematron files use Xpath to be a much more powerful validation than mere Schema files can do, allowing e.g. mathematical operations like the total amount has to match the sum of the items. Which e-invoice related schematron files are published where is part of this lesson.
      • Validate using XSLT Details
        Schematron rules can be converted to format specific XSLT files, in which case the XSLT transformation output is a XML validation report of the input file against the given Schematron rules. This lesson shows how this can be done to obtain validation reports.
    • Codelists Details
      Codelists specify possible attribute values, e.g. „H87“ as unit code for „piece“. Which e-invoice related codelists are published where and which versions are relevant is part of this lesson.
  • PDF Details
    PDF is the second pillar of hybrid invoices
    • Basics Details
      Like XML, PDF is a hierarchical format, but with references, binary data and compression
    • Creation Details
      Ghostscript is one of the very few free open source tools capable of converting PDF to PDF/A. It is often used in virtual PDF printing software and actually Ghostscript can read and process PDF files so well that it is occasionally used to fix even corrupted PDFs. Even Factur-X comliant PDF/A-3 can be created with Ghostscript.
    • Structure analysis Details
      Open-Source tools like itext RUPS, Exiftool, or the structure view of the commercial Acrobat Pro highlight the internal hierachy or metadata within the PDF files.
    • PDF-A Details
      This lesson will discuss the difference between PDF and it’s archival counterparts, PDF/A-1 to 4 and why it is important to at least use PDF/A-1
    • Purpose, ISO Standard Details
      The knowledge of the aforementioned tools, along with the specifications (PDF is available, PDF/A costs money) can help to make files valid and more readable
    • Validation, e.g. using VeraPDF Details
      VeraPDF is a open source Validator for PDF/A as the common PDF standard has evolved so much that validation is de facto no longer possible.
    • File attachments, PDF/A Schema extensions and RDF Metadata Details
      Within PDF/A, file attachments are available since A-3, this lesson also has a look at the A-3 subset a, u and b, as well as PDF/A-4‘s „f“ subsubset.
  • Mustang Details
    How Mustang can be used and embedded
    • Reading Details
      How to use the command line tool to extract XML from Factur-X/ZUGFeRD
    • Writing Details
      Use the command line tool to combine XML and PDF to Factur-X/ZUGFeRD and Order-X
    • Validation Details
      Validation with the command line tool, meaning of the error types. How to follow up on rounding errors.
    • Conversion Details
      How the commandline can be used to convert ZUGFeRD from v1 to v2, from CII to UBL and (for the purpose of visualization) from CII to HTML. How Mustang can be used in automated tests.
    • Integration Details
      How to embed the Mustang Library and the Mustang validator in Java software. How to facilitate checks (and tests, e.g. the HATE test) if the calculation match. How XRechnung can be extracted from the invoice class and how invoices can be parsed either coarse or fine.

Exercises can include e.g.

  • Use Mustang to extract, combine, convert to HTML or UBL and/or validate
  • Use Kosit to validate XRechnung
  • correction of various invalid XML invoices
  • correction of invalid PDF invoices
  • Xpath authoring
  • Assign Which BT is which attribute
  • What is the correct unit code?
  • How to calculate correctly: The HATE test, gross prices
  • How to find my cardinality?
  • May I use this element?
  • Getting aquainted with rounding errors in official schematrons

The trainer: Jochen is a “don’t call me expert” kind of expert, telling about himself that he “somehow faulted his way into this topic”. He graduated in information management, published Gnuaccounting in 2004 and initiated Mustangproject and Corpus in 2014 as well as the e-invoice validator, at that time called ZUV, later incorporated into Mustang, in 2018. When new versions of standards are released he is often somehow entangled in tests.

Prices depend on the number of topics and participants and where the training is conducted. To request an offer for a individual training, please fill out these fields:








    on sitein Frankfurtonline