Facture électronique Türkiye : intégration ERP

Pour opérer en Türkiye, un logiciel ERP doit en règle générale prendre en charge e-Fatura et e-Arşiv — et e-İrsaliye dans certains secteurs — auprès de l'Administration des recettes (GİB), le plus souvent par un intégrateur privé. L'ERP crée le document au format UBL-TR, le vendeur le signe avec le sceau financier (mali mühür), l'intégrateur le fait valider par la GİB, et le contribuable reste responsable de sa conservation tout au long.

Que doit supporter un ERP pour opérer en Türkiye ?

La Türkiye fait fonctionner la facture électronique comme un système de validation : le document est créé par le vendeur, transmis par un canal autorisé, validé par l'Administration des recettes, et n'est juridiquement efficace qu'à ce moment. Pour une entreprise qui pilote son activité sur un ERP, cela a des conséquences à quatre points du système :

• Création du document. L'ERP — ou un moteur connecté — doit générer les factures dans la structure UBL-TR requise, avec les codes, identifiants de parties et données de ligne exigés par le schéma, pas une mise en page imprimée reformée en XML.


• Signature numérique. Les documents sont signés avec le sceau financier délivré au contribuable ; l'étape de signature doit s'insérer dans le flux, avec une gestion des clés qui corresponde aux dispositions de garde du sceau.


• Échange bidirectionnel. Dans le régime e-Fatura, le statut d'enregistrement du contreparti décide du type de document, et les documents entrants — factures reçues, réponses, annulations là où elles sont autorisées — doivent revenir dans l'ERP avec leurs identifiants d'origine, sinon la comptabilité perd le lien entre le système et l'enregistrement officiel.


• Archivage et recherche. Les documents émis et reçus doivent être retrouvables pendant la durée de conservation légale ; que ce soit l'intégrateur, l'ERP ou les deux qui les stockent est une décision à prendre avant la mise en service, pas après une demande d'audit.

Un point structurel qui surprend les équipes novices dans la validation : la facture n'est pas terminée quand l'ERP l'imprime. Elle l'est quand l'échange est achevé et que les réponses sont revenues — ce qui veut dire que la notion d'état d'une facture dans l'ERP doit dépasser « créée » et « envoyée » pour inclure acceptée, rejetée et corrigée. Les entreprises qui passent là-dessus finissent par rapprocher à la main, en fin de mois, deux versions de la vérité — leur grand livre et l'enregistrement officiel —, ce qui est exactement le travail que la facture électronique devait supprimer.

Un autre point concerne le timing. Dans un système de validation, les documents ne sont pas asynchrones au sens d'une pièce jointe d'e-mail : un rejet arrive pendant que l'équipe travaille encore, et la correction qu'il exige touche le plus souvent les données maîtresses plutôt que le document lui-même. Concevoir le flux pour que la personne capable de corriger la cause soit avertie sur le moment, plutôt que de le découvrir dans un rapport mensuel, distingue un système qui tourne d'un système qu'il faut surveiller.

e-Fatura, e-Arşiv, e-İrsaliye expliqués

Qui relève de quelle obligation est défini par les règles et circulaires de la GİB, qui changent ; les seuils et désignations de secteurs sont fixés par les autorités et évoluent avec elles. La formulation correcte pour un acheteur est d'ordre procédural : vérifiez votre statut d'enregistrement auprès de votre comptable ou conseil fiscal au regard des règles en vigueur avant de concevoir l'intégration, pas au regard d'un article — y compris celui-ci.

Intégration : quelles options ?

Le modèle d'intégrateur mérite une clarification, car il est souvent mal compris : faire appel à un intégrateur privé ne transfère pas les obligations du contribuable. L'intégrateur fournit le canal technique, le service de transmission et le service de stockage ; la responsabilité juridique des documents — leur exactitude, leur émission et leur conservation au titre du Livre de procédures fiscales — reste au contribuable. Quand la page commerciale d'un intégrateur donne à penser que le problème de conformité est résolu pour vous, relisez cette phrase.

