2 Design requirements and recommendations for the payment part

2.1 - The basics

Payment part must mandatorily be place in the lower right-hand corner

X

2.1 - The basics

Paper perforation of the A6 format is optional. If not used, A6 format must be indicated with lines

X

QR Invoice has an option to choose whether lines are printed or not

2.1 - The basics

If information about the amount is not imprinted during billing process, corresponding are to be provided for handwritten supplementation

X

2.1 - The basics

If information about the debtor is not imprinted during billing process, corresponding are to be provided for handwritten supplementation

X

2.1 - The basics

Only the defined headings and titles may be imprinted for the individual payment part sections

X

2.2 - Paper format and quality

The payment part must be in DIN A6 format horizontal

X

2.3 - Fonts and font sizes

Only the sans-serif fonts OCR-B, Arial, Frutiger and Helvetica are permitted in black. Type may not be in italic nor underlined.

X

QR Invoice Library only supports Helvetica and Arial at the moment

2.3 - Fonts and font sizes

The type size must be at least 6 pt and maximum 12 pt in size.

X

2.3 - Fonts and font sizes

Headings must be 2 pt smaller than the corresponding values

X

2.4 - Correspondence language

QR-bill can be produced in German, French, Italian and English

X

QR Invoice Library supports all 4 languages

2.4 - Correspondence language

The terms to be used in the respective correspondence languages are listed in multiple languages in Annex B: Multilingual headings.

X

2.5 - Sections of the payment part

The spaces between the sections must be at least 5 mm

X

QR Invoice Library uses exactly 5mm as a quiet space

2.5.1 - Title section

The heading "QR-bill payment part" must be printed in the title section in 11 pt type

X

2.5.2 - Alternative schemes section

The heading "supports" must be printed in bold in the process section and beneath the "credit transfer" scheme.

X

2.5.2 - Alternative schemes section

Next to it, all supported alternative schemes can be printed in the chosen correspondence languages in continuous text, separated by commas specifically, listed as long as the elements planned for this are filled in the Swiss QR Code.

-

Not yet implemented (2)

2.5.3 - Swiss QR Code section

In the Swiss QR Code section, the maintaining of the 5 mm wide border ensures that the Swiss QR Code can be read without problems.

X

2.5.4 - Amount section

The amount section includes the currency and the amount.

X

2.5.4 - Amount section

Towards this end, each bit of information must be marked with a heading.

X

2.5.4 - Amount section

The currencies CHF and EUR are supported.

X

2.5.4 - Amount section

The currency codes CHF or EUR must be printed to the left in front of the amount or the amount field.

X

2.5.4 - Amount section

Whitespace must be used as thousands separators.

X

2.5.4 - Amount section

The amount must always be printed with two decimal places, whereby only a period (".") is permitted as a decimal separator.

X

2.5.4 - Amount section

If no amount is contained in the Swiss QR Code, then a colorless field with black corner marks must be printed. It must have the dimensions: 1.5 x 4.0 cm.

X

2.5.5 - Information section

All values relevant for a payment from the Swiss QR Code must be printed in the information section.

X

QR Invoice Library ensure all values are visible

2.5.5 - Information section

While doing so each bit of information must be marked with a heading.

X

2.5.5 - Information section

The following values must, if they are contained in the Swiss QR Code, exist in the following listed order: Account, Creditor, Final creditor, Reference number, Additional information, Debtor, Payable by,

X

2.5.5 - Information section

If the debtor is not listed in the Swiss QR Code, then a colorless field with black corner marks must be printed (see figure 4, right). It must at least measure 2.5 x 6.5 cm

X

2.5.5 - Information section

Use of the above-listed headings (see ) is mandatory and they may not be changed, if they are contained in the Swiss QR Code.

X

2.6 - Notes about the QR-bill in PDF format

PDF bills are only suitable for e-/m-banking payments but not for paper-based payment traffic. The printing of PDFs can lead to format changes. This can lead to processing problems and higher costs.

-

This is up to the integrator of the QR Invoice Library to handle. PDF printing may be fine, however it must not be scaled (typical "scale-to-fit" issue with PDF printing)

3 - Swiss QR Code database

3.2 - Technical specifications

3.2.1 - Character set

Only the Latin character set is permitted (ISO 20022 "Customer Credit Transfer Initiation" message - pain.001)

x

QR Invoice Library validates input against a finite list of all allowed characters

3.2.2 - Permitted characters in the field definitions

Different field definitions

x

QR Invoice Library validates each field against its specific definition

3.2.3 - Field lengths

The field lengths specified represent maximum lengths for the individual elements.

x

QR Invoice Library validates each field against its specific definition

3.2.3 - Field lengths

It is not permitted to fill in the elements with blanks up to the maximum length.

x

QR Invoice Library does warn about input that should be trimmed, but only enforces it in strict validation mode

3.2.4 - Separator element

The individual elements in the Swiss QR Code according to the Swiss standard are separated from one another with a carriage return (CR + LF).

x

