Quand 30 relevés d'hôtel arrivent sur votre bureau
Le fossé du rapprochement par lots

L'indice BTI de la GBTA prévoit 1 690 milliards de dollars de dépenses mondiales en voyages d'affaires pour 2026. Les cabinets de services professionnels — conseil, droit, comptabilité — ont dépassé les niveaux d'avant la pandémie, certains secteurs affichant une hausse de plus de 20 % de leurs dépenses voyages depuis 2019, selon le même rapport. Pour les équipes financières qui gèrent ces voyageurs, le volume s'alourdit chaque mois : la dépense moyenne par déplacement atteint 1 128 $, et le voyage d'affaires moyen en Europe dure 3,1 nuits — générant des notes d'hôtel de plusieurs pages et lignes.

Traiter une note ligne par ligne est fastidieux mais réalisable. Un workflow d'extraction bien structuré transforme une note de trois pages en une ligne de tableur codée en comptabilité en moins d'une minute. Mais face à une pile de trente notes, le goulot d'étranglement se déplace. Vous ne faites plus de la saisie, mais de la consolidation — fusionner les données de différentes chaînes hôtelières qui nomment les frais différemment, placent les lignes de taxes à des endroits distincts, et utilisent des systèmes de gestion différents. C'est cette étape de consolidation qui fait perdre des heures, et c'est là que le traitement par lots change la donne pour tout le cycle de rapprochement.

Le problème de la fragmentation des formats

Une note Marriott générée par Oracle Opera PMS ne ressemble pas à une note Hilton issue du système OnQ, qui diffère d'une note IHG provenant d'un hôtel utilisant Opera Cloud ou un ancien PMS. Les données sont les mêmes — tarif de la chambre, taxes, repas, parking, extras — mais la disposition, les descriptions des lignes et même les en-têtes de sections varient suffisamment pour qu'un modèle conçu pour une chaîne échoue sur la suivante.

Ce n'est pas un cas théorique. Lors d'un traitement de fin de mois typique pour un cabinet de conseil de taille moyenne, un responsable financier peut recevoir :

Un système OCR basé sur des modèles, entraîné sur des relevés Marriott, lit correctement « Destination Fee » mais ne connaît pas la règle pour « Resort Charge » sur un relevé Hilton — et renvoie une cellule vide pour ce qui devrait être la même imputation GL. Multipliez ce décalage par quinze types de frais différents sur trente relevés, et vous obtenez un tableur rempli de blancs, d'erreurs de placement et de corrections manuelles. L'extraction a fonctionné. La consolidation, non.

L'alternative est l'Extraction par Colonnes Personnalisées : au lieu d'indiquer à l'outil où regarder sur la page, vous lui dites quoi chercher. Vous définissez des noms de colonnes — « Tarif de la chambre », « Taxe d'occupation », « Taxe de séjour », « Parking », « Frais de restaurant » — et un modèle de vision IA lit chaque relevé, comprend ce que chaque description de frais signifie réellement, et extrait les valeurs dans la bonne colonne, peu importe leur emplacement sur la page ou le nom donné par la chaîne. Les noms de colonnes que vous définissez une fois fonctionnent sur les trente relevés, les huit chaînes, les quatre formats sources. L'étape de consolidation — celle qui prenait des heures — se fond dans l'étape d'extraction elle-même.

Le Problème de Fusion : De 30 Extractions à un Seul Tableur

Si vous traitez les relevés un par un — téléchargement, extraction, téléchargement du résultat — vous produisez trente tableurs. C'est techniquement « fait », mais vous n'avez pas résolu le problème de fin de mois. Vous avez échangé une tâche de saisie contre une tâche de fusion de données. Le relecteur financier doit encore ouvrir trente fichiers, copier les lignes dans un classeur maître, vérifier l'alignement des colonnes entre des sorties incohérentes, et rapprocher les totaux avec les relevés de carte de crédit.

Le traitement par lots élimine l'étape de fusion. Téléchargez les trente relevés en une fois — les PDF Marriott, les pièces jointes email Hilton, les photos téléphone IHG, les JPEG des hôtels indépendants — définissez vos colonnes d'extraction une seule fois, et le résultat est un seul tableur où chaque ligne correspond à un séjour hôtelier et chaque colonne à un champ défini. Pas de fusion. Pas de réalignement de colonnes. Pas de « est-ce que j'ai copié la ligne 17 dans la bonne feuille ? »

