Intégration Spendesk à Pennylane

L’erreur vient du fait que ton post contient du HTML (notamment les balises ``), et la plateforme (forum/communauté Pennylane) refuse certaines balises (“h4”, “p”, “span”…). En général, ça arrive quand on copie/colle depuis Notion / Google Docs / un éditeur riche.

Ce que tu dois changer (simple)

• Supprime tous les `` → remplace par de vrais retours à la ligne (Entrée).
• Évite les mises en forme “rich text” copiées depuis Notion.
• Le plus sûr : copier depuis un éditeur texte brut (Notes / Notepad) puis remettre une mise en forme simple.
• Utilise uniquement :
  • des retours à la ligne
  • des tirets pour les listes (- )
  • éventuellement du “gras” si le forum le supporte en Markdown, mais sinon reste sobre.

Bonjour à l’équipe Pennylane et à la communauté,

Nous utilisons l’intégration Pennylane Connect avec Spendesk et rencontrons un problème structurant sur l’analytique.

1. Contexte / besoin

Côté Spendesk, nous utilisons 2 dimensions analytiques distinctes :

• Cost centre
• Expense category

Côté Pennylane, nous souhaitons conserver exactement 2 axes (bi-dimensionnel) :

• Famille analytique = équivalent Cost centre
• Catégorie analytique = équivalent Expense category

Objectif : que l’import Spendesk → Pennylane respecte notre référentiel analytique et reste “maîtrisé” (pas de création de nouvelles valeurs non contrôlées).

1. Problème constaté (limitation actuelle)

D’après le support, l’intégration :

• aplatit les 2 dimensions Spendesk (Cost centre et Expense category) en un seul niveau côté Pennylane, importé comme tags analytiques
• ne permet pas de mapper explicitement :
  • Cost centre → Famille analytique
  • Expense category → Catégorie analytique
• si plusieurs tags sont présents sur une facture, Pennylane applique automatiquement une répartition à parts égales (ex : 4 tags → 25% / 25% / 25% / 25%)

Dans notre cas, nous avons aussi des tags servant à suivre des dates de début/fin de prestation (CCA). Nous ne souhaitons pas que ces tags soient importés comme analytique (ni qu’ils déclenchent une ventilation automatique).

1. Impacts opérationnels

• Perte d’information : impossible de distinguer “Cost centre” vs “Expense category”
• Analytique inexploitable / bruitée : multiplication de tags, reporting moins fiable
• Ventilation automatique non souhaitée : la division à parts égales ne reflète pas la réalité
• Risque de dérive du référentiel : création de valeurs non contrôlées

1. Cas connexe : dates de prestation importées en tags

Si dans Spendesk les dates de début/fin de prestation sont configurées comme champs analytiques, elles sont importées comme tags dans Pennylane.

De notre côté, ces dates sont des métadonnées, pas de l’analytique.

1. Demandes / améliorations souhaitées

Nous aimerions savoir si Pennylane prévoit (ou peut considérer) des évolutions du connecteur :

• Support natif de 2 dimensions analytiques Spendesk
• Mapping configurable :
  • Cost centre → Famille analytique
  • Expense category → Catégorie analytique
• Mode “référentiel strict” / gouvernance :
  • option pour désactiver la création automatique de tags/valeurs analytiques
  • et/ou mode bloquant si la valeur n’existe pas (erreur ou mise en attente)
• Contrôle de la ventilation automatique :
  • option pour désactiver la répartition à parts égales quand plusieurs tags existent
  • ou option pour choisir une règle (ex : “un tag principal”, “pas de ventilation par défaut”, etc.)
• Traitement des champs non analytiques :
  • possibilité d’exclure certains champs Spendesk (ex : dates de prestation) de l’import analytique / tags

1. Contournements identifiés (mais insuffisants)

Le support nous a indiqué qu’il faut éventuellement :

• standardiser / limiter les catégories dans Spendesk
• nettoyer/archiver régulièrement les catégories non utilisées dans Pennylane
• reconfigurer les dates de prestation comme champs “standard” plutôt qu’analytique côté Spendesk

Ces solutions aident, mais ne résolvent pas le sujet principal : conserver 2 axes et éviter une dérive du référentiel.

Merci d’avance pour vos retours / bonnes pratiques, et pour la visibilité produit/roadmap sur ce point.

Bien cordialement,

Pascal Ruan

Accounting Lead – Trustpair