Depuis le 1er janvier 2026, le dépôt des certificats de retenue à la source passe obligatoirement par la plateforme TEJ, pour toutes les entreprises tunisiennes. Deux voies existent : la saisie directe, tenable pour quelques certificats par mois, et le dépôt d'un fichier XML, qui devient la seule voie praticable dès que le volume monte.
Ce guide décrit l'obligation, la structure du fichier, et les causes de rejet — parce que le message d'erreur de la plateforme est presque toujours moins utile que le problème lui-même.
Qui est concerné, et dans quel délai
Toute entreprise qui pratique une retenue à la source est adhérente de la plateforme et doit y déposer ses certificats. Le délai est fixé à la fin du mois qui suit le mois du paiement : une opération payée en juillet 2026 doit avoir son certificat au plus tard le 31 août 2026.
Le rythme est donc mensuel, ce qui a une conséquence pratique sous-estimée : un processus qui demande une reprise manuelle casse douze fois par an, pas une.
La structure du fichier, en bref
Le format est défini par le cahier des charges CCT-RS-V2 et trois schémas XSD publiés par l'administration. L'élément racine est DeclarationsRS, et il contient :
| Élément | Rôle |
|---|---|
Declarant | Le matricule fiscal du déposant |
ReferenceDeclaration | Acte de dépôt, année et mois |
AjouterCertificats | Les certificats ajoutés, chacun avec son bénéficiaire et ses opérations |
ModifierCertificats | Les corrections d'un dépôt antérieur |
AnnulerCertificats | Les annulations |
Chaque Certificat porte un bénéficiaire — identifié par exactement un parmi matricule fiscal, CIN, passeport ou carte de séjour — une date de paiement, une référence propre au déclarant, et une ou plusieurs opérations.
Chaque Operation porte les montants (HT, TVA, TTC, retenue, net servi), le taux de retenue, et le code d'opération choisi parmi les 36 codes de la nomenclature (RS1_000001, RS2_000003, etc.).
Les quatre causes de rejet
1. Les montants avec une virgule
C'est la première, et de loin. Le schéma type les montants en entiers arrondis en millimes. Le dinar comptant trois décimales, un montant de 1 234,500 DT s'écrit :
<MontantHT>1234500</MontantHT>Or un tableur enregistre ce même montant comme 1234.5. Exporté tel quel, le point décimal fait refuser le dépôt entier. C'est contre-intuitif — on écrit un montant, on s'attend à une virgule — et c'est la raison pour laquelle tant de premiers dépôts échouent.
2. Le matricule fiscal mal formé
Le format est strict : sept chiffres suivis d'une lettre majuscule, par exemple 1234567A. Cela vaut pour le déclarant comme pour chaque bénéficiaire identifié par matricule.
Un matricule tronqué à six chiffres, ou dont la lettre est passée en minuscule au fil d'un copier-coller, ne se voit pas dans un export de plusieurs centaines de lignes.
3. Les références en double
La référence du certificat chez le déclarant (Ref_certif_chez_declarant) doit être unique dans le dépôt. Deux lignes qui la partagent font rejeter l'ensemble.
Le cas typique n'est pas une faute de saisie : c'est un compteur remis à zéro en début d'exercice, ou deux exports concaténés qui repartent chacun de 1.
4. L'arithmétique
Le net servi doit égaler exactement le TTC moins la retenue :
MontantNetServi = MontantTTC − MontantRS
Un écart d'un seul millime suffit à faire échouer le contrôle, et l'arrondi en produit facilement. Le rapport entre HT, TVA et TTC mérite la même vérification, même s'il tolère davantage.
Vérifier avant de déposer
La difficulté n'est pas de comprendre ces règles : c'est de les vérifier sur un fichier de plusieurs centaines de certificats, quand la plateforme refuse l'ensemble sans dire lequel est en cause.
Nous avons publié un validateur XML pour la retenue à la source qui fait exactement cela : il lit le fichier dans votre navigateur, applique les règles ci-dessus et nomme le certificat et le champ. Rien n'est envoyé — un fichier qui liste chaque bénéficiaire et chaque montant payé n'est pas une donnée à confier à un tiers pour une vérification de syntaxe.
Pour la génération du fichier depuis vos propres écritures, le tutoriel technique détaille la construction du XML et les contrôles à placer en amont.
Ce qu'il faut retenir
L'obligation est mensuelle et sans exception depuis janvier 2026. Le format est documenté et stable ; ce qui casse, ce n'est presque jamais la compréhension de la règle, c'est le chemin entre votre comptabilité et le fichier — un export, un tableur, une reprise manuelle.
Un processus qui exige cette reprise chaque mois finira par échouer un mois où personne n'a le temps. Le contrôle appartient en amont du dépôt, pas après le refus.
Sources : cahier des charges CCT-RS-V2 et schémas XSD publiés sur jibaya.tn.