Un exemple concret : un responsable financier dans un cabinet de conseil collecte trente-quatre relevés auprès de dix-sept consultants après un mois de déplacements clients. Sept sont des PDF Marriott reçus par email. Neuf sont des relevés Hilton, certains en PDF, d'autres en captures d'écran d'application. Six sont des impressions IHG photographiées par les consultants avant de quitter le parking. Quatre proviennent d'hôtels indépendants où la réception a imprimé un exemplaire sur papier thermique. Deux sont issus d'une réservation Booking.com où le voyageur a oublié de demander un relevé, et seul le reçu de la plateforme est disponible.

Les colonnes d'extraction sont définies une fois — le même ensemble de noms de champs fonctionne sur les trente-quatre documents. Le résultat atterrit dans un seul tableur. L'étape de relecture passe de « saisir chaque ligne » à « repérer les anomalies » — ce qui, pour un lot de cette taille, prend dix minutes au lieu de dix heures.

Affectation GL par lot : 400 lignes, un seul passage

Extraire les données ne résout que la moitié du problème du traitement par lots. L'autre moitié consiste à affecter chaque charge au bon compte du grand livre sans avoir à examiner et catégoriser manuellement chaque ligne de chaque relevé. Un relevé Marriott de quatre pages peut contenir quarante-sept lignes réparties sur cinq catégories départementales USALI. Trente relevés de ce type produisent environ quatre cents charges individuelles à mapper sur quatre ou cinq codes GL. Ce mappage, effectué manuellement, est là où la fatigue s'installe — et où les erreurs se multiplient.

C'est là que les colonnes inférées deviennent le levier à grande échelle. Une colonne inférée fonctionne en donnant à l'IA un ensemble d'options valides et en lui demandant de choisir la bonne en fonction de ce que dit la description de la charge sur le relevé. Définissez une colonne appelée « Code GL » avec les options « 6400 (Hébergement), 6500 (Repas et divertissements), 6600 (Transport), 6800 (Bureau/Communications), Non remboursable », et l'IA lit chaque ligne — « Frais de chambre » → 6400, « Restaurant The Palm » → 6500, « Service de voiturier » → 6600, « Film en chambre » → Non remboursable. La règle de classification est écrite une seule fois et appliquée à l'ensemble du lot.

La différence pratique est frappante. Allouer manuellement quatre cents lignes au bon code GL à trente secondes par article prend plus de trois heures — et ce, avant toute correction. Avec les colonnes inférées appliquées à l'ensemble du lot, l'allocation se fait lors de la même passe d'extraction qui lit les montants. La sortie arrive pré-catégorisée. Le travail du relecteur passe de la classification — « à quel GL va le stationnement ? » — à la gestion des exceptions : « cette charge de spa a été automatiquement catégorisée comme Hébergement ; remplacez-la par Non remboursable. »

Ce modèle s'aligne également sur les exigences du plan de remboursement responsable de l'IRS en vertu de la Publication 463. Un plan de remboursement responsable exige que les employés justifient quatre éléments pour chaque dépense : la date, le lieu, l'objet professionnel et le montant. Un total de relevé de 1 247 $ ne justifie aucun de ces éléments au niveau de la ligne. Le décomposer en tarif de chambre, taxes, repas et frais accessoires — chacun avec son propre montant et sa classification GL — transforme le relevé d'une image de reçu en documentation conforme. Lorsque cette ventilation est appliquée à l'ensemble du lot de relevés d'un mois, la valeur de conformité se cumule : chaque charge, de chaque voyageur, dans chaque hôtel, est allouée de manière cohérente à la même structure GL.

La norme comptable propre au secteur hôtelier renforce l'importance de ce point. La 12e édition révisée du Uniform System of Accounts for the Lodging Industry (USALI), publiée en février 2025 avec une adoption obligatoire au 1er janvier 2026, structure les revenus hôteliers en catégories départementales : Chambres, Restauration et boissons, Autres départements exploités et Revenus divers. Un relevé reflète le plan comptable interne de l'hôtel — et non le GL de la société du client. Le travail de traduction — de la logique départementale USALI à la logique des dépenses d'entreprise — est ce que l'extraction par lots avec colonnes inférées automatise, et ce qu'aucun OCR basé sur des modèles n'aurait jamais pu faire.

Obtenir les relevés en premier lieu : le défi de la collecte

