Extraire les données des PDF de demande d'achat — N'importe quel formulaire interne d'entreprise en Excel structuré, sans modèle
Une demande d'achat est un document interne — et les documents internes sont les moins standardisés. Contrairement aux factures ou bons de commande qui suivent des conventions sectorielles, chaque entreprise conçoit son propre formulaire de toutes pièces. L'OCR basé sur des modèles nécessite un nouveau modèle pour chaque mise en page interne. L'extraction par nom de colonne lit selon le sens du champ — ainsi « Demandé par », « Service » et « Approuvé par » sont trouvés n'importe où sur le formulaire de n'importe quelle entreprise, en 5 secondes par page.
5–10 s par page · Jusqu'à 99 % de précision sur texte imprimé · Aucun modèle par entreprise
Ce que vous pouvez extraire d'une demande d'achat
Saisissez les noms de colonnes dont vous avez besoin — l'IA trouve ces valeurs dans n'importe quel formulaire interne en comprenant le sens des champs, pas leurs coordonnées. La même liste fonctionne pour le formulaire SAP de l'ingénierie, la feuille Excel du marketing et la demande papier scannée des services généraux.
En-tête et informations d'approbation
Champs des lignes d'article
Ce n'est pas une liste exhaustive — saisissez n'importe quel champ présent dans vos formulaires de demande d'achat. L'IA lit le document pour trouver ce que vous demandez.
Les documents internes sont les moins standardisés — et cela brise l'OCR basé sur des modèles
Une facture suit des conventions vieilles de plusieurs décennies — montants à droite, nom du fournisseur en haut, dates près du numéro de facture. Une demande d'achat est un document interne que chaque entreprise conçoit de toutes pièces. L'OCR basé sur des modèles, qui repose sur des zones fixes et la correspondance d'étiquettes, a besoin d'un nouveau modèle pour chaque formulaire d'entreprise. L'extraction par nom de colonne lit par sens sémantique, pas par mise en page — elle fonctionne donc sur tous sans configuration par entreprise.
Le Problème
Contrairement aux factures, qui suivent les mêmes conventions structurelles, qu'elles viennent de Microsoft ou d'un consultant freelance, les formulaires de demande d'achat sont entièrement internes — conçus pour s'adapter au flux d'approbation, à l'intégration ERP et au processus budgétaire de chaque organisation. Une entreprise place le numéro de DA dans l'en-tête en haut à droite avec un code-barres. Une autre l'appelle « ID de demande » dans la marge de gauche. Une troisième l'appelle « N° DA » et le place dans le tableau des lignes. Les outils OCR basés sur des modèles nécessitent une définition de zone distincte pour chaque variante. Si votre organisation traite des demandes d'achat provenant de filiales acquises, de différents services ou de bureaux utilisant encore du papier, vous devez configurer un modèle pour chaque variante — et assurer une maintenance continue lorsque les formulaires changent.
Les documents externes comme les factures standardisent les noms de champs car ils traversent les frontières organisationnelles — les fournisseurs veulent être payés, ils utilisent donc des libellés reconnaissables. Les formulaires internes n'ont pas cette contrainte. Le formulaire d'un service indique « Demandé par », un autre « Demandeur », un troisième « Nom de l'employé ». Les outils basés sur des modèles qui effectuent une correspondance exacte du texte du libellé échouent sur les variantes. Un outil configuré pour trouver « Demandé par » ne retournera rien sur un formulaire qui indique « Demandeur » — même si les deux champs contiennent les mêmes données. Comme les équipes d'approvisionnement sur Reddit le décrivent régulièrement, l'incohérence des formulaires de DA internes entre les services est un point de friction opérationnel persistant — et non un cas marginal isolé.
Une demande d'achat comporte deux niveaux : les champs d'en-tête (N° DA, Service, Approuvé par, Lieu de livraison) et les lignes (Description de l'article, Quantité, Coût unitaire estimé, Total de la ligne, Justification). Pour produire un tableur utilisable, les valeurs d'en-tête doivent se répéter sur chaque ligne d'article. Les outils basés sur des modèles configurent généralement chaque zone indépendamment — l'extraction de l'en-tête et l'extraction du tableau sont des configurations distinctes. Les aligner en une seule sortie avec des champs d'en-tête répétés nécessite un post-traitement dans Excel, ce qui ajoute une étape manuelle entre l'extraction et l'importation ERP.
Comment l'extraction par nom de colonne gère les formulaires internes
Le mécanisme central d'ImageToTable.ai, appelé Extraction personnalisée de colonnes, fonctionne différemment de l'OCR basé sur des modèles. Au lieu de délimiter des zones autour de chaque champ sur un formulaire spécifique, vous saisissez les noms des champs souhaités : « N° PR », « Date de demande », « Nom du demandeur », « Service », « Centre de coût ». L'IA lit l'intégralité du document et localise chaque valeur en comprenant sa signification contextuelle — une chaîne de caractères près du haut du formulaire au format « PR-2024-#### » est un numéro de PR, qu'il apparaisse dans le coin droit, la marge gauche ou à l'intérieur d'un bloc d'en-tête avec un code-barres. La même liste de colonnes fonctionne pour le formulaire de PR généré par Oracle d'une filiale, la feuille papier scannée d'un service hérité, et la sortie SAP d'une nouvelle acquisition — le tout en un seul chargement par lot.
Lorsque vous ajoutez une colonne « Nom du demandeur », l'IA ne recherche pas la chaîne littérale « Nom du demandeur » sur la page. Elle comprend le rôle sémantique : le nom d'une personne dans le contexte de qui a demandé l'achat. La même colonne extrait « Demandé par : Jean Dupont » sur un formulaire, « Demandeur : J. Dupont » sur un autre, et « Nom de l'employé : Jean Dupont » sur un troisième — car l'IA reconnaît les trois comme le même champ, exprimé différemment. C'est la différence cruciale avec l'extraction basée sur des modèles : elle lit comme une personne qui comprend le but du document, pas comme un scanner qui fait correspondre des chaînes d'étiquettes.
Définissez vos colonnes pour inclure à la fois les champs d'en-tête et les champs de lignes d'articles dans une seule liste. L'IA extrait les valeurs d'en-tête une fois et les répète sur chaque ligne d'article. Une demande avec 5 lignes d'articles produit 5 lignes — chacune portant le N° PR, le Service, l'Approbateur et le Lieu de livraison. Les utilisateurs SAP signalent fréquemment que l'écart entre les données du formulaire de PR et le formatage d'importation ERP est là où se produit la majeure partie du travail manuel de retouche — l'extraction par nom de colonne comble cet écart en produisant directement une sortie aplatie avec en-tête répété.
Des formulaires de demande d'achat disparates à un seul tableur consolidé
Si vous recevez des demandes d'achat de plusieurs services, chacune avec un formulaire interne différent, voici à quoi ressemble le flux de travail, du téléchargement à la sortie prête pour l'ERP.
Téléchargez les demandes d'achat — une ou des dizaines, dans n'importe quel format interne
Importez des PDF, des formulaires scannés ou des photos de demandes papier de n'importe quel service. L'ingénierie utilise un PDF SAP généré par machine avec codes-barres. Le marketing soumet un tirage Excel avec annotations manuscrites. Les installations envoient un formulaire carbone interne scanné. Les trois vont dans le même lot de téléchargement. L'outil accepte les formats PDF, JPG, PNG et WebP — les formats peuvent être librement mélangés dans un seul téléchargement. Pour collecter les demandes des bureaux distants ou des services éloignés, générez un Lien de collecte : une URL partageable où n'importe qui peut télécharger des formulaires de demande dans votre file d'attente de traitement en entrant un court code de vérification — aucune inscription requise pour le téléchargeur.
Saisissez les noms de colonnes une fois — ils fonctionnent pour tous les formulaires
Entrez les champs dont vous avez besoin : « N° de demande », « Date de demande », « Nom du demandeur », « Service », « Centre de coût », « Fournisseur », « Description de l'article », « Quantité », « Coût unitaire estimé », « Total ligne », « Justification », « Approuvé par », « Date d'approbation », « Lieu de livraison ». La même liste de colonnes s'applique à la demande SAP de l'ingénierie, au formulaire Excel du marketing et au papier scanné des installations. Pour une validation automatisée des coûts, utilisez une Colonne calculée comme « Vérification total ligne (Quantité × Coût unitaire estimé) » — l'IA compare le total ligne imprimé à la valeur calculée et affiche tout écart. Si vos formulaires de demande n'incluent pas systématiquement un champ Fournisseur, utilisez une Colonne inférée comme « Suggestion de fournisseur (options : basée sur la description de l'article et l'historique des commandes) » pour que l'IA suggère un fournisseur à partir du contexte. Après connexion, enregistrez votre configuration de colonnes comme modèle pour une utilisation récurrente à chaque cycle d'achat.
Téléchargez le fichier Excel consolidé — chaque ligne d'article est une ligne
Chaque ligne d'article devient une ligne avec les champs d'en-tête répétés. Une demande avec 6 lignes d'article produit 6 lignes — chacune portant le N° de demande, le Service, l'Approbateur et le Lieu de livraison. Un lot de 40 demandes provenant de 5 services, avec une moyenne de 4 articles chacune, produit environ 160 lignes dans un seul fichier Excel — toutes correctement associées aux services sources et au statut d'approbation. Exportez en XLSX, CSV ou JSON. La sortie est structurée pour une importation directe dans SAP, Oracle, Coupa, NetSuite ou tout ERP qui attend des enregistrements d'articles aplatis avec un contexte d'en-tête répété. Les utilisateurs de Google Sheets peuvent utiliser le module complémentaire de la barre latérale pour extraire les résultats directement dans une feuille active sans quitter le tableur.
Quand ça fonctionne le mieux — et quand vérifier les résultats
Quand ça fonctionne le mieux
PDF générés automatiquement par les ERP (SAP, Oracle, Coupa, Workday). Les formulaires de demande d'achat numériques avec des libellés de champs clairs, des codes-barres et des tableaux structurés d'articles sont extraits avec la plus grande précision. Les champs d'en-tête, les informations d'approbation et les affectations de centre de coûts correspondent proprement à vos noms de colonnes.
Lots multi-services avec différentes mises en page de formulaires internes. La même définition de colonne extrait les données du formulaire SAP du service Ingénierie, du fichier Excel du Marketing et du papier scanné des Opérations — le tout en un seul lot. Comme l'extraction est sémantique plutôt que positionnelle, les différences de format entre les services ne nécessitent pas de configurations séparées.
Demandes d'achat avec signatures d'approbation et cachets de date clairs. Les signatures d'approbation imprimées, les cachets de date et les blocs d'autorisation sont extraits de manière fiable. L'IA identifie le nom associé à un bloc d'approbation et le mappe à « Approuvé par », que l'approbation apparaisse comme un nom tapé, une ligne de signature imprimée ou une autorisation avec cachet de date.
À vérifier
Chaînes d'approbation multi-niveaux avec routage hiérarchique. Lorsqu'une demande d'achat passe par plusieurs paliers d'approbation (Responsable → Directeur → VP → Achats), l'IA extrait le nom et la date de chaque approbateur. Cependant, l'ordre hiérarchique — qui a approuvé en premier vs. qui a contresigné — peut ne pas être conservé dans la structure de sortie. Vérifiez les chaînes d'approbation multi-niveaux si l'ordre de routage est important pour la conformité.
Lignes manuscrites sur des formulaires carbone internes scannés. Les formulaires papier scannés dont les tableaux de lignes sont remplis à la main — surtout lorsque l'écriture est serrée, cursive ou superposée aux lignes du quadrillage — peuvent présenter une précision réduite sur les descriptions d'articles et les quantités. Les champs d'en-tête imprimés du même formulaire sont extraits normalement. Vérifiez les valeurs des lignes manuscrites avant l'importation par lots.
L'outil extrait ce qui figure sur la page — il ne valide pas votre budget ni votre liste de fournisseurs. Si un demandeur inscrit un coût unitaire estimé gonflé ou mentionne un fournisseur absent de votre liste approuvée, l'outil extrait ces valeurs telles quelles. La validation budgétaire, la conformité fournisseur et la vérification du routage d'approbation restent des étapes de contrôle que votre service achats effectue après l'extraction. L'outil rend les données accessibles ; il n'applique pas la politique d'achat.
Questions fréquentes
Comment l'outil gère-t-il les formulaires de demande d'achat de différents services lorsque chaque service utilise une mise en page différente ?
Les demandes d'achat sont des documents internes — chaque entreprise, et souvent chaque service, conçoit son propre formulaire. L'extraction par nom de colonne résout ce problème en lisant le sens du champ, pas sa position. Saisissez une fois « N° DA », « Demandé par », « Service », « Total ligne », et l'IA localise chaque valeur n'importe où sur la page en comprenant ce qu'elle signifie. La même liste de colonnes fonctionne pour le formulaire DA généré par SAP de l'ingénierie, la feuille Excel imprimée du marketing et la demande papier scannée des services généraux — sans configuration de modèle par service. Importez-les tous en un seul lot et obtenez un fichier Excel consolidé où chaque ligne correspond à un article avec le bon service issu de son formulaire source.
Puis-je extraire à la fois les champs d'en-tête et les lignes d'article d'une demande d'achat en une seule passe ?
Oui. Définissez des colonnes pour les champs d'en-tête (N° DA, Date de demande, Nom du demandeur, Service, Centre de coût, Approuvé par, Date d'approbation, Lieu de livraison) et les champs de ligne (Description de l'article, Quantité, Coût unitaire estimé, Total ligne, Justification, Fournisseur) dans la même liste. L'IA extrait les valeurs d'en-tête une fois et les répète sur chaque ligne d'article. Une demande avec 8 lignes produit 8 lignes de sortie — chacune portant le N° DA, le Service et tout le contexte d'en-tête. Pour l'import ERP dans SAP, Oracle ou Coupa où des enregistrements de ligne aplatis sont attendus, ce format de sortie ne nécessite aucun post-traitement.
L'outil peut-il extraire des données de formulaires de demande d'achat scannés et manuscrits ?
Oui. Le VLM (Vision Large Model) lit le document visuellement plutôt que de se fier à une couche de texte recherchable. Les formulaires papier internes scannés — y compris ceux avec des écritures manuscrites dans les champs de description et de quantité, des marques de stylo et des signatures d'approbation — sont traités de la même manière. Pour une précision optimale sur les formulaires fortement manuscrits, numérisez à 200 dpi ou plus. Le texte imprimé est extrait avec une précision allant jusqu'à 99 % ; les champs manuscrits peuvent être légèrement inférieurs et méritent une vérification rapide avant l'import ERP.
Puis-je traiter par lots les DA de plusieurs services et obtenir un seul fichier Excel consolidé ?
Oui. Importez les DA d'un nombre quelconque de services — Ingénierie, Marketing, Opérations, Services généraux — chacun utilisant un modèle de formulaire interne différent, en un seul lot. La même définition de colonne extrait les données de tous. Le résultat est un fichier Excel fusionné où chaque ligne est un article, avec les informations de service et d'approbation renseignées sur chaque ligne. Pour les cycles d'achat récurrents, sauvegardez votre configuration de colonnes en tant que modèle après vous être connecté et réutilisez-la à chaque période. Pour collecter les DA des bureaux distants ou des services sans accès à votre système d'entreprise, générez un Lien de collecte — une URL partageable où n'importe qui peut importer des formulaires de demande dans votre file d'attente de traitement en saisissant un court code de vérification, sans nécessiter de compte de la part de l'importateur.
Et si une demande d'achat ne comporte pas de champ Fournisseur — l'IA peut-elle aider à identifier un fournisseur ?
L'IA extrait ce qui figure sur la page — elle ne trouve pas elle-même les fournisseurs. Si le formulaire de DA ne comporte pas de champ Fournisseur, ajoutez une Colonne déduite comme « Suggestion de fournisseur (basée sur la description de l'article et l'historique des achats) » pour que l'IA lise la description de l'article et le contexte et suggère un fournisseur probable. Il s'agit toutefois d'une déduction, pas d'une extraction confirmée — le fournisseur suggéré doit être vérifié par votre équipe achats avant l'émission d'un bon de commande. Si un fournisseur spécifique est essentiel pour la conformité, assurez-vous que votre modèle de formulaire de DA comporte un champ Fournisseur obligatoire.
En savoir plus sur l'extraction de documents d'achat
Comment extraire uniquement les champs dont vous avez besoin des bons de commande — En-tête + lignes d'article, sans modèles
Comment l'extraction par nom de colonne lit les champs de bon de commande par sens dans tous les formats fournisseur — le même mécanisme qui gère les demandes d'achat interservices.
Traiter par lots les bons de commande dans Excel : une configuration, tous les formats fournisseur
Appliquez la même définition de colonne sur des documents de formats variés — l'approche par lots qui fonctionne à l'identique pour les demandes d'achat de plusieurs services.
Automatiser la saisie des données de bon de commande : de l'approbation de la DA au traitement du BC
Comment l'extraction basée sur l'IA relie les données de demande d'achat au flux de travail aval du bon de commande — de la demande interne à la commande fournisseur.