QR Invoice Library always uses CR + LF for writing codes, but handles each line break variant (CR, LF, CR + LF) during code parsing

3.2.4 - Separator element

The carriage return is eliminated after the final element.

x

3.2.5 - Delivery of the data elements

All data elements must be present. If the information of the data element is not available, then at least one carriage return (CR + LF) must take place.

x

3.2.5 - Delivery of the data elements

The sole exceptions to this are additional data elements marked with "A" (alternative scheme). These can be eliminated if not needed.

x

3.2.5 - Delivery of the data elements

The last data element delivered may not be completed with a concluding carriage return (CR + LF).

x

3.3 - Data structure

Data Structure Definition

x

QR Invoice Library checks all constraints. Validated against official SIX validation platform

3.3 - Data structure

Reference type - with the use of a QR-IBAN must contain the QRR code or SCOR.

x

QR Invoice Library checks for this cross-element dependency

3.3 - Data structure

Reference - must be filled if a QR-IBAN is used.

x

QR Invoice Library checks for this cross element dependency

3.3 - Data structure

Reference - The element may not be filled for the NON reference type

x

QR Invoice Library checks for this cross element dependency

3.3 - Data structure

Alternative scheme parameters - Can be currently delivered a maximum of two times.

x

3.4 - Technical specifications

3.4.2 - Use of the "unstructured message" element

The unstructured part (text) must be placed at the beginning of the field.

-

Not enforced by QR Invoice Library (1)

3.4.2 - Use of the "unstructured message" element

The switch to the structured part must be marked by the character series "##".

-

Not enforced by QR Invoice Library (1)

3.4.2 - Use of the "unstructured message" element

The rest of the field (von "##" to the end of the field) contains structured information.

-

Not enforced by QR Invoice Library (1)

3.4.2 - Use of the "unstructured message" element

For this purpose, the first two characters (after "##") are reserved as code for the rule used, which defines how the remaining characters in this field are to be interpreted.

-

Not enforced by QR Invoice Library (1)

3.4.3 - Depiction of the customer reference in the ISO 20022 pain.001 payment message

-

pain.001 mapping is currently not covered by the QR Invoice Library

3.4.4 - Alternative schemes

The element may be delivered twice at the most according to these Implementation Guidelines.

X

3.4.4 - Alternative schemes

The first two characters (alphanumeric) are the indicators for the alternative scheme.

-

Not enforced by QR Invoice Library (2)

3.4.4 - Alternative schemes

The next character must contain the sub-element separator used.

-

Not enforced by QR Invoice Library (2)

3.4.4 - Alternative schemes

An unlimited number of sub-elements can be delivered within the permitted field length of the element.

-

Not enforced by QR Invoice Library (2). Only the length of the field is validated

3.4.5 - Use of address information

The "Street" element is to be used to enter a P.O. Box.

-

Cannot be enforced by QR Invoice Library

3.4.6 - The payment amount

The "Amount" element is to be entered without leading zeroes, including decimal separators and with two decimal places. The "." symbol is to be used as a decimal separator.

x

3.4.6 - The payment amount

The "Amount" element need not be filled in the Swiss QR Code.

x

3.5.1 - Checking of field contents

The content must match a valid value; this applies for QR type, the version, the coding type and the currency.

x

Covered in parseAndValidate

3.5.1 - Checking of field contents

The general specifications according to Nr. 3.2 of the Technical Specifications, must be adhered to.

x

Covered in parseAndValidate

3.5.1 - Checking of field contents

The value must be syntactically correct; this applies for the amount (if entered), account (IBAN/QR-IBAN), reference type (QRR/SCOR/NON) and, if present, the biller’s reference (QR reference, Creditor Reference (ISO 11649).

x

Covered in parseAndValidate

3.5.2 - Meta data

The following elements from the Swiss QR Code (data group header) will never be forwarded with the payment: QR type, version, coding type

-

Not covered as the QR Invoice Library does not forward payments on its own.

4 - Parameters for generating the code

4.1 - Error correction level

The code generation must take place with error correction level "M".

x

4.2 - Maximum data range and QR code version

The maximum Swiss QR Code data content permitted is 997 characters (including the element separators).

x

4.2 - Maximum data range and QR code version

The version of the QR Code resulting with error correction level "M" and binary coding is version 25 with 117 x 117 modules.

x

4.3 - Minimum module size

To guarantee the secure scanning of the Swiss QR Code, a minimum module size of 0.4 mm is recommended for printing.

x

This is implicitly covered as the QR code is printed at size 46mm. 46mm / 117 (max modules) ⇒ 0.393 mm

4.4 - Measurements of the Swiss QR Code for printing

The measurements of the Swiss QR Code for printing must always be 46 x 46 mm

x

4.4.1 - Quiet space according to ISO 18004

5mm quiet space around the QR Code

x

4.4.2 - Recognition characters

To increase the recognizability and differentiation for users, the Swiss QR Code created for printout is to be overlaid with a Swiss cross logo measuring 7 x 7 mm.

x