Importer en lot des factures fournisseurs dans Pennylane

Pennylane importe les factures fournisseurs en lot par plusieurs voies natives : glisser-déposer multi-fichiers depuis l'interface web, e-mail dédié à l'adresse achat de l'entreprise, connecteurs portails fournisseurs (Amazon Business, Cdiscount Pro, Manomano Pro et autres), application mobile avec un plafond de 20 factures par envoi, import d'écritures Excel ou CSV, et API. L'OCR natif accepte les fichiers PDF, JPEG et PNG, avec une résolution minimale de 400×400 pixels pour les images. Quand le besoin sort de ces voies (reprise d'historique en masse, relevé fournisseur agrégeant plusieurs factures, scan mobile en dessous du seuil de résolution, dédoublonnage d'un backlog partiellement déjà saisi), on prépare en amont un Excel d'écritures. Les colonnes attendues sont la date, le fournisseur, le n° de facture, les montants HT, TVA et TTC ; la voie d'import en masse de Pennylane convertit ensuite chaque ligne en pièce comptable individuelle.

Cet article est écrit pour les cas où l'OCR natif ne suffit pas. L'OCR de Pennylane est solide pour le flux courant, mois après mois, sur des PDF supplier propres : les contraintes documentées sur help.pennylane.com (formats acceptés, seuil 400×400 px, plafond mobile de 20 factures par lot, comportement face aux relevés multi-factures) sont des choix produits cohérents avec un OCR de production, pas des défauts. Le besoin de staging amont apparaît au moment où l'on doit absorber une situation hors flux nominal, typiquement à l'occasion d'une bascule cabinet, d'une migration vers Pennylane à mi-exercice, ou d'un fournisseur récurrent qui ne livre que des relevés.

La mécanique sur laquelle repose le reste de l'article est une caractéristique documentée de Pennylane : l'import en masse d'écritures Excel ou CSV crée des écritures comptables qui sont automatiquement converties en pièces comptables (Invoice records) côté plateforme. Cette voie importe des données structurées, pas les fichiers PDF d'origine ; les pièces source restent gérées séparément, selon le besoin du cabinet, en archive externe ou attachées a posteriori aux écritures créées. C'est précisément cette mécanique qui rend possible un workflow de staging : on extrait les données utiles d'un PDF (ou d'une image refusée par l'OCR), on les met en forme dans un Excel structuré, et on laisse la voie d'import en masse de Pennylane prendre le relais pour matérialiser chaque ligne en pièce du journal des achats. Pour un cabinet ou un dirigeant qui cherche à importer factures Pennylane en lot dans des conditions que le glisser-déposer OCR n'absorbe pas proprement, la suite décrit quatre workflows concrets, chacun aboutissant à une voie d'import documentée par Pennylane.

Quatre limites de l'OCR natif Pennylane qui rendent un staging amont nécessaire

Quatre situations sortent du périmètre que le glisser-déposer Pennylane traite proprement. Toutes les quatre se rencontrent en cabinet et chez les dirigeants en pleine bascule comptable ; aucune n'est marginale.

Reprise d'historique de 100 factures et plus. L'OCR natif est dimensionné pour le flux courant : un cabinet qui reçoit dix à trente factures par jour pour un client, ou un dirigeant qui traite ses pièces au fil de l'eau. Il n'est pas conçu pour absorber un backlog en une fois, ce que confirme indirectement le plafond mobile de 20 factures par envoi documenté dans help.pennylane.com. Quand le client arrive avec dix mois de PDF supplier à intégrer avant la première clôture sous Pennylane, le glisser-déposer fonctionne mais devient une file d'attente humaine : chaque pièce passe par la file OCR, génère son brouillon de facture, et attend une revue manuelle. Sur un volume de 100, 200 ou 500 pièces, la mécanique tient mais consomme un temps cabinet hors de proportion avec le travail comptable réel.

Relevés fournisseurs multi-factures (statement of account). Un fournisseur récurrent (un distributeur, un grossiste, un prestataire en abonnement) envoie souvent un relevé mensuel qui consolide les factures du mois dans un PDF unique. Le PDF contient en réalité huit ou douze factures distinctes, chacune avec son numéro, sa date et son montant. Pennylane lit le document comme une seule pièce et tente de rapprocher le total à un seul mouvement bancaire. Côté comptabilité, ce n'est pas la lecture qu'il faut : chaque ligne du relevé est une pièce comptable autonome qui doit passer individuellement au journal des achats, et le rapprochement bancaire se fait facture par facture, pas sur le total agrégé.

