NetSuite et trésorerie : connecter votre ERP à un outil de cash management, étape par étape

NetSuite enregistre une facture client le jour de son émission. Votre trésorerie, elle, ne bouge qu'au jour du virement. Entre ces deux dates, le DAF qui veut connaître sa situation de trésorerie du matin croise l'ERP, les portails de chaque banque et, bien souvent, un fichier Excel.

Connecter NetSuite, l'ERP cloud d'Oracle, à un outil de gestion de trésorerie revient à automatiser les échanges de données entre les deux logiciels. Les factures, les tiers et le plan comptable partent de NetSuite vers la trésorerie ; les relevés de compte et les paiements rapprochés font le chemin inverse. Quant aux paiements, ils suivent un troisième chemin, vers les banques.

Ce guide s'adresse aux DAF et aux trésoriers qui pilotent ce projet sans en être les techniciens. Chaque terme technique y est traduit en langage métier, afin que vous sachiez quoi demander à votre administrateur NetSuite et à vos banques. Aucune compétence technique n'est requise pour le suivre.

Que fait NetSuite nativement pour la trésorerie ?

Les fonctions de cash management incluses dans l'ERP

Oracle présente le module Cash Management de NetSuite comme un outil de suivi de la trésorerie sur tous les sites d'un groupe. Le module rapproche automatiquement les opérations bancaires et génère les écritures comptables. Concrètement, l'ERP sait importer vos relevés de compte, les rapprocher de ses propres écritures et produire des fichiers de virement.

Pour lire un relevé, NetSuite s'appuie sur des « parsers », de petits traducteurs qui convertissent un format de fichier bancaire en données exploitables. La documentation Oracle en liste cinq en standard : BAI2, CAMT.053, CSV, MT940 et OFX/QFX.

Où s'arrête l'ERP

NetSuite raisonne en comptabilité d'engagement. Il enregistre ce qui est dû et ce qui a été comptabilisé. La situation de trésorerie du jour, banque par banque, dépend en revanche des relevés qu'il reçoit et de leur fréquence. Le livre blanc d’Agicap sur la connectivité bancaire, co-écrit par l’expert en finance d’entreprise Christian Wattig, juge le module bancaire des ERP « souvent incomplet ». Ses options de connexion répondent mal aux besoins des groupes qui travaillent avec plusieurs banques dans plusieurs pays.

Quels flux échanger entre NetSuite et un outil de trésorerie ?

Avant de parler technique, listez les données à faire circuler. Chaque flux se décide séparément.

De NetSuite vers la trésorerie

Les factures clients et fournisseurs, avec leur date d'échéance, constituent le premier flux. Elles alimentent la vision des encaissements et des décaissements à venir, par exemple sur 13 semaines glissantes. Le plan comptable, les tiers et les axes analytiques suivent. Sans eux, l'outil de trésorerie ne sait ni sur quel compte, ni sur quel client imputer un virement reçu.

De la trésorerie vers NetSuite

Le retour concerne d'abord les relevés de compte. Si l'outil de trésorerie récupère déjà vos relevés auprès des banques, il peut les déposer dans NetSuite, ce qui évite d'entretenir une seconde connexion bancaire côté ERP. Vient ensuite le résultat du rapprochement : lorsqu'un virement reçu a été associé à une facture, NetSuite doit savoir que cette facture est payée.

Cette information arrive sous deux formes possibles. Il peut s'agir d'une écriture de banque, ou d'un paiement directement imputé sur la facture ouverte. Dans ce second cas, NetSuite génère lui-même l'écriture comptable selon vos propres règles.

Les paiements : préparer dans NetSuite, exécuter par un canal bancaire sécurisé

De nombreuses équipes préparent leurs campagnes de virements fournisseurs dans NetSuite. Pour la France, NetSuite produit notamment des virements SEPA et des virements internationaux au format ISO 20022, appelé pain.001.

La chaîne type comporte quatre temps. Le bon à payer des factures est donné dans NetSuite, qui génère ensuite le fichier de virement, au format pain.001 pour un virement SEPA. Ce fichier rejoint l'outil de trésorerie, où les signataires valident la campagne selon leurs seuils et habilitations. L'outil transmet enfin les ordres à chaque banque.

