Organigramme de reconnaissance des revenus IFRS 15 : Secteur technologique | ciferi

IFRS 15 Organigramme de reconnaissance des revenus : Edition France Appliquez le modèle en cinq étapes de reconnaissance des revenus selon l'IFRS 15...

En-tête

IFRS 15 Organigramme de reconnaissance des revenus : Edition France


Appliquez le modèle en cinq étapes de reconnaissance des revenus selon l'IFRS 15 avec des conseils adaptés aux priorités de contrôle de la H3C et aux pratiques du secteur technologique français.
Normes comptables applicables : IFRS 15 (adoptée par l'UE)
Régulateur : H3C (Haut Conseil du Commissariat aux Comptes) / AMF (Autorité des Marchés Financiers)
---

Contexte IFRS 15 en France

La France a adopté IFRS 15 Produits des contrats avec des clients par le biais du mécanisme d'approbation de l'UE, applicable aux exercices ouverts à compter du 1er janvier 2018. L'IFRS 15 est obligatoire pour les entités françaises qui préparent des états financiers consolidés selon l'IFRS, ce qui concerne principalement les sociétés cotées sur des marchés réglementés (Euronext Paris, Euronext Croissance). Les entités non cotées qui appliquent l'IFRS le font volontairement ou pour conformité avec des obligations de groupe.
Les entités non cotées opérant selon le droit français continuent à appliquer le Plan Comptable Général (PCG), où la reconnaissance des revenus suit le principe de réalisation défini par l'article L. 123-12 du Code de commerce. Cette différence crée des enjeux de consolidation pour les groupes avec filiales soumises au PCG et maison mère appliquant l'IFRS.
---

Priorités de contrôle de la H3C et de l'AMF

La H3C, en collaboration avec l'AMF pour les entités cotées, a identifié la reconnaissance des revenus comme un axe de contrôle prioritaire depuis l'adoption de l'IFRS 15. Les constats récurrents incluent :
La H3C a publié un rapport thématique en 2024 identifiant que 34 % des dossiers examinés contenaient des défaillances substantielles dans l'application de l'étape 2 (identification des obligations de performance) et 28 % dans l'application de l'étape 3 (détermination du prix de transaction).
---

  • Identification insuffisante des obligations de performance distinctes dans les arrangements complexes (par exemple, contrats SaaS bundlés avec services de mise en œuvre)
  • Évaluation inadéquate de la considération variable, notamment les remises volume et les éléments contingents
  • Documentation insuffisante des jugements professionnels appliqués au modèle en cinq étapes
  • Reconnaissance prématurée de revenus avant le transfert du contrôle de l'actif

Secteur technologique : Considérations spécifiques

Le secteur technologique français (logiciels, services cloud, conseil informatique, services numériques) présente des défis distinctifs pour l'application de l'IFRS 15.

Arrangements bundlés courants


Les éditeurs de logiciels et prestataires cloud français proposent souvent des arrangements intégrés combinant :
L'identification de ces éléments comme obligations de performance distinctes requiert l'application rigoureuse du paragraphe 27 de l'IFRS 15.

Évaluation de la séparabilité


Pour déterminer si chaque élément constitue une obligation de performance distincte, le commissaire aux comptes doit évaluer :
Capacité à bénéficier de manière indépendante : Le client peut-il utiliser le logiciel ou le service seul ou avec des ressources facilement disponibles ? Une licence logiciel est généralement capable d'être distincte. Un service d'implémentation intégrant le logiciel au système du client peut ne pas l'être si le service modifie ou personnalise de manière substantielle le logiciel.
Séparabilité dans le contexte du contrat : Le prestataire fournit-il une intégration significative du logiciel avec d'autres éléments du contrat ? Si le service d'implémentation ne se limite pas à paramétrer le logiciel standard mais requiert une personnalisation substantielle affectant sa fonctionnalité, l'implémentation n'est pas séparable du logiciel lui-même.
---

  • Licences de logiciel (ou droit d'accès)
  • Services d'implémentation et d'intégration
  • Services de maintenance et support
  • Services d'hébergement ou cloud

Étape 1 : Identifier le contrat (IFRS 15.9–21)

Critères d'existence d'un contrat


Pour que le contrat soit reconnu, les cinq critères de l'IFRS 15.9 doivent être satisfaits.
Approbation et engagement : Les parties ont-elles approuvé le contrat et s'engagent-elles à exécuter leurs obligations respectives ? L'approbation peut être écrite, orale ou implicite selon les pratiques commerciales établies. Dans le secteur technologique français, les arrangements peuvent débuter par une lettre d'intention (LOI) ou une commande suivies d'un contrat de service détaillé signé ultérieurement. Évaluer si le comportement des parties démontre l'engagement à exécuter à partir du moment de la commande ou seulement après signature du contrat complet.
Identification des droits : Chaque partie peut-elle identifier ses droits respectifs ? Pour une fourniture de logiciel SaaS, cela signifie identifier précisément la durée d'accès, la capacité (nombre d'utilisateurs, stockage), les niveaux de service (SLA), et les droits de propriété intellectuelle.
Identification des conditions de paiement : Les modalités de paiement sont-elles identifiables. montant, calendrier, contingences ? Les contrats technologiques français incluent fréquemment des structures de paiement échelonnées : acompte à la signature, tranches à certains jalons de mise en œuvre, solde à l'acceptation fonctionnelle.
Substance commerciale : Le contrat modifie-t-il les flux de trésorerie futurs attendus de l'entité ? Un contrat SaaS avec engagement d'un an crée une substance commerciale claire en raison de la modification du timing et du montant des flux. Les arrangements de troc ou d'échange de droits de propriété intellectuelle entre concurrents présentent un risque d'absence de substance.
Recouvrement probable de la contrepartie : Est-il probable que l'entité percevra la contrepartie ? Évaluer la solvabilité du client, son historique de paiement, et toute garantie. Pour les clients publics français (collectivités, ministères), le risque de non-paiement est généralement faible, mais les délais de paiement peuvent être substantiels (90 jours ou plus selon les règlements publics). Une entité logicielle ne doit pas reconnaître une trésorerie probabiliste si la contrepartie contractuelle dépend fortement de l'exercice d'options optionnelles par le client après la mise en œuvre.

Combinaison de contrats


Plusieurs contrats conclus simultanément avec le même client doivent-ils être combinés ? Appliquer les trois critères de l'IFRS 15.17 :

Modifications de contrat


Les modifications surviennent fréquemment dans les contrats technologiques : changements de champ, extensions de capacité, services supplémentaires, amendments dus à des changements réglementaires.
Pour chaque modification, évaluer :
---

  • Objectif commercial unique : Un arrangement combinant un contrat de logiciel de base et un contrat d'extensibilité future avec options conjointes suggère une négociation comme paquet.
  • Interdépendance tarifaire : La réduction consentie sur le logiciel de base est-elle conditionnée par l'engagement du client à acquérir des services d'extension ultérieurs ?
  • Obligation de performance unique : Les prestations promises constituent-elles une obligation intégrée du point de vue du client ?
  • Les obligations supplémentaires sont-elles distinctes ? Un service de formation supplémentaire pour une installation logicielle est typiquement distinct du logiciel lui-même.
  • Le prix augmente-t-il proportionnellement aux prix de vente autonomes (prix auxquels les éléments sont vendus séparément) ? Comparer la hausse tarifaire à ce que l'entité pourrait charger pour le service ajouté à un nouveau client.
  • Les obligations restantes non satisfaites constituent-elles une obligation de performance distincte du travail déjà livré ? Si le contrat original visait une mise en œuvre sur 12 mois et qu'une modification intervient après 6 mois pour étendre le champ, les 6 mois restants sont distincts de la première moitié. Traiter la modification de manière prospective (comme si le contrat original avait pris fin et un nouveau contrat avait commencé).

Étape 2 : Identifier les obligations de performance (IFRS 15.22–30)

Test de séparabilité


Chaque bien ou service promis doit être testé selon le critère de distincte présenté à l'IFRS 15.27.
Critère A : Capacité à bénéficier de manière indépendante
Le client peut-il bénéficier du bien ou service seul ou avec d'autres ressources facilement disponibles ?
Pour une licence logiciel standard : Oui, le client peut généralement utiliser le logiciel de façon autonome avec ses ressources existantes (infrastructure, personnel).
Pour une implémentation personnalisée intégrant le logiciel aux systèmes du client : L'analyse est plus fine. Si l'implémentation se limite à l'installation et paramétrage du logiciel standard, elle est généralement distincte. Si l'implémentation requiert une personnalisation substantielle du logiciel modifiant sa fonctionnalité pour le client, elle peut ne pas être distincte. le service « intègre » le logiciel dans un bien combiné.
Critère B : Séparabilité dans le contexte du contrat
La promesse est-elle séparable des autres promesses du contrat ? L'IFRS 15.29 énumère les indicateurs de NON-séparabilité :
a) L'entité fournit une intégration significative. Exemple : Un cabinet de conseil implémente une solution logicielle en effectuant une réingénierie complète des processus du client. Le service d'implémentation ne peut pas être séparé du logiciel car il modifie l'utilité du logiciel pour ce client.
b) Le bien ou service modifie ou personnalise significativement un autre bien ou service du contrat. Exemple : Un fournisseur vend une licence standard plus un service de personnalisation adaptant le logiciel aux besoins métier du client. La personnalisation modifie substantiellement le logiciel, créant un actif combiné (logiciel personnalisé) distinct des deux éléments séparés.
c) L'interdépendance hautement significative ou l'interrelation entre le bien ou service et d'autres éléments du contrat. Exemple : Un service cloud multitenant où le client reçoit une « part » de l'infrastructure cloud. Le service ne peut pas être séparé de l'infrastructure partagée car chaque client dépend de manière substantielle de la qualité, de la disponibilité et de la performance de l'infrastructure commune.

