7 erreurs de données de relevé PAYG qui déclenchent
des écarts de rapprochement ATO

Conséquence ATO : Retenue de 47 % (taux marginal supérieur + prélèvement Medicare) au lieu du taux marginal de l'employé si le TFN est manquant. Si le TFN est présent mais incorrect — généralement deux chiffres transposés — le pré-remplissage myGov de l'employé affiche un employeur qu'il ne reconnaît pas, l'employé conteste le relevé de revenus et l'ATO émet une demande de rapprochement de données à l'employeur. Résolution : 30 minutes à deux heures par employé concerné.

Comment cela se produit : L'agent de paie saisit le TFN à partir du relevé de paiement dans la feuille de calcul de rapprochement et transpose deux chiffres — 123 456 789 devient 123 456 798. Les neuf chiffres sont présents, donc un contrôle visuel ne détecte pas l'erreur. La feuille de calcul est utilisée pour vérifier les données STP, et le TFN incorrect se retrouve dans la finalisation. Pour les relevés papier de fournisseurs tiers, le TFN peut être manuscrit et difficile à lire — un « 8 » qui ressemble à un « 3 » dans une mauvaise qualité de numérisation devient une enquête de trois heures.

Prévention lors de l'extraction : L'extraction automatisée lit le TFN à partir du contenu visuel du document — aucune saisie humaine, aucune transposition. Pour le traitement par lots, une colonne calculée qui exécute l'algorithme de somme de contrôle TFN de l'ATO (somme pondérée des huit premiers chiffres modulo 11 doit être égale au neuvième chiffre) sur chaque TFN extrait signale les numéros invalides avant l'ouverture de la feuille de calcul. Une colonne supplémentaire qui signale les TFN en double sur les lignes détecte le scénario où deux employés partagent le même TFN saisi incorrectement — un schéma qui survivrait autrement à la fois à l'extraction et à la vérification visuelle.