Scans en dessous de 400×400 pixels. L'OCR natif Pennylane refuse à l'upload les images qui ne passent pas le seuil de 400×400 pixels. C'est une limite intentionnelle : en dessous de cette résolution, la fiabilité d'extraction n'est plus garantie, et la plateforme préfère rejeter le fichier plutôt que produire un brouillon douteux. Le problème pratique reste entier pour le dirigeant qui reçoit régulièrement des photos prises au mobile par les opérationnels de terrain, ou pour le cabinet qui hérite de scans archivés en basse résolution chez un client. Le fichier ne passe pas, et redemander un document propre au fournisseur n'est pas toujours possible.

Dédoublonnage à grande échelle. Pennylane dédoublonne automatiquement les fichiers strictement identiques par hash de fichier : le second upload est rejeté avec un message d'erreur explicite. Sur les quasi-doublons (même contenu mais fichier différent, par exemple le même PDF re-scanné, ou la même facture issue d'un export comptable différent), Pennylane ne rejette pas mais lève une alerte de similarité de contenu que l'utilisateur traite pièce par pièce dans la file. La mécanique est correcte sur quelques pièces ; sur un backlog où une partie a déjà été saisie côté Pennylane et où le reste arrive d'une autre source, le traitement manuel des alertes devient le goulot d'étranglement réel de l'opération.

Ces quatre cas ne sont pas des défauts à compenser, ce sont des frontières du flux nominal. Et ils ont un horizon. La réforme de la facturation électronique en France crée une obligation de réception des factures électroniques au 1er septembre 2026, tout assujetti à la TVA confondu, par l'intermédiaire d'une plateforme agréée. Une fois cette réception obligatoire en place, la part des factures arrivant en PDF supplier libre va décroître, et avec elle la fréquence des situations décrites ici. Mais le calendrier laisse plus d'un an pendant lequel les backlogs 2024-2025-2026 partiellement saisis, les relevés fournisseurs en PDF mensuel et les scans mobiles continueront d'exister tels quels. Le staging amont est la réponse pour cette fenêtre de transition, et elle reste utile au-delà pour les fournisseurs qui n'auront pas migré dans les délais.

---

Reprise d'historique : préparer un Excel d'écritures pour l'import en masse Pennylane

Le workflow de reprise d'historique repose sur la voie d'import en masse d'écritures Pennylane et sur le fait, documenté côté plateforme, que chaque ligne d'écriture importée est convertie automatiquement en pièce comptable côté journal des achats. Cette mécanique est la clé : elle permet de pousser plusieurs centaines de factures fournisseurs en une seule opération, sans repasser chaque pièce par la file OCR.

Le fichier cible suit une logique simple : une ligne par facture, avec les colonnes que Pennylane attend pour matérialiser une pièce comptable propre. Date de facture, identifiant du fournisseur (raison sociale et compte fournisseur côté plan comptable client si le cabinet le tient), n° de facture, montant HT, taux de TVA, montant de TVA, montant TTC. Le compte d'achat à mouvementer (606, 607, 622 ou autre selon la nature de la dépense) est ajouté quand le cabinet veut piloter la ventilation côté staging plutôt que la laisser se faire en revue post-import. Le format suit ce que Pennylane accepte sur la voie d'import en masse, Excel ou CSV.

Reste l'étape qui transforme un dossier de PDF supplier en lignes Excel exploitables. Sur un volume de 100, 200 ou 500 pièces, la saisie manuelle ne tient pas, et l'OCR natif Pennylane n'est pas l'outil au bon endroit du flux. Une voie d'extraction prompt-driven, dans laquelle le cabinet décrit en langage naturel les colonnes attendues et les règles métier propres au dossier, produit le fichier directement à la forme qu'attend la voie d'import en masse Pennylane. C'est précisément ce que fait l'extraction de données de factures par IA appliquée à ce cas : on dépose le batch de PDF supplier, on indique les colonnes (date, fournisseur, n° facture, HT, TVA, TTC, plus toute mention obligatoire ou règle de classification métier que le cabinet veut imposer), et on récupère un Excel structuré prêt à passer dans l'import en masse. Le résultat pour le cabinet est un changement d'ordre de grandeur sur le temps consommé par la reprise.

