Contrôles DSN
Contrôler les charges par rapport à la DSN
Contrôle en amont : Charges vs DSN
Préambule
L'état récapitulatif pour les déclarations mensuelles est un état qui présente les cotisations calculées par organisme.
Pour l'URSSAF, les cotisations étaient regroupées par le code bordereau et le code DUCS (ils s'agit des anciens codes utilisés avant l'avènement de la DSN). Il y a désormais la possibilité de regrouper les cotisations par code CTP.
Cet état présente des montants des bases valorisés en DSN pour chaque CTP. Pour chaque ligne de CTP, le montant de cotisation est calculé en fonction des taux légaux en vigueur. En fin d'état, il y a le total totalisation des cotisations. Et à coté, le montant des cotisations issu de la paye.
Lorsque la différence entre ces deux totaux est trop importante (supérieur à 2€ voire 3€), il convient de rechercher la source de l'erreur de codification, ce qui peut s'avérer fastidieux.
Désormais, il est possible de visualiser cet écart, par établissement, par CTP, et par salarié. Une fois que le où les salariés causant l'écart sont identifiés, il est alors en général assez facile de corriger la codification, ou même éventuellement la paye du salarié. Il est donc important d'effectuer ce travail avant l'ouverture de la période suivante.
Avant de pouvoir utiliser cette option, plusieurs étapes sont nécessaires :
- Activer le module dans la gestion des structures
- Codifier le gestionnaire de régime afin de renseigner les CTP additionnels. Voir pour cela la modification du bordereau mensuel de déclaration des charges.
- Calculer le bordereau mensuel de déclaration des charges en cochant la case Mode détaillé pour contrôle DSN
- Générer la DSN mensuelle en cochant sur la case Mode détaillé pour contrôle
Codification
Activation du module
Par mesure de précaution et pour vous permettre de codifier le module à votre convenance, le module doit être activé manuellement.
Dans la gestion des structures, niveau association, passer en modification et cliquez sur le bouton Activer le bordereau mensuel par CTP
un message apparait :
l'activation est prise en compte au moment de la validation 
Par la suite, il sera possible de désactiver la fonctionnalité et revenir à la présentation précédente. Toutefois, la codification du régime ci après sera perdue.
Codification des régimes
Dans le gestionnaire de régime, chaque cotisation URSSAF est envoyé en DSN (A l'exception des cotisations complément allocations familiale pour le bulletin simplifié qui ne sont présentes que pour des questions de présentation).
On rappelle ici que chaque rubrique de cotisation ne doit concerner que la cotisation elle même et ne pas regrouper un ensemble de cotisation. Exemple : Créer une cotisation MALADIE_TH avec un taux employeur à 12.35% qui regroupe la maladie, la vieillesse et l'allocation familiale n'est pas correct. Car même s'il n'y a pas d'écart au niveau agrégé, il y en a un au niveau nominatif car chaque cotisation est distinguée
Pour chaque cotisation, on indique un code CTP et un code cotisation. En DSN, le CTP est utilisé en maille agrégée, et c'est l'assiette de cotisation qui est envoyée. Le code cotisation est utilisée dans la maille nominative, où l'assiette, le taux et le montant de cotisation est rempli.
Certains CTP regroupent plusieurs cotisations, le principal étant le CTP 100, mais aussi le CTP 726 (apprenti), le 122 (travailleurs handicapés, et d'autres plus spécifiques. Il y a également le CTP 260 qui regroupe toutes les cotisations CSG-CRDS.
Pour ces CTP particuliers, si on répétait le CTP pour chacune des cotisations qui le compose, l'assiette serait évidemment multipliée et la DSN serait fausse. C'est pour cette raison qu'existe le CTP 999. Par exemple, pour le CTP 100, composé des cotisations maladie, allocation familiale, vieillesse, solidarité et accident du travail, on va indiquer le CTP 100 pour la maladie et le 999 pour tous les autres. Le programme enverra en DSN l'assiette de la maladie dans le CTP 100 et rien pour les autres.
Cependant, pour l'état récapitulatif des déclarations mensuelle par code CTP, le programme a besoin de connaitre le CTP réel pour les cotisations étant codifiées avec le CTP 999.
Après avoir activé la fonctionnalité, 2 nouvelles colonnes (CTP1 et CTP2) apparaissent au niveau de l'écran de codification des régimes
La colonne Code CTP reste la colonne utilisée en DSN et ne doit pas être modifiée. Les colonnes CTP1 et CTP2 sont les CTP qui seront utilisés uniquement par l'état récapitulatif des déclarations mensuelles lorsque le code CTP sera égal à 999.
Pourquoi 2 codes CTP supplémentaires ?
Lorsque le régime utilise deux CTP "multiples" comme par exemple le régime apprenti qui utilise le CTP 726 pour la partie exonérée de part salariale et le CTP 100 pour la partie non exonérée, les cotisations concernées par l'exonération sont doublées : VIEILLESSE et VIEILLESSE_APP, VIEILLESSE_TRA et VIEIL_APP_TRA. Les premières sont assises sur l'assiette au dessus du seuil d'exonération, les secondes sur l’assiette en dessous du seuil.
Les autres cotisations (qui sont en CTP 999) sont assises sur l'assiette totale, dont une partie est attribué au CTP 100 et l'autre au CTP 726. On indiquera donc ces deux CTP en colonne CTP1 et CTP2.
Comment alimenter ces 2 colonnes?
Pour le paramétrage des valeurs par défaut :
Pour les valeurs par défaut, pour les CTP 999 on met 100 au niveau du CTP1.
Pour la partie CSG/CRDS, il n' y a pas de difficulté particulière, pour tous les régimes mettre le CTP1 à 260.
Au niveau de chaque régime :
Si le régime utilise le CTP 100, pas de modification à apporter.
Si le régime utilise un autre CTP à la place du CTP 100, ou en plus du CTP 100, il faudra modifier ce régime
Ici, nous avons ajouté le CTP 726 pour les cotisations accident, allocation familiale et maladie.
Ici, c'est la cotisation vieillesse qui a le CTP 100 utilisé en DSN. De fait la colonne CTP1 ne sera pas utilisée, vous pouvez la laisser telle quel.
Certains clients ont doublé toutes les cotisations dans le cas d'un régime à CTP multiple, la plupart du temps pour le régime travailleurs handicapés. Il faut dans ce cas bien indiquer le CTP1 correspondant à l'assiette utilisée par la cotisation
Dans cet exemple, la cotisation accident a été doublé, _ACCIDENT_TH étant la cotisation sur la partie aide au poste : On met 122 dans la colonne CTP1. Et pour la cotisation ACCIDENT qui est la cotisation sur la partie du salaire direct, on met le CTP100.
Même chose pour les cotisations VIEILLESSETOT et VIEILLESSE_TH
Pour la cotisation Allocation familiale, la particularité du régime travailleur handicapé est que la cotisation est toujours à taux plein, c'est à dire 5.25%. Toutefois en DSN, la cotisation doit être déclarée en trois partie, 3.45% pour le salaire direct (CTP 100), 3.45% pour l'aide au poste (CTP122) et 1.80% pour la totalité en CTP 430.
Certains client ont créé trois cotisations, d'autres ont créé une cotisation spécifique à taux plein.
Dans le premier cas, la codification ne pose pas de difficulté, puisque chaque cotisation possède son CTP.
Mais si il y a une seule cotisation à 5.25%, et que c'est une cotisation utilisateur, il faudra alors modifier cela et utiliser la rubrique ALLOCFAMTXPLEI qui a été créé spécialement pour les types de salariés qui cotisent toujours à taux plein. La codification de cette rubrique doit être la suivante :
- CTP 430
- CTP1 100
- CTP2 122
- Code cotisation 074
Les colonnes CTP1 et CTP2 sont saisissables exceptionnellement lorsque le CTP est égal à 430.
Utilisation
Édition des charges et journaux
Lorsque la codification des régimes est terminée, vous pouvez tester l'édition des état récapitulatifs pour les déclarations mensuelles.
La case à cocher Mode détaillé pour contrôle DSN est désormais toujours cochée, et n'est modifiable qu'en mode administrateur
Pour éditer les états de comptabilisations et les journaux de salaires, la paye doit être complètement calculée. En revanche, ce n'est pas le cas pour les autres éditions et donc pour les déclarations mensuelles
Si l'édition comporte des CTP 999, c'est que les colonnes CTP1 et CTP2 n'ont pas été correctement codifiées
Les "AUT" il s'agit des rubriques qui ne sont pas envoyés en DSN mais uniquement pour l'affichage du bulletin simplifié.
En principe, les cotisations de même CTP et de même qualifiant sont regroupées.
Dans l'exemple ci-dessus, ce n'est pas le cas. Cela est due à la codification des cotisations, la case à cocher Dans la déclaration, éclater en fonction du taux AT doit être cochée pour chacune des cotisations composant le CTP.
Lorsqu'il y a un écart révélé par le bordereau URSSAF DSN, la fonctionnalité du contrôle DSN avancé s'avère nécessaire.
Génération de la DSN
Avant de générer la DSN, cochez la case "Mode détaillé pour contrôle charge"
Cette case à cocher n'est désormais plus disponible, elle est activée automatiquement
Contrôle Charge/DSN
Dans cette option, l'objectif est de vérifier que le montant envoyé en DSN est égal au montant calculé en paye.
Dans la gestion des saisies de la DSN, cliquez sur Contrôle DSN/URSSAF
Sélectionnez le mois/Année à contrôler et cliquez sur Contrôle Charge/DSN
L'écran suivant présente la liste des sections de déclaration Par défaut, si vous en avez plusieurs, seuls les totaux seront visibles.
Le montant attendu correspond au montant de la DSN. Il est égal à la base multiplié par le taux du CTP (ce taux est fixé par l'URSSAF). L'écart est donc égal au montant attendu moins le montant en paye.
Nous avons par exemple dans cet exemple un écart de 92.04 pour l'établissement ET05
Quand on clique sur le "+" au niveau de l'établissement, nous avons le détail par section
Cliquez sur un établissement pour en voir le détail : Pour chaque couple CTP/Qualifiant les colonnes affichées sont :
- La base : Il s'agit de l'assiette alimentée en DSN dans les blocs 23. Attention, s'il y a plusieurs blocs 23 pour un même CTP (C'est le cas lorsqu'il y a plusieurs périodes de rattachement) il s'agit de l'assiette totale.
- Le taux CTP : Il s'agit du taux légal en vigueur
- Le taux AT : Il s'agit du taux AT alimenté dans le bloc 23. Lorsqu'il s'agit d'un CTP de taxe de transport, c'est le taux de la taxe transport.
- Le montant attendu correspond à la base multiplié par la somme des deux taux précédents
- Montant paye : Il s'agit du montant de cotisation issu (Ce montant a été enregistré lors du calcul des charges)
- Écart : Il s'agit de l'écart entre le montant attendu et le montant en paye. Il doit bien entendu être approximativement égal à zéro.
Ici, l'écart vient donc du CTP 100
En double cliquant sur la ligne en écart, nous avons le détail du CTP par matricule
Cela nous permet d'identifier le ou les matricules en écart.
Dans notre exemple, nous avons un écart sur le matricule 000101
Nous pouvons donc analyser le bulletin du matricule en question afin d'identifier l'origine de l'écart ( soit corriger la codification de régime, soit paie incorrecte...)
Contrôle en aval : Synthèse CRM
Introduction
Depuis le début de l'année, de nouveaux CRM sont générés dans un nouveau format ressemblant un peu à la norme DSN. Il s'agit des CRM normalisé à la norme NEOReS. Nous avons donc modifié le lecteur de CRM afin de le présenter de manière lisible.
A cette occasion, nous avons constaté que beaucoup de CRM était en anomalie non bloquante pour la certification de la DSN mais nécessitant des corrections, voire des régularisations si l'échéance est passée.
Afin d'inciter à consulter ces anomalies et à les corriger avant l'envoi définitif de la DSN, nous avons ajouté un module Synthèse CRM qui permet de consulter l'ensemble des anomalies relevées, et cela pour l'intégralité des DSN.
Ce module est accessible via le tableau de bord en cliquant sur la tuile Contrôle DSN. Le module charge alors la synthèse des CRM du mois précédent.
Avant de lancer le module, vous pouvez cocher la case permettant de télécharger les retours.
Le module est également accessible via la gestion de la DSN en cliquant sur le bouton Transmission, puis en cliquant sur le bouton Synthèse CRM
Le programme analyse l'intégralité des CRM issus des dernières transmissions certifiées conformes, qu'elles soient en essai ou en réel.
Lorsque l'anomalie est nominative, le matricule et le numéro de contrat DSN sont affichés.
Le détail de l'anomalie peut être consulté dans le cadre bas de l'écran en cliquant sur une ligne d'anomalie.
Il est également possible de double cliquer sur une ligne d'anomalie pour consulter le CRM contenant cette anomalie.
Pour le moment, les anomalies des CRM OC ne sont pas répertoriés dans ce module car ils ne sont pas normalisés.
Il est également important d'utiliser régulièrement la consultation des anomalies BIS. Si en règle générale, ces anomalies sont mineures et ne concerne que des noms de naissance ou prénoms légèrement différents par rapport au fichier SNGI (Système National de Gestion des Identifiants), elles peuvent parfois révéler que des individus ne sont pas reconnus et donc ne pourront pas être indemnisés lors d'un arrêt et parfois inconnu également au niveau de la DGfiP.
Détail des CRM
Chaque CRM est identifié par un code appelé nature du CRM et permet de connaitre l'organisme émetteur d'identifier le format du CRM.
Chaque CRM a un statut (OK,KO ou ANO) mais n'ont pas forcément de contenu, notamment pour les CRM de type accusé de réception.
Les CRM sont principalement utilisés pour remonter des anomalies mais aussi pour transmettre des informations à l'utilisateur :
CRM DGfIP pour la liste des taux PAS, CRM Taux AT pour transmettre les nouveaux Taux AT, CRM effectif. Certains d'entre eux sont automatiquement exploités par le logiciel.
Ci après sera présenté une liste non exhaustive des différents CRM
10-Avis de dépôt organisme SI DSN
Indique par le statut l'accusé de réception de la DSN ainsi que différentes informations comme le siret émetteur, la date de réception, etc.
11-Certificat de conformité organisme SI DSN
Il s'agit du certificat qui valide votre DSN au niveau du SI DSN. Cela veut dire que le fichier envoyé est conforme à la norme en vigueur mais ne certifie pas que la DSN est correcte vis à vis des autres organismes. En cas de statut KO, le contenu indique les anomalies détectées.
20-Bilan d'identification des salariés SI DSN
Ce CRM est le résultat du contrôle de vos salariés vis à vis du fichier Système National de Gestion des Identifiants (SNGI). Si les correspondances nom prénom NIR sont exactes, il n'y aura pas d'anomalie. Si la correspondance n'est pas exacte, une anomalie sera affichée, cependant le salarié peut être correctement identifié. C'est l'anomalie I0310 Salarié reconnu et il s'agit bien souvent de différence sur le prénom ou le nom de naissance et il n'est pas forcément nécessaire de le corriger.
Dans la synthèse des CRM, ce type d'anomalie n'est pas répertoriée
21-Contrôle inter déclaration SI DSN
Ce CRM contrôle la cohérence entre les contrats déclarés dans le mois en cours et le mois précédent. Si un contrat n'est plus déclaré alors qu'il n'y a pas eu de fin de contrat le mois précédent, une anomalie est remontée
Cette anomalie peut survenir lors qu'un salarié change d'établissement, il convient de ne pas tenir compte du message dans ce cas
34-CRM Taux AT
Ce CRM contient les nouveaux taux AT et sont exploités par la GRH dans la mise à jour des chiffres de paye. Il est généralement mis à disposition au mois de novembre pour les taux AT de l'année suivante mais peut être envoyé à tout moment si les taux changent en cours d'année.
50-Accusé de réception Organisme complémentaire
Il s'agit de l'accusé de réception des organismes complémentaires
51-CRM Organisme complémentaire
Le CRM des organismes complémentaires n'est pas normalisé et peut varier d'un organisme à l'autre
61-CRM données agrégées Organisme URSSAF
Ce CRM indique que le télépaiement a été enregistré par l'URSSAF
62-CRM données nominatives Organisme URSSAF
Ce CRM remontent les incohérence détectées sur les données nominatives. Il indique pour chaque anomalie le salarié concerné
94-CRM données nominatives Organismes DGfIP
Ce CRM contient la liste des taux PAS des salariés déclarés le mois précédent
119-CRM H+4 Organisme URSSAF
Ce CRM est l'équivalent du CRM 62 mais au nouveau format Néores beaucoup plus lisible que le format XML. Il a la particularité d'être disponible 4 heures après l'envoi de la DSN (en test ou en réel), ce qui permet une résolution des anomalies avant la date d'échéance. De plus, un CRM peut contenir un ensemble d'anomalies, soit au niveau de l'établissement, soit au niveau de l'individu.
120-CRM J+5 Organisme URSSAF
Ce CRM est identique au CRM précédent mais n'est disponible que 5 jours après l'échéance, et les anomalies détectées devront être corrigées sur la DSN suivante
124-CRM de rappel
Ce CRM est identique au CRM précédent mais concerne l'ensemble des anomalies de l'année précédente est est émis en mars de l'année en cours. C'est ce CRM qui servira de base pour générer une éventuelle DSN de substitution si les anomalies ne sont pas corrigées
Anomalies URSSAF
Ce chapitre traite plus particulièrement les anomalies Urssaf issues des CRM 120 et CRM 124.
Dans l'écran CRM de synthèse, les anomalies "substituables" sont affichées en rouge ce qui permet d'avoir les anomalies les plus urgentes à corriger.
Le bouton 
permet d'affiner la sélection. Tous les CRM sont analysés et retravaillés pour afficher la liste de toutes les anomalies trouvées dans l'ensemble des CRM du mois en cours.
Comme précédemment, les anomalies en rouge sont les anomalies réellement substituables. Pour la DSN de substitution de 2026, concernant l'année 2025, seules les anomalies individuelles de calcul de plafond sont substituables. Exceptées les anomalies dues à une assiette brute négatives.
L'écran se décompose en quatre parties :
- La partie 1 présente la liste des anomalies Urssaf.
- La partie 2 le détail du message de l'Urssaf
- La partie 3 présente le détail des éléments de la DSN qui ont été envoyés pour le salarié concerné par période de rattachement
- La partie 4 affiche le détail des périodes DSN se rapportant à la période de rattachement sélectionnée.
Dans cet exemple, nous avons 4 anomalies substituables.
Si on clique sur une anomalie, les éléments permettant d'arriver au recalcul de l'Urssaf, c'est à dire les élément qui ont été envoyés en DSN sont affichés.
Ici il s'agit d'une anomalie de type plafond erroné. Sont affichés donc la modalité du temps de travail, l'horaire, la base brute, la base plafonnée, le nombre d'heures complémentaires, toutes ces zones étant issues de la dsn envoyée.
Vient ensuite le plafond recalculé, la base plafonnée recalculée et enfin les cumuls nécessaires au recalcul
Pour le moment, le détail n'est affiché que pour les anomalies de type plafond. Dans une version ultérieure, ces données changeront en fonction du type d'anomalie (Exemple Net social)
Dans cet exemple, une anomalie est détectée sur avril 2025. Néanmoins toutes les périodes depuis le début d'année sont affichées afin de permettre une vision d'ensemble des éléments de calcul. On remarque que la cause de l'anomalie est la base brute qui est négative. Dans ce cas, l'Urssaf prend zéro pour le recalcul du plafond.
La liste ci dessus est regroupée par période de rattachement. Si une ligne est issue de plusieurs dsn (Par exemple la dsn mensuelle d'origine et une régularisation qui a eut lieu le mois suivant), la colonne Régul sera égal à oui.
Le bouton WikiEIG permet de lancer le navigateur sur la page wiki expliquant l'anomalie et sa méthode de résolution
Fichier des contrôles URSSAF
Le fichier des contrôles est un fichier fourni par l'Urssaf. Il permet de consulter tous les contrôles effectué par ce dernier.
On retrouve l'ensemble des informations relative aux anomalies, la description détaillée, la méthode de résolution et des informations complémentaires.
Résolution des anomalies des CRM de type plafond
Vous pouvez consulter le document en lien pour résoudre les anomalies.
Assiettes négatives 2025
Depuis début 2025, l'Urssaf a mis en place un nouveau contrôle, sur l'assiette plafonnée en période courante.
Sur ce contrôle, les assiettes négatives sont prises pour une valeur à zéro. En conséquence, cela génère une anomalie dans le CRM 120.
Tout au long de l'année 2025, la SDDS (l'association des éditeurs) a discuté avec la DSS et Urssaf Caisse Nationale, en indiquant que ces cas étaient courants dans le cas de saisie décalée des évènements : plusieurs mois d'absences saisies sur un mois, saisies d'IJSS, etc.
Par conséquent, seul le fait générateur pourra corriger cette anomalie puisque l'évènement sera ramené à sa période d'emploi. Et le fait générateur n'entrera en vigueur qu'au 1er janvier 2027.
Ce n'est que début janvier 2026 que l'Urssaf a actualisé sa FAQ sur la DSN de substitution (Question 5), en indiquant que ces cas ne seraient pas pris en compte dans la DSN de substitution.
Toutefois, la question de savoir ce que deviendront ces anomalies. La FAQ indique Ces signalements ne peuvent pas être neutralisés, car ils traduisent une situation déclarative non conforme. Ils continueront donc d’être émis chaque mois tant que la déclaration n’aura pas été corrigée. Mais il n'est pas possible de corriger ces anomalies sans fait générateur. Il y a la une incohérence que nous ne comprenons pas.
En résumé il n'y a pas à s'inquiéter pour le moment de cette anomalie.
Le contrôle sur l'assiette plafonnée peut ne pas être dû a une assiette négative. Il convient dans ce cas de le corriger impérativement. Cela peut être du a une erreur de paramétrage (Cf. https://wikiapp.heberg-eig.fr/books/mise-a-jour-de-decembre-2025/page/add-on-codification)