Pourquoi la saisie manuelle des relevés PAYG coûte plus cher
que ne le pensent la plupart des équipes paie
Le système de recoupement de données de l'ATO traite environ 14 millions de déclarations de revenus individuelles chaque année, en comparant les salaires déclarés par les contribuables aux données de retenue PAYG déclarées par les employeurs. Lorsque les deux chiffres ne correspondent pas — et l'examen de l'Inspecteur général des impôts a révélé que 85 à 89 % des écarts signalés entraînent un ajustement — la lettre qui atterrit dans la boîte de réception myGov d'un employé déclenche une réaction en chaîne. L'employé appelle son service paie. Le responsable paie ouvre le relevé de paie original. Et quelqu'un — généralement la personne qui a tapé ce TFN dans le tableur de rapprochement il y a quatre mois — passe les deux heures suivantes à retracer un seul chiffre inversé sur trois systèmes et deux exercices fiscaux.
Points clés
- Le pic PAYG de juillet cumule trois échéances en une seule date : la finalisation STP, la distribution des relevés non-STP, et un rapport annuel d'août qui recoupe les données saisies quatre semaines plus tôt avec quatre déclarations BAS trimestrielles.
- 85 à 89 % des alertes de recoupement de l'ATO entraînent des ajustements réels — et chaque requête résolue remonte à un seul chiffre inversé saisi pendant une fenêtre de juillet compressée où le taux d'erreur double en cas d'interruption.
- Le STP a éliminé les relevés pour 88 de vos 100 employés et a fait consommer aux 12 restants 80 % de votre temps de rapprochement — automatisez ces 12 cas particuliers et tout le goulot d'étranglement de juillet s'effondre autour d'eux.
Le Crunch de Juillet : Trois Échéances Déguisées en Une
La plupart des descriptions du processus de synthèse PAYG se concentrent sur une seule date : le 14 juillet, date limite pour remettre les relevés de paiement aux employés et finaliser la DSN. Mais pour l'équipe paie qui effectue le travail, juillet représente en réalité trois échéances qui se chevauchent, chacune avec ses propres exigences de rapprochement, et chacune puisant dans une source de données différente. La charge de travail de saisie manuelle est la somme des trois — pas le temps nécessaire pour taper un seul relevé.
La première échéance — la finalisation de la DSN au 14 juillet — exige que le responsable paie confirme que les chiffres cumulés de chaque employé dans le système de paie sont corrects avant de soumettre la déclaration de finalisation. Cela implique de rapprocher les totaux du système avec les données des relevés. Pour une entreprise utilisant une seule plateforme de paie avec des données propres, c'est une simple étape de vérification. Pour une entreprise qui a changé de prestataire de paie en cours d'année, qui a des employés dans plusieurs entités avec des ABN différents, ou qui a des bénéficiaires proches avec une extension de finalisation au 30 septembre, la vérification devient un rapprochement multi-sources — et chaque source qui ne peut pas être interrogée électroniquement doit être saisie manuellement.
La deuxième échéance — la remise des relevés de paiement PAYG aux employés non déclarés via la DSN, également au 14 juillet — génère la pile de documents. Les employeurs exemptés de DSN, les bénéficiaires proches recevant des relevés provisoires, et les employés dont les périodes antérieures à la DSN nécessitent un certificat traditionnel produisent tous des relevés papier ou PDF que l'équipe paie doit vérifier avant distribution. Chaque relevé se trouve dans un dossier ; chaque dossier contient des données qui doivent être intégrées au tableur de rapprochement.
La troisième échéance — le rapport annuel des relevés de paiement PAYG (NAT 3447) dû le 14 août — exige l'agrégat de tous les relevés émis, recoupé avec les quatre totaux de retenues BAS trimestrielles (cases W1 et W2). Un seul chiffre inversé sur un seul relevé crée un écart de 10 $ sur le rapport annuel — et un écart de 10 $ déclenche la même lettre de demande de l'ATO qu'un écart de 10 000 $.
Ce que la plupart des équipes paie oublient : la charge de travail n'est pas le nombre de relevés multiplié par le temps de saisie d'un relevé. C'est le nombre de relevés multiplié par le temps de saisie, plus le temps de recouper chaque relevé avec un système source différent, plus le temps d'enquêter sur les écarts que le recoupement révèle. La saisie manuelle est le coût visible ; le rework de rapprochement est le coût invisible qui le double.
Trois sources, trois formats, un seul tableur de rapprochement
Le tableur de rapprochement de juillet puise dans trois sources de données distinctes, chacune introduisant ses propres frictions de saisie manuelle :
Source 1 : Données du système de paie STP. Pour la majorité des employés, le système de paie contient les bons cumuls annuels — rémunération brute, retenue d'impôt, cotisations super — mais ces chiffres sont dans le logiciel de paie, pas dans un format exploitable par le tableur. Exporter un rapport de registre de paie en CSV est la première étape. Faire correspondre chaque ligne du CSV au résumé PAYG correspondant — par nom ou TFN — est la deuxième. Cette deuxième étape est manuelle, sauf si chaque résumé a déjà été extrait dans un format ligne/colonne identique. Les données existent ; la connexion entre la ligne CSV et le PDF du résumé, elle, n'existe pas — et créer cette connexion, c'est de la saisie.
Source 2 : Résumés de paie pré-STP. Les employés ayant travaillé une partie de l'année fiscale avant la transition vers STP — ou dont l'employeur a changé de fournisseur de paie en cours d'année, laissant la période pré-transition hors du périmètre STP — possèdent un résumé de paie PAYG traditionnel pour les mois pré-STP. Ces résumés n'existent qu'en PDF, générés par l'ancien logiciel de paie ou scannés à partir de certificats papier. Ils n'ont pas de ligne correspondante dans les données STP actuelles, donc le tableur doit les inclure comme entrées indépendantes. Chaque champ de chaque résumé pré-STP — ABN, TFN, brut, retenue d'impôt, RFBA, RESC, montants forfaitaires — doit être ressaisi, car aucun extrait électronique n'existe.
Source 3 : Résumés de paie de fournisseurs tiers. Les sous-traitants sous convention de retenue volontaire, les employés d'entités liées partageant l'administration de la paie mais sous des ABN distincts, et les travailleurs ayant reçu des paiements d'une entreprise de travail temporaire ayant émis son propre résumé PAYG — ces certificats arrivent dans la boîte de réception paie sous forme de PDF ou de courrier papier. Chacun est un document unique avec 15 à 20 champs à extraire et à ajouter au tableur. Contrairement aux données du système de paie, il n'y a pas d'export CSV, ni d'enregistrement STP, ni d'équivalent électronique. Le seul chemin du PDF au tableur passe par le clavier. C'est également le scénario rencontré par les équipes paie britanniques traitant la saisie manuelle des données P60 et le traitement papier des P45 — le type de document change, la géographie change, mais le problème central d'extraction des données d'un certificat papier ou PDF vers un tableur de rapprochement reste identique.
Les coûts que personne ne comptabilise : requêtes ATO, friction d’audit et flot de demandes des employés
Le coût direct de la saisie manuelle — les heures passées à taper — est la plus petite composante de la charge totale. Trois coûts aval sont plus importants, plus difficiles à quantifier et presque jamais budgétés dans la planification de la paie :
Résolution des requêtes de croisement de données de l'ATO
Le système de croisement de données de l'ATO compare la déclaration fiscale de chaque employé avec les données PAYG déclarées par l'employeur. L'Inspecteur général des impôts a constaté que 85 à 89 % des cas signalés aboutissent à un ajustement — ce qui signifie que la grande majorité des écarts sont de véritables erreurs, et non de faux positifs. Un chiffre de TFN inversé (employé 123 456 789 saisi 123 456 798) crée un écart qui traverse trois systèmes : le pré-remplissage myGov de l'employé affiche le mauvais employeur, l'employé le conteste, l'ATO interroge l'employeur, et le responsable paie doit retrouver le formulaire de déclaration TFN original pour prouver le bon numéro. Temps de résolution par requête : 30 minutes à deux heures. Nombre de requêtes pour un lot de 100 résumés saisis manuellement où le taux d'erreur du responsable paie est de 1 % (chiffre prudent) : au moins une par an — et souvent plus, car la fatigue s'accumule lors d'une session de saisie de huit heures.
Frictions liées à l'audit externe
Lorsque l'auditeur externe sélectionne 20 employés pour un contrôle substantiel des charges salariales, il doit retracer les chiffres du résumé PAYG de chaque employé jusqu'au système de paie, au relevé bancaire du paiement et à la BAS trimestrielle. Si les résumés n'existent que sous forme de PDF non extraits et que le tableur de rapprochement a été saisi manuellement, l'auditeur ne peut pas vérifier indépendamment l'exactitude de l'extraction sans ressaisir lui-même un échantillon. Cela allonge le calendrier d'audit et augmente les heures facturables — non pas parce que les données sont erronées, mais parce qu'il est impossible de démontrer leur exactitude sans répéter le processus manuel. En revanche, un seul tableur généré par extraction automatisée fournit à l'auditeur une source traçable qui peut être échantillonnée par rapport aux PDF originaux sans ressaisie.
Afflux de demandes des employés pendant la période fiscale
Les Australiens peuvent déclarer leurs impôts à partir du 1er juillet. Dès qu'un employé se connecte à myGov et voit son relevé de revenus, tout écart entre ce qui apparaît dans les données préremplies de l'ATO et ce qu'il attend — en fonction de son dernier bulletin de paie, de sa compréhension de son salaire ou d'un récapitulatif de l'année précédente — génère un appel ou un courriel au service de paie. Pendant les deux semaines entre le 1er et le 14 juillet, un responsable de la paie pour 120 employés reçoit généralement 15 à 25 demandes de renseignements sur les chiffres récapitulatifs. Chaque demande nécessite de consulter le récapitulatif original, le registre de paie et le dernier bulletin de paie de l'employé pour expliquer l'écart — qui n'en est souvent pas un, mais plutôt un décalage temporel (une prime de juin versée en juillet, un arrangement de sacrifice salarial que l'employé a oublié, un avantage accessoire déclarable dont l'employé ignorait la déclarabilité). Si le tableur de rapprochement a été construit manuellement, le responsable de la paie examine ses propres saisies pour répondre à la question — sans pouvoir confirmer si le chiffre que l'employé voit est correct ou s'il s'agit d'une erreur de transcription sans revérifier le PDF original.
Ce que la transition STP était censée résoudre — et ce qu’elle a laissé de côté
Le Single Touch Payroll a été introduit avec la promesse de supprimer les relevés de paiement PAYG. Pour la plupart des employés standards chez la plupart des employeurs, cela a réussi : une fois que l’employeur finalise les données STP avant le 14 juillet, l’employé accède à son relevé de revenus via myGov et aucun résumé papier ou PDF n’est nécessaire. L’ATO reçoit les données directement à chaque cycle de paie ; la déclaration de finalisation de fin d’année les confirme.
Mais la promesse STP échoue dans trois scénarios spécifiques qui, ensemble, affectent des milliers d’équipes de paie australiennes chaque juillet :
Premièrement, la queue pré-STP. Tout employeur ayant transitionné vers STP en cours d’année financière — ou ayant changé de logiciel de paie et ne pouvant pas déclarer la période pré-migration via le canal STP du nouveau système — doit encore fournir des relevés PAYG traditionnels pour la période pré-STP. Ces relevés existent sous forme de PDF générés par l’ancien logiciel, et l’ATO exige que les employeurs les conservent pendant cinq ans. Lorsque le nouveau responsable paie en juillet 2026 doit rapprocher l’année financière 2023-24 (parce qu’un ancien employé a soulevé une question sur son évaluation fiscale 2024), ces relevés pré-STP sont des PDF dans un dossier d’archive — pas des lignes dans les données STP.
Deuxièmement, les bénéficiaires proches. Les administrateurs, les membres de la famille d’une entreprise familiale et certains bénéficiaires de fiducie classés comme bénéficiaires proches ont une date limite de finalisation STP distincte au 30 septembre — deux mois et demi après la date limite standard des employés. De nombreux employeurs choisissent d’émettre à ces bénéficiaires un relevé PAYG traditionnel comme document provisoire pendant que les données STP sont encore en cours de finalisation. Chaque relevé de bénéficiaire proche arrive sous forme de PDF en juillet — et doit être extrait et rapproché séparément des données STP qui ne seront finalisées qu’en septembre.
Troisièmement, les certificats tiers. Les agences de travail temporaire, les sociétés parapluie et les entités apparentées opérant sous différents ABN émettent leurs propres relevés PAYG aux travailleurs qui peuvent également apparaître sur la paie de l’employeur principal pour un autre engagement. Ces certificats arrivent de l’extérieur du système de paie de l’organisation. Ils n’ont pas de contrepartie STP dans les propres déclarations de l’employeur. Et chaque champ sur chacun d’eux — ABN, TFN, brut, impôt retenu — doit être saisi manuellement dans le tableur de rapprochement car aucun pipeline automatisé ne relie le PDF d’un tiers au processus de rapprochement de l’employeur.
Le récit STP — « les relevés PAYG sont obsolètes » — est correct pour la majorité des scénarios d’employés simples. Il est incorrect précisément aux marges où la charge de saisie manuelle se concentre. Une équipe de paie qui traite 100 employés via STP et 12 employés via des relevés traditionnels ne consacre pas 12 % de son temps de rapprochement aux relevés traditionnels. Elle y consacre 80 % — car les données STP sont déjà électroniques, et les relevés traditionnels sont ceux qui nécessitent de la saisie.
Le même schéma apparaît dans chaque juridiction ayant modernisé la déclaration fiscale des employeurs : l’extraction de relevés PAYG en Australie reflète l’extraction P60 au Royaume-Uni — les deux rapprochent le reporting numérique moderne des certificats papier hérités qui refusent de disparaître.
Questions fréquentes
Pourquoi ne puis-je pas simplement utiliser l'export CSV de mon logiciel de paie pour le rapprochement ?
Un export CSV de paie vous donne les données telles qu'enregistrées dans votre système de paie. Le relevé de paiement PAYG vous donne les données telles que déclarées à l'employé et à l'ATO. Les deux peuvent différer — et ces différences sont précisément ce que le rapprochement vise à détecter. Une correction manuelle de paie saisie directement dans le système après le dernier cycle de paie, une prime payée en juin mais traitée dans le cycle de juillet (qui appartient à l'exercice suivant), ou un arrangement de sacrifice salarial mal codé comme SG standard au lieu de RESC — tout cela crée des écarts entre le CSV et le relevé. Le CSV indique ce que le système de paie pense avoir payé ; le relevé indique ce qui a été déclaré à l'employé et à l'ATO comme ayant été payé. Le rapprochement nécessite les deux sources, et l'écart entre elles est ce que la saisie manuelle crée — car quelqu'un doit saisir les données du relevé dans le même format que le CSV pour effectuer la comparaison.
La finalisation STP signifie-t-elle que je peux ignorer complètement l'étape de rapprochement manuel ?
Non. La finalisation STP confirme que les données déclarées tout au long de l'année sont correctes — mais elle ne vérifie pas indépendamment que les données correspondent aux relevés de paiement que vous émettez, à votre grand livre général ou à vos BAS trimestriels. L'ATO comparera vos données STP aux déclarations de revenus des employés, quoi qu'il arrive. Si la déclaration d'un employé indique un revenu différent de celui que vous avez déclaré via STP, le système de l'ATO signale l'écart — et l'enquête remonte jusqu'à vos registres de paie. STP automatise le pipeline de déclaration ; il ne remplace pas l'étape de vérification qui confirme que le pipeline a transporté les bons chiffres.
Quelle est la différence de temps réelle entre la saisie manuelle et l'extraction automatisée pour 100 relevés ?
La saisie manuelle d'un seul relevé de paiement PAYG — taper 15 à 20 champs incluant ABN, TFN, paiements bruts, impôt retenu, RFBA, RESC, allocations et montants forfaitaires, avec une vérification croisée du registre de paie — prend environ 2 à 3 minutes par relevé lorsqu'elle est effectuée avec soin. Pour 100 relevés : 3,5 à 5 heures de saisie, sans compter le temps de traitement des écarts découverts lors de la saisie. L'extraction automatisée — télécharger les 100 relevés en lot et recevoir un tableur consolidé — prend quelques minutes de traitement, suivies de 15 à 30 minutes d'examen des indicateurs de validation calculés. La différence est d'environ 3 à 4,5 heures pour 100 relevés — et ce temps est économisé au moment du calendrier de juillet où les équipes de paie ont le moins de temps à perdre.
Quel est l'impact des anciens résumés papier pré-DSN sur le rapprochement actuel ?
Lors d'un contrôle ou d'un réexamen par l'ATO d'une année fiscale antérieure — que l'ATO peut initier jusqu'à quatre ans après l'évaluation pour la plupart des contribuables, et sans limite de temps en cas de fraude ou d'évasion — l'employeur doit produire les relevés de paiement originaux de l'année concernée. Si ces relevés ont été générés par un logiciel de paie qui ne fonctionne plus sur les systèmes actuels (par exemple, une version de bureau MYOB abandonnée en 2020), le seul enregistrement accessible est le PDF scanné ou la copie papier. Lorsque le vérificateur demande un tableur de tous les relevés émis pour cette année, l'équipe paie doit choisir : ressaisir chaque champ de chaque relevé scanné, ou les extraire des scans vers un tableur. Plus l'année fiscale est ancienne, plus la probabilité que les données de paie originales soient inaccessibles est élevée — et plus l'extraction automatisée devient précieuse comme seule voie pour passer d'un classeur de papiers à un tableur que le vérificateur peut examiner.
Qu'en est-il des entrepreneurs rémunérés dans le cadre d'une convention de retenue volontaire — ont-ils aussi besoin d'un relevé PAYG ?
Oui. Si vous avez conclu une convention de retenue volontaire PAYG avec un entrepreneur, vous devez lui remettre un relevé de paiement PAYG — revenus d'entreprise et de services personnels (NAT 72545) avant le 14 juillet. Il s'agit d'un type de relevé distinct du formulaire individuel non professionnel, avec des libellés de champs différents, mais les mêmes données essentielles : paiements bruts et retenue d'impôt. Ces relevés ne transitent pas par le canal DSN standard. Ils existent sous forme de PDF séparés — généralement un par entrepreneur — et chacun doit être extrait et inclus dans la déclaration annuelle. Pour une entreprise de construction avec 15 sous-traitants sous convention de retenue volontaire, cela représente 15 relevés supplémentaires à traiter en juillet, chacun avec ses propres exigences d'extraction.