Swiss QR-Bill for Gravity PDF · add-on for Gravity PDF

A real QR-bill, not just a QR code on a page.

If you issue invoices with an account in Switzerland or Liechtenstein, you need a payment slip of the kind Swiss banks expect. Swiss QR-Bill for Gravity PDF appends a complete Swiss QR-bill to the invoice that Gravity PDF creates, with a payment part and a receipt, laid out to the millimeter as prescribed. It already follows version 2.4 of the guidelines for the Swiss QR-bill, which applies from November 14, 2026.

The QR-bill is the Swiss payment slip with a QR code, the counterpart to a SEPA credit transfer by QR code. It measures 210 × 105 mm and sits at the lower cut edge of the page. Your customer scans it with their banking app, or tears it off and hands it in at the bank counter. Gravity PDF is the extension that creates a PDF file from a completed Gravity Forms form.


To the millimeter

The document a Swiss bank expects.

Receipt
62 mm wide
Payment part
148 mm wide, with a Swiss QR Code of exactly 46 × 46 mm
The layout of the QR-bill: a 210 × 105 mm block at the foot of the page, made up of the receipt (62 mm) and the payment part (148 mm), separated by a cut line; the widths are drawn to scale.

The receipt is 62 mm wide, the payment part 148 mm, and the mandatory 5 mm border is kept. The boxes for the amount and for “Payable by” have their prescribed sizes, and the acceptance point area is present. The cut lines with a scissors symbol and the notice to separate the slip before paying in are printed as well. The measurements in the table are not approximations, because we measured them back from a produced PDF.

Element Required Produced
Total block 210 × 105 mm at the foot of the page 210 × 105
Receipt / payment part 62 / 148 mm 62 / 148
Swiss QR Code exactly 46 × 46 mm 46 × 46
Clear space around the code at least 5 mm 17 / 5 / 5 / 13
Module size at least 0.4 mm 0.667 mm
Swiss cross 7 × 7 mm, centered 7 × 7, centered
Corner marks 0.75 pt 0.75 pt
Acceptance point area at least 20 mm high 20 mm

There is deliberately no heading of your own inside the payment part. Section 3.1 of the Implementation Guidelines, the rules for the Swiss QR-bill, rules out using it as advertising space, and free text inside the A6 area would make the bill non-compliant. Whatever you want to tell your customer therefore goes above the upper cut line, in the invoice area. The feed has a setting of its own for this. A feed is a mapping that defines which PDF is created from which form.


Version 2.4

Built to version 2.4, which applies from November 14, 2026.

Version 2.4 of the Implementation Guidelines applies from November 14, 2026. Three of its changes carry real weight, because each one of them can invalidate a bill. An implementation that still follows version 2.3 will therefore no longer be correct from that day on. With this add-on, you are already set up for the new rules today.

Change in version 2.4 What it means for you
QR reference and QR-IBAN only in CHF A QR-IBAN requires a QR reference. The previously allowed combination “QR-IBAN plus EUR” is therefore no longer possible. The feed screen reports this case as a blocker before you configure anything.
The structured address is mandatory The combined address type “K” is gone. Postal code, town and country of the creditor are mandatory and not just recommended.
Romansh as a fifth correspondence language The language list has five entries instead of four.

Verified against the examples of the standard

Annex A of the guidelines contains two complete worked data sets, and the add-on produces both of them byte for byte. This includes a detail that is easy to overlook: the version line inside the code stays 0200 and does not become 0240. Section 7.1 requires readers to check this line, so a code with 0240 is rejected outright.

euroSIC is being discontinued

euroSIC is the Swiss system for payments in euros. QR-bills in EUR will be settled as SEPA credit transfers from November 2027 at the latest. The guidelines warn that the address of the payer and a message next to a structured reference are then no longer guaranteed to reach you. For a EUR bill, the add-on therefore writes a note to the log instead of staying silent.


The reference

What links a payment to an invoice.

Which kind of reference you may use is decided by your account, not by your preference. The add-on can derive the right kind from the IBAN, so you do not have to worry about it.

Type Requirement Format
QRR, the QR reference a QR-IBAN, and since version 2.4 also CHF 27 digits, check digit using recursive modulo 10
SCOR, the Creditor Reference an ordinary IBAN; CHF or EUR RF, two check digits and up to 21 further characters
NON, no reference an ordinary IBAN the line stays empty

Built per invoice

Enter your invoice number in a field. Merge tags are allowed here. A merge tag is a placeholder like {Name:1} that Gravity Forms replaces with the entered value. The add-on builds the 27-digit reference from it and calculates the check digit.

Or passed through unchanged

If the same field points to an existing reference, the add-on recognizes a complete and valid reference and leaves it untouched. Without this detection, a merge tag pointing to a stored reference would silently produce nonsense, such as RF97RF18… from RF18…. If this case occurs, it is written to the log.

What the check digit can and cannot do

We measured it rather than assumed it. A single wrong digit is always detected: of the 97,200 altered references we tested, none slipped through. A swap of two adjacent digits is usually detected, but not always, because about 2% of these swaps slip through. This gap is precisely known and documented.