Conséquence ATO : Si le RFBA est omis du relevé alors que l'employé a effectivement reçu des avantages sociaux à déclarer, le revenu de l'employé aux fins de la surtaxe Medicare et des remboursements HELP est sous-estimé. L'employé peut recevoir un remboursement d'impôt auquel il n'a pas droit, ou éviter une surtaxe qu'il aurait dû payer. Lorsque l'ATO recoupe la déclaration FBT de l'employeur (déposée avant le 21 mai pour l'exercice FBT se terminant le 31 mars) avec les montants RFBA déclarés sur les relevés PAYG, un écart déclenche un examen au niveau de l'employeur — et non pas seulement une vérification auprès d'un seul employé. Un RFBA incorrect sur un relevé peut entraîner un examen de conformité de l'ensemble de la déclaration FBT de l'employeur.

Comment cela se produit : L'exercice FBT (du 1er avril au 31 mars) et l'exercice financier (du 1er juillet au 30 juin) ne coïncident pas. Un avantage fourni en avril 2026 appartient à l'exercice FBT 2026-27, mais peut apparaître sur le relevé PAYG 2025-26 de l'employé si l'équipe de paie applique par erreur la logique de l'exercice financier au champ RFBA. Autrement, le montant RFBA a été correctement calculé pour la déclaration FBT, mais n'a jamais été mis à jour dans le système de paie — le relevé indique un RFBA de 0 $, alors que la déclaration FBT rapporte une valeur majorée non nulle pour cet employé, et le recoupement automatisé de l'ATO signale l'incohérence.

Prévention lors de l'extraction : Une colonne calculée qui vérifie : si la rémunération totale d'un employé (paiements bruts + tout sacrifice de salaire) dépasse 100 000 $ et que le RFBA = 0 $, signaler pour examen — les employés à revenu élevé sont statistiquement plus susceptibles de recevoir des avantages sociaux à déclarer. Une règle de validation distincte : pour tout employé ayant un arrangement d'avantages connu (voiture de fonction, assurance santé, avantages de divertissement), confirmer que le RFBA est non nul et correspond au calendrier de la déclaration FBT. Le tableur d'extraction, recoupé avec la déclaration FBT avant la finalisation du 14 juillet, détecte les écarts RFBA pendant qu'il est encore temps de corriger le relevé.

Conséquence ATO : Une mauvaise classification d'une somme forfaitaire modifie le revenu imposable et l'impôt à payer de l'employé. Saisir un paiement d'indemnité de licenciement légitime de 15 000 $ comme somme forfaitaire A (congés annuels non pris imposables) au lieu de la somme forfaitaire D (composante d'indemnité de licenciement exonérée d'impôt) signifie que le relevé de revenus de l'employé affiche 15 000 $ de revenu imposable supplémentaire. L'employé est imposé sur ce montant — potentiellement 4 875 $ au taux marginal de 32,5 % plus la taxe Medicare — conteste l'évaluation et dépose une plainte. L'employeur doit réémettre le relevé, soumettre un rapport STP modifié et potentiellement indemniser l'employé pour tout intérêt de pénalité facturé par l'ATO sur l'évaluation incorrecte. Pire : un liquidateur ou un administrateur examinant une entreprise qui a mal classifié les sommes forfaitaires de plusieurs employés sur plusieurs années peut identifier une défaillance systémique de conformité de la paie — une constatation bien plus grave qu'un simple paiement mal classifié.

Comment cela se produit : Le flux de travail de paiement de cessation du logiciel de paie demande à l'agent de paie de sélectionner un type de somme forfaitaire dans une liste déroulante. L'agent, peu familier avec la distinction fiscale entre le type A (congés annuels — imposables) et le type D (indemnité de licenciement — exonérée d'impôt), sélectionne la mauvaise option. Le logiciel génère le relevé avec la classification incorrecte, et aucune vérification ultérieure ne détecte l'erreur car le montant en dollars — 15 000 $ — semble plausible quel que soit le type. L'erreur ne fait surface que lorsque la déclaration de revenus de l'employé est évaluée et que le système de l'ATO détecte qu'une somme forfaitaire D a été déclarée par l'employeur mais que la déclaration de l'employé montre un revenu imposable incluant le montant — ou vice versa.

Prévention lors de l'extraction : Créez une règle de validation lors de l'extraction : pour tout employé avec une somme forfaitaire D non nulle, signalez la ligne pour vérification d'une véritable indemnité de licenciement ou d'un régime de retraite anticipée — et exigez une documentation (lettre d'indemnité de licenciement, approbation du régime de retraite anticipée) avant l'émission du relevé. Pour tout employé avec une somme forfaitaire A ou B non nulle, confirmez que l'employé a effectivement cessé ses fonctions au cours de l'exercice financier — un employé actuel ne devrait pas avoir de sommes forfaitaires pour congés non pris. Une colonne calculée qui recoupe les soldes de congés du système de paie avec les montants des sommes forfaitaires du relevé détecte les écarts lorsque le montant de l'indemnité de congés du relevé ne correspond pas au solde de congés accumulés à la cessation.

Conséquence ATO : Pour les employés déclarés via STP, la déclaration de finalisation STP et le relevé de paiement PAYG (si les deux existent pour le même employé pour la même période — ce qui ne devrait pas être le cas, mais arrive parfois) doivent indiquer des chiffres identiques. Un écart signifie que l'employé reçoit deux versions différentes de son revenu du même employeur : une via myGov (STP) et une sur le relevé papier/PDF. La déclaration de revenus de l'employé — qui utilise le pré-remplissage myGov — peut ne pas correspondre au relevé de paiement qu'il détient. Le croisement de données de l'ATO détecte l'incohérence et interroge à la fois l'employeur et l'employé. Résolution : l'employeur doit déterminer quel chiffre est correct, corriger celui qui est incorrect (événement de mise à jour STP ou relevé réémis) et informer l'employé.

Comment cela se produit : Le scénario le plus courant : un employé est passé d'une période pré-STP à une période STP au cours de la même année financière (par exemple, l'employeur a mis en place STP en octobre 2025). Le système de paie génère un relevé de paiement PAYG pour la période pré-STP de juillet à septembre et des données STP pour la période d'octobre à juin. Si les deux ensembles de données ne sont pas rapprochés avant la finalisation, l'employé peut apparaître dans les deux rapports avec des chiffres qui se chevauchent ou sont incohérents. Un scénario moins courant mais tout aussi problématique : un ajustement manuel de la paie saisi après la finalisation STP met à jour le système de paie, mais l'événement de mise à jour STP correspondant n'est pas soumis — les données STP détenues par l'ATO sont désormais obsolètes, mais aucun indicateur d'écart n'est visible dans les propres systèmes de l'employeur.

Prévention lors de l'extraction : Pour tout employé ayant reçu à la fois un relevé PAYG traditionnel (période pré-STP) et des données déclarées via STP (période post-transition) au cours de la même année financière, extrayez les deux sources de données dans la feuille de calcul de rapprochement et rapprochez les totaux combinés avec le rapport annuel complet du système de paie. La feuille de calcul d'extraction devient la source unique de vérité : utilisez RECHERCHEV pour chaque TFN de l'employé par rapport aux données STP et au relevé pré-STP, confirmez que la somme des paiements bruts et de l'impôt retenu sur les deux sources est égale au rapport cumulatif de l'année du système de paie, et signalez tout employé dont le chiffre combiné ne correspond pas. Cela évite le scénario où les données STP et le relevé semblent tous deux cohérents en interne mais indiquent des totaux différents pour le même employé.

Conséquence ATO : Les allocations doivent être détaillées séparément sur le relevé de paiement PAYG, car différents types d'allocations ont des traitements fiscaux différents. Une allocation d'outils peut être exonérée d'impôt jusqu'à un taux ATO spécifié ; une allocation de déplacement peut être partiellement imposable selon qu'un journal de déplacements a été tenu ; une allocation de premiers secours est entièrement imposable. Si une allocation est regroupée dans les paiements bruts sans détail séparé, l'employé ne peut pas réclamer le traitement fiscal correct sur sa déclaration. Si l'allocation est entièrement omise du relevé, le revenu déclaré de l'employé est sous-estimé — et le croisement de données de l'ATO (qui compare les totaux salariaux BAS de l'employeur à la somme des chiffres des relevés des employés) détecte l'écart. Une divergence d'allocation se manifeste généralement par une inadéquation BAS-relevés — les salaires déclarés sur le BAS sont plus élevés que la somme des paiements bruts sur les relevés, déclenchant une demande de l'ATO concernant des revenus d'employés non déclarés.

Comment cela se produit : Le système de paie peut coder les allocations comme faisant partie du salaire brut à des fins de reporting interne, mais les imprimer comme une ligne séparée sur le relevé PAYG. Si l'agent de paie qui extrait le relevé saisit le chiffre du paiement brut tel qu'il apparaît dans le registre de paie — qui peut inclure les allocations — mais que le relevé imprime les allocations séparément, le chiffre extrait est trop élevé. À l'inverse, si l'agent de paie saisit les montants des allocations du relevé mais oublie de les inclure dans le total des paiements bruts, le chiffre extrait est trop bas. L'erreur est une inadéquation entre ce que le système de paie déclare en interne et ce que le relevé déclare en externe — et la feuille de calcul d'extraction qui se fie à une source sans vérifier l'autre propage l'erreur.

Prévention lors de l'extraction : Extrayez les allocations comme colonnes séparées dans le schéma de sortie. Une colonne calculée qui additionne les paiements bruts plus toutes les colonnes d'allocations et compare le résultat au rapport de gains bruts de fin d'année du système de paie détecte le cas où les allocations étaient incluses dans le brut dans une source mais séparées dans une autre. Une colonne de validation distincte qui signale tout type d'allocation non nul dont le montant semble invraisemblable — une allocation d'outils de 50 000 $ pour un employé de bureau, ou une allocation de déplacement de 200 $ pour un technicien de terrain ayant parcouru 5 000 km au cours de l'année — détecte les erreurs de classification sans nécessiter une vérification ligne par ligne.

Conséquence ATO : Un paiement d'indemnité de fin d'emploi se voit attribuer un code ETP qui détermine son traitement fiscal : R pour licenciement pour motif économique, O pour autre (démission, licenciement, indemnité de départ), D pour prestation de décès, B pour invalidité, N pour paiements non exclus. Le plafond ETP — le montant maximal bénéficiant d'un traitement fiscal préférentiel — dépend du code. Un paiement codé O (autre) alors qu'il devrait être R (licenciement pour motif économique) signifie que l'employé bénéficie d'un plafond ETP inférieur : 245 000 $ pour 2025-26 (indexé annuellement) pour le code R, mais potentiellement uniquement le plafond de revenu total de 180 000 $ moins les autres revenus imposables pour le code O — une différence de dizaines de milliers de dollars en revenu imposable par rapport au revenu bénéficiant d'un traitement préférentiel. L'employé découvre l'erreur lorsque sa déclaration de revenus affiche une obligation fiscale sur l'ETP bien plus élevée que prévu. L'employeur doit réémettre le relevé de paiement ETP avec le bon code, recalculer l'impôt retenu et potentiellement indemniser l'employé pour tout impôt supplémentaire et intérêts.

Comment cela se produit : Le responsable de la paie qui traite la cessation d'emploi dans le logiciel de paie se voit présenter une liste déroulante de codes ETP — R, O, D, B, N — avec une explication minimale à l'écran de ce que chaque code signifie sur le plan fiscal. Le responsable sélectionne le code qui « semble approprié » plutôt que celui qui correspond au motif de cessation. Pour un licenciement pour motif économique où l'employé a signé un acte de libération (qui peut utiliser un langage comme « paiement à titre gracieux » ou « indemnité de cessation » sans préciser « licenciement pour motif économique »), le responsable peut sélectionner O (autre) parce que l'acte n'utilise pas le mot « licenciement pour motif économique » — même si la cessation répond à la définition de licenciement pour motif économique de l'ATO. Le code est enregistré dans le système de paie, imprimé sur le relevé ETP et transmis à l'ATO via STP — et aucune vérification ultérieure ne détecte le mauvais classement, car le montant total de l'ETP est correct quel que soit le code.

Prévention lors de l'extraction : Extrayez le code ETP dans une colonne distincte et recoupez-le avec le motif de cessation enregistré dans le système RH. Une colonne calculée qui signale tout ETP avec le code O lorsque le motif de cessation est « licenciement pour motif économique » ou « compression d'effectifs » — ou le code R lorsque le motif est « démission » — met en évidence les mauvais classements potentiels avant que le relevé n'atteigne l'employé. Pour l'extraction par lots de plusieurs relevés ETP, une colonne qui regroupe les montants ETP par code et compare la répartition aux schémas attendus (une entreprise traversant une seule vague de licenciements pour motif économique ne devrait pas présenter un mélange de codes R et O pour les employés licenciés dans le même processus) détecte les erreurs de codage systémiques.

Conséquence ATO : Le nombre d’employés pour lesquels des relevés PAYG sont émis doit correspondre au nombre d’employés pour lesquels la retenue PAYG a été déclarée à l’ATO — via STP, BAS et le rapport annuel. Un employé rémunéré au cours de l’année mais n’ayant pas reçu de relevé n’a aucune trace de ses revenus ni de la retenue d’impôt, ne peut pas remplir correctement sa déclaration de revenus et — lorsqu’il reçoit finalement un relevé ou découvre l’omission — peut déjà avoir déposé une déclaration incorrecte. Le croisement de données de l’ATO signale l’écart : le nombre total d’employés avec retenue PAYG sur le rapport annuel est inférieur au nombre d’employés sur le BAS, ou le total des paiements bruts sur les relevés est inférieur aux salaires déclarés sur le BAS. L’employeur doit expliquer l’écart et, si des employés ont été oubliés, émettre des relevés rétroactifs — potentiellement pour une année fiscale déjà clôturée.

Comment cela se produit : Les employés ayant quitté l’entreprise au cours de l’exercice financier mais ayant travaillé une partie de celui-ci constituent le groupe le plus souvent oublié. Le responsable de la paie génère les relevés à partir de la liste actuelle des employés — qui exclut les employés licenciés — et ne vérifie pas par recoupement avec le registre de paie de l’année complète. Les employés occasionnels ayant travaillé un seul quart de travail et ayant eu 12 $ de retenue d’impôt constituent une autre omission courante : l’équipe de paie peut supposer un seuil en dessous duquel les relevés ne sont pas requis, mais l’ATO exige un relevé pour chaque travailleur ayant eu une retenue d’impôt, quel que soit le montant. Les entrepreneurs sous convention de retenue volontaire ayant reçu un relevé NAT 72545 distinct (revenus d’entreprise et de services personnels) peuvent être omis du rapport annuel si l’équipe de paie pense que seuls les relevés NAT 0046 comptent.

Prévention lors de l’extraction : Avant la finalisation, extrayez chaque relevé PAYG — y compris les relevés ETP, les relevés de revenus d’entreprise et de services personnels, et les relevés pour les employés licenciés et occasionnels — dans une seule feuille de calcul. Ajoutez une colonne calculée qui compte les TFN uniques dans l’extraction et affiche le nombre total d’employés. Comparez ce nombre avec : (a) le nombre d’employés sur le rapport cumulatif du système de paie ayant eu une retenue PAYG (pas seulement la liste actuelle des employés actifs), (b) le nombre d’employés déclarés sur les quatre BAS trimestriels, et (c) le nombre d’employés avec des données STP finalisées. Toute différence entre ces nombres — même une différence d’un seul — nécessite une enquête avant le dépôt du rapport annuel. Un seul relevé manquant est une demande de l’ATO qui n’attend que de se produire.