Toute entreprise émirienne réalisant 50 millions d'AED de chiffre d'affaires ou plus a aujourd'hui la même ligne dans son calendrier de conformité : nommer un prestataire de services accrédité (ASP) avant le 30 octobre 2026, entrer en production le 1er janvier 2027.
Cette échéance est traitée comme si elle était le projet. Elle ne l'est pas. Nommer un ASP est une décision d'achat qu'un directeur financier boucle en trois réunions. Ce qui vient ensuite — amener votre ERP à émettre 51 champs correctement renseignés en XML PINT AE, pour chaque type de document et chaque contrepartie — est un projet d'intégration, et presque personne ne l'a chiffré.
Cet article traite de la seconde moitié. Nous ne vendons pas de logiciel de facturation électronique et nous ne sommes pas un ASP, ce qui nous permet précisément d'être francs sur l'endroit où s'arrête la responsabilité du fournisseur.
L'échéance n'est pas la date de mise en production
Le calendrier émirien actuel, après le report qui a décalé la date de nomination pour les grandes entreprises du 31 juillet au 30 octobre 2026 :
| Cohorte | Nomination de l'ASP avant | Mise en production |
|---|---|---|
| Pilote / volontaire | — | 1er juillet 2026 |
| Chiffre d'affaires de 50 M AED ou plus | 30 octobre 2026 | 1er janvier 2027 |
| Chiffre d'affaires inférieur à 50 M AED | 31 mars 2027 | 1er juillet 2027 |
| Entités gouvernementales | 31 mars 2027 | 1er octobre 2027 |
| Transactions intragroupe | — | transition jusqu'au 1er janvier 2029 |
Lisez les deux colonnes ensemble. Si vous nommez votre ASP le 30 octobre, il vous reste environ neuf semaines pour mapper, tester et rapprocher avant que la première facture obligatoire ne doive passer. Et chaque ASP émirien aura l'intégralité de sa clientèle grands comptes en onboarding dans cette même fenêtre de neuf semaines. Le travail d'ingénierie que vous n'aurez pas commencé en octobre, vous le ferez dans une file d'attente.
La phase pilote a ouvert le 1er juillet 2026 pour une raison. La participation volontaire n'est pas une case de conformité — c'est la seule période où vous pouvez échouer sans conséquence.
Ce que le modèle à cinq coins vous demande réellement
Les EAU ont retenu un modèle décentralisé — le modèle Peppol à cinq coins, ou DCTCE. Il mérite d'être compris car il détermine exactement où se situe votre responsabilité.
- C1 — l'émetteur. Vous. Votre ERP, votre système de facturation ou votre caisse produit les données.
- C2 — l'ASP de l'émetteur. Valide votre document contre PINT AE, le signe, le dépose sur le réseau.
- C3 — l'ASP du destinataire. Reçoit le document, le valide, le délivre à l'acheteur.
- C4 — le destinataire. Le système de votre client.
- C5 — la plateforme de facturation de la FTA. Reçoit les données fiscales en parallèle, comme référentiel de l'autorité.
Les ASP possèdent C2 et C3. C'est la couche réseau : transport, validation du schéma, signature, consultation de l'annuaire Peppol, protocole d'accusés de réception. C'est du vrai travail et cela vaut d'être payé.
Mais remarquez ce que personne en C2 ne peut faire à votre place : décider de ce que vos données signifient. L'ASP vérifie que le champ cbc:TaxExclusiveAmount est un décimal et que le code de catégorie fiscale figure parmi les valeurs autorisées. Il ne peut pas savoir que votre ERP comptabilise depuis six ans les exportations à taux zéro sous le même code fiscal que les services financiers exonérés. Il transmettra très volontiers une facture structurellement parfaite et factuellement fausse.
C'est exactement la leçon que les entreprises saoudiennes ont apprise à leurs dépens lors de la phase 2 de Fatoorah — nous l'avons documentée dans le guide ZATCA Fatoorah sur la facturation électronique, et le schéma d'échec se transpose directement.
Où l'ASP s'arrête et où vous commencez
Tracez la ligne honnêtement et le périmètre devient évident :
L'ASP prend en charge : la connectivité Peppol et les certificats, la validation du schéma PINT AE, la signature, la transmission vers C3 et C5, la remise des messages de retour, l'archivage au format attendu par le régulateur.
Vous prenez en charge : le sens de chaque champ avant qu'il ne quitte votre système. Les données de référence. La logique de détermination fiscale. Le choix du type de document. L'identification des contreparties. Le rapprochement de ce qui revient. Et la gestion des exceptions quand un document est rejeté à 16 h le dernier jour du trimestre.
Cette seconde liste est un projet ERP et intégration. Ce n'est pas un achat de licence, et cela ne se comprime pas.
Cinq endroits où les données ERP cassent
Ce sont les défaillances que nous rencontrons de façon répétée sur les intégrations de facturation électronique dans le Golfe. Aucune n'est exotique.
1. Le TIN n'est pas le TRN
La participation au réseau est indexée sur un numéro d'identification fiscale (TIN), et l'identifiant inscrit dans le document n'est pas simplement votre numéro de TVA. Pour une entreprise assujettie, le TIN est dérivé des 10 premiers chiffres du TRN à 15 chiffres, et l'identifiant de point d'accès Peppol est ce TIN sous le code de schéma émirien 0235.
// Dériver l'identifiant de participant émirien à partir d'un TRN à 15 chiffres.
const UAE_SCHEME = "0235";
export function participantIdFromTrn(trn: string): string {
const digits = trn.replace(/\D/g, "");
if (digits.length !== 15) {
throw new Error(`Expected a 15-digit TRN, received ${digits.length} digits`);
}
return `${UAE_SCHEME}:${digits.slice(0, 10)}`;
}Trois choses tournent mal ici en pratique. Votre référentiel clients stocke les TRN avec des espaces, des tirets et parfois une annotation en fin de champ. Chaque membre d'un groupe TVA a besoin de son propre TIN, alors que votre ERP ne détient probablement qu'un numéro pour l'ensemble du groupe. Et les entreprises non assujetties ont malgré tout besoin d'un TIN — ce qui signifie qu'une partie de votre référentiel de contreparties n'a aucun identifiant exploitable et que quelqu'un doit aller les collecter.
Commencez cette collecte maintenant. C'est l'élément au délai le plus long de tout le programme, et il ne nécessite aucun contrat ASP pour démarrer.
2. Catégories fiscales contre plan comptable
PINT AE attend une catégorie fiscale précise sur chaque ligne. Taux standard, taux zéro, exonéré et hors champ sont quatre choses différentes pour la FTA et, dans la plupart des ERP que nous ouvrons, deux ou trois choses seulement pour l'entreprise. Exportations, livraisons en zones désignées et services financiers exonérés finissent tous regroupés sous le code choisi par l'intégrateur d'origine en 2019.
Les exclusions de périmètre du régulateur rendent le point encore plus tranchant : activités gouvernementales souveraines, holdings d'investissement passives, billets d'avion et services financiers exonérés de TVA sont hors mandat. Si votre système ne sait pas les distinguer des livraisons ordinaires, il ne peut pas décider quoi transmettre.
3. Choisir le bon type de document
Quatre documents électroniques sont en jeu — la facture fiscale, l'avoir fiscal, la facture commerciale pour les opérations hors champ de la TVA, et l'avoir commercial — auxquels s'ajoutent les variantes d'autofacturation lorsqu'un accord contractuel prévoit que le client émette le document. Le jeu de champs obligatoires diffère : 51 champs pour la facture fiscale électronique standard, 49 pour la facture commerciale électronique.
La plupart des ERP n'ont qu'un seul objet « facture » et un champ de type en texte libre renseigné par des humains. Cela doit devenir une logique déterministe avant la mise en production, car un document envoyé sous le mauvais type échoue à la validation en C2 et revient sur le bureau de quelqu'un.
4. Unités, quantités et arrondis
Peppol exige des codes d'unité UN/ECE. « Pièce », « unité », « pcs » et une chaîne vide ne sont pas des codes d'unité. Les arrondis au niveau ligne doivent également se rapprocher des totaux d'en-tête dans la tolérance admise ; si votre ERP arrondit ligne par ligne pendant que votre moteur fiscal arrondit au récapitulatif, vous produirez des documents incohérents de quelques fils — et rejetés pour cela.
5. Acomptes et références d'avoir
Une facture électronique doit être émise à la réception d'un acompte, et la facture finale ne doit alors porter que le solde restant. Les avoirs doivent référencer l'identifiant du document d'origine. Les deux exigent un modèle de liaison entre documents que beaucoup de systèmes de facturation simulent avec un champ commentaire.
Le flux retour que personne ne budgète
Voici la partie qui transforme un projet de conformité en problème d'exploitation : la facturation électronique est bidirectionnelle.
Votre ASP vous renverra des accusés de réception, des résultats de validation et un statut de livraison pour chaque document. Côté achats, les factures de vos fournisseurs arriveront en C4 sous forme de XML structuré plutôt que de PDF dans une boîte mail. Ces deux flux doivent atterrir quelque part.
Concrètement, avant le 1er janvier 2027, vous devez pouvoir répondre à :
- Quelles factures émises ces dernières 24 heures n'ont pas été confirmées comme livrées ?
- Lesquelles ont été rejetées, avec quelle erreur, et qui est responsable de la correction ?
- Le nombre de documents acceptés en C5 se rapproche-t-il du chiffre d'affaires comptabilisé sur la période ?
- Que devient une facture fournisseur entrante, structurellement valide mais commercialement fausse ?
Si la réponse honnête est « le portail de l'ASP a un écran pour ça », vous venez de faire d'un tableau de bord fournisseur un contrôle de votre clôture comptable. La plupart des directions financières finissent par vouloir rapatrier cet état dans leur propre couche de reporting, à côté du grand livre — une intégration simple à construire, et pénible à rétrofiter sous la pression de l'échéance. Nous avons écrit sur les raisons pour lesquelles la couche de reporting au-dessus de vos systèmes compte souvent plus que les systèmes eux-mêmes dans le piège de l'ERP.
Que faire avant le 30 octobre
Une séquence réaliste pour une entreprise de la cohorte janvier 2027, à partir de maintenant :
- Extrayez votre référentiel de contreparties et notez-le. Combien d'enregistrements portent un TRN valide à 15 chiffres ? Combien de membres de groupes TVA sont regroupés sous un seul numéro ? Ce pourcentage est votre véritable indicateur de préparation, et vous pouvez le mesurer cette semaine sans parler à un seul fournisseur.
- Inventoriez vos types de documents. Chaque canal par lequel votre organisation émet quelque chose que le client traite comme une facture — l'ERP, la plateforme e-commerce, la caisse, le tableur de l'équipe projets. Chacun est soit un point d'intégration, soit un processus à supprimer.
- Mappez la détermination fiscale vers les catégories PINT AE. Faites-le sous forme de table de correspondance écrite et validée par la fiscalité, pas comme un écran de paramétrage rempli par la DSI.
- Choisissez ensuite votre ASP. Muni de ce mapping, vous pouvez poser aux fournisseurs les questions qui les départagent : comment ils remontent les erreurs de validation vers vos systèmes plutôt que vers un portail, s'ils exposent un bac à sable réellement testable, et à quoi ressemble leur API de récupération de statut.
- Faites passer de vrais documents dans le pilote. Pas trois échantillons propres. Un mois de volume de production, avoirs, acomptes et livraisons à l'export compris.
Les étapes 1 à 3 ne requièrent aucun contrat ASP signé. C'est tout l'enjeu. Les entreprises qui souffriront en janvier sont celles qui traitent la date d'octobre comme le début du travail plutôt que comme son milieu.
En résumé
Le mandat émirien n'est pas techniquement difficile. C'est un document XML structuré sur un réseau bien documenté, avec une couche fournisseurs compétente qui existe déjà. Ce qui en fait un projet, c'est qu'il impose une remise à plat de la qualité des données que votre organisation repousse depuis des années — et qu'il l'impose à une date fixée par quelqu'un d'autre.
Un ASP vous rendra connecté. Il ne vous rendra pas juste.
Vous cherchez à cadrer ce que votre côté de la ligne implique réellement ? Nous ne sommes pas un ASP et nous ne vous vendons pas de logiciel de facturation. Ce que nous faisons, c'est la couche d'intégration et de reporting au-dessus de vos systèmes existants — le mapping ERP, les données de contreparties, le rapprochement entre ce que vous avez envoyé et ce que l'autorité a reçu. Si vous voulez une lecture technique franche de l'état de préparation de vos systèmes avant de signer avec un ASP, contactez-nous et nous cadrons cela avec vous.