e-invoice trainings 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.
- GoBD Details
- 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.
- EDI, EDIFACT and APERAK Details
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
- SDKs Details
- 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
- Well-formedness Details
- 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)
- XSLT Details
XSL transformations allow to transform any XML file in one format into anotther file in the same, or a different format
- 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.
- Validate using XSLT Details
- 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.
- Basics Details
- 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.
- Basics Details
- 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.
- Reading Details
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: