Présentation des éliminations standard
Les entreprises enregistrent les résultats de leurs transactions avec d'autres entreprises. Ces autres sociétés peuvent être des sociétés liées ou non liées (c'est-à-dire des sociétés tierces). Lors de la présentation des résultats financiers consolidés, l'impact des transactions pour lesquelles les sociétés légales comprises dans la consolidation ont un contrôle commun doit être supprimé/éliminé des résultats consolidés. Les résultats nets doivent être présentés comme si le groupe d'entités juridiques était une unité économique unique.
Les transactions avec des entreprises non liées ne doivent pas être éliminées. Il se peut que les transactions avec des sociétés liées aient à être éliminées totalement ou partiellement selon que la société liée entre dans le périmètre des résultats consolidés et en fonction des exigences comptables appliquées à l'arithmétique de consolidation.
La nature de la relation entre les parties liées déterminera la manière dont les informations des sociétés du périmètre seront agrégées et éliminées pour produire les résultats consolidés. Des normes comptables différentes nécessiteront des méthodes d'agrégation différentes, mais la plupart des normes suivent des principes généraux similaires.
Lorsqu'une application est activée pour des comptes intragroupes et qu'elle contient des données de compte intragroupe, les éliminations ont lieu dans le cadre du processus de consolidation.
Traitement des éliminations intragroupes
Les données qui résultent de transactions entre deux entités (c'est-à-dire les transactions intragroupes), les deux étant consolidées dans une entité parent commune, doivent être éliminées afin de présenter les résultats consolidés de l'entité parent comme s'il s'agissait d'une seule unité économique.
Les montants des transactions intragroupes sont initialement enregistrés deux fois. Chacune des deux parties (sociétés) impliquées dans la transaction enregistre sa vision de la transaction. La transaction est enregistrée séparément par chaque entité, l'autre entité étant le partenaire intragroupe. Les entrées enregistrées par les deux entités représentent la même transaction, mais sont saisies séparément par les deux entités impliquées dans cette transaction.
Les montants à éliminer sont les montants contrôlés en commun par l'entité parent où la propriété commune est représentée dans la hiérarchie de l'organisation. L'effet net des éliminations doit être nul (c'est-à-dire que les débits doivent être égaux aux crédits), mais les données sont reclassées afin d'être compensées au niveau de l'entité parent. Si les données source des deux entités impliquées dans la transaction sont proportionnalisées à 100 %, le montant proportionnalisé complet doit être éliminé. Si le montant proportionnalisé par l'une ou l'autre entité est inférieur à 100 %, seul le montant proportionnel le plus bas est éliminé, car il est le seul à être contrôlé en commun. Par conséquent, un montant éliminé ne peut en aucun cas dépasser le montant proportionnalisé. Si le pourcentage de consolidation pour l'une ou l'autre des sociétés concernées est de 0 %, aucune élimination n'est effectuée.
Chaque entrée d'élimination se compose de deux entrées dans le membre de la dimension Source de données "FCCS_Intercompany Eliminations" dans le membre de la dimension de consolidation des éliminations. La première entrée annule (ou annule partiellement) le montant intragroupe initial. Tous les membres des dimensions auxquels l'inversion est appliquée sont tirés du PDV source, à l'exception des dimensions Consolidation et Source de données. Une deuxième écriture de contrepartie est passée sur le compte "Liaison", tel que défini dans les métadonnées du compte intragroupe source. Comme pour l'entrée d'annulation, l'entrée Liaison est enregistrée dans le membre de la dimension Source de données "FCCS_Intercompany Eliminations" dans le membre de la dimension de consolidation des éliminations. Tous les membres des dimensions auxquels l'entrée Liaison est appliquée sont tirés du PDV source, à l'exception des dimensions Consolidation et Source de données. Si le compte Liaison n'est pas défini comme un compte intragroupe, l'entrée Liaison est enregistrée dans "FCCS_No Intercompany" dans la dimension intragroupe.
Conditions des éliminations intragroupes
Les structures d'entité d'une application peuvent être créées comme des structures "plates" (une entité parent avec toutes les entités détenues directement et indirectement en tant qu'enfants directs). L'entité parent représente les résultats consolidés de la société mère. Il est également possible de créer des structures à plusieurs niveaux (ou "intermédiaires"). Dans une structure à plusieurs niveaux, les entités semblables de chaque société mère sont les sociétés directement détenues par cette société. Si ces sociétés détenues directement possèdent elles-mêmes d'autres sociétés, la société semblable à la société mère propriétaire est la société mère consolidée de la société mère détenue.
Dans une structure plate, la logique pour déterminer si une élimination doit être traitée est simple. La logique suivante est appliquée :
Les données peuvent faire l'objet d'une élimination si :
le compte est un compte intragroupe et est associé à un compte Liaison (de compensation) valide ;
les données ont une entrée de dimension intragroupe autre que "FCCS_No Intercompany" (c'est-à-dire qu'elles contiennent un partenaire valide) ;
l'entité dans laquelle la transaction intragroupe a été comptabilisée et le partenaire référencé dans la définition des données (PDV) sont tous deux consolidés dans la société parent à un taux supérieur à 0 %.
Si ces conditions sont remplies, les données sont reclassées dans le compte Liaison dans le membre de la dimension Elimination au plus bas du taux de consolidation de l'entité et de celui du partenaire.
Dans une structure à plusieurs niveaux, la logique permettant de déterminer si une élimination doit être traitée est en principe identique à celle employée dans une structure plate. Toutefois, la nature d'une structure à plusieurs niveaux introduit des complications potentielles supplémentaires. La logique suivante est appliquée :
Les données peuvent faire l'objet d'une élimination si :
le compte est un compte intragroupe et est associé à un compte Liaison (de compensation) valide ;
les données ont une entrée de dimension intragroupe autre que "FCCS_No Intercompany" (c'est-à-dire qu'elles contiennent un partenaire valide) ;
l'entité dans laquelle la transaction intragroupe a été comptabilisée et le partenaire référencé dans la définition des données (PDV) sont tous deux consolidés dans un parent ou ancêtre commun à un taux supérieur à 0 %.
a. L'entité et le partenaire peuvent ne pas se regrouper en un parent commun immédiat, ou bien l'entité et le partenaire peuvent se regrouper en un ancêtre commun via un ou plusieurs parents intermédiaires.
b. Le taux de consolidation pertinent utilisé dans l'évaluation et l'enregistrement de l'élimination est le taux de consolidation cumulé obtenu en multipliant le taux niveau par niveau de l'entité ou du partenaire par la contribution à l'ancêtre commun (c'est-à-dire le facteur cumulé propre à une branche de la hiérarchie aboutissant à l'ancêtre commun). Le taux de consolidation cumulé représente la contribution de l'entité source/partenaire à l'ancêtre commun pour chaque contributeur.
c. Le "plus bas des taux de consolidation de l'entité ou du partenaire" est appliqué à la somme du taux cumulé de l'entité, agrégé sur l'ensemble des semblables de l'entité et de la somme du taux cumulé du partenaire, agrégé sur l'ensemble des semblables de l'entité. Dans une hiérarchie à plusieurs niveaux, l'entité et le partenaire peuvent tous deux exister dans plusieurs branches de la hiérarchie et peuvent donc s'agréger à l'ancêtre commun par le biais de plusieurs de ses enfants.
d. Le point de données peut faire l'objet d'une élimination à plusieurs niveaux de la hiérarchie, immédiatement en dessous de plusieurs ancêtres communs. Si le partenaire existe dans plusieurs branches de la hiérarchie, le chemin de consolidation de l'entité vers le haut de la structure peut rencontrer plusieurs ancêtres communs. Si, immédiatement sous le premier ancêtre commun (ou un ancêtre ultérieur), le montant total de l'entité est éliminé, il n'y a pas d'élimination supplémentaire car le montant de l'élimination ne peut pas dépasser le montant proportionnalisé. Si aucune élimination (ou seulement une élimination partielle) n'a eu lieu aux niveaux précédents de la hiérarchie, une nouvelle élimination peut être nécessaire immédiatement en dessous de l'ancêtre commun actuel.
Le système applique des validations de sorte que les éliminations intragroupes ne soient traitées que si les conditions appropriées sont remplies pour un partenaire qui est un semblable ou le descendant d'un semblable de l'entité en cours. Si vous voulez désactiver cette fonctionnalité, vous pouvez créer une variable de substitution nommée StrictElimCondition et définir sa valeur sur False. Les données intragroupes peuvent alors toujours être éliminées si l'entité et le partenaire sont identiques.
Si ces conditions sont remplies, les données sont reclassées dans le compte Liaison dans le membre de dimension Elimination au plus bas de la somme (entre entités semblables/succursales) du taux de consolidation de l'entité cumulée et de la somme (entre entités semblables/succursales) du taux de consolidation du partenaire cumulé. Si le taux de consolidation du partenaire agrégé est inférieur à celui de l'entité agrégée, le taux du partenaire est appliqué.
Comment veiller à ce que les éliminations n'excèdent pas la proportionnalisation
Comme indiqué précédemment, sur la base du concept de l'élimination des transactions contrôlées en commun, le montant d'élimination cumulé d'une transaction intragroupe ne peut pas dépasser le montant proportionnalisé. Le système doit donc garantir que si le montant de la contribution nette d'un compte intragroupe a été réduit à zéro, aucune autre élimination ne peut avoir lieu.
Il est possible qu'un système informatisé ne puisse pas enregistrer une accumulation à zéro avec précision*. Cela est dû à un problème de précision décimale commun à tous les systèmes informatiques. Par conséquent, il peut arriver que la contribution nette d'un montant intragroupe source ne soit pas réduite à zéro exactement alors qu'elle est logiquement égale à zéro. Le test visant à déterminer s'il est nécessaire de traiter des éliminations intragroupes supplémentaires ne peut donc pas dépendre du fait que la contribution nette soit égale à zéro, mais doit plutôt être basé sur le fait que la contribution nette est approximativement égale à zéro.
Le test visant à déterminer si le montant d'une contribution nette est approximativement égal à zéro peut dépendre de l'ampleur des données dans le système. Par défaut, FCCS applique une précision décimale de quatre décimales lors du test. Dans ce cas, toute contribution nette inférieure à 0,0001 sera considérée comme nulle et aucune autre élimination ne sera appliquée aux données. Dans la plupart des cas et pour la plupart des devises, ce niveau de précision doit être suffisant. Toutefois, si des éliminations inattendues se produisent encore, une variable de substitution peut être ajoutée à l'application pour modifier la précision décimale appliquée au test.
Pour ajouter une variable de substitution, accédez à la carte Variables et sélectionnez l'onglet Variables de substitution. Cliquez sur le symbole plus (+) pour ajouter une variable de substitution. Pour Tous les cubes, entrez le nom PrécisionDécimale (sans espace entre "Précision" et "Décimale"). Indiquez le nombre de décimales à prendre en compte lors de l'application du test "approximativement égal". Plus la valeur des données saisies est importante (c'est-à-dire le nombre de chiffres significatifs à gauche du point décimal), plus la précision de la saisie décimale doit être faible.
L'entrée de la variable de précision décimale doit être un nombre entier (zéro ou un nombre entier positif ou négatif), sinon les consolidations ultérieures risquent d'échouer. Une entrée positive arrondit le montant de la contribution nette au nombre de décimales spécifié, zéro à un nombre entier et une entrée négative à un multiple de 10 (ainsi, une précision décimale de -2 arrondit 1 234 567,89 à 1 234 600, en arrondissant à la centaine la plus proche).
*Pour connaître les conditions propres à FCCS, consultez le document consacré aux limites de la précision des données dans Essbase à l'adresse https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=443798297810512&id=1311188.1&_afrWindowMode=0&_adf.ctrl-state=zlaqk3trz_4.