Cas pratique : Contrat SaaS bundlé


Prenons Gérant Logistique S.A.S., une PME basée à Toulouse fournissant une plateforme SaaS de gestion d'entrepôt.
Contrat signé : Éditions Auvergne S.A.R.L. (distributeur de manuels scolaires, Clermont-Ferrand) s'engage à utiliser la plateforme pour 36 mois moyennant :
Analyse de distincte (IFRS 15.27)
| Élément | Capable de bénéficier seul | Séparable dans le contexte | Conclusion |
|--------|--------------------------|---------------------------|-----------|
| Licence SaaS | Oui. Client accède à la plateforme. | Oui. Vendue seule à d'autres clients. | Distincte. Obligation de performance : accès à la plateforme durant 36 mois. Reconnaissance over-time selon le calendrier de mise à disposition (IFRS 15.35). |
| Implémentation | Partiellement. Effectue installation, paramétrage standard, migration de données. Pas de personnalisation substantielle du code. | Oui. Gérant Logistique peut vendre ce service à d'autres clients sans modification pour ce client. | Distincte. Obligation de performance : services de mise en place. Reconnaissance over-time selon mesure d'avancement (heures/jalons). |
| Formation | Oui. Client peut bénéficier de la formation seul. | Oui. Service vendu indépendamment. | Distincte. Obligation de performance : livraison des services de formation. Reconnaissance over-time selon calendrier de prestation (jours de formation). |
| Support annuel | Oui. Maintenance, bug-fixes, alertes de sécurité sont bénéfices autonomes. | Oui. Offert séparément. | Distincte. Obligation de performance : services de support mensuels durant la période. Reconnaissance over-time mensuellement. |
Résultat : Quatre obligations de performance distinctes.
Documentation en dossier : Matrice de distincte signée par l'équipe financière et technique de Gérant Logistique documentant le résultat de chaque test.
---

  • 450 EUR/mois pour la licence plateforme (50 utilisateurs, 100 Go stockage)
  • Implémentation initiale : 15 000 EUR (installation, configuration, migration des données)
  • Formation utilisateurs : 3 000 EUR (deux jours sur site)
  • Support annuel : 6 000 EUR/an (helpdesk 8/17, mises à jour, alertes de sécurité)