Le fichier part vers la banque par un canal sécurisé, souvent EBICS. Ce protocole, lancé en 2006, est répandu en France, en Allemagne, en Autriche et en Suisse. Il existe en deux variantes. Avec EBICS T, le fichier est seulement transporté : les signataires le valident ensuite sur le portail web de la banque. En EBICS TS, le fichier arrive déjà signé électroniquement par les personnes habilitées, grâce à un certificat personnel. Le choix dépend de votre organisation des signatures et des offres de vos banques.

Connexion directe ou échange de fichiers : quel mode choisir ?

Deux mécanismes relient NetSuite à un autre logiciel. Le choix dépend des flux visés et du connecteur retenu.

La connexion directe par API

Une API est une porte d'entrée que NetSuite ouvre à un logiciel autorisé. Les deux applications échangent leurs données directement, sans fichier intermédiaire, à fréquence régulière. Côté NetSuite, ce mode repose sur les services web REST et sur une authentification OAuth 2.0, l'équivalent d'un badge d'accès nominatif délivré au seul connecteur. Il convient aux factures, aux tiers, au plan comptable et aux écritures. Certains connecteurs, dont celui d'Agicap, exigent l'édition NetSuite OneWorld, celle qui gère plusieurs sociétés dans un même compte. Cette exigence vient du connecteur et non de NetSuite, dont les services web existent aussi sur les éditions mono-entité.

L'échange de fichiers par SFTP

Le SFTP fonctionne comme une boîte aux lettres sécurisée : un logiciel y dépose un fichier, l'autre vient le relever à heure fixe. NetSuite s'y connecte grâce à des extensions appelées SuiteApps. Elles s'installent dans l'ERP comme une application sur un smartphone. La SuiteApp Auto Bank Statement Import (ABSI) va ainsi chercher chaque jour les relevés déposés sur un serveur SFTP et les importe dans NetSuite. Ce mode sert surtout aux relevés et aux ordres de paiement, que les banques produisent déjà sous forme de fichiers.

Quel mode pour quelle situation ?

La plupart des projets combinent les deux mécanismes, selon le besoin.

Les prérequis propres aux banques françaises

Les formats de relevé : CFONB 120, MT940 ou camt.053

Les relevés de compte français circulent surtout en CFONB 120 et en MT940, selon le guide d'utilisation du camt.053 publié par le Comité Français d’Organisation et de Normalisation Bancaire (CFONB) (version 1.2, mai 2019). Leur équivalent ISO 20022 s'appelle camt.053. Il s'agit d'un fichier XML structuré.

NetSuite ne lit pas le CFONB 120 en standard. Demandez donc à chaque banque un relevé au format MT940, ou en camt.053 dans la version 001.02 ou 001.08, encodé en UTF-8 comme l'exige le parser d'Oracle. D'après les équipes d'intégration d'Agicap, c'est à cette étape que les projets s'enlisent le plus souvent.

Les paiements et le contrat EBICS

Vérifiez d'abord les formats acceptés par chaque banque, canal par canal. L'exécution en EBICS T ou TS suppose un contrat signé avec chaque établissement, qui précise aussi le mode de signature des ordres. Lancez ces démarches en parallèle du projet NetSuite, car elles relèvent de la relation bancaire et non de l'ERP.

Connecter NetSuite à un outil de trésorerie en 7 étapes

Les étapes suivantes valent pour une connexion par API complétée par des échanges SFTP. Chacune précise qui agit : vous, votre administrateur NetSuite ou l'éditeur.

Étape 1 : cartographier les flux et les entités

C’est votre étape. Listez les entités concernées telles qu’elles sont paramétrées dans NetSuite, les banques et les comptes de chacune, puis les flux à activer en premier. Un groupe de quatre entités travaillant chacune avec trois banques représente déjà douze relations bancaires à passer en revue. Commencez par la remontée des factures, puis ajoutez les autres flux une fois la première connexion stable. 

Étape 2 : vérifier l'édition NetSuite et les formats bancaires

