It appears the Dutch government is engaged in a struggle with its own tech-savvy developers who wish to invoice them using the SI UBL 2.0 standard for e-invoicing. Even though a standard might be useful, the government seems to have gone overboard this time. With a slogan like “Simpler invoicing,” it suggests that this methodology is anything but simple.

In reality, it’s highly complex and costly to implement.

The government has chosen an old-fashioned XML/XSD implementation. XML/XSD would be tolerable if there weren’t any other options for standardizing contracts. However, this is no ordinary XML/XSD file. It’s an XML with numerous imports to other files, many of which are irrelevant to most businesses.

I support standards, but I also advocate for easy implementation and minimal friction.

Factors that make adoption and implementation difficult:

  • Dispersed documentation with no clear, straightforward implementation method. A single resource explaining how to implement the spec is not readily available.
  • Excessive implementation details, many of which are likely irrelevant to your business.
  • Limited libraries for popular programming languages, with the exception of Java.
  • An overly complex one-size-fits-all solution for various invoicing needs.
  • A whopping 243 rules plus 700+ warnings for the implementation (even with schematron).
  • Support is either hard to find or expensive.

Specific challenges with this XML/XSD standard:

  • Generating a compliant XSD/XML file without .Net/Java is already difficult. Proper parsers, validators and serializers for other major platforms (like XSD.exe on .net) are minimal, forcing you to develop your own solutions.
  • Tooling outside Java/C# is mediocre, making it hard to create fully compliant XML files from XSD and objects.
  • Merging validation rules, data structures and translations into one file.
  • Utilizing a bloated data transportation format.

I will open a repository and a Slack for companies needing help with implementing this standard. Feel free to reach out.

What truly frustrates me about the Dutch government’s approach:

  • SimplerInvoicing.org, a company recommended by the government’s website, charges €99 per month for a support portal. More details available here.
  • Forcing companies to use this arcane standard with insufficient implementation documentation, libraries to generate invoices or support, resulting in higher costs for businesses due to implementation, XSLT, XSD, language porting, schematron, ongoing support, and bug-testing. This over-engineered, convoluted standard brings unnecessary hardship. Don’t do it.

So, what’s the best approach, really?

  • Simplify vendor adoption by generating code from XSD/XML files for validation and parsing.
  • Offer libraries or packages and working samples in the top 3 languages for reference.
  • Centralize a single git repo containing clear samples, a README.md to get started, and possibly Docker images for out-of-the-box functionality.
  • Create a standard with only what’s absolutely necessary for 80% of vendors and focus on that primary use case.
  • Supply converters, if required, between formats.
  • Emphasize the core protocol, similar to Byron Lee’s method with GraphQL or the RFC process used with MOP, and minimize nonessential inclusions.

Standards have their place, but they should be easy, accessible, and cost-effective to implement.