50 relevés de transaction coréens,
Un seul tableur : par lots, sans saisie

Si vous débutez avec les relevés de transaction coréens, commencez par notre guide pour extraire les données des relevés de transaction coréens vers Excel, qui couvre la structure des champs, le rapprochement à 3 voies et le problème de l'échec des modèles. Cet article se concentre sur ce qui change lorsque vous passez d'un document à cinquante — du format d'un fournisseur à celui de quinze.

Ce que le traitement par lots signifie réellement pour les achats coréens

La différence entre traiter un relevé de transaction (거래명세서) et cinquante ne tient pas seulement au temps. Il s'agit d'une catégorie de problème complètement différente.

Traitez un seul 거래명세서 — un fournisseur, une livraison, un document — et votre flux de travail est simple. Ouvrez le PDF. Lisez le nom du fournisseur (공급자), la date de transaction (거래일자), le tableau des articles. Saisissez la désignation de l'article (품목명), la quantité (수량), le prix unitaire (단가) et le montant de la ligne (금액) de chaque ligne dans votre feuille de réception. Copiez la valeur de la fourniture (공급가액) et le montant de la TVA (세액) dans votre fichier de rapprochement. Terminé. Trois minutes par document, peut-être cinq si la mise en page du fournisseur est dense ou si la qualité du scan est médiocre.

Maintenant, faites-le cinquante fois — pour quinze fournisseurs différents, chacun avec sa propre mise en page, son propre système de codes d'articles, sa propre qualité d'impression. Les problèmes qui émergent à grande échelle sont invisibles lors du traitement d'un seul document :

• Parcours des formats. Le 거래명세서 du fournisseur A est un PDF net généré par Douzone iCUBE, avec le tableau des articles dans une grille standard. Celui du fournisseur B est une photo prise au mobile d'un formulaire manuscrit, avec les quantités griffonnées dans la marge. Celui du fournisseur C est un document imprimé depuis Excel avec des cellules fusionnées. Une approche d'extraction qui fonctionne pour le document 1 échoue sur le document 2. Au document 50, vous avez rencontré toutes les variations de format que la chaîne d'approvisionnement B2B coréenne peut offrir — et vous les avez toutes saisies manuellement.
• Conventions de nommage. Vous devez savoir quelle ligne provient de quel fichier. « 거래명세서_20260430.pdf » ne vous dit rien sur le fournisseur. Si vous recevez trois factures du même fournisseur au cours du mois, vous devez retracer chaque ligne jusqu'à son document d'origine — et les noms de fichiers seuls ne peuvent pas assurer cette traçabilité.
• Gestion des exceptions. Sur 50 documents, vous rencontrerez des champs vides. Un fournisseur a oublié d'imprimer le prix unitaire. Un autre a laissé la cellule de TVA vide. Une photo prise au téléphone a coupé les lignes du bas du tableau des articles. Lors du traitement d'un seul document, vous remarquez ces problèmes immédiatement et les résolvez. En traitement par lots, les exceptions sont enfouies dans une pile — et les trouver nécessite de parcourir chaque ligne complétée.
• Fusion des sorties. Même si vous pouviez extraire parfaitement chaque document, vous auriez cinquante feuilles de calcul distinctes. Le livrable réel — celui dont votre équipe de réception a besoin — est un tableau unique contenant toutes les lignes de tous les fournisseurs, trié et filtrable par date, fournisseur et numéro de BC.

Pourquoi Douzone, ECOUNT et iQuest ne résolvent pas l'extraction entrante

Le marché coréen de l'ERP a investi des décennies dans la perfection de la génération de documents sortants. Les résultats sont vraiment impressionnants. Douzone Bizon (더존비즈온) — le plus grand fournisseur d'ERP coréen, racheté par la société suédoise de capital-investissement EQT pour 1 300 milliards de KRW en 2025 — permet à ses ~20 000 clients entreprises de générer des relevés de transaction à partir des enregistrements de ventes en un clic, de remplir automatiquement les champs fournisseur et acheteur depuis la base de données clients, et d'imprimer ou d'envoyer par e-mail des centaines de relevés en lot via WEHAGO et iCUBE.