En pratique, cette répartition se voit en petits détails concrets. Si un document est rejeté parce que l'identifiant fiscal du client était erroné dans vos données maîtresses, le système de l'intégrateur a parfaitement fonctionné et l'erreur est à vous de corriger. Si une facture est émise avec le mauvais code de taxe, aucun contrôle de canal ne vous sauvera. L'intégrateur est une infrastructure ; la qualité des données qui y circule est une discipline interne, et l'ERP est l'endroit où cette discipline est intégrée ou laissée à l'habitude. Les acheteurs qui comparent des intégrateurs devraient donc consacrer moins de temps à la liste de fonctionnalités et davantage aux questions qui révèlent qui fait quoi quand quelque chose échoue : qui alerte qui, sous quel format, et à quelle vitesse un document corrigé peut être retransmis.

Étapes de mise en œuvre et tests

Une séquence praticable pour une intégration côté ERP :

1. Fixer le périmètre des obligations. Quels documents s'appliquent à l'entreprise — e-Fatura, e-Arşiv, e-İrsaliye, e-Defter — confirmé au regard des règles en vigueur avec le comptable de la société.


2. Choisir le canal. La plupart des entreprises sélectionnent un intégrateur privé ; les questions de sélection — qualité de l'API, disponibilité d'un bac à sable, langue et horaires du support, traitement des mises à jour du schéma, références — méritent un exercice de présélection à part entière.


3. Mapper les données maîtresses. Clients et leurs identifiants fiscaux, articles, unités, devises et codes de taxe doivent correspondre aux attentes du schéma ; les écarts ici sont la première source d'erreurs ultérieures.


4. Concevoir le flux documentaire. Qui crée quoi, quand le sceau est appliqué, ce qui se passe en cas d'échec, comment les documents sortants et entrants sont appariés aux enregistrements de l'ERP, et comment les corrections sont émises.


5. Utiliser l'environnement de test. Les deux côtés proposent un environnement de test ; faites-y passer chaque type de document, chaque chemin d'erreur et chaque scénario de correction avant la mise en service, avec le même mappage qu'en production.


6. Traiter l'erreur comme un processus. Les rejets arrivent après la transmission ; quelqu'un doit les voir, en comprendre la cause et corriger les données sous-jacentes — une boîte d'alertes sans responsable, c'est ainsi qu'une entreprise en vient à émettre ses documents en retard.


7. Planifier l'archivage et l'accès. Où les documents sont stockés, qui peut les retrouver, et comment une demande d'auditeur s'honore dans le délai de conservation.

Points pour les groupes à tête étrangère et les non-résidents à poser à un conseil

Pour une société à actionnaire étranger, ou qui entre en Türkiye sans une équipe finance locale complète, plusieurs questions relèvent d'un conseil fiscal plutôt que du projet informatique — les réponses déterminent la conception, posez-les donc avant le démarrage de l'intégration, pas après :

• Voie d'enregistrement. Comment la société devient-elle soumise aux obligations, qui signe les demandes, et quel représentant est reconnu — questions d'immatriculation fiscale, pas de logiciel.


• Dispositions sur le sceau. Comment le sceau financier est obtenu pour la société et comment sa garde est organisée quand les signataires se trouvent hors de Türkiye.


• Représentants et signatures. Qui est autorisé à signer quels documents, et ce que l'ERP doit enregistrer sur le signataire pour la piste d'audit.


• Position de la filiale étrangère. Si des exigences supplémentaires s'appliquent aux sociétés à actionnariat non résident, et comment la facturation intra-groupe est traitée.

Il vaut aussi de décider qui porte la relation avec le conseil. Dans les sociétés où la finance et l'IT supposent chacune que l'autre a posé la question, ces points parviennent tard à l'intégration — d'ordinaire dans les semaines précédant la mise en service, quand le flux documentaire est déjà figé. Un responsable nommé de chaque côté, et une réunion conjointe avant l'étape 3 de la mise en œuvre, prévient l'essentiel de cela.

Problèmes courants

Les échecs qui reviennent le plus souvent dans ce type de projet, et ce que chacun désigne en général :

• Rejets à la validation. Presque toujours un problème de mappage : un code de taxe, un format d'identifiant ou un champ de ligne qui ne correspond pas à l'attente du schéma. Corrigez les données maîtresses, pas la logique de nouvelle tentative.


• Numérotation en doublon. Des séquences de numéros générées par plus d'un système, ou régénérées après un incident ; la numérotation doit avoir exactement un responsable et une règle de reprise documentée.


• Erreurs de statut du contreparti. Émission du mauvais type de document parce que le statut d'enregistrement du client a été mis en cache ou supposé ; interrogez le statut selon les règles de l'intégrateur, pas selon la mémoire.