Étape 3 : Déterminer le prix de transaction (IFRS 15.47–72)

Le prix de transaction est le montant de la contrepartie qu'une entité s'attend à avoir le droit de percevoir en échange de la promesse de transférer des biens ou services au client.

Considération variable


Existe-t-il une considération variable dans le contrat ?
Les contrats technologiques français incluent fréquemment des éléments variables :

Estimation de la considération variable


L'IFRS 15.53 offre deux méthodes. Laquelle prédit mieux le montant attendu ?
Méthode 1 : Valeur attendue (moyenne probabiliste)
Exemple : Contrat de logiciel avec bonus de performance. Le client paiera un montant de base, plus un bonus selon la réalisation d'objectifs :
Valeur attendue = (20 % × 30 000) + (50 % × 15 000) + (30 % × 0) = 6 000 + 7 500 + 0 = 13 500 EUR
Utiliser la valeur attendue quand il existe de nombreux contrats similaires ou une large gamme de résultats possibles.
Méthode 2 : Montant le plus probable (outcome unique le plus probable)
Exemple : Contrat de SaaS avec pénalité SLA. L'analyse de données historiques montre que dans 87 % des cas, le fournisseur respecte les SLA et aucune pénalité n'est due. Dans 12 % des cas, une pénalité de 5 000 EUR est appliquée. Dans 1 % des cas, pénalité de 15 000 EUR.
Le montant le plus probable est 0 EUR (outcome à 87 %). Utiliser cette méthode.
Utiliser le montant le plus probable quand une seule valeur domine ou quand la réalité se limite à quelques résultats discrets.