ECOUNT (이카운트), qui sert plus de 80 000 clients entreprises à un tarif fixe de 40 000 KRW/mois, suit le même modèle : saisie des ventes → génération automatique du relevé de transaction → diffusion multicanale (e-mail, KakaoTalk, SMS, fax). Son module d'achat permet d'enregistrer les données d'achat entrantes — mais la saisie est manuelle. Il n'existe pas de chemin télécharger-document → extraction-automatique-des-champs pour les documents que vous recevez.

iQuest (아이퀘스트), éditeur d'ERP Eolmaeyo, est le seul grand fournisseur coréen à proposer une extraction de données de relevé de transaction par OCR — prenez une photo d'un relevé de transaction reçu avec l'application mobile, et l'IA extrait les informations du fournisseur et la liste des articles dans l'ERP. C'est un véritable pas en avant, et à certains égards l'analogue local le plus proche de ce que ImageToTable.ai fait pour des documents uniques. Mais l'hypothèse de conception est un document à la fois : photographier, vérifier l'extraction IA à l'écran, corriger les erreurs, confirmer, répéter. Pour un commercial terrain qui capture un reçu d'un déjeuner, cela fonctionne. Pour une équipe achats qui reçoit cinquante relevés de transaction de quinze fournisseurs le dernier jour du mois, non — car le goulot d'étranglement n'est pas la précision d'extraction par document, mais la boucle de vérification humaine par document qui empêche un véritable traitement par lots.

Gyeongnara et Gyeongyeongiji — populaires auprès des petites entreprises coréennes pour leur simplicité — gèrent compétemment l'émission de relevés de transaction mais n'offrent aucune extraction entrante. Il en va de même pour les grandes plateformes ASP : Popbill (팝빌), avec plus de 373 000 entreprises enregistrées et plus de 324 millions de documents cumulés, et Barobill (바로빌) fournissent des API pour l'émission en masse et l'intégration HomeTax, mais leurs fonctions de récupération extraient les données de vos propres documents émis — pas les données structurées extraites des documents fournisseurs que vous avez reçus au format PDF, scan ou photo.

Le schéma est cohérent sur toutes les plateformes ERP et comptables coréennes : l'automatisation sortante est un problème résolu. L'extraction de données entrantes n'est même pas au programme produit. L'hypothèse — implicite mais uniforme — est que l'acheteur saisira les données.

La réalité de la fin de mois : pourquoi ce problème a une échéance

Les cycles de paiement B2B coréens amplifient la pression du traitement par lots. Deux modes de règlement dominent : 월말결제 (règlement de fin de mois), où le paiement est réglé à la fin du mois de livraison des marchandises, et 익월결제 (règlement le mois suivant), où le paiement est réglé à la fin du mois suivant. Dans les deux cas, les relevés de transaction reçus durant le mois s'accumulent en une pile qu'il faut rapprocher avant de pouvoir autoriser le paiement.

Pour un fabricant ou distributeur coréen de taille moyenne comptant 10 à 30 fournisseurs actifs, un mois typique génère 50 à 200 relevés de transaction entrants. Ils arrivent tout au long du mois — quelques-uns par jour — mais le rapprochement se fait dans une fenêtre compressée : les 3 à 5 derniers jours ouvrables avant l'autorisation de paiement. Le service réception a besoin de chaque ligne de chaque relevé de transaction dans le système pour vérifier les bons de commande et préparer l'échéancier de paiement pour l'équipe financière.

L'arithmétique de cette fenêtre, pour un lot conservateur de 50 documents :

Cinq heures et demie, c'est presque une journée de travail complète — et cela suppose que chaque document arrive sous forme de PDF propre et lisible. En pratique, le lot comprendra des PDF générés par ERP imprimés sur A4 standard, des formulaires manuscrits de petits fournisseurs familiaux qui n'ont jamais utilisé de logiciel de facturation, des photos prises par les chauffeurs-livreurs et envoyées via KakaoTalk, et des copies scannées avec un alignement de travers. Chaque variante de format ajoute des frictions — et ces frictions s'accumulent quand on travaille sous échéance.

