dimanche 29 août 2010

La facture électronique vue par les comptables

Les questions de la facture électronique : les objectifs que l’entreprise peut se fixer, le cadre juridique en France, les contraintes techniques et les solutions (en interne ou recours à des plates-formes de dématérialisation).
LE CONTEXTE
À quoi sert une facture ?
La facture a plusieurs fonctions :
- elle matérialise la transaction commerciale ;
- elle est le support d’échanges d’information entre l’acheteur et le vendeur et au sein de l’organisation de l’acheteur ;
- elle est le support des écritures comptables clients et fournisseurs ;
- elle constitue une pièce justificative au regard de la collecte et de la déduction de TVA.
Quelques chiffres
Sur les 1,7 milliard de factures établies en France sur une année par les 2,4 millions d’entreprises, 4 % sont électroniques (environ 70 millions), et moins de 0,5 % sont traités en dématérialisation fiscale.
Il est prévu pour 2005 de 25 à 50 millions de factures électroniques supplémentaires, dont 50 % en dématérialisation fiscale.
Distinguer la « facture numérisée » et la « vraie » facture électronique
Une facture numérisée est une facture qui, au départ, est émise par le fournisseur sous forme papier (même si elle est imprimée à distance).
Elle fait l’objet chez le client d’une saisie, même si elle est éventuellement numérisée et même si elle fait l’objet de lecture automatique de documents (LAD).
Ce flux physique peut, le cas échéant, être doublé par un flux électronique pour alimenter le système informatique, mais la numérisation n’est que la copie électronique d’un document. L’archivage de l’original doit donc se faire sous forme papier.
La facture électronique, elle, est dès sa création sous forme électronique et arrive chez son destinataire sous forme d’image ou de données. En réalité, du point de vue technique, une facture dématérialisée peut être de deux types :
- la facture « texte » ou « image » (apparence similaire à une facture papier) qui est signée électroniquement ;
- la facture de données structurées (fichier informatique), qui sont directement intégrées dans le système informatique du destinataire. Les factures de données structurées sont assimilées aux factures EDI bien connues.
Cette dualité technique a été confirmée sur le plan juridique par le législateur (voir p. 17).
La facture électronique devra être archivée sous forme électronique (qui constitue l’original), quelle que soit sa forme, chez le client comme chez le fournisseur.
Remarque :
Un document perd sa qualité d’original dès l’instant où il ne se trouve plus sur son support premier. Ainsi, la numérisation qui est la première étape de l’archivage sous forme électronique de documents physiques (papier ou support microforme) n’est qu’une copie par rapport à l’original papier.