Avant de pouvoir traiter trente relevés, il faut d'abord les avoir en main. En pratique, c'est la partie la plus difficile du flux de travail. Les consultants en déplacement oublient de demander un relevé imprimé à la réception lors du départ. Les systèmes de messagerie des hôtels ne parviennent pas à livrer le PDF — une plainte récurrente sur les forums de voyage. Le papier thermique s'estompe en quelques semaines. Un employé qui photographie son relevé sur un bureau sombre de chambre d'hôtel, sous un mauvais angle, produit une image qui est techniquement un relevé, mais fonctionnellement illisible pour l'extraction.

Pour l'équipe financière qui gère la clôture mensuelle, ces lacunes apparaissent tardivement — souvent lorsque le relevé de carte de crédit arrive et qu'un débit de 1 247 $ d'un Hilton à Chicago n'a aucun relevé correspondant dans le lot. Réconcilier cet écart signifie relancer un employé déjà parti sur la prochaine mission client, qui appelle ensuite l'hôtel, navigue dans le menu téléphonique et attend un duplicata du relevé qui arrivera peut-être, ou pas. Chaque relevé manquant coûte une heure de coordination, et non d'extraction.

Les Liens de collecte comblent cette lacune en amont. Au lieu d'attendre que les employés pensent à soumettre leurs relevés, l'équipe financière génère un lien partageable et l'envoie à tous les employés en déplacement au début du mois. Toute personne disposant du lien peut téléverser son relevé — sans connexion, sans compte, sans installation de logiciel. Les relevés arrivent directement dans la file de traitement, organisés au même endroit avant même la fin du mois. Le lot est constitué en continu tout au long du mois, plutôt que d'être assemblé dans l'urgence pendant la semaine de clôture.

Ce qui pose problème en pratique : la réalité de la gestion des exceptions

Aucun lot de trente relevés n'est parfait. Certains manquent. D'autres sont illisibles. Certains ont été imprimés avec le mauvais type de relevé — une version tronquée ne montrant que le total, inutile pour l'extraction ligne par ligne. Certains voyageurs ont facturé des articles personnels à la chambre, et le relevé mélange désormais des frais remboursables et non remboursables. Un flux de traitement réaliste tient compte de ces exceptions avant qu'elles ne fassent dérailler le processus de clôture.

Les exceptions de lot les plus courantes, par ordre de fréquence :

Relevés d'hôtel manquants dans les hôtels indépendants. Les chaînes hôtelières dotées de systèmes PMS standardisés peuvent envoyer un relevé par e-mail sur demande. Les établissements indépendants qui utilisent des systèmes plus anciens ou des processus manuels ne le peuvent souvent pas — la réception imprime un exemplaire unique, et si le voyageur ne le photographie pas, ce relevé est perdu. L'équipe financière découvre cette lacune non pas pendant le traitement, mais lors du rapprochement, lorsqu'une charge de carte d'entreprise n'a pas de relevé correspondant. La prévention — le Lien de collecte envoyé avant le voyage — est la seule solution fiable.

Relevés tronqués ne montrant que le total. Certains hôtels, notamment sur les marchés où la réception suppose que le client souhaite un reçu simplifié, impriment ou envoient par e-mail un relevé abrégé avec une seule ligne « Frais de chambre » et un total. Cette version est inutile pour l'extraction ligne par ligne et pour la conformité au régime fiscal des frais remboursables. Le voyageur doit spécifiquement demander le « relevé client avec solde nul » — la version complète détaillée — et tous les voyageurs ne savent pas qu'il faut le demander. Le flux de traitement par lots doit signaler tout relevé dont les lignes extraites ne correspondent pas au total, indiquant un document source tronqué.

Frais professionnels et personnels mélangés. Service en chambre, minibar, spa, films à la carte — ces frais sont imputés au même relevé que le tarif de la chambre et les repas d'affaires. Dans un flux à relevé unique, le réviseur repère les frais personnels manuellement. Dans un lot de trente, ils se fondent dans la masse. La colonne inférée pour « Remboursable ? » (options : Oui/Non/À vérifier) les fait ressortir pendant l'extraction plutôt que pendant l'audit, transformant un risque de conformité caché en ligne visible que le réviseur peut traiter en quelques secondes.

