writing/blog/2026/08
BlogAug 5, 2026·6 min read

Withholding tax and the TEJ platform: a guide to the XML file

Since 1 January 2026 TEJ is mandatory for every Tunisian company. This guide covers the obligation, the deadlines, the structure of the CCT-RS-V2 XML file, and the four errors that get a deposit refused — one of which the spreadsheet produces every time.

Since 1 January 2026, filing withholding tax certificates goes through the TEJ platform for every Tunisian company. Two routes exist: direct entry, workable for a few certificates a month, and depositing an XML file, which becomes the only practical route once the volume rises.

This guide covers the obligation, the file structure, and the causes of rejection — because the platform's error message is almost always less useful than the problem itself.

Who is affected, and by when

Any company that applies withholding tax is a member of the platform and must file its certificates there. The deadline is the end of the month following the month of payment: an operation paid in July 2026 needs its certificate by 31 August 2026.

The rhythm is therefore monthly, which has an underestimated practical consequence: a process requiring manual rework breaks twelve times a year, not once.

The file structure, briefly

The format is defined by the CCT-RS-V2 specification and three XSD schemas published by the administration. The root element is DeclarationsRS, containing:

ElementRole
DeclarantThe filer's tax ID
ReferenceDeclarationDeposit act, year and month
AjouterCertificatsAdded certificates, each with beneficiary and operations
ModifierCertificatsCorrections to an earlier deposit
AnnulerCertificatsCancellations

Each Certificat carries a beneficiary — identified by exactly one of tax ID, CIN, passport or residence card — a payment date, a reference of the declarant's own, and one or more operations.

Each Operation carries the amounts (HT, VAT, TTC, withholding, net paid), the withholding rate, and an operation code from the 36-entry nomenclature (RS1_000001, RS2_000003, and so on).

The four causes of rejection

1. Amounts with a decimal point

This is the first by a wide margin. The schema types amounts as integers rounded to millimes. The dinar carrying three decimals, an amount of 1,234.500 TND is written:

<MontantHT>1234500</MontantHT>

A spreadsheet stores that same amount as 1234.5. Exported as is, the decimal point gets the whole deposit refused. It is counter-intuitive — you write an amount, you expect a decimal separator — and it is why so many first deposits fail.

2. A malformed tax ID

The format is strict: seven digits followed by a capital letter, e.g. 1234567A. This applies to the declarant and to every beneficiary identified by tax ID.

An ID truncated to six digits, or whose letter was lowercased in a copy-paste, is invisible in an export of several hundred rows.

3. Duplicate references

The declarant's certificate reference (Ref_certif_chez_declarant) must be unique within the deposit. Two rows sharing one gets the whole thing rejected.

The typical case is not a typo: it is a counter reset at the start of the year, or two exports concatenated, each restarting at 1.

4. The arithmetic

Net paid must equal exactly TTC minus the withholding:

MontantNetServi = MontantTTC − MontantRS

A single millime of drift is enough to fail the check, and rounding produces it easily. The relationship between HT, VAT and TTC deserves the same scrutiny, though it tolerates more.

Checking before you file

The difficulty is not understanding these rules: it is verifying them across a file of several hundred certificates, when the platform refuses the lot without saying which one is at fault.

We have published a withholding XML validator that does exactly this: it reads the file in your browser, applies the rules above, and names the certificate and the field. Nothing is sent — a file listing every beneficiary and every amount paid is not data to hand a third party for a syntax check.

For generating the file from your own entries, the technical tutorial covers building the XML and the checks to place upstream.

What to take away

The obligation is monthly and without exception since January 2026. The format is documented and stable; what breaks is almost never the understanding of the rule, it is the path between your accounts and the file — an export, a spreadsheet, a manual fix.

A process demanding that rework every month will eventually fail in a month when nobody has time. The check belongs upstream of the deposit, not after the refusal.

Sources: the CCT-RS-V2 specification and XSD schemas published on jibaya.tn.