POURQUOI DÉMATÉRIALISER LES FACTURES ?
Les motivations des entreprises pour mettre en œuvre un projet de dématérialisation des factures peuvent être :
- d’améliorer les processus,
- d’optimiser le coût de traitement de la  facture,
- de partager l’information,
- d’éliminer le papier des process,
- d’optimiser la qualité de l’information,  notamment la traçabilité comptable.
Améliorer les processus
Les processus qui pourront être optimisés par une opération de dématérialisation répondent  à des attentes réciproques des clients et des fournisseurs :
- maîtrise des délais de paiement,
- visibilité du processus en interne et en externe,
- partage de l’information,
- automatisation des traitements,
- validation,
- réduction des appels et des relances,
- meilleure prévision de trésorerie.
Optimiser le coût de traitement de la facture
Le coût « standard » par facture reçue est, selon une étude d’Arthur D. Little (Deskom) de 2001, de 13,8 €, décomposés comme suit :
- réception : 0,9 €
- saisie/codification : 1,4 €
- validation : 5,4 €
- paiement : 2,8 €
- archivage : 1,5 €
- gestion des litiges : 1,8 €.
Le coût « standard » par facture émise, qui se situe dans une fourchette de 8 à 9,5 €, se compose des éléments suivants :
- préparation facturation et comptabilisation : 0,3 €
- envoi : 1,2 €
- rapprochement paiements : de 0,5 € à 2 €
- archivage : 0,8 €
- gestion des relances : 0,8 €
- gestion des litiges : 2,4 €
- coûts de trésorerie : 2,0 €.
Les plus gros postes de coûts interviennent ainsi dans les étapes postérieures :
- à la saisie ou codification des factures reçues ;
- à la préparation/comptabilisation des factures émises.
Améliorer la qualité et la sécurité de la facture
La qualité des données de la facture regroupe :
- la fiabilité des données,
- la validation mutuelle de la facture,
- la traçabilité comptable.
La sécurité peut être améliorée à chaque étape du cycle de vie de la facture :
- création,
- transports et traitements,
- conservation et archivage sécurisé,
- traçabilité.
Optimiser le partage de l’information
Un des objectifs de l’entreprise peut être d’obtenir un meilleur partage de l’information. La facture est le support d’une information qui circule :
en interne, entre les différents services. La dématérialisation :
- permet une gestion collaborative du traitement des factures,
- permet également de se libérer de l’obligation de proximité physique des acteurs,
- peut favoriser l’opportunité d’un redéploiement des ressources ;
en externe, avec les partenaires (au-delà des clients et des fournisseurs, les factors, les banques, les experts comptables, les commissaires aux comptes, la DGI...).
DÉFINIR LE PÉRIMÈTRE DU PROJET
Une démarche qui doit être progressive
Une démarche volontariste par rapport à un projet de dématérialisation des factures permet de fixer les priorités en la matière et, notamment, de procéder progressivement par type de flux, pour certains partenaires, par services, ce qui permet de garder la maîtrise de l’information et des processus. L’entreprise se trouvera donc, la plupart du temps, amenée à gérer des flux mixtes.
De plus, un projet de dématérialisation des factures, quels qu’en soient les contours et le périmètre, passe par la modification d’une série de processus de l’entreprise (par exemple, circuit d’autorisation de dépenses, procédures de contrôle interne). La couverture du périmètre choisi s’effectuera progressivement.
Quelles fonctions de la facture veut-on dématérialiser ?
* L’entreprise doit, dès l’origine, pour mener à bien le projet, définir ce qu’elle cherche à dématérialiser parmi les 3 fonctions suivantes de la facture :
- la fonction probatoire de la facture qui permet de faire la preuve des obligations de l’acheteur et du vendeur (par exemple, dans le cadre du recours à l’assurance-crédit) ;
- la fonction de pièce justificative dans le cadre du contrôle des comptabilités informatisées ;
- la fonction fiscale au regard de la TVA qui permet l’exercice du droit à déduction par l’acheteur et à l’administration d’effectuer les contrôles.
Le projet de l’entreprise peut être de dématérialiser l’ensemble de ces 3 fonctions ou bien de se limiter à une ou deux.
Rappelons que la facture a aussi une fonction de véhicule d’informations entre deux ou plusieurs utilisateurs.
* En outre, l’entreprise doit se demander si elle recherche, par la dématérialisation, la possibilité d’alimenter directement le système d’information comptable.
* En pratique, l’entreprise qui met en œuvre un projet de dématérialisation va être amenée, quel que soit le périmètre défini, à gérer un environnement mixte, compte tenu des contraintes de ses partenaires commerciaux.
LE CADRE JURIDIQUE ET FISCAL
Les entreprises disposent désormais du cadre légal, normatif et contractuel pour établir une véritable chaîne de confiance du traitement du document électronique.
Le contexte juridique et fiscal est le suivant :
* obligation de facturation (CGI art. 289-I-1) ;
* rédaction en double exemplaire (c. com. art. 441-3) ;
* obligation de conservation du double des factures émises (CGI art. 289-I-1) ;
* directive européenne du 20 décembre 2001. Notons qu’elle constitue un atout pour les groupes européens, puisqu’elle est déjà transposée dans un tiers des 25 pays européens et en cours de transposition dans un deuxième tiers ;
* transposition de la directive dans le droit français par :
- le décret 2003-632 du 7 juillet 2003, sur le stockage des factures (CGI, LPF, art. L. 102 C) ;
- le décret 2003-659 du 18 juillet 2003 sur les conditions d’émission des factures, de leur signature électronique et leurs modalités de stockage ;
- l’instruction du 7 août 2003 qui précise les conditions de validité du caractère probant pour les deux procédés de transmission électronique (authenticité garantie par le format structuré du fichier pour la facture EDI, et par la signature pour la facture électronique ; voir RF Comptable 301, décembre 2003, dossier « La facture : mentions obligatoires, dématérialisation, archivage »).
Dispositions spécifiques aux factures signées électroniquement
Le signataire, qui détient et met en œuvre le moyen de création de la signature électronique, peut être :
- une personne morale. La signature électronique est alors produite automatiquement lors de l’envoi des factures ;
- une personne physique. La signature électronique est alors produite par une personne physique en son nom pour le compte de l’entreprise.
Le certificat électronique, document sous forme électronique qui atteste du lien entre l’identité du signataire et les données de vérification de sa signature électronique a les caractéristiques suivantes :
- délivrance par un prestataire de services de certification,
- contenu spécifique a minima,
- absence de nécessité d’un certificat « qualifié ».
Dispositions spécifiques à l’archivage électronique
La norme NF Z 42-103 fournit les spécifications pour l’enregistrement, le stockage et la restitution de documents électroniques afin d’assurer la conservation de ceux-ci.
Concernant la force probante de l’archivage électronique, signalons que les conventions de preuve sont reconnues en la matière.
SOLUTIONS FONCTIONNELLES
Une opération de dématérialisation s’articule autour de quatre axes :
- savoir gérer des factures dématérialisées (GED, Workflow, Processus...) ;
- savoir dématérialiser ses factures (factures structurées, factures signées, scan, OCR, archivage...) ;
- savoir déployer et gérer un monde externe hétérogène (déploiement, communautés, réseaux...) ;
- savoir conserver et fiabiliser une validité juridique et fiscale en mode dématérialisé.
Nous présentons ci-dessous les différentes solutions qui permettent de dématérialiser les factures.
L’EDI
L’EDI (échange de factures de données structurées sans signature électronique) est la solution la plus utiliséedepuis plus de 10 ans, qu’elle soit pratiquée en interne par l’entreprise ou par l’intermédiaire de prestataire de services (plate-forme EDI).
Ce type de dématérialisation est basé sur une convention EDI ou un contrat d’interéchange : cet engagement contractuel entre client et fournisseur régit la responsabilité et la validité des échanges clients/fournisseurs (en conformité avec l’article 289 bis du CGI).
La station EDI du fournisseur et celle du client gèrent :
- le fichier des partenaires,
- la création de l’original (fonction qui concerne le fournisseur),
-  le contrôle des mentions obligatoires,
- la liste récapitulative,
- la transmission de l’original (concerne le fournisseur),
- la réception de l’original et la transmission des données (concerne le client),
- l’archivage,
- la restitution des données archivées.
L’EDI peut se pratiquer en infogérance sous mandat du fournisseur.
Le recours à un prestataire de services permet de s’affranchir d’un contrat d’interéchange client/fournisseur deux à deux. Le contrat de services recouvre au minimum la garantie de la validité juridique, à laquelle peuvent être ajoutés d’autres services, notamment l’archivage.
La facture électronique signée
Le circuit de la facture électronique est le suivant :
- création des données spécifiques de la facture par le fournisseur à partir de données issues d’applications de gestion ;
- intégration des éléments permanents de la facture (par exemple, capital social) ;
- signature électronique par clé asymétrique privée ;
- horodatage (facultatif) ;
- e-archivage immédiat par le fournisseur ;
- transmission de la facture électronique au client ;
- vérification, par le client, de l’identité de l’émetteur par la clé asymétrique publique ;
- e-archivage immédiat par le client ;
- vie de la facture chez le client (indexation, comptabilisation...).
L’entreprise peut, de même que pour l’EDI, externaliser sa dématérialisation en passant par une plate-forme ou un opérateur de facturation électronique. Le fournisseur passe un contrat de services (certificats, mandats), qui nécessite l’accord (même tacite) du client.
S’agissant de l’espace fournisseur, l’opérateur prend en charge :
- l’horodatage et la signature,
- le suivi des émissions,
- l’archivage,
- la restitution des données archivées.
Pour l’espace client, l’opérateur assure (mais le client peut aussi assurer en interne) :
- la réception et l’aide à l’intégration,
- la vérification de la signature,
- l’archivage,
- la restitution des données archivées.
Homogénéiser les supports : le scan
Le scan est l’outil qui permet à l’entreprise d’homogénéiser ses supports : il transforme un document physique en un fichier électronique pouvant être « lié » à d’autres informations (index) dans un objectif de traitement.
Ainsi, des factures non électroniques, indépendamment du fait qu’elles seront archivées sur papier, vont devoir être numérisées pour entrer dans une base d’images (après indexation, LAD ou vidéocodage et vérification) et alimenter le système informatique.
Précisons qu’il existe des formats standards publics de stockage de ces images (pdf, tiff) qui permettent de les réutiliser.
Homogéniser les flux : la LAD
La LAD, opération de reconnaissance des caractères (OCR en anglais), concerne à la fois :
- les factures papier qui ont été numérisées et donc sont issues de scan (voir ci-dessus) ;
- les factures électroniques signées.
C’est l’outil utilisé pour constituer une base d’images indexées qui vont alimenter le système informatique en aval.
Deux techniques sont utilisées :
- soit l’application de modèles. Il existe environ 200 à 250 modèles différents de factures et des masques sont utilisés pour retrouver les mentions obligatoires des factures (montant HT, montant TTC...),
- soit la reconnaissance de mots-clés.