C'est pourquoi « tapez plus vite » cesse d'être une réponse vers le vingtième document. La vraie question n'est pas la vitesse à laquelle vous pouvez saisir des champs individuels — c'est la façon dont vous traitez tous les documents à la fois, dans un seul flux de travail, avec une seule sortie, et avec une piste d'audit claire remontant à chaque fichier source.

Fonctionnement de l'extraction par lots : une définition de colonnes pour tous les fournisseurs

Le mécanisme central qui rend possible le traitement par lots des relevés de transaction est l'extraction par nom de colonne : au lieu d'indiquer à un outil où trouver chaque champ sur un document (en dessinant des rectangles autour de coordonnées ou en entraînant un modèle sur des mises en page types), vous lui indiquez quoi rechercher en saisissant les noms des champs souhaités. L'IA lit le document visuellement, localise chaque valeur en comprenant le sens sémantique du nom du champ, et remplit le tableau de sortie — peu importe où le fournisseur a placé le champ sur la page.

Cette distinction entre extraction par coordonnées et extraction sémantique est ce qui rend le traitement par lots viable. Un outil basé sur les coordonnées nécessite un modèle distinct pour la mise en page de chaque fournisseur — car le champ « Quantité » du fournisseur A se trouve à la position pixel (400, 320) tandis que celui du fournisseur B est à (380, 450). Avec cinquante documents provenant de quinze fournisseurs, il vous faudrait quinze modèles, et tout modèle casse lorsqu'un fournisseur modifie la mise en page de son formulaire. Un outil d'extraction sémantique nécessite une seule définition de colonnes — une liste de noms de champs comme « Nom du fournisseur », « Date de transaction », « Désignation de l'article », « Quantité », « Prix unitaire », « Valeur de la fourniture » — et applique la même définition à chaque document du lot, quelle que soit la mise en page.

Le traitement par lots dans ImageToTable.ai fonctionne sur ce principe. Vous téléchargez les cinquante fichiers de relevés de transaction en une seule fois — PDF, scans JPG, captures d'écran PNG, photos WebP, tout en un seul envoi. Vous définissez les colonnes à extraire dans votre feuille de calcul de sortie. L'IA lit chaque document, trouve chaque champ par son sens plutôt que par sa position, et compile tous les résultats dans un seul tableau Excel fusionné. Chaque document devient une ligne (ou plusieurs lignes s'il contient un tableau d'articles multiligne), chaque champ demandé devient une colonne, et vous téléchargez une seule feuille de calcul — pas cinquante séparées.

Le multiplicateur d'efficacité provient de l'élimination de la configuration par document. Vous ne configurez rien par fournisseur. Vous ne créez pas de modèles. Vous n'entraînez pas de modèles. Vous définissez vos colonnes une seule fois — « Nom du fournisseur (공급자) », « Numéro d'enregistrement d'entreprise (사업자등록번호) », « Date de transaction (거래일자) », « Désignation de l'article (품목명) », « Spécification (규격) », « Quantité (수량) », « Prix unitaire (단가) », « Montant de la ligne (금액) », « Valeur de la fourniture (공급가액) », « Montant de la TVA (세액) », « Numéro de référence du bon de commande » — et le même ensemble de colonnes traite chaque relevé de transaction de chaque fournisseur. Cinquante fichiers, quinze fournisseurs, un seul résultat.

Rapprochement à 3 voies à grande échelle : BC → Relevé de transaction (거래명세서) → Facture fiscale (세금계산서)

Pour les équipes d'approvisionnement coréennes, extraire les données du 거래명세서 dans une feuille de calcul n'est pas l'objectif final — c'est l'étape intermédiaire. Le livrable réel est le rapprochement à 3 voies : bon de commande (발주서) → relevé de transaction (거래명세서) → facture fiscale (세금계산서).

