Have e-invoicing software built

When custom software is the right answer

The market for e-invoicing software is crowded. There are good standard products, and for many companies they are the right choice. I will say so openly in the intro call if I get the impression that an existing product solves your problem.

But there are situations where standard software does not fit:

• Your invoice data sits in several systems and has to be merged first.
• You have billing logic no standard product knows — tiered pricing, usage-based billing, project-based partial invoices.
• You run an industry-specific system for which no e-invoicing extension exists.
• You do not want to hand the data to a cloud service.
• You process very high volumes and per-document licences would cost more than your own solution.

In these cases custom software is usually cheaper in the long run and always more flexible.

What the software has to do

A complete e-invoicing solution consists of four building blocks. Depending on where you stand, you need one of them or all four.

Generation

A file following EN 16931 is produced from your invoice data. That sounds simpler than it is, because the standard has numerous mandatory fields that are often missing or named differently in data that has grown over the years. A large part of the work is closing those gaps properly instead of inserting placeholders that cause problems at the recipient later.

Validation

Every file produced is checked against the official rules before it leaves the company. KoSIT publishes Schematron rules for this, whose error messages are unreadable for a finance team. I translate those messages into plain text with a pointer to the affected field and what would have to change.

Sending and receiving

The route to the recipient is not standardised. Public sector clients use portals such as ZRE or OZG-RE, many companies use plain email, and internationally a lot runs over the Peppol network. A good solution covers all relevant routes and records what went where and when.

The same applies in reverse on the inbound side: incoming e-invoices are read, checked, matched to an order or project and handed over to accounting.

Storage

Invoices are subject to retention obligations. The structured original has to be preserved unchanged — more on that under GoBD-compliant archiving.

How I work

I never start with code, but with your real invoice data. During the analysis I look at which fields exist, which are missing and where data quality becomes a problem. Only after that does a quote with a clear scope appear.

Development runs in short rounds. Every week you get a build you can try out, not a presentation. That is less comfortable, but it prevents something being finished at the end that misses your day-to-day reality.

On completion you receive the source code, technical documentation and a handover session. The solution belongs to you, not to me.

What you should bring

Very little. It helps if you can show me:

• a few real invoices, anonymised is fine
• access to the system where the invoice data is created today
• who you invoice — public sector, domestic companies, customers abroad

With that, an intro call is usually enough to clarify whether custom development makes sense or whether converting your existing invoices gets you there faster and cheaper.