Variabilité de la qualité des sources. Un PDF envoyé par e-mail depuis le PMS de l'hôtel est propre, net et optimisé pour la machine. Une photo de téléphone d'un relevé imprimé thermique prise en angle sous un éclairage fluorescent de hall ne l'est pas. Le modèle de langage visuel qui alimente l'extraction gère les deux — il lit en comprenant la mise en page et le contexte du document, et non en faisant correspondre des modèles de pixels — mais la précision diminue sur les captures de mauvaise qualité. Un flux de traitement par lots pratique définit des attentes de qualité : les PDF et les photos de téléphone claires produisent des extractions à haute fiabilité. Les impressions thermiques fortement pliées ou mal inclinées peuvent nécessiter une passe de vérification. Même avec cette passe de vérification, analyser une feuille de calcul pour repérer les valeurs aberrantes est d'un ordre de grandeur plus rapide que de saisir manuellement quarante-sept lignes à partir de zéro.

FAQ

Le traitement par lots peut-il gérer les relevés lorsque certains voyageurs ne disposent que d'une documentation partielle ?

Oui. Si un voyageur soumet uniquement un reçu Booking.com au lieu d'un relevé complet, l'extraction capture les champs visibles — date d'arrivée, date de départ, total — et laisse les colonnes de lignes vides. La sortie du lot fait ressortir la lacune au lieu de la masquer. Le réviseur financier peut ensuite décider d'accepter le reçu de la plateforme pour ce voyage ou de demander le relevé complet à l'hôtel.

Que se passe-t-il si deux employés ont séjourné dans le même établissement Marriott mais que l'un a reçu un PDF et l'autre une photo de téléphone ?

Les définitions de colonnes fonctionnent avec les deux formats. L'IA lit le texte du PDF directement et la photo de téléphone par compréhension visuelle de la mise en page du document. La qualité d'extraction est supérieure sur le PDF — le texte est net à la machine — mais la photo de téléphone produit tout de même une sortie exploitable tant que l'image est raisonnablement plane et lisible. La feuille de calcul de sortie inclut les deux lignes dans le même lot avec la même structure de colonnes.

Comment cela fonctionne-t-il avec Concur ou Expensify ?

Cela les complète. Les T&E d'entreprise platforms handle the full expense lifecycle — booking, approval routing, policy enforcement, reimbursement. What they do not reliably handle is turning a multi-page hotel folio from any chain into structured, GL-coded line-item data at batch scale. The extraction produces a clean, categorized spreadsheet that feeds into your expense system as structured input. Instead of the platform's OCR reading a folio total and the employee manually itemizing, the employee uploads the folio once and the line items populate automatically. Les petites équipes financières qui traitent des notes de frais pour vingt voyageurs ou plus réalisent les plus grandes économies de temps proportionnelles grâce à cette transition.

Quel pourcentage de relevés nécessite une correction manuelle dans un lot ?

Pour les relevés PDF propres provenant de grandes chaînes hôtelières, l'extraction est très précise et l'allocation des codes GL est cohérente — la plupart des lignes passent la revue sans modification. Le taux de correction augmente avec les photos de téléphone de mauvaise qualité, les impressions thermiques et les relevés d'établissements indépendants aux formats non standard. Une attente réaliste : environ 80 à 85 % des lignes d'un lot typique ne nécessitent aucune intervention ; les 15 à 20 % restants demandent une revue rapide et un ajustement occasionnel. Le relecteur consacre son temps aux exceptions, pas à chaque ligne.

Les colonnes inférées peuvent-elles gérer les cas particuliers comme les frais de resort libellés différemment selon les chaînes ?

Oui, et c'est là que les colonnes inférées surpassent les règles basées sur des modèles. Un système basé sur des modèles recherche la chaîne de texte « Resort Fee » et manque « Destination Fee », « Resort Charge », « Urban Fee » et « Amenity Fee ». Une colonne inférée lit la description de la charge, comprend sa signification sémantique — « il s'agit d'une taxe journalière obligatoire facturée par chambre » — et la classe dans la bonne colonne, quel que soit le nom utilisé par l'hôtel. La même inférence fonctionne sur l'ensemble du lot.

Combien de temps faut-il pour traiter un lot de trente relevés ?

L'extraction elle-même prend cinq à dix secondes par relevé — soit environ deux à cinq minutes pour un lot de trente. L'étape de revue prend plus de temps : l'analyse du tableur de sortie pour repérer les valeurs aberrantes, la vérification des allocations GL et le traitement des exceptions nécessitent généralement dix à quinze minutes pour un lot propre, plus longtemps si de nombreux relevés sont des captures de mauvaise qualité ou contiennent des charges ambiguës. Comparez cela à l'alternative manuelle : traiter trente relevés ligne par ligne avec une ventilation détaillée dans Concur ou un tableur consomme généralement quatre à six heures de travail concentré, souvent réparties sur plusieurs jours pendant la clôture mensuelle.