Dans le cadre de la TVA coréenne, la facture fiscale (세금계산서) est le document légalement réglementé — régi par l'article 32 de la loi sur la TVA, comportant des champs obligatoires incluant les numéros d'enregistrement du fournisseur et de l'acheteur, la valeur de la fourniture, le montant de la TVA et la date d'établissement. C'est le document qui ouvre droit à la déduction de la TVA d'amont (매입세액 공제) pour l'acheteur et qui doit être fidèlement reflété dans les déclarations trimestrielles de TVA (échéances les 25 janvier, 25 avril, 25 juillet et 25 octobre). Le relevé de transaction n'a pas cette portée légale — c'est un justificatif privé (사적 증빙), non éligible à la déduction fiscale — mais c'est le document qui accompagne réellement les marchandises et qui porte le détail au niveau de l'article que la facture fiscale omet souvent. Pour l'ensemble complet des documents fiscaux coréens réglementés — factures fiscales, reçus de caisse et attestations — notre aperçu de l'extraction des documents fiscaux coréens cartographie les champs de chacun.

Le flux de rapprochement à 3 voies à grande échelle :

L'association de l'extraction du relevé de transaction et de l'extraction de la facture fiscale est ce qui en fait un système complet de rapprochement des achats. Chaque type de document comporte des champs différents, remplit un objectif différent et arrive par un canal différent. Mais les deux alimentent le même tableur — et tous deux doivent concorder.

Le problème du nommage : pourquoi le traitement par lots exige une traçabilité à la source

Il existe un problème qui n'apparaît pas dans le traitement d'un document unique et qui devient critique dans les flux par lots : savoir quelle ligne extraite provient de quel fichier.

Un lot typique de fin de mois peut inclure ces fichiers :

• 거래명세서_20260430.pdf — de Donghae Steel, généré par ERP
• 거래명세서_20260430.pdf — d'un autre fournisseur, même nom de fichier, dossier différent
• KakaoTalk_20260502_143021.jpg — photo d'un relevé de transaction manuscrit, fournisseur inconnu à partir du seul nom de fichier
• scan001.pdf — formulaire papier scanné, nom du fournisseur présent dans l'image mais pas dans le nom de fichier
• 2026-04-30_거래명세표_대한포장.pdf — nom de fichier propre et identifiable — l'exception, pas la règle

Lorsque cinquante lignes extraites arrivent dans votre tableur de sortie, vous devez savoir à quel document source de quel fournisseur correspond chaque ligne. Sans cette traçabilité, vous ne pouvez pas résoudre un écart de quantité — vous ne pouvez pas revenir au document source pour vérifier si l'extraction était correcte ou si le fournisseur a commis une erreur.

Le flux d'extraction par lots d'ImageToTable.ai préserve cette traçabilité en incluant le nom du fichier source comme colonne dans la sortie. Chaque ligne extraite porte le nom du fichier d'origine, ce qui vous permet de retracer instantanément n'importe quelle donnée jusqu'à son document source. Pour les documents aux noms de fichiers ambigus comme KakaoTalk_20260502_143021.jpg, renommez-les avant le téléversement — même un simple préfixe comme DonghaeSteel_20260430.pdf fournit la traçabilité dont vous avez besoin.

C'est l'un de ces défis propres aux lots que les tutoriels sur le document unique ne mentionnent jamais. Lorsque vous traitez un seul document, vous savez d'où viennent les données parce que vous venez de le consulter. Lorsque vous en traitez cinquante, vous avez besoin que le système s'en souvienne à votre place.

Gérer la diversité des formats : du manuscrit au document généré par ERP

Le problème de la diversité des formats dans les achats B2B coréens dépend de la taille et du secteur du fournisseur. Un grand fournisseur de produits chimiques à Ulsan expédie ses marchandises avec un PDF généré par Douzone iCUBE — imprimé sur papier laser, formaté professionnellement, chaque champ dans une grille prévisible. Un petit fournisseur d'emballages à Incheon rédige un relevé de transaction à la main sur un formulaire à carbone pré-imprimé, détache l'exemplaire bleu destiné à l'acheteur (공급받는자용) et le remet au chauffeur-livreur. Un distributeur alimentaire de taille moyenne utilise un modèle Excel qui semble professionnel à l'écran mais s'imprime avec des cellules fusionnées qui chevauchent les limites des champs.

