30 albaranes par jour, un seul journal
Traitement par lots des bons de livraison espagnols
L'éditeur espagnol de logiciels de gestion d'entrepôt Mecalux — groupe d'intralogistique basé à Barcelone, présent dans plus de 70 pays et cité dans le Magic Quadrant Gartner 2026 pour les WMS (systèmes de gestion d'entrepôt) — indique que sa plateforme Easy WMS atteint 99 % d'élimination des erreurs et 60 % d'amélioration de la productivité pour ses clients entrepôts. Ces chiffres décrivent ce qui se produit lorsque le WMS reçoit des données propres. L'écart entre cette promesse et la réalité, c'est la pile d'albaranes (bons de livraison) qui attend sur le bureau de réception chaque matin : 30 pages provenant de 20 fournisseurs différents, imprimées par 20 systèmes ERP (progiciels de gestion intégrés) différents, certaines sur papier thermique, d'autres en papier carbone, la plupart portant des corrections de quantités manuscrites du réceptionnaire. Cet article explique comment combler cet écart à l'échelle des lots.
Points clés à retenir
- Une pile matinale de 30 albaranes provenant de 20 fournisseurs coûte 2 heures de saisie — et c'est la partie la moins chère.
- Une erreur d'un seul chiffre dans un numéro d'albarán et le rapprochement à trois voies de toutes les factures mensuelles de ce fournisseur échoue — mais vous ne le découvrirez que trois semaines plus tard.
- ImageToTable.ai lit les numéros d'albarán, les NIF (numéros d'identification fiscale) et les quantités de 20 formats fournisseurs différents avec une seule définition de colonne — car l'IA cherche la signification du champ, pas sa position sur la page.
Saisir un seul albarán prend quelques minutes. Le vrai problème commence quand il y en a 30, venant de 20 fournisseurs différents, chaque matin.
L'extraction d'un document unique résout un problème de 3 minutes. Le traitement par lots résout un problème de flux de travail structurel où 30 minutes de saisie ne sont pas le coût réel — ce sont les 30 décisions indépendantes sur le placement des champs, les 30 occasions de mal lire une quantité manuscrite, et les 30 saisies manuelles dans le WMS, chacune avec un taux d'erreur de 1 à 3 %.
Un seul albarán espagnol est gérable. Le réceptionnaire lit les champs imprimés — numéro d'albarán, NIF du fournisseur, codes produits, quantités expédiées — et les saisit dans le WMS ou l'ERP. À 3 minutes par page, une pile de 5 prend 15 minutes. C'est fastidieux mais supportable. Le problème, c'est que les entrepôts approvisionnés par une base typique de fournisseurs espagnols ne voient pas 5 albaranes par jour. Un centre de distribution de taille moyenne desservant le commerce de détail régional, ou une usine recevant des matières premières d'un mélange de grands et petits fournisseurs espagnols, traite 20 à 50 albaranes par jour. À ce volume, le calcul de 3 minutes par page donne 1 à 2,5 heures de pure saisie. Mais le vrai coût n'est pas le temps de frappe — c'est ce qui se produit lorsque ces 50 transcriptions manuelles rencontrent le rapprochement à trois.
Si vous avez besoin d'une introduction sur ce qui rend les albaranes espagnols structurellement différents des bons de livraison génériques — notamment le format du NIF, la tradition du papier carbone et leur poids juridique selon le Código de Comercio — commencez par le guide d'extraction d'albarán unique. Cet article part du principe que vous savez déjà ce qu'est un albarán et se concentre sur ce qui change lorsqu'on les traite par douzaines plutôt qu'un par un.
Le mur du volume ne concerne pas la vitesse — mais la densité décisionnelle. Traiter un albarán nécessite un ensemble de décisions de localisation des champs. En traiter 30 de fournisseurs différents en nécessite 30 ensembles indépendants. Le cerveau humain peut en gérer 5 sans fatigue. À 30, les taux d'erreur se cumulent. À 50, le rapprochement à trois — albarán → factura → bon de commande — commence à échouer, non pas parce qu'une saisie individuelle était erronée, mais parce que la probabilité cumulative d'une discordance sur 150 numéros de référence (50 albaranes × 3 clés de rapprochement) devient quasi certaine.
Le traitement par lots ne crée pas la fragmentation des formats — il révèle que l'extraction par modèle n'a jamais été une vraie solution.
Traiter un seul albarán, on peut tolérer ses bizarreries. Mais en traiter 30 venant de 20 fournisseurs, les différences de format entre un albarán d'un centre logistique Mercadona, un carnet d'albaranes rempli à la main par un fabricant andalou, et un PDF Sage Murano d'un fournisseur industriel basque ne sont plus des bizarreries — ce sont des barrières structurelles que l'extraction par modèle ne peut pas franchir.
Le paysage des formats d'albarán en Espagne est structurellement hétérogène car l'économie de la standardisation est désalignée. L'AECOC (Asociación de Fabricantes y Distribuidores, l'organisme de normalisation GS1 en Espagne avec plus de 35 000 entreprises membres) a développé des normes de bons de livraison électroniques via ses plateformes AECOC EDI et AECOC TRANSP. Les grands distributeurs comme Mercadona, Carrefour Espagne et El Corte Inglés imposent l'EDI à leurs fournisseurs de rang 1. Mais pour le marché intermédiaire — distributeurs régionaux, fournisseurs industriels, fabricants locaux — les albaranes papier imprimés depuis l'ERP du fournisseur restent la norme.
UNO Logística, la principale association professionnelle de logistique en Espagne représentant plus de 350 opérateurs logistiques et transporteurs, identifie la fragmentation des formats de documents comme une barrière structurelle à la digitalisation de la chaîne d'approvisionnement. Le Centro Español de Logística (CEL), la plus grande communauté professionnelle de logistique en Espagne depuis 1978, est parvenu à la même conclusion dans ses groupes de travail sur la digitalisation : la standardisation touchera d'abord les corridors à fort volume, mais la longue traîne des fournisseurs du marché intermédiaire continuera de produire des albaranes papier et PDF hétérogènes pendant des années.
À l'échelle d'un document unique, on peut créer un modèle par fournisseur. Avec 20 fournisseurs, cela fait 20 modèles à créer et à maintenir — et les modèles cassent quand un fournisseur modifie le format de sortie de son ERP sans vous prévenir. Le responsable réception ne contrôle pas les formats des fournisseurs. Il reçoit ce qui arrive au quai. La seule approche viable à l'échelle du lot est l'Extraction par Colonnes Personnalisées : une méthode où vous définissez les noms de champs souhaités — « Numéro d'Albarán », « NIF Fournisseur », « Qté Expédiée » — et l'IA lit chaque document pour localiser ces valeurs en comprenant ce que le nom du champ signifie, sans chercher une position fixe sur la mise en page d'un fournisseur spécifique.
Une seule définition de colonne fonctionne avec 20 formats fournisseurs différents, car l'IA lit par le sens, pas par la position. Les noms de colonnes que vous tapez deviennent les en-têtes de votre feuille de calcul de sortie — aucune maintenance de modèle requise.
Le traitement par lot des albaranes espagnols : importez la pile du jour, définissez les colonnes une fois, exportez un registre de réception unifié.
Tous les albaranes du matin — PDF du portail fournisseur, carbones scannés du quai, photos prises à la livraison — sont regroupés en un seul import. Une seule définition de colonnes. Un seul fichier de sortie.
Le traitement par lot chez ImageToTable.ai permet d'importer plusieurs fichiers simultanément, de définir vos colonnes d'extraction une seule fois, et de recevoir un fichier de sortie consolidé où chaque document devient une ligne du tableau. L'avantage fondamental est que vous ne répétez pas l'étape de définition des colonnes par document — vous le faites une fois pour tout le lot, et l'IA applique la même compréhension sémantique à chaque mise en page de fournisseur. Pour les utilisateurs de Google Sheets, le module complémentaire de la barre latérale extrait les résultats directement dans la feuille active sans quitter le tableur.
Importez les albaranes du jour — tous formats confondus
Déposez les albaranes PDF des portails fournisseurs, les copies carbone scannées du quai de réception, ou les photos prises lors des contrôles de livraison. PDF numériques, papiers scannés et photos peuvent être mélangés dans un même lot. Si vos chauffeurs ou le personnel d'entrepôt distant doivent soumettre des albaranes directement, le Lien de collecte génère une page de dépôt partageable — l'expéditeur ouvre le lien, saisit un code de vérification et télécharge les fichiers. Aucune connexion ni inscription requise pour l'expéditeur. Les albaranes atterrissent directement dans votre file de traitement, contournant les pièces jointes email et les photos WhatsApp.
Définissez une fois les colonnes de votre registre de réception — elles fonctionnent pour tous les fournisseurs
Saisissez les noms de champs dont votre flux de réception et votre ERP ont besoin : N° Albarán | Réf. Commande | Nom Fournisseur | NIF Fournisseur | Date Livraison | Code Produit | Description Article | Qté Expédiée | Qté Reçue | Notes Exception | Signature Réceptionnaire. L'IA trouve chaque valeur sur l'albarán de chaque fournisseur en comprenant la signification du nom de colonne — pas en faisant correspondre une position de pixel mémorisée. Ajoutez une colonne calculée comme Écart Qté (Qté Expédiée − Qté Reçue) et l'IA calcule la différence lors de l'extraction, signalant les écarts avant que les données n'atteignent votre WMS. Ajoutez une colonne déduite comme État Livraison (options : Complète/Partielle/Endommagée) et l'IA évalue le contenu de l'albarán pour attribuer le statut correct à chaque document du lot.
Exportez le registre de réception consolidé
Téléchargez en XLSX, CSV ou JSON. Chaque albarán devient une ligne. Chaque champ — numéro d'albarán, NIF fournisseur, codes produits, quantités expédiées et reçues, notes d'exception, statut de signature — apparaît dans sa propre colonne. Le tableur est prêt pour la comptabilisation des entrées de marchandises dans SAP Business One, Sage 200 / Sage Murano, Microsoft Dynamics NAV / Business Central, Holded ou Mecalux Easy WMS. La colonne numéro d'albarán est la clé qui relie chaque ligne à la facture suivante pour le rapprochement à trois voies. Le traitement s'effectue en 5 à 10 secondes par page.
Essayez le flux d'extraction ci-dessous avec un bon de livraison exemple. La démo charge un préréglage — un ensemble préconfiguré de noms de colonnes correspondant à la structure standard du bon de livraison et du bordereau d'emballage — afin que vous puissiez voir les résultats d'extraction immédiatement sans saisir de noms de colonnes.
Les fichiers sont traités en toute sécurité et ne sont pas stockés.
Le rapprochement à trois voies ne passe pas à l'échelle de façon linéaire — un seul numéro d'albarán mal saisi dans un lot de 50 peut rompre le rapprochement pour l'ensemble des factures mensuelles d'un fournisseur.
Le Plan comptable général espagnol (PGC) attribue un chemin comptable précis à chaque albarán : débiter la Classe 3 Stocks (compte 600 pour les achats de marchandises ou 601 pour les matières premières) et créditer le compte 400 Fournisseurs. Le numéro d'albarán est la référence qui relie la réception physique à cette écriture comptable — avant l'arrivée de la facture (factura).
Dans un flux de travail mono-document, si vous saisissez mal un numéro d'albarán, vous le remarquez lorsque la facture (factura) correspondante arrive et ne correspond pas. Vous passez 5 minutes à retracer la trace papier et corrigez l'écriture. Agaçant mais limité. Dans un flux de travail par lots où vous saisissez 30 à 50 albaranes dans l'ERP (progiciel de gestion intégré) avant l'arrivée des factures (facturas), les dégâts s'accumulent silencieusement : des numéros d'albarán incorrects restent dans le système jusqu'à ce que le fournisseur envoie sa facture, moment où le rapprochement à trois voies — bon de commande → albarán (marchandises reçues) → facture (factura) — échoue non pas pour un document mais potentiellement pour toutes les livraisons du mois de ce fournisseur. L'équipe comptable doit alors rétro-ingénierer quelles écritures sont erronées parmi des dizaines de transactions.
C'est là que l'extraction qui récupère le numéro d'albarán directement depuis le document — plutôt que de s'appuyer sur la transcription humaine — change le profil de risque. Un numéro d'albarán saisi manuellement a un taux d'erreur de 1 à 3 % par champ. Un numéro d'albarán lu par machine directement depuis l'image du document présente une erreur de transcription pratiquement nulle sur du texte imprimé. Pour les copies carbone scannées où l'impression peut être délavée, l'IA signale les valeurs à faible confiance plutôt que de produire silencieusement un résultat erroné — ce qui signifie que le responsable de réception vérifie les 2 à 3 lectures incertaines au lieu de relire les 50 écritures.
Le rapprochement à trois voies ne casse pas au stade de la facture, mais à celui de la saisie du bon de livraison (albarán) — des semaines avant que quiconque ne s'en aperçoive. Le corriger au moment de la capture des données coûte des secondes. Le corriger après l'arrivée des factures (facturas) coûte des heures par fournisseur.
Un bon de livraison (albarán) espagnol comporte deux couches de données : ce que le fournisseur a expédié et ce que le destinataire a réellement compté. À l'échelle d'un lot, lire manuellement les deux couches signifie lire 30 fois des corrections identiques.
La nature circulaire du bon de livraison (albarán) — le fournisseur l'imprime, la marchandise voyage avec lui, le destinataire l'annote, une copie signée revient — crée un problème de document à deux couches qui est gérable dans le traitement d'un document unique, mais qui devient le goulot d'étranglement dominant à l'échelle d'un lot.
Chaque bon de livraison (albarán) espagnol qui arrive au poste de saisie contient trois types de contenu manuscrit : des corrections de quantités (« solo 8 uds recibidas » à côté d'un « 10 » imprimé), des notes sur l'état (« caja dañada, » « embalaje roto »), et la signature du destinataire confirmant la réception. Dans un flux de travail à document unique, l'employé de réception lit ces annotations et saisit la quantité ajustée dans le WMS (système de gestion d'entrepôt). Lorsque vous avez 30 bons de livraison (albaranes), l'employé lit 30 corrections manuscrites — beaucoup utilisant une formulation similaire chez différents fournisseurs — et doit correctement associer chaque correction à sa ligne imprimée correspondante sans transposer les données entre les documents.
Ce n'est pas un problème de vitesse. C'est un problème de charge cognitive. Après 10 bons de livraison (albaranes), le cerveau cesse de distinguer entre « 8 uds recibidas » sur le bon de livraison (albarán) de Mercadona et « 8 uds » griffonné sur le bon de livraison de RS Components España. Les outils d'extraction basés sur des modèles aggravent la situation en ignorant entièrement la couche manuscrite (produisant des quantités expédiées qui ne reflètent pas ce qui a été réellement reçu) ou en mélangeant le texte manuscrit et imprimé dans la même cellule de sortie (produisant des données absurdes).
Une approche sémantique résout ce problème en traitant les couches imprimée et manuscrite comme des cibles d'extraction distinctes. Définissez Qty Shipped et l'IA lit la quantité imprimée du fournisseur dans le tableau des lignes. Définissez Qty Received dans la même configuration de colonnes et l'IA lit la correction manuscrite. Ces données atterrissent dans des colonnes adjacentes de la sortie — quantité imprimée et quantité reçue côte à côte, l'écart étant immédiatement visible. Définissez Exception Notes et les commentaires manuscrits en marge sont extraits sous forme de texte structuré.
L'écriture manuscrite standard en bloc s'extrait de manière fiable sur l'ensemble du lot. L'écriture cursive très rapide — courante dans les annotations des chauffeurs griffonnées sur le quai — peut nécessiter une vérification ponctuelle pour la transcription intégrale, mais la détection structurée (signature présente : oui/non, corrections de quantités) reste fiable même sur une écriture rapide. C'est la limite honnête : l'outil lit ce qui est lisible, signale ce qui est ambigu, et ne produit jamais silencieusement une valeur erronée.
Questions fréquentes
Combien d'albarans puis-je traiter en un seul lot ?
L'outil traite les fichiers séquentiellement au sein d'un lot et gère des téléchargements de toute taille pratique — 30, 50 albarans ou plus en une seule fois. Chaque page prend environ 5 à 10 secondes à traiter, donc un lot de 30 albarans se termine en environ 3 à 5 minutes de temps de traitement. Vous ne regardez pas la barre de progression — vous lancez le lot et revenez à un tableur complété. La contrainte pratique n'est pas la capacité de l'outil mais le rythme de réception du quai : la plupart des entrepôts traitent la pile d'albarans du matin en une seule session et gèrent les arrivées de l'après-midi dans un second passage.
Que se passe-t-il si un albarán n'a pas de numéro imprimé, seulement un numéro manuscrit ?
L'IA lit le texte manuscrit quelle que soit la langue. Si le numéro d'albarán est manuscrit — ce qui arrive avec certains petits fournisseurs utilisant des carnets d'albarans génériques — l'extraction tente toujours de le localiser en fonction du nom de colonne que vous avez défini. La précision est inférieure à celle des numéros imprimés (une écriture manuscrite en lettres moulées se lit bien ; une cursive rapide peut nécessiter une vérification manuelle). Si l'IA ne trouve pas de valeur avec certitude, la cellule reste vide plutôt que d'être remplie avec une estimation. Pour le contrôle qualité, vous pouvez ajouter une colonne nommée Confiance numéro d'albarán pour signaler les entrées nécessitant une vérification manuelle.
Puis-je traiter des albarans qui mélangent des libellés de champs en espagnol, catalan et anglais dans le même lot ?
Oui. L'IA lit la signification des champs, pas la langue du libellé. Qu'un fournisseur imprime « Albarán N.º », « Albarà Núm. » ou « Delivery Note Ref », la colonne que vous avez définie comme Numéro d'albarán trouve la valeur correcte car l'IA comprend ce qu'est un numéro de bon de livraison sémantiquement, et non dans quelle langue il est libellé. Cela est particulièrement utile pour les entrepôts espagnols recevant de fournisseurs internationaux où les albarans peuvent porter un mélange de libellés en espagnol, anglais et langues régionales — et pour les fournisseurs nationaux dans les régions bilingues (Catalogne, Pays basque, Galice, Valence) où les libellés de champs peuvent apparaître dans la langue régionale.
Le traitement par lot gère-t-il la validation NIF/CIF pour les champs d'identification fiscale ?
L'IA extrait le NIF tel qu'il apparaît sur le document mais n'effectue pas de validation algorithmique du NIF (vérification de la lettre de contrôle par rapport à l'algorithme modulo-23). Le format à 8 chiffres plus lettre de contrôle aide l'IA à distinguer le NIF du numéro d'albarán lors de l'extraction, mais la validation formelle doit être effectuée dans votre ERP ou via le service de vérification en ligne de l'Agencia Tributaria. Pour le contrôle qualité, les champs NIF bénéficient de l'ajout d'une colonne calculée comme Vérification format NIF (valide/invalide) pour signaler les entrées qui ne correspondent pas au modèle attendu — mais il s'agit d'une vérification de format, pas d'une validation légale.
Comment récupérer les albaranes de mes chauffeurs ou entrepôts distants sans email ?
La fonction Lien de collecte génère une page de téléchargement partageable. Envoyez le lien aux chauffeurs, au personnel d'entrepôts distants ou aux partenaires logistiques tiers. Ils ouvrent le lien, saisissent un code de vérification et téléchargent directement les albaranes — sous forme de photos prises à la livraison ou de scans PDF. Aucune inscription ni connexion requise pour l'expéditeur. Les fichiers arrivent automatiquement dans votre file d'attente de traitement. Particulièrement utile pour les opérations logistiques espagnoles où les livraisons ont lieu sur plusieurs sites — un bureau central à Madrid, un entrepôt satellite à Valence, un hub de distribution à Barcelone — et où les documents de réception doivent parvenir à une équipe centralisée de comptabilité fournisseurs ou de gestion des stocks sans dépendre des pièces jointes email des chauffeurs.
La pile d'albaráns espagnols qui s'accumule chaque matin sur le bureau de réception n'est pas un problème de saisie de données — c'est un problème de traduction de format multiplié par le nombre de fournisseurs dont vous recevez des marchandises. Lorsqu'une seule définition de colonne fonctionne avec la mise en page de chaque fournisseur, la pile devient un seul téléchargement, une seule exécution de traitement et une seule feuille de calcul qui alimente votre WMS (système de gestion d'entrepôt) avec les données propres qu'il est conçu pour recevoir. C'est la différence entre un WMS qui affiche une élimination des erreurs à 99 % sur le papier et un qui y parvient réellement sur votre quai de chargement.
À lire aussi : Comment extraire les données des bons de livraison espagnols (albaranes) vers Excel · Extraire par lots les bons de livraison et bordereaux d'expédition vers Excel · Extraire les champs des bordereaux d'expédition depuis n'importe quel format vers Excel · Traiter par lots les bons de livraison français · Traiter par lots les bons de livraison allemands (Lieferscheine) · Convertisseur de bons de livraison vers Excel