Heckin’. Seems like the Dutch government is waging a war against its own tech savvy devs that want to invoice them with the SI UBL 2.0 standard for e-invoicing. Sure, a standard sounds flex but wtf, they really outdid themselves this time. Wrapped in a cute slogan like “Simpler invoicing”, it expects us to be charmed as sheep to swallow that this thing is simple.

Thats not easy at all. That’s effing, complicated and expensive to implement.

We’re talking here an old school arcane XML/XSD implementation. Now XML/XSD is sorta (I SAY SORTA) okay since we don’t really have an easy alternative to standardize contracts. But hey, this ain’t your average XML/XSD file. It’s an XML with a dozen imports to other files, many of them that wont touch your business directly.

I’m pro standards, but I am also for easy implementation and low friction.

Things that make adoption and implementation hard:

  • Scattered documentation without a clear single, straightforward way of implementing it. There is not a simple site that clearly states how to implement the spec.
  • Excessive amount of details to implement, a lot of them that probably doesnt affect your business.
  • No libraries in any sane language to get you started unless Java is your thing.
  • A super elaborate cover it all solution for whatever the heck you’re trying to solve, which is not necessary for a lot of the cases.
  • A set of 243 rules in order to implement + plus 700+ warnings (yes you can use schematron but still)
  • Support is hard to find or either paid.

Some reasons why this specific XML/XSD standard is pretty tough:

  • A compliant XSD/XML file is already hard to implement properly by itself outside of the .Net/Java ecosystem. minOcccurs, unqualified, unbounded? Refs? Yes XML parsing has a pretty good coverage on any platform but the tooling and object class, validation generation, and serialization such as (xsd.exe on .net) is completely lacking on other major platforms. Forcing you to brew all the stuff yourself on other platforms.
  • The tooling for any other platform than Java/C# is at best ‘meh’. It’s hard to generate completely compliant XML files from XSD and objects.
  • It mixes validation rules, with translation and data structures in one file.
  • It’s a bloated data transportation format.

I’m opening up a repo and a Slack for the companies that need help implementing it. I’ll try my best. Feel free to give me a ping.

Additionally, things that makes my blood completely boil regarding this move from the Dutch government.

  • SimplerInvoicing.org a company that needs help, referenced from the government’s website asks asks you 99,- per month for a support portal. Check this link (dutch) for details.
  • As a government you force a bunch of companies to use your arcane standard, without any good implementation documentation, or standard libraries to generate said invoices is just a bit of a jerk. This means that not only the companies need to pay for the actual implementation of said standaard but also for the reading up on XSLT, XSD, porting to their language, schematron, ongoing support, bug-testing and overhead that goes with this. Your over engineered, over communicated standard, with arcane technologies trickles all the way down. Don’t do it.

So what would be the best approach really?

  • Make it as easy as possible for your vendors to adopt a standard. This can be done by generating code from said XSD/XML files to validate and parse the files.
  • Provide libraries / packages and working samples in top 3 for languages as reference implementations.
  • Have singular git repo on github/gitlab with clear samples, a simple README.md to get started. If possible provide docker images, so people can run the samples as-is without needing to install a runtime.
  • Come up with a standard that’s easy to implement and only does the things that are absolutely completely necessary to fullfill the most valuable use case that 80% of the vendors need.
  • Provide converters if necessary between formats.
  • Go with the absolute minimum, and make additions on top of that. Be vigilant about what needs to be included. Use a strategy like Byron Lee on the GraphQL protocol, or use something like the RFC process used with XMPP.

There is nothing wrong with standards, just make it easy and cheap for people to adhere it too 😘.

Hey you 👋 Want FREE resources to become the best developer and get a competitive edge? Subscribe!

Would you like to stay up to date on ? Subscribe here! I'll only use your email to keep u up to date on new technology and software development tips. It wont be shared. Feel free to unsubscribe anytime!