L'OCR conventionnel — qui attend le texte à des positions prévisibles — échoue sur les deuxième et troisième catégories. Les caractères coréens manuscrits sur des formulaires à carbone ont déjà un faible contraste avant même de prendre en compte l'écriture du chauffeur. Les formulaires imprimés depuis Excel avec des cellules fusionnées produisent des blocs de texte où les libellés de champs et les valeurs se mélangent. Les systèmes basés sur des modèles exigent de créer un modèle distinct pour chaque format — et avec quinze fournisseurs utilisant cinq types de formats différents, la maintenance des modèles devient à elle seule une tâche récurrente.

L'extraction par nom de colonne gère la diversité des formats par conception — car elle ne dépend pas de la mise en page. Que « Quantité (수량) » se trouve dans la troisième colonne d'un tableau quadrillé sur un PDF, griffonnée dans une marge sur un formulaire manuscrit, ou intégrée dans une cellule Excel fusionnée, l'IA la localise en lisant le document comme le ferait un humain : en recherchant le sens sémantique, pas les coordonnées en pixels. La même définition de colonne qui fonctionne sur le PDF Douzone fonctionne sur la copie carbone manuscrite et sur l'impression Excel.

Il existe une limite pratique : une photo si floue qu'un humain ne peut pas lire le texte échouera aussi pour l'IA. Mais le seuil de « lisible » est nettement plus bas que ce qu'exige un OCR basé sur des modèles — car un texte flou mais lisible reste sémantiquement lisible, même si ses coordonnées en pixels sont trop imprécises pour qu'un modèle puisse les faire correspondre.

Gérer les exceptions dans un lot de cinquante documents

Dans tout lot de cinquante documents, quelques-uns poseront problème. Un fournisseur a laissé le champ TVA vide parce qu'il est assujetti simplifié (간이과세자) et ne facture pas la TVA séparément. Un autre a saisi la valeur de la fourniture dans la mauvaise cellule, si bien que l'extraction renvoie un nombre inattendu. Une photo prise au téléphone a coupé les deux dernières lignes d'un tableau de dix articles.

En traitement document par document, vous les repérez instantanément — parce que vous regardez le document et les données en même temps. En traitement par lots, le document et les données extraites sont séparés par l'étape d'extraction, et les exceptions peuvent se cacher dans un tableau fusionné de 400 lignes.

Le flux de travail pour gérer les exceptions en mode lot :

L'essentiel à retenir : le traitement par lots n'élimine pas les exceptions — il change la façon de les trouver. Au lieu de découvrir les erreurs document par document au fil de la saisie, vous exécutez des contrôles structurés sur la sortie complète et isolez les documents problématiques. Ce passage d'une découverte réactive des erreurs (repérer les fautes au moment où on les commet) à une détection proactive (analyser la sortie complète pour repérer les anomalies) est ce qui rend le traitement par lots non seulement plus rapide, mais plus fiable.

Intégrer l'extraction par lots dans votre flux de travail achats existant

L'extraction par lots de relevés de transaction ne remplace pas votre ERP — et ne devrait pas essayer. L'ERP gère les enregistrements de ventes, la génération des factures sortantes, la transmission au NTS et le reporting financier. L'extraction par lots gère l'étape d'ingestion des données que l'ERP laisse à votre clavier.

Le point d'intégration est la sortie Excel. Extrayez toutes les données de relevés de transaction entrants dans un seul tableur, rapprochez-les des BC et des factures fiscales, puis importez les données vérifiées dans votre ERP via sa fonction d'import Excel standard. Tous les grands ERP coréens le prennent en charge : Smart A et iCUBE de Douzone proposent l'import par lots Excel pour les enregistrements d'achats. ECOUNT fournit l'import en masse Excel pour les relevés de transaction et autres documents de transaction. iQuest ERP Eolmaeyo prend en charge le téléversement Excel pour les données de relevés de transactions d'achat. Le tableur extrait devient la source d'import — propre, structuré et vérifié avant même d'atteindre votre ERP.