Limitation de la considération variable (contrainte)


L'IFRS 15.56 exige de n'inclure la considération variable dans le prix de transaction que dans la mesure où il est hautement probable qu'une révision ultérieure du montant n'entraînerait pas une réduction significative du cumul des revenus reconnus.
Question clé : Y a-t-il un risque de reversal significatif ?
Exemple : Un fournisseur SaaS signe un contrat de 36 mois avec une structure de bonus dépendant de l'utilisation du client. Le bonus estimé à 50 000 EUR représente 18 % du prix de transaction total. Si l'utilisation diminuait de manière substantielle à partir du mois 12, le bonus serait réduit.
La limitation de la contrainte impose de n'inclure que le montant dont l'entité est « hautement probable » (probablement > 80 %) qu'il ne sera pas réduit.
Documentation : Modèle de sensibilité évaluant les scénarios de variation (réduction d'utilisation de 10 %, 20 %, 30 %) et montrant le seuil probabiliste pour inclusion.
---

  • Remises volume : Réduction tarifaire si le client déploie le logiciel à plus d'utilisateurs
  • Remises de paiement comptant : 2 % si facturation payée sous 30 jours
  • Éléments contingents : Bonus de performance basé sur les KPI du client utilisant la plateforme
  • Pénalités : Crédit d'utilisation si les SLA ne sont pas respectés (disponibilité < 99,5%)
  • Options d'extension : Client a option (non obligation) d'étendre la licence à davantage d'utilisateurs à prix fixe
  • 20 % de probabilité : Bonus de 30 000 EUR (objectif largement dépassé)
  • 50 % de probabilité : Bonus de 15 000 EUR (objectif atteint)
  • 30 % de probabilité : Bonus de 0 EUR (objectif manqué)

Étape 4 : Allouer le prix de transaction (IFRS 15.73–90)

Le prix de transaction doit être alloué aux obligations de performance distinctes selon les prix de vente autonomes.

Détermination des prix de vente autonomes


Quel prix l'entité demande-t-elle à titre autonome pour chaque obligation de performance ?
Pour Gérant Logistique :
Prix de vente autonome total :
Prix contractuel du contrat bundlé: 450 EUR/mois (36 mois) + 15 000 + 3 000 + 6 000 EUR/an = 16 200 + 15 000 + 3 000 + 18 000 = 52 200 EUR

Allocation basée sur les PVA


Allouer le prix de transaction au prorata des prix de vente autonomes :
| Obligation | PVA | % du total | Allocation |
|-----------|-----|-----------|-----------|
| Licence SaaS | 18 000 | 29 % | 15 230 EUR |
| Implémentation | 18 000 | 29 % | 15 230 EUR |
| Formation | 2 000 | 3 % | 1 566 EUR |
| Support | 24 000 | 39 % | 20 376 EUR (6 792 EUR/an) |
| Total | 62 000 | 100 % | 52 200 EUR |
Chaque obligation de performance est désormais associée à un montant de prix de transaction déterminé.

Ajustements pour circonstances contractuelles


L'allocation peut être ajustée pour circonstances contractuelles. par exemple, remises de volume.
Si le contrat prévoit : « Pour chaque tranche de 50 utilisateurs supplémentaires, réduction de 5 % du prix mensuel », l'ajustement du PVA peut être justifié si la réduction reflète une réduction des coûts d'exécution ou un changement du modèle de risque de l'entité pour ce client.
---

  • Licence SaaS : Prix observé de vente séparée : 500 EUR/mois (client typique, 50 utilisateurs)
  • Implémentation : Proposée séparément à 18 000 EUR pour clients non bundlés
  • Formation : 1 000 EUR/jour de formation ; contrat prévoit 2 jours = 2 000 EUR
  • Support : Prix de vente autonome : 8 000 EUR/an pour support complet
  • Licence : 500 EUR/mois × 36 mois = 18 000 EUR
  • Implémentation : 18 000 EUR
  • Formation : 2 000 EUR
  • Support : 8 000 EUR × 3 ans = 24 000 EUR
  • Total PVA : 62 000 EUR

Étape 5 : Reconnaître le revenu (IFRS 15.31–45)

Le revenu est reconnu quand (ou au fur et à mesure que) une obligation de performance est satisfaite : quand le contrôle du bien ou service promis est transféré au client.

Test over-time vs point-in-time


Pour chaque obligation de performance, déterminer si le contrôle est transféré over-time ou à un moment précis.
Over-time : Reconnaître le revenu au fur et à mesure de la satisfaction de l'obligation. Cela s'applique quand :
Point-in-time : Reconnaître le revenu à un moment précis, généralement quand le transfert de contrôle s'accomplit en un moment distinct. Exemple : transfert de propriété d'une licence perpétuelle.

Application au contrat SaaS d'Éditions Auvergne


| Obligation | Over-time ou point-in-time | Mesure d'avancement | Traitement |
|-----------|---------------------------|-------------------|-----------|
| Licence SaaS | Over-time | Calendrier (par mois) | Reconnaître 450 EUR/mois × 36 mois au fil du temps. À chaque mois, le revenu mensuel est reconnu à la fin du mois quand l'accès à la plateforme pour ce mois a été fourni. |
| Implémentation | Over-time | Heures / jalons | Mesurer la progression selon les jalons : (1) installation et migration = 30 %, (2) paramétrage = 40 %, (3) tests de recette = 30 %. Reconnaître 30 %, 40 %, 30 % du revenu d'implémentation alloué (15 230 EUR) au fur et à mesure de chaque jalon. |
| Formation | Over-time | Heures de formation livrées | Contrat prévoit 2 jours. Reconnaître 1 566 EUR / 2 = 783 EUR par jour au fur et à mesure de la prestation. |
| Support | Over-time | Calendrier (par mois) | Services de maintenance et support livrés mensuellement. Reconnaître 6 792 EUR / 12 = 566 EUR par mois. |

Documentation et présentation en états financiers


Le commissaire aux comptes doit vérifier la conformité de la comptabilisation aux états financiers :
Passif de contrat : Si un acompte de 10 000 EUR a été reçu avant la satisfaction d'une obligation (par exemple, acompte sur l'implémentation), comptabiliser un passif de contrat jusqu'à satisfaction.
Créance de contrat : Si des obligations ont été satisfaites mais le paiement n'est pas exigible (par exemple, paiement à jalon), comptabiliser une créance de contrat.
Annexe et divulgations : La norme IFRS 15.114–115 exige une ventilation du revenu par type d'obligation de performance, par géographie, ou par autres catégories informatives. Pour Gérant Logistique, déclarer séparément le revenu provenant des licences SaaS (revenu récurrent) versus les services (implémentation, formation, support).
---

  • Le client reçoit et consomme simultanément les bénéfices de la performance de l'entité. Exemple : service SaaS mensuel. Le client reçoit l'accès à la plateforme chaque mois et consomme ce bénéfice immédiatement.
  • La performance de l'entité crée ou améliore un actif que le client contrôle (IFRS 15.35(b)). Exemple : implémentation / paramétrage du logiciel. Chaque jour de travail améliore la configuration du système ; le client contrôle de façon progressive cet actif en cours de création.
  • L'entité n'a pas d'utilisation alternative pour l'actif et possède un droit exigible au paiement pour la performance à ce jour. Exemple : développement logiciel personnalisé. Si le code développé n'a aucune utilité pour le fournisseur en dehors de ce contrat, et que le client a accepté le travail, l'entité a un droit exigible au paiement.

