
Chaque mois, la DSN (Déclaration Sociale Nominative) centralise les informations qui servent à calculer les cotisations et les droits des salariés : retraite, indemnités journalières, chômage, protection sociale complémentaire. Pendant des années, la logique était simple : l’URSSAF signalait les erreurs, l’entreprise corrigeait… ou pas. Les CRM s’accumulaient, certaines anomalies traînaient d’un mois sur l’autre, faute de temps, de compréhension des CRM ou simplement d’un défaut de suivi, et la vie continuait. Ce temps est révolu.
C’est pour limiter les effets de ces erreurs durables sur les droits des salariés que l’administration a mis en place la DSN de substitution. Opérationnel depuis quelques mois, le mécanisme représente une rupture culturelle plus profonde qu’une simple nouveauté technique. « On passe d’un système où l’employeur est maître de la donnée à un système où l’organisme peut en devenir co-producteur en cas d’inaction », observe Sarah*, experte DSN. Une évolution qui marque un changement important dans la logique déclarative de la paie. Démonstration.
Un mécanisme en quatre temps et un délai qui ne s’arrête pas
L’objectif affiché par les organismes n’est pas de corriger unilatéralement vos déclarations, mais de laisser aux entreprises le temps et les moyens de régulariser elles-mêmes les anomalies détectées. En théorie. En pratique, le cycle est minuté.
1 – La détection de l’anomalie
L’URSSAF – ou la MSA pour les entreprises relevant du régime agricole – analyse les données transmises dans votre DSN mensuelle et identifie certaines incohérences susceptibles d’affecter la fiabilité des droits sociaux. Parmi les anomalies les plus fréquemment détectées : un plafond de Sécurité sociale incohérent, une durée de travail mal renseignée, une assiette erronée ou un élément de rémunération mal rattaché dans le temps.
2 – La réception d’un CRM et la qualification de l’anomalie
L’entreprise reçoit un Compte Rendu Métier (CRM). Et c’est là qu’une distinction essentielle s’impose :
- Le CRM d’anomalie : signale une erreur bloquante à traiter immédiatement
- Le CRM de rappel : relance une anomalie déjà signalée mais non corrigée, c’est ce second type qui déclenche le délai avant substitution
« Le CRM de rappel ne contient pas uniquement les anomalies susceptibles d’être substituées. Il agrège l’ensemble des anomalies non corrigées, y compris des anomalies anciennes ou non prioritaires », rappelle Sarah. Il constitue un signal d’alerte renforcé : il ne signifie pas automatiquement qu’une substitution sera générée, mais ne pas le traiter, c’est laisser tourner le compteur.
3 – Le délai de correction : deux échéances déclaratives
À partir de la réception du CRM de rappel, l’entreprise dispose de deux dépôts DSN mensuels, soit environ deux mois, pour corriger l’erreur, la justifier ou la contester auprès de l’organisme. Cela peut passer par une DSN corrective, une régularisation de paie ou une contestation motivée si l’employeur estime que l’analyse n’est pas fondée.
Le service « Suivi DSN », accessible sur net-entreprises.fr, devient l’outil central pour consulter les anomalies ouvertes, transmettre des justificatifs et suivre les corrections effectuées.
4 – La substitution automatique de la donnée
Aucune correction dans les délais ? L’organisme génère une DSN de substitution. La donnée est ajustée sur le périmètre des anomalies éligibles et devient opposable, c’est-à-dire officiellement retenue pour le calcul des droits sociaux. « Même si la donnée substituée ne correspond pas exactement à la paie réelle, c’est elle qui sera retenue pour les droits du salarié », souligne Sarah.
À retenir
Un droit de contestation existe. Si vous estimez qu’une substitution est injustifiée, vous disposez d’une procédure contradictoire pour la contester auprès de l’URSSAF ou de la MSA. Ce droit de recours est important à connaître et à faire valoir dans les délais encadrés. Passé ce stade, la donnée est validée tacitement.
2026 : un démarrage ciblé, mais une logique appelée à s’élargir
Le périmètre 2026
Pour l’instant, la substitution automatique reste limitée à un périmètre précis. Seules deux anomalies sont aujourd’hui éligibles : DIPA01I et DIPA01J, qui correspondent à des incohérences de plafonds de Sécurité sociale entre salariés à temps plein et à temps partiel. Ces deux codes ciblent des erreurs ayant un impact direct sur les droits à la retraite de base et complémentaire.
Pour les non-initiés : le plafond de Sécurité sociale est la limite au-delà de laquelle certaines cotisations sont calculées différemment. Pour un salarié à temps partiel, ce plafond doit être proratisé et une erreur de déclaration peut fausser le calcul de ses droits à la retraite pendant des mois, voire des années.
À retenir
Ce démarrage ciblé ne doit pas induire en erreur. Le dispositif est explicitement prévu pour s’élargir à d’autres données déclaratives sensibles à partir de 2027, dans le cadre de la montée en puissance du fait générateur et de l’opposabilité des données sociales. À noter également : pour la MSA, le déploiement de la substitution suit un calendrier distinct.
Le fait générateur : un enjeu qui dépasse la substitution
Derrière le mécanisme de substitution se dessine une évolution plus large : la montée en puissance du fait générateur. Ce principe consiste à rattacher chaque élément de rémunération au bon mois d’exigibilité, et non simplement à sa date de versement. Une prime, une régularisation ou un élément variable mal rattaché dans le temps peut désormais générer des incohérences détectables automatiquement dans les flux DSN.
Selon le calendrier prévu, l’opposabilité du fait générateur devrait encore se renforcer à partir de 2027. Les équipes paie ont donc intérêt à traiter ce sujet maintenant, sans attendre que de nouvelles anomalies viennent alimenter les CRM.
Ce que ça change concrètement pour les équipes paie
Au-delà de la réforme technique, la DSN de substitution modifie profondément les pratiques opérationnelles des équipes paie. Les anomalies déclaratives ne peuvent plus être traitées comme des irritants secondaires à régulariser plus tard. La logique devient continue, traçable et pilotée dans le temps.
Les CRM deviennent un flux métier permanent
Beaucoup d’entreprises considéraient encore les CRM comme des alertes ponctuelles, consultées à l’approche d’un contrôle. Avec la DSN de substitution, cette approche devient beaucoup plus risquée. « Le CRM n’est plus une alerte exceptionnelle : c’est un flux métier à suivre tous les mois », explique Sarah.
Concrètement, les équipes doivent intégrer la lecture des CRM dans leur calendrier mensuel post-dépôt DSN, suivre les anomalies ouvertes et prioriser rapidement les corrections. Certaines entreprises commencent à mettre en place des tableaux de bord dédiés, avec une coordination renforcée entre paie, RH et prestataires externes.
La fiabilité doit être assurée en amont, pas en aval
Historiquement, certaines erreurs étaient corrigées progressivement, parfois plusieurs mois après leur apparition. Avec la DSN de substitution, cette logique n’est plus tenable. Les erreurs de plafonds, de quotité de travail, de statut salarié, de rattachement des primes ou de fait générateur peuvent désormais générer des CRM récurrents, puis conduire à une substitution automatique.
Cela oblige les entreprises à renforcer la qualité des données dès l’entrée en paie : collecte des variables, paramétrage des logiciels, gestion des temps et des absences, rattachement temporel des éléments variables.
La traçabilité des corrections devient stratégique
Les entreprises doivent désormais être capables de distinguer clairement ce qu’elles ont corrigé elles-mêmes, ce qui a été substitué par l’organisme et ce qui reste en anomalie ouverte. « Les entreprises vont devoir apprendre à documenter leur histoire déclarative », observe Sarah.
Cela implique la mise en place d’un véritable historique déclaratif : archivage des CRM, suivi des régularisations, documentation des corrections, journal des substitutions reçues. Un enjeu particulièrement sensible dans les grandes structures ou dans les organisations faisant appel à plusieurs intervenants sur la paie.
En pratique
Une entreprise déclare par erreur un nombre de jours calendaires incohérent dans sa DSN. L’anomalie passe inaperçue pendant deux mois. Un CRM de rappel arrive, mais n’est pas traité dans les délais. L’URSSAF procède à la substitution.
Résultat : modification des droits retraite du salarié, régularisation de cotisations sociales, décalage entre les données du bulletin de paie et celles désormais opposables dans les bases sociales. Sans oublier plusieurs mois de travail pour reconstituer l’historique exact. Ce qui semblait être un écart purement technique s’est transformé en chantier de régularisation.
5 chantiers pour sécuriser vos déclarations dès maintenant
Pour Sarah, le sujet impose désormais une transformation des pratiques paie. « La logique du “on corrigera plus tard” n’est plus tenable. La fiabilité doit être assurée en amont », insiste-t-elle. Voici les 5 axes prioritaires pour s’adapter.
1 – Intégrer la vérification des CRM dans le calendrier mensuel de paie
Les CRM doivent faire l’objet d’une revue systématique après chaque dépôt DSN. « Le CRM n’est plus une alerte ponctuelle : c’est un flux métier à suivre chaque mois », explique Sarah. L’objectif : identifier les anomalies ouvertes, prioriser les CRM de rappel et engager les corrections sans attendre. Certaines équipes mettent déjà en place des tableaux de bord dédiés pour identifier les anomalies récurrentes, les délais de régularisation ou les zones de paie les plus exposées.
2 – Former les équipes à lire et interpréter les CRM de rappel
Les CRM reposent sur des logiques techniques parfois complexes : codes anomalies, blocs DSN concernés, délais de correction, mécanismes de substitution… Une anomalie mal interprétée peut rester ouverte plusieurs mois, puis conduire à une substitution automatique. Les équipes doivent donc être capables d’identifier rapidement si le problème provient d’un paramétrage, d’un rattachement temporel, d’un statut salarié ou du fait générateur. Les former, c’est leur permettre de comprendre ce que révèle réellement le CRM, pas seulement de savoir corriger une erreur.
3 – Auditer les paramétrages paie sensibles
Une grande partie des anomalies persistantes provient de problèmes structurels de paramétrage. Les points à vérifier en priorité :
- Les plafonds de Sécurité sociale (notamment en cas de temps partiel)
- La quotité de travail et le statut salarié
- Les assiettes IJSS et CSG-CRDS
- Le rattachement des primes et des régularisations
- La gestion du fait générateur
4 – Vérifier la cohérence entre les bulletins et les données DSN avant chaque envoi
Les données transmises en DSN ne peuvent plus être considérées comme une simple restitution automatique de la paie. Les contrôles de cohérence entre bulletins et DSN (bases plafonnées, assiettes CSG-CRDS, IJSS, données statutaires…) doivent être effectués systématiquement avant chaque dépôt déclaratif.
5 – S’assurer que le logiciel applique correctement le fait générateur
Vérifiez que votre logiciel rattache bien les éléments variables au bon mois d’exigibilité, gère correctement les corrections M-1 et les mécanismes de régularisation. Tous les outils ne sont pas encore totalement alignés sur les nouvelles exigences déclaratives. Une mauvaise gestion des rappels de salaire ou des primes peut générer des incohérences visibles dans les flux DSN et alimenter de nouveaux CRM.
Un filet de sécurité pour les salariés, un signal fort pour les employeurs
La DSN de substitution n’a pas été conçue comme un outil de sanction. Son objectif premier est de protéger les droits sociaux des salariés, en empêchant que des erreurs persistantes ne les pénalisent durablement. Pour les entreprises, le message est clair : la donnée sociale devient un objet partagé, susceptible d’être corrigé en dehors de l’organisation.
À ce stade, le dispositif reste limité à deux codes anomalies. Mais il introduit une logique nouvelle : celle d’une paie placée sous supervision continue, où l’inaction face à une anomalie devient elle-même une information. Et selon le calendrier prévu, ce périmètre pourrait s’élargir. Pour les équipes paie, la question n’est donc plus de savoir si ces évolutions vont impacter leurs pratiques. C’est déjà le cas.
*La source a été anonymisée.
L’URSSAF peut corriger vos données. Votre logiciel, lui, peut les fiabiliser en amont
CRM non traités, plafonds mal paramétrés, fait générateur mal rattaché… Chaque anomalie laissée ouverte est une substitution potentielle. Découvrez comment mySilae Paie sécurise vos déclarations à chaque étape du cycle.
FAQ – Vos questions les plus fréquentes sur la DSN de substitution
La DSN de substitution peut-elle modifier rétroactivement des droits déjà liquidés, comme une pension de retraite en cours de versement ?
Non, dans l’état actuel du dispositif. La substitution porte sur les données déclaratives en cours, avec un impact sur les droits en cours de constitution. Elle ne remet pas en cause des droits déjà liquidés et versés. En revanche, pour un salarié encore en activité dont les données de plafond ont été mal déclarées pendant plusieurs années, la correction peut avoir un effet significatif sur le calcul futur de ses droits à la retraite. C’est précisément ce risque cumulatif que le dispositif cherche à prévenir.
Une substitution peut-elle créer un écart entre le bulletin de paie du salarié et ses droits sociaux officiels ?
Oui, et c’est l’une des conséquences les plus délicates à gérer. Si l’URSSAF substitue une donnée (un plafond de Sécurité sociale par exemple), sans que le bulletin de paie ait été corrigé en parallèle, le salarié dispose de deux versions de sa situation sociale : celle qui figure sur son bulletin et celle qui est retenue dans les bases de l’organisme. Cette divergence peut créer de la confusion, voire des contentieux, notamment au moment du départ à la retraite ou d’un contrôle des droits. Aligner bulletin et DSN après une substitution n’est donc pas optionnel.
Qui est responsable en cas d'erreur dans une DSN de substitution émise par l'URSSAF ?
La question est juridiquement ouverte, mais la charge de la preuve repose sur l’employeur. Si l’URSSAF substitue une donnée de manière erronée, c’est à l’entreprise de le démontrer via la procédure contradictoire. Sans trace des déclarations initiales, des corrections apportées et des échanges avec l’organisme, il est très difficile de contester efficacement. C’est ce qui rend la constitution d’un historique déclaratif structuré aussi importante : en cas de litige sur une substitution, c’est la documentation de l’entreprise qui fait foi.
Les entreprises multi-établissements sont-elles plus exposées que les autres ?
Oui, structurellement. Dans une organisation multi-établissements, les DSN sont souvent produites par des équipes différentes, avec des logiciels parfois distincts et des niveaux de paramétrage hétérogènes. Les anomalies peuvent provenir d’un seul établissement et passer inaperçues dans la consolidation globale. La coordination entre les équipes paie des différents sites, le suivi centralisé des CRM et l’homogénéité des paramétrages deviennent des enjeux de gouvernance, pas seulement des questions techniques.
Les cabinets d'expertise comptable et prestataires de paie externalisée sont-ils concernés au même titre que les entreprises ?
Oui, et leur responsabilité est engagée au même titre. Lorsque la paie est externalisée, c’est l’employeur qui reste juridiquement responsable de la conformité des déclarations, mais c’est souvent le prestataire qui reçoit et traite les CRM. La question de savoir qui surveille les anomalies, dans quel délai et avec quelle traçabilité, doit donc être explicitement encadrée dans le contrat de prestation. Un CRM non traité par un prestataire qui ne l’a pas transmis à son client peut conduire à une substitution dont l’entreprise n’a pas été informée à temps.
Comment anticiper l'élargissement du périmètre de substitution prévu à partir de 2027 ?
En traitant 2026 comme une répétition générale, pas comme un régime définitif. Le dispositif actuel ne porte que sur deux codes anomalies liés aux plafonds de Sécurité sociale. Mais la logique sous-jacente (détection automatique, délai de correction, substitution en cas d’inaction…) est appelée à couvrir progressivement d’autres données déclaratives sensibles, notamment celles liées au fait générateur. Les entreprises qui auront structuré leur suivi des CRM, audité leurs paramétrages critiques et formé leurs équipes à la lecture des anomalies DSN seront en mesure d’absorber ces élargissements sans rupture dans leurs pratiques.