Pour les équipes qui traitent aussi des documents de fournisseurs étrangers, le même flux de travail s'applique. Un bon de livraison d'un fournisseur de composants chinois ou une liste de colisage d'un équipementier européen suit la même logique d'extraction — définir les colonnes, téléverser, obtenir un tableur. La langue et le format du document changent, mais le principe d'extraction par nom de colonne reste identique.

FAQ

Le traitement par lots peut-il gérer à la fois des relevés de transaction manuscrits et imprimés dans le même téléversement ?

Oui. L'IA lit chaque document indépendamment, reconnaissant les caractères coréens manuscrits (y compris une qualité d'écriture variable) et le texte imprimé selon la même logique d'extraction sémantique. La même définition de colonnes traite les deux formats. La limite pratique est la lisibilité : si un humain ne peut pas lire l'écriture manuscrite, l'IA ne le pourra probablement pas non plus.

Que se passe-t-il lorsqu'un relevé de transaction (거래명세서) d'un fournisseur utilise des noms de champs non standard ?

L'extraction par nom de colonne ne correspond pas à des chaînes de texte — elle localise les valeurs par compréhension sémantique. Un fournisseur dont le formulaire intitule le champ quantité « 출하수량 » (quantité expédiée) au lieu de « 수량 » (quantité) verra tout de même ses données correctement extraites, car l'IA comprend que les deux libellés renvoient au même concept. C'est la différence fondamentale entre la correspondance par modèle (qui échouerait) et l'extraction sémantique (qui s'adapte).

Comment le système gère-t-il les relevés de transaction (거래명세서) multipages dont le tableau d'articles s'étend sur plusieurs pages ?

Les PDF multipages sont traités comme un seul document. L'IA lit toutes les pages et extrait toutes les lignes d'articles du tableau, quels que soient les sauts de page. Le résultat consolide toutes les lignes de toutes les pages dans l'enregistrement du même document dans la feuille de calcul.

Puis-je extraire uniquement certaines lignes — par exemple, seulement les articles correspondant à un numéro de BC donné ?

L'étape d'extraction extrait toutes les données de tous les documents. Le filtrage par numéro de BC, fournisseur, plage de dates ou tout autre critère s'effectue dans la feuille de calcul de sortie après l'extraction — ce qui vous donne l'ensemble complet des données à exploiter et à filtrer selon vos besoins, plutôt que de restreindre l'extraction à un sous-ensemble en amont.

L'extraction des données des relevés de transaction (거래명세서) est-elle conforme aux exigences coréennes de conservation des documents fiscaux ?

Le 거래명세서 est lui-même un justificatif privé (사적 증빙) — il n'a aucun format légalement imposé et n'est déposé auprès d'aucune autorité gouvernementale. Aucune exigence de conformité spécifique ne régit la façon dont vous extrayez ou stockez ses données. La facture fiscale (세금계산서), régie par l'article 32 de la loi sur la TVA, est le document soumis à des obligations légales de conformité — et elle est traitée séparément. Pour l'extraction des factures fiscales, consultez le guide de traitement par lots des factures fiscales. En pratique, la loi-cadre sur les impôts nationaux (국세기본법) article 85-3 recommande de conserver les relevés de transaction pendant cinq ans — et un fichier Excel structuré avec traçabilité du nom de fichier source répond mieux à cet objectif qu'une pile de formulaires papier.

Cela fonctionne-t-il aussi pour les factures fiscales coréennes (세금계산서) traitées par lots ?

Oui — le même flux d'extraction par lots s'applique. Pour le traitement par lots des factures fiscales, définissez des colonnes telles que le numéro d'enregistrement d'entreprise (사업자등록번호), la valeur de la fourniture (공급가액), le montant de la TVA (세액) et le numéro d'approbation (승인번호), puis traitez 100 à 200 factures fiscales en un seul import. Le principe d'extraction est identique ; seuls les noms des champs changent.

Chaque ERP coréen peut générer un relevé de transaction à partir d'un enregistrement de vente. Le décalage — et l'opportunité — se situe du côté de la réception. L'extraction par lots y répond avec une seule définition de colonne, un seul import et un seul tableur. Essayez-la lors de votre prochain traitement de fin de mois. Voyez si 5,5 heures de saisie deviennent 15 minutes de vérification.