97,200
references with one wrong digit tested, none of them slipped through
about 2%
of swaps of adjacent digits go undetected
Our measurement of the check digit: a single wrong digit is always detected, a swap of adjacent digits usually.

Built not to break

Small pitfalls don’t hold up your invoice.

An apostrophe cannot break your bill

The standard only allows a certain set of characters, but WordPress inserts characters that are not part of it without asking. A typed apostrophe, for example, is silently turned into a typographic one. The add-on converts such characters into their plain equivalents instead of removing them. So “L’Atelier” stays readable and the bill stays payable.

An unknown amount or payer is fine

Both are allowed. The payment part then prints an empty box with black corner marks in exactly the dimensions of the standard, which the customer fills in by hand. A donation form works just as well as an invoice.

It does not get in the way of your template

The payment part occupies exactly the area where a footer would otherwise sit. That is why the add-on switches off the template’s running footer for this one page, and only for this one. Your invoice pages keep their footer.

Five languages, chosen per form

You can choose German, French, Italian, Romansh and English. The headings are prescribed wording, not free translations. The biller chooses the language, per form. So a German-language WordPress site can print an Italian payment part.

Advice notes, too

An advice note is a QR-bill that is not meant to be paid. A switch produces the variant the guidelines provide for this: the amount is fixed at 0.00, together with the prescribed wording in the chosen language. This also ensures that a conversion into an eBill cannot be released for payment.

Nothing to install

There is no Composer step, no bcmath PHP extension, no API key, no external service and no third-party QR-bill library. Data content, check digits and layout are all inside the plugin, which is why it runs from PHP 7.4. Gravity PDF itself provides the QR encoder.

Developer-friendly

The layout is an array of named constants that can be adjusted through a filter. The class for the data content works without WordPress, so the rules of the standard can be tested separately. The QR reference ships as a portable package of two files that you may copy into any other Gravity Forms plugin.


Requirements

What has to be in place.

WordPress with Gravity Forms 2.5 or newer
Gravity PDF 6 or newer
PHP 7.4 or newer
Currency in Gravity Forms CHF or EUR
IBAN Switzerland or Liechtenstein

The add-on checks seven requirements in one place and shows the result in two places: as a list on the feed screen, where you can change something, and as a line in the log when the PDF is created, where the add-on then quietly skips the payment part. Because both come from the same check, they can never disagree about what is missing.


Setup

Four steps, then it runs on its own.

1 · Enter the address
in full, per version 2.4
2 · Add a feed
and pick the language
3 · Derive the reference
from the IBAN
4 · Open the PDF
with payment part and receipt
Setup in four steps, from the biller’s address to the finished payment part.

01   Enter the full address of the biller

Version 2.4 made the structured creditor address mandatory, meaning street, postal code, town and country, not just a name. These details go on the shared (e)invoice Settings page together with the IBAN, and every add-on of the family reads them from there.

02   Add a feed and pick the language

A feed decides which PDF carries the payment part. The headings are prescribed wording in German, French, Italian, Romansh and English, and you choose the language per feed. So a German website can print an Italian payment part.

03   Let the IBAN decide the reference

A QR-IBAN requires a QR reference and CHF, while an ordinary IBAN takes a Creditor Reference or no reference at all. Leave the setting on Decide from the IBAN, and the add-on picks the right kind. If your combination cannot work, it tells you so on the feed screen.

04   Open the PDF

Receipt and payment part appear at the lower cut edge of the last page, together with the cut lines and the notice to separate before paying in.


The shared (e)invoice Settings page. Since version 2.4, the biller’s address is a mandatory part.

There is one feed for each document that should carry the payment part.

The settings of a feed. They define which PDF carries the payment part, which of the five languages applies and which reference type is used.

The produced QR-bill: the receipt is 62 mm wide and the payment part 148 mm, plus the cut lines with a scissors symbol.


Manual

Everything to read up on.

The manual describes the installation, the first steps, every setting and special cases. It applies to version 1.1.8 of the plugin.

View the manual
Manual as PDF

Deutsches Handbuch · PDF


Goes well with

These extensions complement the add-on.

EPC QR code

EPC-QR for Gravity PDF appends a payment page with a QR code for a SEPA credit transfer to the PDF. It is the right add-on for invoices in euros to customers in the SEPA area.

Learn more

E-invoices from Gravity PDF

eInvoice Generator for Gravity PDF turns the invoice PDF that Gravity PDF already creates into an e-invoice according to EN 16931. An e-invoice is an invoice as a structured file that a program can read. The plugin is a paid product, available in the invoicePress.de shop.

Learn more

SEPA fields

SEPA Fields for Gravity Forms brings three validated fields for bank details into Gravity Forms: IBAN, BIC (also called SWIFT code) and Creditor Reference according to ISO 11649.

Learn more

All QR codes for Gravity PDF · All extensions


Does your account allow a QR reference?

Your IBAN decides: a QR-IBAN requires a QR reference and CHF, while an ordinary IBAN takes a Creditor Reference or no reference. The add-on can derive the right kind by itself and tells you on the feed screen if version 2.4 rules out your combination. The demo will soon show you a finished QR-bill from a sample form. Swiss QR-Bill for Gravity PDF is a paid product. You will find everything about getting it on the product page.

Open the demo
Go to the product
View the manual