From Copy-Paste to QR Code: A 5-Minute Tool That Fixed a 4-Year Annoyance

The annoyance I lived with for four years

Like most small companies, I rely on a handful of tools to keep the financial side of the business running. For bookkeeping, payroll (Gehalt) and pretty much everything financial, my main tool is Lexware. My business banking runs through Holvi.

On paper, these two should play together nicely. In practice, there is a small but persistent gap between them:

Lexware does not support initiating transfers (Überweisungen) directly with Holvi.
Holvi does not support importing the SEPA XML export that Lexware produces for those transfers.

So for four years, every payroll run and every batch of transfers meant the same tedious ritual: open Lexware on one side, open Holvi on the other, and manually copy-paste each transaction — recipient name, IBAN, amount, reference — one by one, line by line. It is exactly the kind of routine work that is too small to ever make it onto a project plan, but just annoying enough to quietly cost time and attention every single month.

The realization

The Lexware export is a standard SEPA pain.001 XML file. It already contains everything I need: each Überweisung with its creditor name, IBAN, amount and remittance information.

And modern banking apps — including the Holvi app — can scan EPC QR codes (also known as Girocode). Scan a code, and the transfer form is pre-filled automatically. No typing, no copy-paste, no transposition errors.

The missing piece was tiny: something that reads the XML and turns each transaction into a QR code. That’s it.

The tool

So I built it. The whole thing is a single HTML file that runs entirely in the browser:

You drop in the SEPA pain.001 XML file that Lexware exports.
It parses every CdtTrfTxInf transaction in the file.
For each one it generates a scannable EPC/Girocode QR code, alongside the recipient, IBAN, amount and reference.

Then I just scan the codes with my banking app, one after another, and the transfers are pre-filled. No data ever leaves my machine — the parsing and QR generation happen locally in the browser.

You can try it here: SEPA XML → QR codes .

What it actually took to build

Here’s the honest part: I didn’t write this code by hand. I described what I wanted to Cursor, and this was — almost literally — the entire prompt:

create a very simple website with javascript code to convert a sepa xml file like
@snippets/tools/SEPA_Ueberweisungstraeger_2026-06.xml to sepa QR codes that can be
scanned with the banking app.
The xml contains multiple (in the example just two) überweisungen.
implement the page in @snippets/tools/sepa-xml-to-qr-codes.html
For styling use tailwind css latest version.
If it makes sense import a well established javascript framework for form and services handling.
If possible everything should be kept in one html file plus a few resources for javascript, images, etc.

That was it. No back-and-forth, no debugging session — the tool came out working.

But notice what’s in that prompt. I still had to know what I wanted: a single-page application, kept simple and maintainable, with the right shape of solution (parse the XML, generate Girocodes), sensible technology choices (Tailwind, an established library where it helps), and a constraint to keep it to one self-contained file. The AI didn’t decide that this was the right tool to build, or how to scope it. That part is still the job — and it’s exactly the part that comes from experience.

A few implementation notes for the curious:

The QR payload follows the EPC069-12 specification (the Girocode standard) that German and European banking apps understand.
I used version 002 of the format, which allows omitting the creditor BIC — the Lexware export only contains the debtor’s BIC, and BIC is optional for SEPA transfers within the EEA.
Everything is one HTML file plus a few well-established libraries loaded from a CDN (Tailwind CSS for styling, Alpine.js for the small bit of interactivity, and a battle-tested QR-code generator with proper UTF-8 handling so German umlauts encode correctly).

The build took less than five minutes of actual work.

The bigger point

Here’s the part I find genuinely interesting. This problem existed for four years. The fix was always technically simple. So why didn’t I build it before?

Because the math never worked out. Spending an afternoon writing, testing and styling a one-off utility to save a few minutes a month is hard to justify. The annoyance stays just below the threshold where you’d actually invest the time — so you keep copy-pasting.

What changed is the cost of building small solutions. With AI-assisted development, a focused tool like this goes from “an afternoon I can’t spare” to “five minutes between two other tasks.” When the implementation cost drops that far, a whole category of previously-not-worth-it improvements suddenly becomes worth it.

That’s the real shift. It’s not the one flashy automation — it’s the long tail of tiny frictions in routine work that you can finally afford to remove. A few minutes saved here, a manual error avoided there. Individually small; together, a noticeably smoother workflow.

This little SEPA-to-QR tool is my favorite example so far: a four-year annoyance, gone, for five minutes of effort. I’ll be keeping an eye out for the next one.

And to be clear: turning a small task into a small tool is the easy end of what I do. The more valuable work is the bigger version of the same idea — helping companies integrate AI into their existing software products and workflows. That means knowing where AI actually pays off, how to wire it into systems that are already in production, and how to do it in a way that’s maintainable rather than a one-off demo. The five-minute tool and the production integration draw on the same skill: knowing what to build and how to scope it well. AI makes the typing fast; the judgment is still the point.

If you have a similar bit of routine friction in your own workflow — or you’re looking to integrate AI into an existing product or workflow — let’s talk .