Avant de pousser le fichier dans Pennylane, le cabinet vérifie ligne à ligne que chaque facture porte les mentions obligatoires exigées par l'article 242 nonies A du CGI : numéro de facture, date d'émission, identification du fournisseur (dénomination sociale, adresse, n° SIREN ou SIRET, n° de TVA intracommunautaire le cas échéant), identification du client, désignation des biens ou services, montant HT, taux et montant de TVA, montant TTC. Une ligne incomplète sur une mention obligatoire peut passer techniquement l'import mais posera problème en cas de contrôle ; mieux vaut traiter le manque côté staging, en revenant à la pièce source, plutôt qu'après création de l'écriture côté Pennylane.

Le push dans Pennylane. L'import en masse d'écritures se fait depuis l'espace dédié de Pennylane. La plateforme renvoie une file de messages : lignes refusées (format incorrect, champ obligatoire manquant), comptes fournisseurs à créer si le compte n'existe pas encore dans le plan comptable du dossier client, alertes de doublon par similarité de contenu (qui devraient déjà avoir été traitées côté staging si le dédoublonnage en amont a été appliqué). Le cabinet vide cette file avant de valider, puis chaque ligne d'écriture est convertie en pièce comptable du journal des achats.

Les PDF source. La voie d'import en masse importe des écritures, pas les fichiers PDF eux-mêmes. Selon la pratique du cabinet, les PDF d'origine restent en archive externe (Drive, GED cabinet, archive locale du client) avec une référence au n° de pièce Pennylane, ou ils sont attachés a posteriori aux pièces comptables créées. Pour les fournisseurs qui proposent un portail (Amazon Business, Cdiscount Pro, Manomano Pro et autres), les connecteurs Pennylane récupèrent les pièces source à la demande, ce qui peut compléter le dispositif sans repasser par l'upload.

La logique de reprise d'historique vaut au-delà de l'AP : un cabinet qui prend la main sur un dossier client a souvent à reprendre, dans la même fenêtre, les bulletins de paie des mois antérieurs pour aligner les déclarations DSN. Le workflow d'extraction suit la même mécanique côté paie ; la ressource utile pour extraire les bulletins de paie pour reprendre l'historique paie d'un client cabinet couvre ce volet à part entière.

Découper un relevé fournisseur multi-factures en pièces comptables distinctes

Un relevé fournisseur (statement of account) est un PDF unique qui consolide plusieurs factures émises sur une période donnée, en général le mois écoulé. La structure est familière : un en-tête fournisseur, un tableau de lignes (date, n° de facture, montant HT, montant TTC, statut payé / en attente), et un total agrégé en bas. Côté comptabilité, chaque ligne du tableau est une facture autonome qui doit être passée individuellement au journal des achats, et le rapprochement bancaire se fait facture par facture sur l'extrait de compte.

Ce que Pennylane voit. La plateforme reconnaît le PDF comme une seule pièce comptable. L'OCR extrait l'en-tête fournisseur et le total agrégé, et le rapprochement bancaire tente de matcher ce total à un mouvement unique sur le compte. La logique tient pour les rares cas où le client a payé l'intégralité du relevé en un seul virement ; elle casse dès que le client paye facture par facture au fil du mois, ce qui est la norme. Le journal des achats reçoit alors une seule pièce de plusieurs milliers d'euros qui ne se rapproche d'aucun mouvement bancaire individuel, et le cabinet doit reprendre la main pour rééclater manuellement.

Le traitement consiste à transformer le PDF du relevé en N lignes Excel, une par facture listée dans le tableau, chacune portant la date, le n°, le HT, la TVA et le TTC de la facture. Le nom du fournisseur est commun à toutes les lignes du relevé et se répète en colonne. Si le relevé descend au niveau ligne (description du produit ou du service par facture), ce détail peut être conservé dans une feuille séparée pour archivage analytique, ou agrégé dans une cellule unique par facture si le cabinet ne pilote pas la ventilation analytique au niveau ligne. La forme finale du fichier reprend la structure d'écritures du workflow de reprise d'historique : une ligne par pièce, prête pour l'import en masse Pennylane.

