EPC QR code invoices without typing errors

A payment sits in the account and nobody knows what it belongs to. No reference, one digit swapped in the invoice number, an odd amount. So somebody in accounting spends half an hour searching, calls the customer in the end, and the customer is puzzled, because he transferred the money days ago. An EPC QR code on the invoice deals with that at the source: it takes the typing away from the customer before the mistake can happen.

The mistake happens while somebody is typing

The cause is rarely in the system. It is in the hand movement in front of it: 22 characters of IBAN, an amount, a reference, copied off paper or a PDF into online banking. Every one of those lines is a chance to transpose two digits.

Europe has had an answer to this for years. In Germany it is known as the GiroCode, technically a QR code following EPC069-12, the standard of the European Payments Council. It carries payee, IBAN, amount and reference. The customer opens the banking app, points the camera at the invoice, and the transfer form is filled in. He checks it and confirms. That is the whole interaction.

What an EPC QR code API takes over in the invoice run

The benefit lands on both sides. Your customer pays sooner because the hurdle is smaller, and you get payments that can be matched, because the reference is right every single time.

The catch is never the code itself. It is the place where the code has to appear. Invoices come out of the ERP, out of the shop, out of the accounting software, often out of several of them at once. Pasting a picture in by hand does not scale past the first week.

So we built the GiroCode API: an interface that turns IBAN, amount and reference into a finished code as SVG, PNG or JPG, in milliseconds, with the IBAN validated before anything is generated at all. It gets connected where the invoice is born:

• in the ERP or the inventory system, straight into the invoice template
• in the shop, for payment in advance or on account
• in the accounting software or in a mail merge

What decides in practice whether it works

Adding the code takes half an hour. The questions a project like this actually hangs on are different ones, and they are worth settling first.

Where exactly does the code sit on the invoice? Next to the bank details, not in the footer. Put it where the eye is already looking for the IBAN and you save yourself every explanation. A short line beside it, "scan with your banking app", noticeably lifts how often it gets used, especially the first time somebody sees one.

Does the reference match what your accounting expects? The entire gain only appears if the text inside the code is exactly the reference your system looks for later. Get generous with the wording here and you have shipped the code and kept the handwork.

What happens with part payments and credit notes? A fixed amount in the code is convenient, and it gets in the way as soon as somebody pays in instalments or settles open items. In that case you leave the amount out. The customer types it himself, and IBAN and reference are still free of errors.

Who generates the code, the server or the layout? We recommend the server. Then the code still exists when the invoice is regenerated months later, archived as a PDF or sent by mail again.

Common questions

Does this work with every banking app?

With the common banking apps in Germany, yes. The standard behind it is European and open, not one provider's offer, so nobody has to sign up for anything. Whoever does not use an app transfers the money the way they always did: the code sits on the invoice in addition to the details, it does not replace them.

Is this payment processing?

No, and that is the pleasant part. No money moves through us, there is no payment service provider in between and no commission per transaction. The code is nothing more than a machine readable version of your own bank details.

What happens to the data on the invoice?

The code is built from the details that are printed on the invoice anyway. The interface runs on our own infrastructure in Germany, or inside your environment if you would rather the invoice data never left the building. Both are normal, and which one fits is a question of your rules, not of the technology.

How we approach it

Pieces like this are typical custom software: small in scope, sitting exactly where the working day snags. Built so it can be connected, rather than as one more program somebody has to open in the morning. If you want to try it before you decide anything, the interface and its documentation are at girocode-api.de.

If you want to know whether it fits into your invoicing, tell us what you write invoices with. Whether that is an afternoon or a project, we will say so honestly. Talk to us.