Migration vers SAP S/4HANA : reprise des soldes, postes non soldés et immobilisations

Les données financières à reprendre lors d’une migration vers SAP S/4HANA dépendent du mode de migration retenu. En nouvelle implémentation, les soldes des comptes généraux, les postes non soldés et les immobilisations sont des objets de migration distincts, chacun avec ses restrictions ; en conversion du système, les données existantes sont converties dans le système. Dans les deux cas, la comptabilité doit démontrer que le grand livre et les livres auxiliaires concordent avant et après la date de reprise.

Le mode de migration détermine le périmètre

SAP distingue trois voies :

• Conversion du système (brownfield) : le système SAP ERP existant est migré vers SAP S/4HANA ; selon SAP, cette voie convient lorsque l’on souhaite conserver les processus métier.
• Nouvelle implémentation (greenfield) : pour les entreprises qui veulent redéfinir leurs processus. Les soldes, les postes non soldés et les immobilisations sont repris depuis l’ancien système.
• Selective Data Transition : elle associe les deux approches. Seuls les entités métier, les sociétés, les processus et l’historique nécessaires sont repris.

Pour la conversion du système, le « Conversion Guide for SAP S/4HANA 2025 » (version 3.0 du document, version du 7 octobre 2026) décrit un déroulement outillé ; SAP recommande expressément le SAP Readiness Check. Pour la validation des données, le guide mentionne la « Data Transition Validation », qui compare les données métier avant et après la conversion. Pour la comptabilité, il renvoie notamment aux notes SAP 2332030 (« Conversion of Financial Accounting to SAP S/4HANA ») et 2294486 (« Do not migrate twice! »), cette dernière concernant les systèmes avec Simple Finance ou S/4HANA Finance.

Reprise des soldes : date de reprise et historique

La documentation SAP « Migration Objects for SAP S/4HANA » (release 2021, version du 7 octobre 2022) répertorie pour les comptes généraux l’objet « FI - G/L account balance ». Il reprend les soldes de l’exercice comptable en cours par BAPI ; les soldes historiques passent par « FI - Historical balance ». SAP cite deux approches : « File/Staging Table » et « Direct Transfer ».

Si la « Business Function » « Registration for Indirect Taxation (Abroad) » (RITA) est active dans le système cible, les objets « Direct Transfer » des soldes et des postes non soldés sont inutilisables.

Une date de reprise en fin de période, après la clôture de la période dans l’ancien système, a fait ses preuves. Il faut décider au préalable si des soldes à la date de reprise suffisent ou si des valeurs par période sont nécessaires pour les comparaisons. Les comptes collectifs ne sont pas mouvementés directement : leurs soldes résultent des postes non soldés et des valeurs d’immobilisations repris. Cela correspond à la définition que donne SAP : les comptes collectifs sont des comptes généraux qui reçoivent des écritures de livres auxiliaires.

Postes non soldés : les processus en aval doivent fonctionner

Les postes non soldés sont repris par les objets « FI - Accounts receivable open item » (clients) et « FI - Accounts payable open item » (fournisseurs). Sur le fond, ce qui compte, c’est que le paiement, la relance et le lettrage fonctionnent après la mise en production sans reprise manuelle. Les caractéristiques nécessaires à ces processus doivent donc être reprises : échéance, condition de paiement, devise, code TVA et blocages, par exemple.

Cela suppose des données de partenaires commerciaux nettoyées. Dès 2017, SAP recommandait, pour les conversions de système, de nettoyer tôt les données clients et fournisseurs en vue de l’intégration des partenaires (« Customer/Vendor Integration », CVI).

À notre avis, toute reprise doit s’accompagner de la preuve que la somme des postes non soldés par compte collectif correspond au solde de l’ancien système, par société et par devise, avant et après la migration.

Immobilisations : les valeurs par tableau d’évaluation

Pour la comptabilité des immobilisations, la documentation cite les objets « Fixed asset (including balance) », « Fixed asset - Master data », « Fixed asset - Postings » et « Fixed asset - Usage object ». L’objet « Fixed asset (including balance) » reprend les données historiques des immobilisations par BAPI. Si la « Business Function » « Asset Accounting with Universal Parallel Accounting » est active dans le système cible, cet objet n’est pas utilisable.

Avant le premier test, il faut avoir défini quel tableau d’évaluation (« depreciation area ») du système cible représente quel référentiel comptable : les normes locales (PCG en France, SCF en Algérie), les IFRS ou les règles fiscales. Pour chaque tableau, on reprend les valeurs d’acquisition et de production ainsi que les amortissements cumulés ; si la date de reprise tombe en cours d’exercice, s’y ajoutent les mouvements et les amortissements jusqu’à cette date. Une date de reprise au changement d’exercice simplifie l’opération, puisque les valeurs infra-annuelles disparaissent.

La concordance se vérifie avec la grille d’évolution des immobilisations de chaque tableau d’évaluation, rapprochée des comptes d’immobilisations du grand livre.

Rapprochement : la preuve qui compte

La « Data Transition Validation » aide à la comparaison lors d’une conversion. Le rapprochement fonctionnel reste du ressort de la comptabilité ; un concept arrêté avant le premier test de migration a fait ses preuves :

• Objets de contrôle : soldes des comptes généraux, postes non soldés par compte collectif, valeurs d’immobilisations par tableau d’évaluation.
• Niveau : société, devise, période.
• Liste des écarts : chaque écart avec sa cause, la décision prise et un responsable.
• Validation : qui signe avant l’ouverture du système aux écritures ?

Des comptes de contrepartie dédiés à la reprise rendent l’exhaustivité visible : toutes les écritures de reprise passent par ces comptes, qui doivent être soldés globalement une fois la reprise complète. Le même concept s’applique à chaque test de migration et au cut-over.

Ce que vous pouvez faire dès maintenant

1. Fixer le périmètre. Consignez par écrit le mode de migration, la date de reprise, les sociétés et l’historique nécessaire. Il en découle quelles données financières sont reprises et lesquelles sont converties.
2. Vérifier les restrictions. Comparez les objets de migration et leurs restrictions avec la documentation de votre release cible, notamment pour RITA et Universal Parallel Accounting. Les noms d’objets cités ici proviennent de la documentation de la release 2021.
3. Établir le concept de rapprochement et le plan de cut-over avant le premier test. Définissez les objets de contrôle, la liste des écarts et la validation, ainsi que l’arrêt des écritures, l’ordre de reprise et les points de validation. Appliquez les deux à chaque test de migration.

Si vous souhaitez passer en revue votre concept de rapprochement avec nous avant le premier test de migration, nous vous proposons volontiers un premier échange. Pour structurer la démarche, voyez notre Finance Readiness Check et nos expertises en finance et contrôle de gestion.