Interfaces de paie vers les systèmes RH : exigences et sources d’erreurs

L’interface de paie comme point de rencontre entre le système RH et les destinataires

ELM – Lohnstandard-CH – est la procédure unifiée de communication des salaires de l’association Swissdec (français Procédure Unifiée de Communication des Salaires, PUCS). Au lieu de remplir manuellement une multitude de formulaires, le logiciel de paie transmet les données salariales par voie électronique ; une seule transmission sert tous les destinataires souhaités. Parmi eux figurent les assurances sociales, les caisses de pension et les autorités fiscales ainsi que l’Office fédéral de la statistique (OFS) ; sont également cités l’AVS, les caisses d’allocations familiales et les assureurs.

L’interface de paie n’est donc pas une simple exportation ponctuelle, mais une interface système entretenue en continu : ELM signale les entrées et sorties à l’AVS et, tout au long de l’année, toutes les mutations à l’impôt à la source. Celui qui l’exploite doit effectuer des déclarations en continu et maintenir à jour la connexion entre système RH, logiciel de paie et standard. L’interface constitue un état opérationnel, pas un projet unique.

Du système RH aux destinataires : une transmission, de nombreux adresses

Ce que le Lohnstandard-CH (ELM) exige sur le plan technique et métier

Le Lohnstandard-CH se divise en deux séries documentaires. La documentation métier comprend les directives pour le traitement des données salariales avec leurs annexes : Annexe 1 Exemples de calcul de l’impôt à la source, Annexe 2 Directives TariTemp – Suva, Annexe 5 Directives relatives au certificat de salaire. La documentation technique s’adresse aux interfaces et se compose des directives pour les destinataires de données salariales et de celles pour les émetteurs de données salariales.

Les documents s’appliquent selon la version et portent des dates de publication. La version 6.0 (publication du 06.03.2026) constitue la base actuelle de certification ; les annexes 3, 4 et 6 suivront au cours de l’année 2026. Les états antérieurs restent documentés : 5.5 (TariTemp Suva, branche unique), 5.4 (TariTemp Suva, multi-branches), 5.3 (Accord complémentaire à la CDI Suisse–France), 5.1 (AVS21) et 5.0. Pour l’interface, cela signifie que les champs de données, les règles de calcul et le contenu des déclarations dépendent d’une version concrète ; un système qui implémente une version plus ancienne ne satisfait pas automatiquement aux exigences de la version actuelle.

États documentaires du Lohnstandard-CH

Certification et niveau de version : la preuve continue pour le système RH

Swissdec certifie les logiciels de paie aux niveaux basic et plus et attribue à chaque produit un numéro de certification. Dans la liste des éditeurs ERP certifiés figurent par exemple le n° de cert. 1003.21 pour Abacus Lohnbuchhaltung (plus) et le n° de cert. 1129.22 pour Abacus LohnLight (basic). Le numéro n’est pas spécifique à la version : Abacus Lohnbuchhaltung utilise le même n° de cert. 1003.21 pour ELM 5.5*, 5.3*, 5.1* et 5.0. Outre la certification ELM, il existe des certifications partielles pour certains domaines, par exemple KLE 1.1 (partiellement certifié LAA & LAA-Z, en combinaison avec UKA-Connect) et SUA 1.1.

La mention self-validated signifie que les éditeurs ont eux-mêmes fait évoluer leur logiciel de paie vers la version déclarée et ont effectué la validation via les systèmes de test de Swissdec. Cela n’est autorisé que pour les versions mineures, c’est-à-dire les versions présentant de légers écarts par rapport à la version majeure (ELM 5.0 / ELM 6.0). En conséquence, les listes des éditeurs indiquent des combinaisons telles que ELM 5.0 sans astérisque et ELM 5.1*, 5.3*, 5.4* ou 5.5* avec astérisque.

Pour le système RH, il en découle que le niveau de version doit être activement maintenu à jour. Le numéro de certification peut rester identique pour plusieurs versions mineures d’un même produit, les auto-validations se poursuivent côté éditeur, et les listes des éditeurs répertorient plusieurs versions pour un même produit. Une homologation unique lors de l’introduction ne dit rien sur l’état après la prochaine mise à jour.

Niveaux de certification et preuve de version en aperçu

Source d’erreur liée au décalage de version : lorsque les systèmes RH et de paie ne sont pas au même niveau

ELM 4.0 était utilisé depuis 2013 et a été progressivement remplacé par ELM 5.0 à partir de janvier 2025. La transition était calendrisée : au 31.12.2024, tous les systèmes ERP devaient être certifiés selon ELM 5.0, la date limite pour les décomptes d’impôt à la source dans ELM 4.0 était le 31.12.2025, et dans tous les autres domaines, la transmission dans ELM 4.0 prenait fin le 30.06.2026. Depuis le 1er janvier 2026, Swissdec n’accepte pour les nouvelles données salariales 2026 que ELM 5 ; pour les données d’impôt à la source 2025, la date du 31 mars 2026 est mentionnée, et au 30 juin 2026 suit la désactivation complète de tous les domaines (AVS, LAA, AMal).

