Valider une QR-facture, élément par élément

En huit groupes de données et une trentaine d’éléments, dans un ordre fixe, séparés par des retours chariot. Ce n’est pas du JSON ni du XML : c’est une suite de lignes, et la position d’une ligne EST son sens. C’est ce qui rend le format si facile à casser — une ligne oubliée décale tout ce qui suit, et le logiciel de la banque lit alors la localité là où il attend une monnaie.

Les éléments sont séparés par un retour chariot — CR + LF, ou LF seul, mais le même dans tout le document. Tous les éléments doivent exister : un élément sans contenu se réduit à son retour chariot.

SIX, Implementation Guidelines suisses pour QR-facture, version 2.3 (valable dès le 21.11.2025), § 4.1.4. Document relevé le 30.07.2026.

Six, presque toujours les mêmes. La liste ci-dessous n’est pas écrite à la main : chaque entrée est le verdict que le validateur de cette page rend sur une charge utile officielle de SIX dans laquelle une seule ligne a été abîmée. Ce que vous lisez est donc exactement ce que l’outil vous dira.

• Élément 27, Tp — Référence QR sur un IBAN ordinaire. La référence QR suppose un QR-IBAN — un compte dont l’identifiant d’institution est compris entre 30000 et 31999. Sur ce compte, la référence attendue est une Creditor Reference (SCOR), ou aucune (NON).
• Élément 28, Ref — Référence QR : la clé de contrôle vaut 8 alors que le calcul en modulo 10 récursif sur les 26 premiers chiffres donne 7. Un chiffre a été retapé.
• Élément 04, AdrTp — Type d’adresse du créancier : type « K » (adresse combinée). Seule l’adresse structurée « S » est admise depuis le 22.11.2025 : rue, numéro, NPA, localité et pays dans des champs séparés.
• Élément 08, PstCd — Numéro postal d’acheminement du créancier : « CH-8000 » porte le code pays. Le NPA s’écrit seul — le pays a son propre élément.
• Élément 18, Amt — Montant : la virgule n’est pas admise comme séparateur décimal. Seul le point l’est, avec exactement deux décimales.
• Élément 12, Name — Nom du créancier final : « Max Muster & Söhne » alors que le groupe « En faveur de » se livre vide. Il est réservé à un usage futur.

Verdicts produits au build par le validateur de cette page, sur les charges utiles de l’annexe A des Implementation Guidelines 2.3.

• Comment reconnaître un QR-IBAN d’un IBAN ordinaireLe détail de cette combinaison, entrez votre IBAN et l’outil vous dit quel type de référence il impose.

Le calcul se fait de gauche à droite, en partant d’un report nul. À chaque chiffre, le report courant et le chiffre lu désignent une case de la matrice de SIX, dont la valeur devient le report suivant. La clé est le complément à 10 du dernier report.

• Comment une référence QR est construite, calcul et vecteur d’essaiLe vecteur d’essai officiel de l’annexe B, et la seconde implémentation qui le contre-vérifie.

SIX, Implementation Guidelines suisses pour QR-facture, version 2.3 (valable dès le 21.11.2025), § 2.12.1. Document relevé le 30.07.2026.

Non, et cela se vérifie en une ligne. La Creditor Reference publiée à l’annexe A des Implementation Guidelines, dans le tableau 20, ne passe pas le contrôle mod-97-10 de l’ISO 11649 : le reste vaut 49 au lieu de 1, et les chiffres de contrôle corrects seraient « RF24 » et non « RF72 ».

PUBLIÉ — annexe A, tableau 20
  RF720191230100405JSH0438
  reste mod-97-10 ..... 49   (attendu : 1)
  clé lue ............. 72
  clé calculée ........ 24

TÉMOIN — même document, tableaux 21 et 22
  RF18539007547034
  reste mod-97-10 ..... 1   conforme

Cela compte si vous écrivez du code : une implémentation correcte rejettera cet exemple, et vous chercherez votre erreur là où elle n’est pas. Le même document contient un exemple valide, « RF18539007547034 » (tableaux 21 et 22) : c’est celui à employer comme vecteur d’essai.

Constat établi le 30.07.2026 par quatre implémentations arithmétiques indépendantes, avec l’exemple valide du même document comme témoin, et la chaîne relue dans le PDF officiel, éditions française et anglaise. La version 2.4 des Implementation Guidelines, publiée le 24.02.2026, porte la même chaîne.

Si SIX publie un erratum ou corrige l’exemple, cette page est mise à jour et le signalement retiré. Notre suite de tests fige les deux références : elle nous préviendra avant nos lecteurs.

SIX, Implementation Guidelines suisses pour QR-facture, version 2.3 (valable dès le 21.11.2025), § 2.12.2. Document relevé le 30.07.2026. Exemple relevé à l’annexe A, tableau 20, le 30.07.2026.

1. 01Il décode la charge utile et affiche les 34 éléments avec leur statut et leur règle.
2. 02Il contrôle les valeurs fixes, les longueurs, le jeu de caractères, la clé de l’IBAN, celle de la référence, et la combinaison du compte avec le type de référence.
3. 03Il nomme chaque faute, dit quoi corriger, et cite le chapitre des Implementation Guidelines qui la fonde.

• Il ne lit pas d’image : collez le texte que rend votre lecteur de code QR, pas une capture d’écran.
• Il ne juge pas la mise en page de la section paiement — les millimètres, les polices et la croix suisse relèvent du chapitre 3 des Implementation Guidelines, pas de la charge utile.
• Il ne parle pas au nom de votre banque. Un essai réel avec votre application bancaire reste la seule vérification qui vaille avant d’envoyer une première facture.

La section paiement est conforme à la spécification SIX — Swiss QR Code version 0200, Implementation Guidelines QR-facture 2.3, la version en vigueur depuis le 21.11.2025. Les adresses sont structurées (type S), la référence est contrôlée par son algorithme officiel, et chaque build vérifie tout cela en décodant réellement le QR produit. Ce que nous ne pouvons pas encore affirmer : que vos factures ont été scannées par chaque banque suisse. Nous n’avons pas fait cette campagne de tests. Contrôlez votre première facture avec l’application de votre banque avant de l’envoyer.