C'est typiquement le cas où l'extraction prompt-driven montre sa flexibilité. Le prompt envoyé à l'outil de staging décrit le document tel qu'il est : « le PDF est un relevé fournisseur, créer une ligne par facture listée dans le tableau récapitulatif, répéter le nom du fournisseur sur chaque ligne, extraire date, n° de facture, HT, TVA, TTC, ignorer la ligne de total et toute page de bordereau d'envoi ». Le fichier produit contient les N factures sous forme de lignes d'écritures distinctes, exactement à la forme qu'attend l'import en masse Pennylane.

Le fichier Excel passe ensuite par la voie d'import en masse d'écritures, comme pour la reprise d'historique. Chaque ligne devient une pièce comptable individuelle dans le journal des achats, et le rapprochement bancaire retrouve sa logique facture-par-facture : chaque virement émis par le client se rapproche d'une pièce, sans rééclatement manuel.

Une exception utile à connaître concerne les fournisseurs qui proposent un connecteur Pennylane (Amazon Business, Cdiscount Pro, Manomano Pro et autres opérateurs marchands grand compte). Dans ce cas, le portail récupère chaque facture individuellement à la source, et le découpage de relevé devient inutile pour ce fournisseur. Le workflow Excel décrit ici cible les fournisseurs qui n'ont pas de portail connecté, ce qui couvre l'essentiel des fournisseurs de services BtoB et des grossistes régionaux.

Le découpage de relevé suit la même logique d'extraction structurée que le côté trésorerie. Quand le client envoie aussi des relevés bancaires PDF à intégrer sur la même période (typiquement à l'occasion d'une migration en milieu d'exercice), la conversion d'un relevé bancaire suit un workflow miroir : convertir un relevé BNP Paribas PDF en Excel pour Pennylane ou, selon la banque du client, convertir un relevé Crédit Agricole PDF en Excel pour Pennylane — la mécanique d'extraction est la même, la voie d'import côté Pennylane bascule vers les opérations bancaires plutôt que vers les écritures d'achat.

Récupérer les données d'un scan en dessous de 400×400 px sans passer par l'OCR natif

Le seuil 400×400 px de Pennylane est ferme : le fichier image qui ne le passe pas est rejeté à l'upload, sans création de brouillon. C'est une décision produit cohérente, en dessous de cette résolution la fiabilité d'extraction se dégrade au point de produire plus de bruit que d'information. Le bon réflexe n'est pas de chercher à contourner la limite par redimensionnement ou interpolation du fichier source, qui ne crée pas de pixels d'information utile.

Le contournement honnête. Une voie d'extraction prompt-driven, séparée de l'OCR Pennylane, peut typiquement lire des images en dessous du seuil dès lors que le contenu reste lisible à l'œil humain. La calibration des modèles d'extraction modernes ne s'aligne pas sur le même seuil que celui que Pennylane a fixé pour son flux d'upload, et un scan mobile pris dans des conditions médiocres reste souvent exploitable pour les champs comptables (n° de facture, date, fournisseur, HT, TVA, TTC) même quand l'image elle-même est sous résolution. Notre outil traite spécifiquement ce cas : il interprète des données depuis des scans de qualité réduite et des photos prises au mobile, et peut être instruit de privilégier les annotations manuscrites sur le texte imprimé d'origine si le bon de commande client est annoté à la main.

Côté Pennylane, l'image n'arrive jamais dans la plateforme. Les données extraites partent dans l'Excel d'écritures et c'est ce fichier qui entre par la voie d'import en masse. La pièce comptable créée côté journal des achats est conforme, le rapprochement bancaire fonctionne, et la limite OCR de 400×400 px n'a jamais été un blocage à traiter. Si le cabinet veut conserver une trace du document source pour archivage ou contrôle, l'image basse résolution est stockée hors Pennylane (Drive, GED cabinet, archive locale), avec une référence au n° de pièce créée dans le journal.

Le workflow décrit traite les scans dégradés-mais-lisibles, qui couvrent l'écrasante majorité des photos mobiles reçues en pratique. Si le scan est dégradé au point que l'œil humain doit deviner les chiffres, aucune voie automatisée ne le résoudra de façon fiable et la bonne réponse reste la demande d'un document propre au fournisseur.

Dédoublonner un backlog avant import dans Pennylane