What is a schematron?

The Schematron is a language and toolkit for making assertions about patterns found in XML documents. It can be used as a friendly validation language and for automatically generating external annotation (links, RDF, perhaps Topic Maps). Because it uses paths rather than grammars, it can be used to assert many constraints that cannot be expressed by DTDs or XML Schemas.
Schematron 1.5 can be trivially implemented using XSLT in two stages.
  • Scimitar is a Python implementation of draft ISO Schematron
  • For .NET users, Schematron.NET is an open source implementation at Source Forge.
  • IBM have added Schematron to their Alphaworks technology Business Integration Information Conformance Statements.
  • The JAXEN XPath engine for Java may be optimized for better Schematron performance.
  • A JUnit-related open source project Schema Unit Test allows Schematron schemas.
  • Open GIS (Geographical Information Systems) has added Schematron as a constraint language to their Geography Markup Language.
  • Topologi Professional Edition is an analytics and reporting tool, including editor, that allows Schematron validation of XML and SGML documents. Multiple documents can be validated in batch. Document sets can be sampled, and a Schematron "usage schema" generated, to allow testing that new documents have the same structure as previous documents. Schematron validation is also possible from the context-sensitive tree editor, and the markup editor.
  • James Clarks' Jing librrary supports RELAX NG, WXS datatypes, Schematron, NRL and (through Xerces) WXS.
  • The Topologi XML Judge is GUI-based tool for Windows. It is useful for checking large numbers of files, for developing schemas and for second opinions on other Schema tools.
  • The Topologi Schematron Validator is GUI-based tool for Windows, free for educational and charity uses. It is useful for checking large numbers of files, for developing schemas and for experimentation. It supports Schematron, RELAX NG, Examplotron, WXS, XML DTD, SGML DTDs. It supports Schematron schemas embedded in WXS or RELAX NG Schemas.
  • The Topologi Collaborative Markup Editor is an XML editor for Windows, Mac OS X and Linux. It supports Schematron, RELAX NG, Examplotron, WXS, XML DTD, SGML DTDs. It supports Schematron schemas embedded in WXS or RELAX NG Schemas.
  • The Topologi Proxy Validator supports Schematron and WXS.
  • The OxygenXML editor supports Schmematron 1.5 validation
  • The reference Academia Sinica Computing Centre Schematron 1.5 implementation sits on top of any XSTL implementation. It is useful if you want to create command-line or batch tools, and you want to tailor the output.
  • The ZVON Schematron is an alternative implementation for XSLT. It provides simple output mapping, and is straight-forward and well-coded.
  • The FourThought 4Suite is a Python-based server system which offers Schematron validation.
  • For Perl users, Kip Hampton's XML::Schematron modules bring Schematron functionality as a Perl module.
  • For C++ users, Ivelin Ivanov's Xmlform is a Java implementation forming part of Apache's validation components, and is based on JXpath It is reported to be much faster than XSLT-based implementations.
  • For .NET developers, Daniel Cazzulino's Open Source Schematron.NET is a C# implementation. It is reported to be much faster than XSLT-based implementations.
  • For iteractive editing with Schematron, use the Academia Sincia Schematron in conjunction with James Clark's XT XSLT processor. XT provides line numbers in the standard format used by FSF GNU Emacs, Edinburgh's XED editor, and many others.
A range of implementations are available for various situations:
Schematron can be used in any language for which there is an XSLT implementation available (e.g. FourThought's Python version of XSLT, Java, C++, Perl) and it is also possible to create a native implementation without using XSLT. Early versions were prototyped using OmniMark.

PEPPOL is using schematron to implement the business rules in CEN BII profiles messages validation.

Rick Jelliffe is one of the fathers of schematron : http://www.oreillynet.com/pub/au/1712