HubSpot, Stripe et NetSuite rapprochés au centime près pour une société SaaS B2B

Le problème

Le moteur de revenus reposait sur HubSpot pour le pipeline, Stripe pour les abonnements et les cartes, et NetSuite pour le grand livre et l'ASC 606. Reliés par un connecteur en glisser-déposer et des exports CSV, les trois systèmes divergeaient en permanence : les échéanciers de facturation s'écartaient des conditions contractuelles du CRM, les rétrofacturations n'atteignaient jamais le solde client dans l'ERP, et à chaque fin de mois l'équipe finance passait huit jours ouvrés à rapprocher à la main les virements Stripe du compte bancaire. Les produits constatés d'avance vivaient dans un classeur d'amortissement hors ligne.

Ce que nous avons fait

Nous avons remplacé le connecteur par des points d'accès directs et authentifiés et un moteur de règlement. Une affaire gagnée dans HubSpot crée dans NetSuite le client et la commande client, valide le numéro fiscal, la devise et la filiale, et crée le client Stripe et l'échéancier d'abonnement. Chaque webhook de paiement Stripe est décomposé : un paiement client pour le montant brut, un débit du compte d'attente pour le dépôt net exact, et les frais de traitement comptabilisés en charges dans la même transaction. Les lignes de l'affaire sont rattachées aux règles de reconnaissance du revenu à la clôture, de sorte que l'arrangement ASC 606 et ses écritures d'amortissement sont créés sans classeur. Chaque payload est haché avec l'identifiant d'événement Stripe, si bien qu'un webhook rejoué met à jour l'enregistrement déjà créé.

Ce schéma est l'un des workflows conçus, avec ses points de contrôle et les preuves associées.

Fonctionnement du mécanisme

1. L'écart de frais de passerelle

   Un connecteur générique enregistre un paiement de 10 000 $ face à une facture de 10 000 $, mais Stripe verse 9 710 $ après 290 $ de frais, et le rapprochement bancaire devient un exercice d'investigation au centime près. Le listener de règlement lit la transaction de solde et comptabilise brut, net et frais en trois lignes d'une même écriture, de sorte que le versement correspond au centime près le jour où il arrive.

2. Allocation multi-éléments ASC 606

   Les contrats d'entreprise regroupent services de mise en œuvre, licences annuelles et paliers de consommation qui sont reconnus selon des calendriers différents, quelle que soit la facturation du client. Les lignes HubSpot sont rattachées aux règles de revenu NetSuite à la signature : l'arrangement, les soldes différés et les écritures d'amortissement existent dès le jour du contrat, que le client paie annuellement d'avance ou mensuellement à terme échu.

3. Reprises idempotentes et déduplication des webhooks

   Les réseaux tombent en panne et Stripe réessaie. Chaque payload entrant est haché en SHA-256 par rapport à l'identifiant d'événement Stripe et consigné dans un enregistrement d'audit encadré. Un événement en double retrouve l'enregistrement existant, renvoie HTTP 200 à Stripe et ne comptabilise rien deux fois.

Résultats

À retenir

1. Votre CRM sert à vendre ; votre ERP sert à établir la vérité

   Les commerciaux ne devraient jamais gérer les codes de taxe du grand livre ni les taux de change. Saisissez les conditions commerciales dans le CRM et traduisez-les en règles comptables dans le code.

2. Séparer les frais de passerelle dès l'ingestion

   Une intégration qui comptabilise les paiements bruts et laisse les frais à la clôture mensuelle revient à payer l'équipe finance pour jouer les calculatrices humaines.

3. Les endpoints directs l'emportent sur le middleware multi-sauts

   Des RESTlets authentifiés avec validation de schéma offrent une comptabilisation en moins d'une seconde, sans abonnement à un middleware et avec un contrôle complet sur ce qui parvient au grand livre.

Rétrospective composite ; le client est présenté comme un archétype et les chiffres illustrent le mécanisme. À lire aussi : Intégration native vs middleware iPaaS : le péage récurrent qui se transfère à la clôture