Pourquoi la saisie manuelle du relevé PAYG coûte plus cher
Que ce que la plupart des équipes de paie réalisent
Le système de croisement de données de l'ATO traite environ 14 millions de déclarations de revenus individuelles chaque année, comparant les montants de salaires et traitements déclarés par les contribuables aux données de retenue PAYG rapportées par les employeurs. Lorsque les deux chiffres ne correspondent pas — et l'examen de l'Inspecteur général de la fiscalité 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 de l'employé déclenche une réaction en chaîne. L'employé appelle son service de paie. Le responsable de la paie ouvre le relevé de paiement d'origine. Et quelqu'un — généralement la personne qui a saisi ce TFN dans le tableur de rapprochement il y a quatre mois — passe les deux heures suivantes à retracer un seul chiffre inversé à travers trois systèmes et deux exercices fiscaux.
Points clés à retenir
- La période chargée de juillet pour le PAYG regroupe trois échéances sur une seule date au calendrier : la finalisation STP, la distribution des relevés hors 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 signalements de croisement de données de l'ATO entraînent des ajustements réels — et chaque demande résolue remonte à un seul chiffre inversé saisi pendant une fenêtre de juillet compressée où les taux d'erreur doublent en cas d'interruption.
- Le STP a éliminé les relevés pour 88 de vos 100 employés et a fait en sorte que les 12 restants consomment 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 pic de juillet est en réalité trois échéances déguisées en une seule
La plupart des descriptions du processus de relevé 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 déclaration STP. Mais pour l'équipe de paie qui fait 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 saisie manuelle est la somme des trois — pas le temps nécessaire pour saisir un seul relevé.
La première échéance — la finalisation STP avant le 14 juillet — exige que le responsable de la paie confirme que les montants 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 la sortie des relevés. Pour une entreprise utilisant une seule plateforme de paie avec des données propres, c'est une étape de vérification. Pour une entreprise qui a changé de fournisseur de paie en cours d'année, qui a des employés répartis sur plusieurs entités avec des ABN différents, ou qui a des bénéficiaires proches avec une prolongation 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 STP, également avant le 14 juillet — génère la pile de documents. Les employeurs exonérés de STP, les bénéficiaires proches recevant des relevés intérimaires, et les employés dont les périodes avant STP nécessitent un certificat traditionnel produisent tous des relevés physiques ou PDF que l'équipe de 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 relevé annuel des relevés de paiement PAYG (NAT 3447) dû le 14 août — exige le total agrégé de chaque relevé émis, recoupé avec les quatre totaux de retenue d'impôt BAS trimestriels (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 renseignements de l'ATO qu'un écart de 10 000 $.
Ce que la plupart des équipes de paie manquent : 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 recoupement de chaque relevé avec un système source différent, plus le temps d'investigation des écarts que le recoupement révèle. La saisie manuelle est le coût visible ; la reprise du rapprochement est le coût invisible qui le double.
Trois sources de données, trois formats, un seul tableur de rapprochement
Le tableur de rapprochement de juillet s'appuie sur trois sources de données distinctes, chacune introduisant sa propre friction de saisie manuelle :
Source 1 : Données du système de paie STP. Pour la majorité des employés, le système de paie détient les chiffres corrects cumulés depuis le début de l'année — rémunérations brutes, retenue d'impôt, cotisations de retraite — mais ces chiffres existent dans le logiciel de paie, pas dans un format que le tableur de rapprochement peut consommer directement. Exporter un rapport de registre de paie en CSV est la première étape. Faire correspondre chaque ligne de ce CSV au relevé PAYG correspondant — par nom d'employé ou TFN — est la deuxième étape. La deuxième étape est manuelle, sauf si chaque relevé a déjà été extrait dans un format ligne-et-colonne correspondant. Les données existent ; la connexion entre la ligne CSV de la paie et le PDF du relevé n'existe pas — et établir cette connexion, c'est de la saisie.
Source 2 : Relevés de paiement avant STP. Les employés qui ont travaillé une partie de l'exercice financier avant que l'entreprise ne passe à STP — ou dont l'employeur a changé de fournisseur de paie en cours d'année, laissant la période précédant la transition hors du champ de déclaration STP — disposent d'un relevé de paiement PAYG traditionnel pour les mois avant STP. Ces relevés n'existent que sous forme de PDF générés par l'ancien logiciel de paie ou de copies numérisées de certificats imprimés. Ils n'ont aucune ligne correspondante dans les données STP actuelles, le tableur de rapprochement doit donc les inclure comme entrées indépendantes. Chaque champ de chaque relevé avant STP — ABN, TFN, brut, retenue d'impôt, RFBA, RESC, montants forfaitaires — doit être ressaisi car aucun extrait électronique n'existe.
Source 3 : Relevés de paiement de fournisseurs tiers. Les sous-traitants rémunérés dans le cadre d'une convention de retenue à la source volontaire, les employés d'entités liées qui partagent l'administration de la paie mais opèrent sous des ABN distincts, et les travailleurs ayant reçu des paiements d'une entreprise de travail temporaire qui a émis son propre relevé PAYG — ces certificats arrivent dans la boîte de réception de la paie sous forme de pièces jointes PDF ou de courrier physique. Chacun est un document unique avec 15 à 20 champs qui doivent être extraits et ajoutés au tableur de rapprochement. Contrairement aux données du système de paie, il n'y a pas d'export CSV, pas d'enregistrement STP, pas de contrepartie électronique. Le seul chemin de ce PDF vers le tableur passe par un clavier. C'est également le scénario rencontré par les équipes de paie britanniques qui traitent 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 fondamental d'extraction de données d'un certificat papier ou PDF vers un tableur de rapprochement reste identique.
Les coûts que personne ne comptabilise : les demandes de l'ATO, les frictions d'audit et le 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 en 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 de revenus de chaque employé aux données PAYG déclarées par l'employeur. L'Inspecteur général de la fiscalité 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 inversé dans le TFN (employé 123 456 789 saisi comme 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 de la paie doit retrouver le formulaire de déclaration TFN d'origine 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 relevés saisis manuellement, avec un taux d'erreur prudent de 1 % pour le responsable de la paie : au moins une par an — et souvent plus, car la fatigue s'accumule lors d'une session de saisie de huit heures.
Frictions lors d'un audit externe
Lorsque l'auditeur externe sélectionne 20 employés pour un contrôle approfondi des dépenses de paie, il doit retracer les chiffres du relevé PAYG de chaque employé jusqu'au système de paie, au relevé bancaire attestant le paiement et au BAS trimestriel. Si les relevés n'existent que sous forme de PDF non extraits et que le tableur de rapprochement a été construit par saisie manuelle, l'auditeur ne peut pas vérifier indépendamment l'exactitude de l'extraction sans ressaisir lui-même un échantillon. Cela prolonge le calendrier de l'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 qu'elles sont correctes sans répéter le processus manuel. Un tableur unique généré par extraction automatisée fournit en revanche à l'auditeur une source traçable qui peut être comparée aux PDF d'origine sans ressaisie.
Afflux de demandes des employés pendant la période fiscale
Les Australiens peuvent déposer leur déclaration de revenus à partir du 1er juillet. Dès qu'un employé se connecte à myGov et consulte son revenu déclaré, tout écart entre ce qui apparaît dans les données pré-remplies de l'ATO et ce qu'il attend — sur la base de son bulletin de paie final, de sa compréhension de son salaire ou d'un relevé de l'année précédente — génère un appel ou un courriel au service de la paie. Au cours des 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 des relevés. Chaque demande nécessite de consulter le relevé d'origine, le registre de paie et le bulletin de paie final de l'employé pour expliquer l'écart — qui n'en est souvent pas un, mais résulte d'une différence de calendrier (une prime de juin versée en juillet, un dispositif de sacrifice salarial que l'employé a oublié, un avantage en nature déclarable dont l'employé ignorait qu'il était déclarable). Si le tableur de rapprochement a été construit manuellement, le responsable de la paie examine sa propre saisie pour répondre à la question — sans pouvoir confirmer si le chiffre que voit l'employé est correct ou s'il s'agit d'une erreur de transcription, sans revérifier le PDF d'origine.
Ce que la transition vers STP était censée corriger — et ce qu'elle a laissé derrière
Single Touch Payroll a été introduit avec la promesse d'éliminer les relevés de paiement PAYG. Pour la plupart des employés standard chez la plupart des employeurs, c'est réussi : une fois que l'employeur finalise les données STP avant le 14 juillet, l'employé accède à son revenu déclaré via myGov et aucun relevé papier ou PDF n'est nécessaire. L'ATO reçoit les données directement à chaque paie ; la déclaration de finalisation de fin d'année le confirme.
Mais la promesse STP échoue dans trois scénarios spécifiques qui affectent collectivement des milliers d'équipes de paie australiennes chaque juillet :
Premièrement, la période avant STP. Tout employeur qui est passé à STP en cours d'année financière — ou qui a changé de logiciel de paie et ne peut pas déclarer la période antérieure à la migration via le canal STP du nouveau système — doit toujours fournir des relevés de paiement PAYG traditionnels pour la période avant 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 de la paie en juillet 2026 doit rapprocher l'année financière 2023-24 (parce qu'un ancien employé a soulevé une question sur son avis d'imposition 2024), ces relevés avant 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 échéance de finalisation STP distincte au 30 septembre — deux mois et demi après l'échéance standard des employés. De nombreux employeurs choisissent d'émettre à ces bénéficiaires un relevé de paiement 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 de tiers. Les entreprises 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 d'équivalent STP dans les déclarations de l'employeur. Et chaque champ de chacun d'eux — ABN, TFN, rémunérations brutes, retenue d'impôt — 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 de paiement 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 % — parce que 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 qui a modernisé les déclarations fiscales des employeurs : l'extraction de relevés PAYG en Australie reflète l'extraction P60 au Royaume-Uni — les deux rapprochent les déclarations numériques modernes avec 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'elles sont enregistrées dans votre système de paie. Le relevé de paiement PAYG vous donne les données telles qu'elles sont 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 est conçu pour détecter. Un ajustement manuel de paie saisi directement dans le système de paie après le dernier cycle de paie, un bonus payé en juin mais traité dans le cycle de paie de juillet (qui appartient à l'exercice financier suivant), ou un dispositif de sacrifice salarial incorrectement codé comme cotisation de retraite obligatoire standard plutôt que RESC — tout cela crée des écarts entre le CSV et le relevé. Le CSV vous indique ce que le système de paie pense avoir payé ; le relevé vous indique ce qui a été déclaré à l'employé et à l'ATO comme payé. Le rapprochement exige 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 sauter complètement l'étape de rapprochement manuel ?
Non. La finalisation STP confirme que les données que vous avez 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 quoi qu'il arrive vos données STP aux déclarations de revenus des employés. Si la déclaration de revenus 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 à 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 transmis 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 — saisie de 15 à 20 champs, y compris ABN, TFN, rémunérations brutes, retenue d'impôt, RFBA, RESC, indemnités et montants forfaitaires, avec une vérification croisée par rapport au 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 nécessaire pour traiter les écarts découverts pendant la saisie. L'extraction automatisée — téléversement des 100 relevés en un lot et réception d'un tableur consolidé unique — 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 à consacrer.
Comment les relevés papier d'avant STP datant de plusieurs années affectent-ils le rapprochement actuel ?
Lors d'un audit ou d'un examen de l'ATO portant sur une année d'imposition 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 d'origine pour l'année examiné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 (une version de bureau de MYOB retirée en 2020, par exemple), le seul enregistrement accessible est le PDF scanné ou la copie imprimée. Lorsque l'auditeur demande un tableur de tous les relevés émis pour cette année, l'équipe de paie doit choisir : ressaisir chaque champ de chaque relevé scanné, ou les extraire des scans dans un tableur. Plus l'année d'imposition est ancienne, plus la probabilité que les données de paie d'origine soient inaccessibles est élevée — et plus l'extraction automatisée devient précieuse comme seule voie entre un classeur de papier et un tableur que l'auditeur peut examiner.
Qu'en est-il des entrepreneurs rémunérés dans le cadre d'une convention de retenue à la source volontaire — ont-ils aussi besoin d'un relevé PAYG ?
Oui. Si vous avez conclu une convention de retenue à la source volontaire PAYG avec un entrepreneur, vous devez lui émettre 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 : rémunérations brutes et retenue d'impôt. Ces relevés ne transitent pas par le canal STP habituel. 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 conventions de retenue à la source volontaires, cela représente 15 relevés supplémentaires à traiter en juillet, chacun avec sa propre exigence d'extraction.