• Documents entrants perdus. Des documents reçus mais jamais reportés dans l'ERP, si bien que les comptes fournisseurs travaillent à partir d'un écran séparé ; le sens de l'échange fait partie de l'intégration, pas d'une option.


• Mises à jour de schéma manquées. La structure évolue dans le temps ; qui en est responsable doit savoir quand elle a changé et ce que le changement a fait au mappage.


• Test sacrifié sous la pression de l'échéance. Chacun de ces points coûte moins cher dans l'environnement de test ; la pression de la mise en service est l'endroit où ils deviennent des incidents.

Questions fréquentes

Quelle est la différence entre e-Fatura et e-Arşiv ?

e-Fatura couvre les factures échangées entre contribuables enregistrés pour le régime, sous forme de documents structurés entre parties enregistrées ; e-Arşiv couvre les factures dont l'acheteur est hors de ce régime — vente au détail et B2C, et une partie du B2B —, que l'acheteur reçoit en général en PDF généré par la même chaîne officielle. Lequel s'applique à une facture donnée découle du statut d'enregistrement du contreparti, c'est pourquoi l'intégration l'interroge plutôt que de le supposer.

Ai-je besoin d'un intégrateur privé ?

Pour la plupart des entreprises, oui — c'est la voie commune, et le canal direct est décrit comme complexe et rare. Un intégrateur privé fournit le canal technique vers la GİB et le service de stockage ; vos obligations de contribuable restent les vôtres. Choisir l'un d'eux est un exercice d'achat : qualité de l'API, bac à sable, support et traitement des mises à jour du schéma décident de l'expérience quotidienne plus que la marque.

Qu'est-ce que le sceau financier (mali mühür) ?

C'est l'identifiant de signature numérique du contribuable, utilisé pour signer les documents électroniques avant leur transmission ; la garde et qui peut s'en servir sont des questions pratiques à trancher en interne. Pour les équipes dont les signataires se trouvent hors de Türkiye, l'organisation de la détention et de l'application du sceau figure parmi les premiers points à poser à un conseil fiscal.

Tout logiciel ERP peut-il émettre des factures électroniques turques ?

Non. L'ERP doit générer la structure UBL-TR requise avec des données maîtresses exactes, ou être connecté à un moteur ou un intégrateur qui le fait ; une mise en page de facture standard ne suffit pas. La plupart des entreprises connectent donc plutôt qu'elles ne reconstruisent — la question à poser à un éditeur est : quels intégrateurs son connecteur prend-il en charge, que mappe-t-il, et où se trouve sa documentation ?

Comment tester avant la mise en service ?

Par les environnements de test proposés côté intégrateur et côté officiel, avec le même mappage de données maîtresses qu'en production : chaque type de document, chaque chemin de rejet, chaque correction et chaque document entrant reporté dans l'ERP. Traitez aussi le test comme une répétition du processus d'erreur — quelqu'un doit recevoir, diagnostiquer et corriger un rejet, pas seulement voir une coche verte.

Qui stocke les factures ?

Le contribuable reste responsable de la conservation au titre du Livre de procédures fiscales ; l'intégrateur fourit en général le stockage technique, et beaucoup d'entreprises gardent aussi les documents dans leur ERP pour l'usage quotidien. Ce qui compte, c'est de décider du dispositif avant la mise en service, de savoir qui peut produire quel document dans le délai de conservation, et de tester cette restitution avant qu'un auditeur ne la demande.

Sources et normes

• GİB — Gelir İdaresi Başkanlığı — l'Administration des recettes publie les règles, circulaires et documentations techniques pour e-Fatura, e-Arşiv, e-İrsaliye et e-Defter ; les versions en vigueur là-bas priment sur tout ce qui est résumé sur cette page.
• Statut d'enregistrement, seuils, désignations de secteurs et délais sont fixés par les autorités et changent ; vérifiez auprès de votre comptable ou conseil fiscal au regard des règles en vigueur. Rien sur cette page ne constitue un conseil fiscal, et aucune relation d'intégrateur, partenariat ou certification n'est revendiquée pour WorldwideTradeX.

Pages associées

Développement logiciel · Odoo ERP pour les entreprises de commerce · ERP sur mesure ou packagé · Audit et conseil IT · Demander un devis