Questions fréquemment posées

Les contrats SaaS avec options d'extension doivent-ils être traités différemment ?
Une option d'extension est distincte d'une obligation substantive. Si un client a l'option (non obligation) de renouveler une licence SaaS après 3 ans à un prix fixe, cette option n'est pas une obligation de performance à l'origine du contrat. Ne reconnaître de revenu que si/quand le client exerce l'option et devient obligatoire.
Cependant, si l'option est substantiellement décidée par les parties dès l'origine (par exemple, les termes rendent l'exercice hautement probable), elle peut être considérée comme une obligation implicite et incluse dans le prix de transaction initial.
Comment traiter les SLA et les crédits de service en vertu de contrats SaaS ?
Un SLA garantissant une disponibilité de 99,5 % avec crédit d'utilisation en cas de non-conformité est une considération variable conditionnelle. Estimer la probabilité de rupture du SLA selon l'historique. Si rupture probable > 0, inclure une provision de crédit d'utilisation estimé dans le prix de transaction (net du prix contractuel).
Documentation : Historique de disponibilité ; calcul de la probabilité ; montant du crédit estimé.
Quelle est la distinction entre prix de vente autonome observable vs estimé ?
Observable : L'entité vend régulièrement le même bien ou service de manière indépendante. Utiliser le prix du marché observé.
Estimé : L'entité ne vend pas régulièrement l'élément seul. Estimer le PVA en considérant le coût d'exécution majoré d'une marge appropriate, les prix du marché concurrentiels pour des services comparables, ou le prix que le client accepterait de payer indépendamment.
Pour Gérant Logistique : Le service de formation n'est pas vendu séparément. Estimer le PVA à partir du coût (2 jours × 1 consultant senior à 400 EUR/jour = 800 EUR) plus marge (33 % = 1 067 EUR arrondi à 1 000 EUR/jour).
---

Considérations spécifiques au secteur technologique français

Contrats avec administrations publiques


Les contrats avec ministères, collectivités ou établissements publics (ministère de l'Éducation, communes, hôpitaux publics) présentent caractéristiques distinctives :
Exemple : Un développeur logiciel signe un contrat pour une plateforme e-services avec une commune de 25 000 habitants. Déploiement = 80 000 EUR. Contrat prévoit « recette technique de 30 jours » post-déploiement. La commune paie dans les 45 jours après acceptation.
Comptabilisation : Reconnaître le revenu à l'acceptation technique (fin de la période de recette), non au déploiement technique. Enregistrer une créance de contrat immédiatement à l'acceptation (paiement pas encore exigible, seulement la performance est satisfaite).

Contrats de maintenance logiciel avec options de remplacement


Certains fournisseurs proposent des contrats long-terme incluant une obligation d'actualiser régulièrement le logiciel (ex., nouvelles versions tous les 18 mois). L'obligation d'actualisation constitue-t-elle une obligation de performance distincte ?
Analyse : Si les mises à jour cumulées constituent une nouvelle version substantiellement différente du logiciel original (par exemple, refonte majeure), elles peuvent constituer une obligation distincte. Allouer une partie du prix de transaction à cette obligation et la reconnaître au cours de la période couverte par les droits de mise à jour.
Si les mises à jour sont des corrections et améliorations mineures du logiciel existant, elles font partie de la « maintenance » et ne sont pas distinctes de la licence elle-même.

Contrats de conseil en transformation numérique


Les cabinets de conseil proposent souvent des arrangements bundlant diagnostic, recommandations, implémentation, et formation. Évaluer chacun pour distincte selon IFRS 15.27.
Diagnostic / audit : Généralement distinct. Le client bénéficie de recommandations indépendamment de l'implémentation.
Implémentation : Peut être intégrée au diagnostic si le consultant mène diagnostic ET personnalise la solution pour ce client sans séparation claire. Peut être distincte si fournie comme service séparé post-diagnostic.
Formation : Typiquement distincte. Vendable indépendamment.
---

  • Longs délais de paiement : Les règles budgétaires publiques imposent généralement 30 à 90 jours. Reconnaître le revenu une fois le contrôle transféré, indépendamment du délai de paiement. La collectabilité reste probable en raison de la solvabilité de l'État.
  • Procédures de recette : Les administrations demandent fréquemment une période de test ou recette technique avant acceptation finale. Le contrôle se transfère généralement à l'acceptation formelle, pas au déploiement technique.
  • Modifications fréquentes : Les contrats publics subissent des modifications (demandes supplémentaires, changements de champ) plus fréquemment que les contrats commerciaux. Traiter chaque modification selon IFRS 15.18–21.

Inspection et documentation requise

La H3C s'attend à ce que le commissaire aux comptes documente :
Absence ou insuffisance de cette documentation est le constat de contrôle le plus fréquent.
---

  • Matrice de distincte : Pour chaque obligation de performance identifiée, documentation du test de l'IFRS 15.27 (capacité à bénéficier seul + séparabilité).
  • Justification du prix de vente autonome : Preuve que le PVA est observable (factures de ventes indépendantes) ou estimé (méthode, données comparatives).
  • Tableau d'allocation : Allocation du prix de transaction aux obligations de performance, avec justification.
  • Mesure d'avancement : Pour les obligations over-time, documentation de la méthode de mesure et du résultat mois après mois ou période après période.
  • Considération variable : Analyse documentée de la probabilité et limitation de la contrainte pour tout montant variable.
  • Modifications de contrat : Documentation du traitement comptable de chaque modification (prospectif, cumul-catch-up, ou incorporation au contrat original).
  • Comparaison aux seuils de matérialité : Vérification que tout élément de jugement dépasse le seuil de matérialité pour justifier le traitement.

Ressources connexes

---

  • Mécanisme d'allocation basée sur les prix de vente autonomes
  • Questions fréquemment posées IFRS 15 et considération variable
  • Checklist d'audit IFRS 15 pour contrats technologiques