Votre administrateur confirme d'abord l'édition. Certains connecteurs, dont celui d'Agicap, exigent en effet OneWorld. Sur OneWorld, l'onglet de configuration (Setup) comporte un gestionnaire des paramètres de filiales (Subsidiary Settings Manager). De votre côté, demandez à chaque banque le format exact de ses relevés, version comprise.

Étape 3 : créer un utilisateur d'intégration dédié

L'accès du connecteur est rattaché à un utilisateur NetSuite et à un rôle. Si cet utilisateur est la comptable qui quittera l'entreprise l'an prochain, la désactivation de son compte coupera la connexion. Un utilisateur réservé à l'intégration, créé par l'administrateur, écarte ce risque.

Étape 4 : activer les fonctionnalités NetSuite requises

Pour un connecteur par API comme celui d'Agicap, l'administrateur active trois fonctionnalités : REST Web Services, OAuth 2.0 et SuiteAnalytics Workbook. Chacune joue un rôle précis. La première autorise les échanges, la deuxième gère l'authentification et la troisième permet les requêtes de lecture des données.

Étape 5 : mettre en place l'authentification par certificat

L'éditeur fournit un certificat, sorte de carte d'identité numérique du connecteur. L'administrateur le charge dans NetSuite et l'associe à l'utilisateur dédié et à son rôle. Aucun mot de passe ne circule entre les deux logiciels, et l'accès peut être retiré à tout moment depuis NetSuite.

Étape 6 : faire correspondre les entités, une étape irréversible

L’outil de trésorerie doit savoir à quelle entité de son côté correspond chaque entité paramétrée dans NetSuite. Relisez cette correspondance avec votre interlocuteur avant de la valider. Chez Agicap, elle ne peut plus être modifiée ensuite : une erreur oblige à recréer la connexion. Les entités inactives dans NetSuite n’ont pas besoin d’y figurer.

Étape 7 : contrôler la première remontée, puis activer les flux un par un

Commencez le contrôle par une seule entité. Les factures doivent y apparaître avec les mêmes montants et devises que dans NetSuite. Sur un compte volumineux, la première collecte prend plus de temps, car elle rapatrie l'historique. Chez Agicap, il couvre par défaut les documents modifiés depuis moins d'un an. Activez ensuite les autres flux un à un, en terminant par les échanges SFTP, qui demandent une configuration propre.

Comment se déroule la connexion avec Agicap

Agicap a développé et maintient en interne son propre connecteur NetSuite, qui fait partie de sa solution de connectivité bancaire et ERP. Votre administrateur installe la SuiteApp « Agicap for NetSuite », qui crée un rôle limité aux droits nécessaires. Comptez environ 30 minutes pour l'installation, l'activation des fonctionnalités et le formulaire de connexion dans Agicap. 

Les documents commerciaux sont ensuite mis à jour deux fois par jour, les autres flux une fois par jour, et une mise à jour manuelle reste possible à tout moment. Cette fréquence concerne les factures, qui évoluent peu d'heure en heure. Les soldes et mouvements bancaires suivent un autre circuit, la connexion bancaire.

Les fichiers, eux, transitent par SFTP. Agicap héberge ce serveur pour les relevés comme pour les fichiers de paiement. Côté paiements, les fichiers NetSuite suivent vos circuits de validation dans Agicap, qui les transmet aux banques en EBICS TS ou en host-to-host. Si le format n'est pas accepté par la banque du compte, Agicap l'importe « à préparer » et le convertit dans un format accepté. L'envoi des fichiers depuis NetSuite se planifie librement : fixez-le avant l'heure limite de traitement (cut-off) de chaque banque. Agicap peut aussi renvoyer dans NetSuite les écritures du journal de banque et les paiements rapprochés. Le détail des flux et des prérequis figure sur la page intégration NetSuite x Agicap.

En pratique : le cas FinQuery

FinQuery, éditeur de logiciels comptables détenu par un fonds dans le cadre d'un LBO, suivait sa trésorerie dans des fichiers Excel actualisés à la main. Les chiffres disponibles au moment de décider avaient une semaine de retard. 