Questions de contrôle pour votre propre situation : À quelle version ELM notre logiciel de paie est-il certifié, et quel numéro de certification s’applique ? S’agit-il d’une version mineure avec auto-validation, et celle-ci couvre-t-elle aussi les certifications partielles telles que LAA/LAA-Z ou SUA ? Des canaux ELM 4.0 fonctionnent-ils encore dans nos processus, et jusqu’à quand exactement ? Qui déclenche la mise à jour, qui teste la nouvelle version, et avec quelle preuve l’état certifié est-il attesté auprès des destinataires ?

D’ELM 4.0 à ELM 5.0 : les désactivations calendrisées

Source d’erreur liée aux données de base : redondances entre les systèmes

De nombreuses erreurs surviennent avant la transmission, au niveau des données de base. Si une personne est gérée à la fois dans le système RH et dans le système de paie, il existe deux jeux de données avec des dates d’entrée et de sortie potentiellement divergentes ; des mutations saisies de manière non uniforme aggravent la situation. Comme ces mouvements alimentent continuellement les déclarations, tout écart a un impact direct.

La parade consiste à réduire les redondances : pour chaque champ de données, on définit quel système fait foi ; les dates d’entrée et de sortie ne sont saisies qu’à un seul endroit et reprises depuis là dans le système de paie. La compilation automatique des données par le logiciel de paie réduit la charge de contrôle personnelle et aide à éviter des primes trop élevées ainsi que des corrections d’erreurs chronophages – à condition que les données de base alimentées soient correctes.

Source d’erreur liée à l’impôt à la source : cantons, codes tarifaires et frontaliers

L’impôt à la source impose des exigences plus élevées à l’interface que d’autres domaines. Les déclarations doivent être établies pour les 26 cantons et reprendre tous les codes tarifaires (A, B, C, D, H, L, M, N, P, Q) ; les tarifs diffèrent selon le canton, l’état civil, la situation familiale, la confession et le niveau de revenu. Outre la déclaration mensuelle ELM 5, ELM 5 génère des statistiques mensuelles OFS et des déclarations mensuelles CAF ainsi que la révision de l’impôt à la source 2021.

Une source d’erreur typique lors de la constitution des données de déclaration concerne les frontaliers : pour les frontaliers venant de France, un taux forfaitaire de 4,5 % s’applique, tandis que pour ceux venant d’Italie, c’est le tarif cantonal qui s’applique, pas de taux forfaitaire. ELM 5 modélise pour cela le domaine frontalier FR/IT ; la version 5.3 concernait l’accord complémentaire à la CDI entre la Suisse et la France. Celui qui ne reflète pas cette distinction dans les données de déclaration déclare avec le mauvais tarif.

Impôt à la source : indicateurs clés pour l’interface

Source d’erreur liée à la logique des destinataires : une déclaration, de nombreux adresses différents

Une seule transmission sert plusieurs destinataires, mais chacun ne reçoit que les données le concernant. Les destinataires traitent les données salariales sur la base d’un mandat légal et/ou contractuel. Les sous-ensembles diffèrent selon le destinataire : assurances sociales comme l’AVS et les caisses d’allocations familiales, assureurs-accidents et maladie, caisses de pension, autorités fiscales et l’Office fédéral de la statistique.

Des erreurs surviennent lorsque les champs de données, les délais de déclaration ou les formats d’un seul destinataire ne sont pas correctement reproduits. Les rythmes diffèrent : certaines déclarations ont lieu mensuellement, d’autres dépendent des entrées et sorties ou de l’année.

Protection des données et transmission sécurisée comme exigence pour l’interface

La transmission s’effectue sous forme de fichier XML chiffré. L’association Swissdec ne fait que transmettre les données aux destinataires prévus, aucun autre traitement des données n’a lieu (principe de finalité), et lors de la transmission, les données ne sont pas stockées par l’association. Les utilisateurs décident eux-mêmes à quels destinataires ils transmettent électroniquement leurs données.

Pour la transmission de données du personnel, la loi révisée sur la protection des données (LPD) est déterminante, en vigueur depuis le 1er septembre 2023. Les données du personnel ne peuvent être transmises qu’à des pays offrant un niveau de protection adéquat ou moyennant des clauses contractuelles types (art. 16 ss LPD). Contrairement au RGPD, la LPD relève du droit pénal : des amendes allant jusqu’à CHF 250'000 en cas de dol visent les personnes physiques responsables.

Points de contrôle pour votre propre paysage de systèmes RH et de paie

Avant la mise en service ou le changement d’une interface de paie, cinq points doivent être clarifiés. Premièrement, le niveau de version certifié : version ELM, numéro de certification, version majeure ou mineure avec auto-validation, étendue d’éventuelles certifications partielles et la question de savoir si des canaux ELM 4.0 sont encore actifs. Deuxièmement, la responsabilité des données de base : quel système fait foi pour chaque champ de données et par quel chemin les mutations parviennent au système de paie. Troisièmement, le processus de changement de version : qui déclenche la mise à jour, qui teste et comment le nouvel état est attesté.

Quatrièmement, la responsabilité des corrections d’erreurs après la transmission : qui vérifie les retours des destinataires, qui corrige, et par quel chemin la déclaration rectificative est-elle effectuée ? Cinquièmement, la preuve de la transmission des données : quels destinataires reçoivent quelles données, sur quelle base légale ou contractuelle, et est-il garanti que seuls les destinataires prévus reçoivent les données et qu’aucun stockage n’a lieu au niveau du standard lui-même.

Cinq points de contrôle avant la mise en service ou le changement