Pennylane gère deux mécaniques de dédoublonnage qu'il est utile de séparer dans la tête, parce qu'elles se comportent différemment et qu'elles n'ont pas la même incidence sur un import en masse.

Le dédoublonnage par hash de fichier. Pennylane refuse à l'upload tout fichier strictement identique à un fichier déjà importé, message d'erreur explicite à l'appui. C'est un dédoublonnage par signature binaire : deux exports du même PDF ne donneront pas le même hash si le fichier a été ré-enregistré, ré-OCRisé en local ou retraité par un outil intermédiaire, et la mécanique passera à côté de quasi-doublons que l'œil humain reconnaît immédiatement comme identiques.

L'alerte de similarité de contenu. Sur les pièces qui ne sont pas binairement identiques mais dont l'OCR Pennylane reconnaît le contenu (même fournisseur, même n° de facture, même montant), Pennylane ne rejette pas mais lève une alerte que l'utilisateur traite manuellement, pièce par pièce, dans la file de revue. Le fonctionnement est correct sur quelques pièces et utile pour attraper les ressaisies accidentelles. Sur un backlog de 100 ou 200 factures dont une partie a déjà été saisie côté Pennylane par le client avant la reprise par le cabinet, le traitement manuel de chaque alerte devient le goulot réel de l'opération, plus coûteux que la saisie de la facture elle-même.

Le dédoublonnage côté staging. L'idée est de retirer les doublons avant le push, pour que Pennylane ne reçoive que des écritures qui ne sont pas déjà dans le journal des achats du dossier. La mécanique tient en deux étapes :

• Exporter la liste des factures déjà saisies depuis Pennylane. L'export Excel ou CSV des écritures du journal des achats, filtré sur la période concernée par la reprise, donne au minimum trois informations utiles par pièce : n° de facture, fournisseur, montant TTC. Cette liste devient la table de référence pour le matching.
• Croiser le batch avec l'export. Avant de pousser l'Excel d'écritures préparé pour la reprise d'historique ou pour le découpage de relevé, on croise chaque ligne du batch avec l'export Pennylane sur la combinaison n° de facture + fournisseur + montant TTC. Les lignes qui matchent sont retirées du batch ; les lignes qui ne matchent pas partent en import.

Le résultat net est qu'aucune alerte de similarité de contenu n'est levée côté Pennylane, parce qu'aucun doublon n'arrive à la voie d'import. Le cabinet ne traite pas une file de revue ; il traite un import propre, et les doublons par contenu (la même facture issue d'une autre source que le hash de fichier ne pouvait pas attraper) ont été filtrés en amont.

Une réserve sur le critère de matching. La combinaison n° de facture + fournisseur + montant TTC est robuste pour la quasi-totalité des fournisseurs, parce que le n° de facture est par construction unique côté émetteur et que les mentions obligatoires l'imposent. On rencontre néanmoins, en pratique, quelques fournisseurs qui réutilisent un même numéro sur plusieurs factures (typiquement de petits indépendants ou des artisans qui repartent à 1 chaque année), ou des factures issues d'imports automatiques d'un système tiers qui réécrivent le n° de pièce. Pour ces cas, ajouter la date de facture au critère de matching couvre les rares ambiguïtés résiduelles.

---

Tirer le pipeline jusqu'à la trésorerie : le côté banque du même chantier

Pour le cabinet en pleine reprise de dossier, l'AP n'est qu'un volet du chantier. Sur la même fenêtre arrivent les relevés bancaires PDF de la période concernée, les justificatifs mensuels à consolider en une note de frais Excel avec ventilation TVA récupérable et comptes 625 avant passage au journal des OD, et selon la mission, les bulletins de paie à reprendre pour aligner les déclarations DSN du client. Les flux suivent le même schéma : extraction prompt-driven depuis le PDF source vers un Excel structuré, contrôles côté staging, push dans la voie d'import en masse Pennylane qui correspond. La voie côté banque alimente le module de rapprochement plutôt que le journal des achats, mais le besoin amont est identique.

Pennylane est conçu pour le flux courant et le fait bien. Pour les ruptures de flux (onboarding cabinet, migration en milieu d'exercice, fournisseurs récurrents en relevé, scans hors format, dédoublonnage d'un backlog partiellement déjà saisi), un staging amont qui tient les voies d'import en masse documentées par Pennylane permet de garder la plateforme comme cible sans se battre contre ses limites natives.