Depuis la mise en place d'Agicap, ses comptes bancaires sont agrégés chaque jour. Les écritures et les factures clients et fournisseurs arrivent de NetSuite pour les prévisions à court terme. Dès la première exécution, plus de 95 % des transactions bancaires ont été catégorisées automatiquement, selon la fiche client FinQuery.

Les erreurs qui bloquent la mise en place

Quatre situations reviennent souvent, et toutes se préviennent avant le démarrage.

Un format de relevé que NetSuite ne lit pas

Les relevés arrivent sur le serveur, mais NetSuite ne les importe pas. En France, la cause tient souvent à un fichier CFONB 120, ou à un camt.053 qui n'est pas encodé en UTF-8. Un camt.053 peut aussi échouer en entier lorsqu'un seul code d'opération manque dans la configuration du parser. 

Ces codes décrivent la nature de chaque mouvement : virement reçu, prélèvement, frais. Dans un camt.053, il s'agit du code ISO à trois niveaux (domaine, famille, sous-famille), complété en France par le code opération CFONB. NetSuite les associe à ses types de transactions, qui servent à ses règles de rapprochement. Faites lister par chaque banque les codes qu'elle utilise.

Une correspondance entre entités validée trop vite

Si une entité NetSuite est rattachée à la mauvaise entité de l’outil de trésorerie, ses factures et ses écritures remontent au mauvais endroit. La correspondance n’étant plus modifiable, seule une nouvelle connexion corrige l’erreur. Faites relire la liste par la personne qui connaît la structure juridique du groupe. 

Des tiers en doublon dans NetSuite

Quand un même fournisseur existe sous deux fiches, le paiement rapproché dans l'outil de trésorerie ne retrouve pas la bonne. NetSuite rejette alors l'export, car la facture et le tiers ne pointent pas vers le même enregistrement. Dédoublonnez clients et fournisseurs avant d'activer le retour des paiements.

Deux sources bancaires pour un même compte

Supposons que NetSuite reçoive déjà les relevés par sa propre connexion bancaire, comme la SuiteApp Bank Feeds. Si l'outil de trésorerie lui envoie aussi les siens, le même mouvement apparaît deux fois parmi les opérations à rapprocher. Fixez une seule source par compte bancaire. Consignez cette règle dans la documentation du projet.

Vérifier la compatibilité de votre environnement NetSuite

Avant un premier rendez-vous avec un éditeur, réunissez quatre informations : l'édition de NetSuite, les filiales actives, le format de relevé de chaque banque et le canal d'exécution des paiements. Une seule séance suffit ensuite pour choisir les flux. Elle fixe aussi leur ordre d'activation.

Demandez une démo Agicap pour passer en revue votre configuration NetSuite

Essayer gratuitement

Questions fréquentes sur NetSuite et la trésorerie

L’outil NetSuite peut-il remplacer un outil de gestion de trésorerie ?

Pour une entité unique travaillant avec une ou deux banques, les fonctions de cash management de NetSuite couvrent l'essentiel : import des relevés, rapprochement et fichiers de virement. Avec plusieurs entités, plusieurs banques et des paiements à valider auprès de chacune, un outil dédié prend en charge la trésorerie quotidienne et l'exécution des paiements. L'ERP garde alors son rôle de référence comptable.

 

Faut-il garder la connexion bancaire native de NetSuite ?

Pas pour les comptes que l'outil de trésorerie gère déjà. Une seule connexion bancaire, côté trésorerie, peut alimenter les deux logiciels si elle renvoie les relevés vers NetSuite. Vous évitez ainsi les doublons. Conservez la connexion native uniquement pour les comptes que l'outil de trésorerie ne couvre pas.

 

Qui doit intervenir dans le projet ?

Quatre interlocuteurs suffisent. Le DAF ou le trésorier définit les flux et valide la correspondance des filiales. L'administrateur NetSuite installe les extensions et gère les accès, tandis que les banques fournissent les relevés au bon format et les contrats EBICS. L'éditeur configure sa partie et valide la connexion. Organisez une première réunion commune avec ces quatre acteurs avant toute installation dans NetSuite.