50 relevés de transaction coréens,
un seul tableur : traitement par lots sans saisie
Chaque ERP coréen peut générer un relevé de transaction (거래명세서) à partir d'un enregistrement de vente en un clic. Pas un seul ne peut en lire un. Le document qui accompagne chaque expédition physique entre entreprises coréennes — listant les articles, quantités, prix unitaires et valeurs de fourniture — entre dans votre flux d'achats via un clavier, un champ à la fois. Lorsque vous en recevez cinquante de quinze fournisseurs en fin de mois, cette asymétrie cesse d'être une curiosité et devient la raison pour laquelle votre équipe de réception est encore au bureau à 22 heures.
Points clés à retenir
- Chaque ERP coréen peut générer un 거래명세서 à partir d'un enregistrement de vente en un clic — et zéro peut en lire un, ce qui explique pourquoi votre équipe de réception tape encore à 22 heures.
- Cinquante 거래명세서 de quinze fournisseurs nécessitent 5,5 heures de saisie manuelle, mais le vrai problème n'est pas votre vitesse de frappe — c'est que le secteur a passé des décennies à perfectionner l'automatisation sortante et a laissé l'extraction entrante à votre clavier.
- ImageToTable.ai traite les cinquante documents avec une seule définition de colonne — pas de modèle par fournisseur, pas de boucle de relecture par document — et fournit un tableur unique où chaque ligne d'article est rattachée à son fichier source.
Si vous débutez avec les relevés de transactions coréens, commencez par notre guide d'extraction de données de relevés de transactions coréens vers Excel, qui couvre la structure des champs, le rapprochement à trois niveaux et le problème d'échec du modèle. Cet article se concentre sur ce qui change lorsque vous passez d'un document à cinquante — d'un format de fournisseur à quinze.
Ce que le traitement par lots signifie réellement pour les achats en Corée
La différence entre le traitement d'un seul relevé de transaction (거래명세서) et de cinquante ne se limite pas au temps. Il s'agit d'une classe de problème complètement différente.
Traitez un seul 거래명세서 — un fournisseur, une expédition, 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 le nom de l'article (품목명), la quantité (수량), le prix unitaire (단가) et le montant de la ligne (금액) de chaque ligne dans votre feuille de calcul 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, cinq peut-être si la mise en page du fournisseur est dense ou si la qualité de numérisation est médiocre.
Maintenant, faites-le cinquante fois — avec quinze fournisseurs différents, chacun avec sa propre mise en page, son propre système de codes articles, sa propre qualité d'impression. Les problèmes qui émergent à grande échelle sont invisibles dans le traitement d'un seul document :
- Navigation entre les 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 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 d'article jusqu'à son document d'origine — et les noms de fichiers seuls ne peuvent pas assurer cette traçabilité.
- Gestion des exceptions. Dans 50 documents, vous rencontrerez des champs vides. Un fournisseur a oublié d'imprimer le prix unitaire. Un autre a laissé la cellule TVA vide. Une photo de téléphone a coupé les lignes du bas du tableau des articles. Dans le traitement d'un seul document, vous les remarquez immédiatement et les résolvez. Dans le traitement par lots, les exceptions sont enfouies dans une pile — et les trouver nécessite de scanner chaque ligne complétée.
- Fusion des sorties. Même si vous pouviez extraire chaque document parfaitement, vous auriez cinquante feuilles de calcul séparées. Le livrable réel — celui dont votre équipe de réception a besoin — est un tableau unique avec toutes les lignes d'articles de tous les fournisseurs, trié et filtrable par date, fournisseur et numéro de bon de commande.
Le traitement d'un seul document teste votre vitesse de frappe. Le traitement par lots teste la conception de votre système. Le goulot d'étranglement passe de « à quelle vitesse puis-je taper » à « comment gérer tous les documents à la fois sans perdre la trace de ce qui vient d'où » — et c'est une question fondamentalement différente.
Pourquoi Douzone, ECOUNT et iQuest ne résolvent pas l'extraction des documents entrants
Le marché coréen de l'ERP a investi des décennies à perfectionner la génération de documents sortants. Les résultats sont impressionnants. Douzone Bizon (더존비즈온) — le plus grand fournisseur d'ERP de Corée, acquis par le fonds suédois EQT pour 1 300 milliards de KRW en 2025 — permet à ses ~20 000 clients entreprises de générer des 거래명세서 à partir des ventes en un clic, de remplir automatiquement les champs fournisseur et acheteur depuis la base clients, et d'imprimer ou d'envoyer par lot des centaines de relevés via WEHAGO et iCUBE.
ECOUNT (이카운트), qui sert plus de 80 000 clients entreprises au tarif fixe de 40 000 KRW/mois, suit le même modèle : saisie des ventes → génération automatique de 거래명세서 → diffusion multicanal (email, KakaoTalk, SMS, fax). Son module achats permet d'enregistrer les données d'achat reçues — mais la saisie est manuelle. Il n'existe pas de fonctionnalité « télécharger un document → extraire automatiquement les champs » pour les documents que vous recevez.
iQuest (아이퀘스트), créateur de 얼마에요 ERP, est le seul grand éditeur coréen à proposer une extraction OCR des 거래명세서 — prenez en photo un 거래명세서 reçu avec l'application mobile, et l'IA extrait les informations fournisseur et la liste d'articles dans l'ERP. C'est un vrai progrès, et à certains égards l'équivalent local le plus proche de ce que ImageToTable.ai fait pour des documents uniques. Mais le principe 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, ça marche. Pour une équipe achats qui reçoit cinquante 거래명세서 de quinze fournisseurs le dernier jour du mois, ça ne marche pas — 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 vrai traitement par lot.
경리나라 et 경영이지 — populaires auprès des petites entreprises coréennes pour leur simplicité — gèrent bien l'émission de 거래명세서 mais n'offrent aucune extraction de documents entrants. Pas plus que les grandes plateformes ASP : Popbill (팝빌), avec plus de 373 000 entreprises inscrites 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 des données structurées extraites des documents fournisseur que vous avez reçus en PDF, scan ou photo.
Le schéma est cohérent dans tous les ERP et plateformes comptables coréens : 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 manuellement.
La réalité de 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 : le 월말결제, où le paiement est effectué à la fin du mois de livraison, et le 익월결제, où le paiement est effectué à la fin du mois suivant. Dans les deux cas, les 거래명세서 reçus au cours du mois s'accumulent en une pile qui doit être rapprochée avant que le paiement puisse être autorisé.
Pour un fabricant ou distributeur coréen de taille moyenne avec 10 à 30 fournisseurs actifs, un mois typique génère 50 à 200 relevés de transactions entrants. Ils arrivent tout au long du mois — quelques-uns par jour — mais le rapprochement se fait dans une fenêtre de temps compressée : les 3 à 5 derniers jours ouvrables avant l'autorisation de paiement. Le service réception a besoin de chaque ligne de chaque 거래명세서 dans le système pour vérifier les bons de commande et préparer le calendrier de paiement pour l'équipe financière.
L'arithmétique de cette fenêtre, pour un lot conservateur de 50 documents :
| Tâche | Par document | × 50 documents |
|---|---|---|
| Ouvrir et lire les champs d'en-tête fournisseur/acheteur | 1 min | 50 min |
| Extraire les lignes (moy. 8 lignes par document) | 3 min | 2,5 heures |
| Vérifier la valeur fournie par rapport au bon de commande | 1 min | 50 min |
| Vérifier par rapport à la facture fiscale (세금계산서) | 1 min | 50 min |
| Total traitement manuel | ~5,5 heures |
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 du A4 standard, des formulaires manuscrits de petits fournisseurs familiaux qui n'ont jamais utilisé de logiciel de facturation, des photos mobiles prises par des livreurs et envoyées via KakaoTalk, et des copies numérisées avec un alignement de travers. Chaque variante de format ajoute des frictions — et ces frictions se cumulent lorsque vous travaillez contre la montre.
C'est pourquoi « tapez plus vite » cesse d'être une réponse autour du vingtième document. La vraie question n'est pas la rapidité avec laquelle vous pouvez saisir des champs individuels — c'est comment traiter tous les documents à la fois, en un seul flux de travail, avec un seul résultat, et avec une piste d'audit claire remontant à chaque fichier source.
Fonctionnement de l'extraction par lot : une définition de colonne, tous les fournisseurs
Le mécanisme central qui rend possible le traitement par lot des 거래명세서 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 exemples de mise en page), vous lui dites quoi chercher en tapant les noms des champs souhaités. L'IA lit visuellement le document, localise chaque valeur en comprenant sémantiquement la signification du nom de champ, et remplit le tableau de sortie — quel que soit l'endroit 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 lot viable. Un outil basé sur les coordonnées nécessite un modèle distinct pour chaque mise en page de 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, vous auriez besoin de quinze modèles, et tout modèle devient obsolète lorsqu'un fournisseur modifie la mise en page de son formulaire. Un outil d'extraction sémantique nécessite une seule définition de colonne — une liste de noms de champs comme « Nom du fournisseur », « Date de transaction », « Nom de l'article », « Quantité », « Prix unitaire », « Valeur de la fourniture » — et applique la même définition à chaque document du lot, quelle que soit sa mise en page.
Le traitement par lot dans ImageToTable.ai fonctionne sur ce principe. Vous téléchargez les cinquante fichiers 거래명세서 en une seule fois — PDF, scans JPG, captures d'écran PNG, photos WebP, le tout en un seul téléchargement. Vous définissez les colonnes que vous souhaitez extraire dans votre feuille de calcul de sortie. L'IA lit chaque document, trouve chaque champ par sa signification 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 multi-lignes), chaque champ demandé devient une colonne, et vous téléchargez un seul fichier — pas cinquante fichiers séparés.
Les fichiers sont traités de manière sécurisée et ne sont pas conservés.
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 du fournisseur (사업자등록번호) », « Date de transaction (거래일자) », « Nom 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 de la commande » — et le même ensemble de colonnes traite chaque 거래명세서 de chaque fournisseur. Cinquante fichiers, quinze fournisseurs, une seule sortie.
À raison de 5 à 10 secondes par page contre 3 minutes de saisie manuelle par document, le traitement par lots réduit 5,5 heures de frappe à environ 15 minutes de traitement — un gain d'efficacité de 18× — mais le véritable avantage n'est pas le temps gagné. C'est que le résultat se présente sous la forme d'un seul tableau fusionné, chaque ligne d'article étant traçable jusqu'à son document source, prête pour le rapprochement à 3 voies avec les bons de commande (BC) et les factures fiscales.
Rapprochement à 3 voies à grande échelle : BC → Relevé de transaction (거래명세서) → Facture fiscale (세금계산서)
Pour les équipes achats coréennes, extraire les données d'un relevé de transaction (거래명세서) dans un tableur 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 juridiquement réglementé — régi par l'article 32 de la loi sur la TVA, comportant des champs obligatoires tels que 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 donne droit à l'acheteur à la déduction de la TVA d'amont (매입세액 공제) et doit être reflété avec précision dans les déclarations de TVA trimestrielles (échéances : 25 janvier, 25 avril, 25 juillet, 25 octobre). Le relevé de transaction n'a pas une telle valeur juridique — c'est un justificatif privé (사적 증빙), non éligible à la déduction fiscale — mais c'est le document qui accompagne réellement les marchandises et qui contient le détail au niveau des articles que la facture fiscale omet souvent.
Le flux de travail du rapprochement à 3 voies à grande échelle :
BC → Relevé de transaction : vérifier que ce qui a été livré correspond à ce qui a été commandé
Comparez les articles, les quantités et les prix unitaires de chaque relevé de transaction fournisseur avec le bon de commande d'origine. Tout écart — quantité non conforme, substitution non approuvée, prix unitaire incorrect — doit être signalé et résolu avant même de traiter la facture fiscale. Extrayez les données du relevé de transaction dans une structure de colonnes incluant le numéro de BC pour chaque ligne.
Relevé de transaction → Facture fiscale : vérifier que les montants facturés correspondent aux montants livrés
La facture fiscale arrive séparément — souvent plusieurs jours après les marchandises, parfois jointe à un cycle de facturation mensuel consolidé. Sa valeur de fourniture (공급가액) et son montant de TVA (세액) doivent correspondre aux totaux du relevé de transaction. C'est là que le tableur fusionné prend tout son sens : une colonne issue de l'extraction du relevé de transaction, une colonne issue de l'extraction de la facture fiscale — une simple comparaison côte à côte remplace la vérification manuelle entre des documents distincts.
Facture fiscale → Déclaration NTS : vérifier l'exactitude de la déclaration de TVA
Les données de la facture fiscale — une fois vérifiées par rapport au relevé de transaction — alimentent la déclaration de TVA trimestrielle. Tout écart entre ce que le NTS a enregistré via la déclaration électronique du fournisseur et ce que vous déclarez déclenche un signal de vérification croisée. Le rapprochement à 3 voies constitue votre piste d'audit : il prouve que ce que vous avez payé correspond à ce que vous avez reçu et à ce que le fournisseur a déclaré.
L'association de l'extraction du relevé de transaction et de l'extraction de la facture fiscale est ce qui fait de cet outil 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 les deux doivent concorder.
Le problème de nommage : pourquoi le traitement par lots a besoin de la traçabilité des sources
Il existe un problème qui n'existe pas dans le traitement de documents uniques et devient critique dans les workflows par lots : savoir quelle ligne extraite provient de quel fichier.
Un lot de fin de mois typique 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érentKakaoTalk_20260502_143021.jpg— photo d'un 거래명세서 manuscrit, fournisseur inconnu d'après le seul nom de fichierscan001.pdf— formulaire papier scanné, nom du fournisseur intégré dans l'image mais pas dans le nom de fichier2026-04-30_거래명세표_대한포장.pdf— nom de fichier propre et identifiable — l'exception, pas la règle
Lorsque cinquante lignes extraites atterrissent dans votre feuille de calcul de sortie, vous devez savoir quelle ligne correspond au document original de quel fournisseur. 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 workflow d'extraction par lots dans 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 de fichier d'origine, vous permettant de tracer instantanément tout point de données jusqu'à son document source. Pour les documents avec des noms de fichier ambigus comme KakaoTalk_20260502_143021.jpg, renommez-les avant le téléchargement — 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 spécifiques aux lots que les tutoriels sur documents uniques ne mentionnent jamais. Lorsque vous traitez un document, vous savez d'où viennent les données parce que vous venez de le regarder. Lorsque vous en traitez cinquante, vous avez besoin que le système s'en souvienne pour que vous n'ayez pas à le faire.
La convention de nommage que vous établissez avant le téléchargement est votre piste d'audit. Un modèle cohérent — [CodeFournisseur]_[Date]_[TypeDocument].pdf — prend dix secondes par fichier et vous évite des heures d'enquête médico-légale sur les noms de fichier lorsqu'un écart apparaît lors du rapprochement.
Gestion de la diversité des formats : du manuscrit au généré par ERP
Le problème de 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 du papier laser, formaté professionnellement, chaque champ dans une grille prévisible. Un petit fournisseur d'emballages à Incheon rédige un 거래명세서 à la main sur un formulaire carbone pré-imprimé, détache la copie bleue acheteur (공급받는자용) et la remet au livreur. Un distributeur alimentaire de taille moyenne utilise un modèle Excel qui semble professionnel à l'écran mais imprime avec des cellules fusionnées qui chevauchent les limites des champs.
L'OCR classique — qui s'attend à du 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 sont déjà à faible contraste avant même de prendre en compte l'écriture du livreur. Les formulaires imprimés depuis Excel avec des cellules fusionnées produisent des blocs de texte où les étiquettes 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 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 sur un PDF, griffonné dans une marge sur un formulaire manuscrit, ou intégré dans une cellule Excel fusionnée, l'IA le localise en lisant le document comme le ferait un humain : en recherchant le sens sémantique, pas les coordonnées des pixels. La même définition de colonne qui fonctionne sur le PDF Douzone fonctionne sur le carbone manuscrit et l'impression Excel.
Il y a 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 « lisibilité » est nettement inférieur à ce qu'exige l'OCR basé sur des modèles — car un texte flou mais lisible reste sémantiquement compréhensible, même si ses coordonnées de pixels sont trop imprécises pour qu'un modèle puisse les faire correspondre.
Gestion des 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 car il est assujetti à la taxation simplifiée (간이과세자) et ne facture pas la TVA séparément. Un autre a saisi la valeur de la prestation dans la mauvaise cellule, donc l'extraction renvoie un nombre inattendu. Une photo prise avec un téléphone a coupé les deux dernières lignes d'un tableau de dix articles.
En traitement unitaire, vous remarquez ces anomalies instantanément — car vous regardez le document et les données simultanément. En traitement par lot, 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 processus de gestion des exceptions en mode lot :
Rechercher les vides dans les colonnes obligatoires
Après extraction, filtrez le tableau de sortie pour les cellules vides dans les colonnes critiques — Nom du fournisseur, Valeur de la prestation, Quantité. Un vide dans Quantité signifie généralement soit que la ligne d'article a été oubliée, soit que le document ne contenait pas de champ de quantité. Dans les deux cas, vous devez le savoir.
Vérifier les totaux par rapport aux sommes du document
La valeur de la prestation (공급가액) sur le 거래명세서 est la somme de tous les montants de ligne. Si vos montants de ligne extraits ne correspondent pas à la valeur de la prestation extraite, soit une ligne a été oubliée, soit la valeur de la prestation a été mal lue. Cette vérification croisée détecte les lacunes d'extraction sans vous obliger à relire chaque document.
Retraiter les documents problématiques individuellement
Si un document spécifique a produit des résultats peu fiables — signalés par des champs obligatoires vides ou une discordance de totaux — re-téléchargez-le individuellement pour une deuxième passe d'extraction. Le processus par lot ne vous oblige pas à retraiter l'ensemble du lot pour corriger les erreurs d'un seul document.
L'idée clé : le traitement par lot n'élimine pas les exceptions — il change la façon dont vous les trouvez. Au lieu de découvrir les erreurs un document à la fois en les saisissant, vous effectuez des vérifications structurées sur la sortie complète et isolez les documents problématiques. Le passage de la découverte réactive d'erreurs (trouver les erreurs en les commettant) à la détection proactive d'erreurs (analyser la sortie complète pour les anomalies) est ce qui rend le traitement par lot non seulement plus rapide mais aussi plus fiable.
Intégrer l'extraction par lots dans votre flux d'approvisionnement existant
L'extraction par lots de relevés de transaction (거래명세서) ne remplace pas votre ERP — et ce n'est pas son objectif. L'ERP gère les enregistrements de ventes, la génération de factures sortantes, la transmission au NTS et les rapports financiers. L'extraction par lots gère l'étape de saisie des données que l'ERP laisse à votre clavier.
Le point d'intégration est la sortie Excel. Extrayez toutes les données des 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. Chaque grand ERP coréen le prend en charge : Smart A et iCUBE de Douzone proposent l'import par lots Excel pour les enregistrements d'achat. ECOUNT fournit un import en masse Excel pour les relevés de transaction (거래명세서) et autres documents de transaction. iQuest 얼마에요 prend en charge le téléchargement Excel pour les données de relevés de transaction d'achat (매입거래명세표). Le tableur extrait devient la source d'import — propre, structuré et vérifié avant même de toucher votre ERP.
Pour les équipes qui traitent également 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 fournisseur d'équipements européen suit la même logique d'extraction — définir les colonnes, télécharger, obtenir un tableur. La langue et le format du document changent, mais le principe d'extraction par nom de colonne reste le même.
C'est fondamentalement différent de la promesse ERP tout-en-un. Vous ne remplacez pas votre système financier. Vous comblez la seule lacune que chaque ERP coréen laisse ouverte : le moment où le document d'un fournisseur — quel que soit son format d'arrivée — doit devenir une ligne dans votre tableur avant de pouvoir devenir un enregistrement dans votre ERP.
FAQ
Le traitement par lots peut-il gérer à la fois les relevés de transaction (거래명세서) manuscrits et imprimés dans le même téléchargement ?
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é en utilisant la même logique d'extraction sémantique. La même définition de colonne 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 des noms de colonnes ne repose pas sur une correspondance textuelle : elle localise les valeurs par compréhension sémantique. Un fournisseur dont le formulaire libelle le champ quantité comme « 출하수량 » (quantité expédiée) au lieu de « 수량 » (quantité) sera toujours correctement extrait, car l'IA comprend que les deux libellés renvoient au même concept. C'est la différence fondamentale entre la correspondance de modèles (qui échouerait) et l'extraction sémantique (qui s'adapte).
Comment le système gère-t-il les relevés de transaction (거래명세서) multipages avec des tableaux d'articles s'étendant sur plusieurs pages ?
Les PDF multipages sont traités comme un seul document. L'IA lit toutes les pages et extrait tous les articles du tableau, indépendamment des sauts de page. La sortie consolide toutes les lignes de toutes les pages dans l'enregistrement du même document dans le tableur.
Puis-je extraire uniquement des articles spécifiques — par exemple, seulement ceux correspondant à un numéro de BC particulier ?
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 le tableur de sortie après l'extraction — ce qui vous donne l'ensemble complet des données à traiter et à filtrer selon vos besoins, plutôt que de limiter 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 tenue de registres fiscaux ?
Le 거래명세서 lui-même est un document de vérification privé (사적 증빙) — il n'a pas de format légal imposé et n'est déposé auprès d'aucune autorité gouvernementale. Il n'existe aucune exigence de conformité spécifique régissant la manière 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 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 enregistrements de transactions pendant cinq ans — et un fichier Excel structuré avec traçabilité du nom du fichier source sert cet objectif bien mieux qu'une pile de formulaires papier.
Cela fonctionne-t-il aussi pour les factures fiscales coréennes en lot (세금계산서) ?
Oui — le même processus d'extraction par lot s'applique. Pour le traitement de factures fiscales par lot, définissez des colonnes comme le numéro d'enregistrement de l'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 téléchargement. Le principe d'extraction est identique ; seuls les noms des champs changent.
Tout ERP coréen peut générer un relevé de transaction à partir d'un enregistrement de vente. L'écart — et l'opportunité — se trouve du côté de la réception. L'extraction par lot le comble avec une définition de colonne, un téléchargement et un tableur. Essayez-la lors de votre prochain lot de fin de mois. Voyez si 5,5 heures de saisie deviennent 15 minutes de vérification.