La réponse en bref

Pour un éditeur, la QR-facture implique de maintenir la génération des données, du code et de la présentation pour les cas pris en charge. Les fonctions de rapprochement, Swico S1 ou canaux alternatifs dépendent du périmètre du produit. Documentez les versions et testez les sorties : un rapport de validation ne certifie pas toutes les fonctions du logiciel.

Le périmètre fonctionnel attendu

La génération d’un document conforme et les fonctions de gestion sont deux sujets distincts. Le périmètre ci-dessous sert de grille de conception à adapter au produit, pas de liste de fonctions toutes imposées par SIX.

Bloc Contenu minimal Différenciant
Données Structure conforme, adresses structurées, trois types de référence, contrôle des couples compte-référence et des règles EUR Validation en temps réel à la saisie, messages d’erreur qui citent la règle
Code Niveau M, plus petite version, croix suisse, vectoriel Décodage des QR-factures reçues
Mise en page Style Guide, cinq langues, champs vides, ciseaux ou perforation, PDF avec polices incorporées Modèles calés sur le papier QR, aperçu avant envoi
Retour Import camt.054 (et camt.053 détaillé), lettrage par référence, exceptions Connexion bancaire directe ou EBICS, règles d’affectation configurables
S1 Génération depuis les lignes de facture, échappement, 140 caractères Lecture de S1 côté créanciers
Canaux PDF, impression, eBill en procédure alternative Portail client conforme au chapitre 3.8
Cycle de vie Relances avec même référence, avoirs, factures annulées Reprise des références lors des migrations

Le cycle de maintenance

Chaque version possède son calendrier de publication, d’entrée en vigueur et de transition. Un éditeur prépare les opérations suivantes :

  1. Lecture de la documentation des modifications dès la publication ;
  2. Implémentation et mise à jour de la bibliothèque de génération ;
  3. Tests : jeu de non-régression sur le texte du code, rapport du portail de validation SIX, validateur Swico pour S1 ;
  4. Déploiement avant l’entrée en vigueur, avec activation des nouvelles règles à la date prévue (par exemple les restrictions EUR des IG 2.4, en tenant compte du maintien parallèle des IG 2.3 jusqu’en novembre 2027) ;
  5. Communication aux clients : ce qui change pour eux, ce qu’ils doivent faire, rien pour la plupart.

Les points qui font la différence chez les clients

  • La migration des adresses : vos utilisateurs ont des fichiers clients avec des adresses sur une ligne. Un assistant de découpage rue/numéro/NPA/localité, avec validation, épargne des heures et des rejets.
  • Le lettrage : c’est le moment où le client juge le logiciel. Import simple, propositions claires, exceptions expliquées, réconciliation avec le relevé.
  • Les relances : reprise de la référence d’origine, solde exact, nouvelle QR-facture conforme.
  • Le papier QR : modèles calés au millimètre sur la perforation, avec un test d’alignement imprimable.
  • La transparence : publier la version de la norme prise en charge, le rapport de validation et la date prévue pour la prochaine version.

Tests à automatiser

  • Chiffres de contrôle (modulo 10 récursif, mod 97-10) sur des valeurs connues et sur des cas limites (zéros, longueur, lettres).
  • Refus des couples interdits : QRR sans QR-IBAN, SCOR avec QR-IBAN, QRR en EUR après le 14.11.2026.
  • Texte du code comparé à une référence pour chaque scénario (montant vide, débiteur absent, S1, procédure alternative, cinq langues).
  • Longueur totale ≤ 997 caractères, Ustrd + StrdBkgInf ≤ 140.
  • Rendu PDF : polices incorporées, dimensions, présence des ciseaux.

Le guide pour développeurs présente les bibliothèques open source qui couvrent la génération et le décodage.

Sources et références