30 factures fournisseur, un
Tableur AP prêt à payer

Ce que l'extraction par fichier unique laisse de côté

L'article principal sur l'extraction de données de factures japonaises vers Excel couvre la structure complète des champs — comment capturer les coordonnées bancaires, les conditions de paiement, la taxe à la consommation et la retenue à la source à partir d'une seule 請求書. Mais un flux de travail par fichier unique résout le problème d'extraction par document. Il ne résout pas le problème du traitement par lots vers le paiement, qui est un problème différent avec un ensemble de résultats différent.

Le comptable fournisseurs qui traite trente factures à la main suit une séquence : ouvrir le PDF de la facture, trouver le bloc des coordonnées bancaires, saisir les quatre champs bancaires dans l'écran de banque en ligne, analyser les conditions de paiement pour déterminer la date d'échéance, vérifier la retenue à la source, contrôler la ventilation de la taxe à la consommation et confirmer le numéro d'enregistrement de facture qualifiée par rapport au fichier fournisseur. Cette séquence se répète trente fois. L'acte d'extraction — lire les données sur la facture — et l'acte de préparation du paiement — assembler ces données dans un format prêt pour le virement bancaire — sont fusionnés en une seule tâche répétitive. Un outil d'extraction par fichier unique les sépare : les données sont extraites dans une ligne de feuille de calcul. Mais la préparation du paiement — assembler ces trente lignes en un fichier de virement groupé, un calendrier de paiement, un échéancier de dépôt de la retenue à la source et un récapitulatif de la taxe à la consommation prêt pour la déclaration fiscale — nécessite encore un assemblage manuel. L'extraction a résolu le problème de lecture. Elle n'a pas résolu le problème d'assemblage.

Le traitement par lots résout les deux simultanément, car il traite les trente factures comme une seule unité de travail — extrayant les données de tous les documents en une seule exécution et produisant des résultats structurés pour les systèmes en aval, et pas seulement pour qu'un humain les regarde.

Le flux de travail par lots : définir une fois, traiter chaque mois

Le schéma de colonnes pour le traitement par lots de factures japonaises est défini une fois. Les mêmes vingt-cinq noms de colonnes — Numéro de facture (請求書番号), Date d'émission (発行日), Fournisseur (発行元), Numéro d'enregistrement de facture qualifiée (インボイス登録番号), Nom de l'article (品名), Quantité (数量), Prix unitaire (単価), Montant de la ligne (金額), Sous-total (小計), Montant imposable à 10 %, Taxe à la consommation à 10 %, Montant imposable à 8 %, Taxe à la consommation à 8 %, Total (合計金額), Classification de la retenue à la source (源泉徴収区分), Nom de la banque (振込先銀行名), Nom de l'agence (支店名), Type de compte (口座種別), Numéro de compte (口座番号), Titulaire du compte (口座名義), Conditions de paiement (支払条件), Jour de clôture (締日), Responsabilité des frais de virement (振込手数料負担) — sont saisis une fois. Chaque mois suivant, l'équipe comptable dépose la pile de factures PDF de fin de mois dans l'outil d'importation, le lot traite tous les documents simultanément, et la feuille de calcul de sortie arrive avec les trente lignes remplies. Les noms de colonnes ne changent pas. Les formats de facture des fournisseurs peuvent changer — un nouveau système ERP chez un fournisseur, une migration de plateforme de facturation chez un autre — mais l'IA lit chaque document en comprenant ce que chaque champ signifie, et non en mémorisant où chaque fournisseur place ses coordonnées bancaires sur la page.

Ce schéma capture l'Extraction de colonnes personnalisées : vous saisissez les noms de colonnes souhaités dans la sortie, et l'IA localise les données correspondantes dans chaque document en comprenant la signification du champ — sans se fier à une position fixe qui varie d'une mise en page de facture d'un fournisseur à l'autre. Une colonne calculée peut dériver des valeurs supplémentaires lors de l'extraction : une colonne comme Montant net du paiement (si retenue à la source applicable : Total × 0,8979 ; sinon : Total) calcule directement le montant réel du virement. Une colonne inférée peut convertir le texte compact des conditions de paiement en valeurs structurées : Jour de clôture (d'après les conditions de paiement : si "20日締" alors 20) et Décalage de paiement en mois (si "翌月末払い" alors 1) — divisant la chaîne de texte "20日締翌月末払い" en deux nombres calculables qu'une formule de calendrier de paiement peut lire directement.

Résultat 1 : Les coordonnées bancaires deviennent un lot de paiement

La tâche de saisie la plus répétitive en comptabilité fournisseurs japonaise est la ressaisie des coordonnées bancaires de la facture dans le système de banque en ligne. Chaque 請求書 contient un bloc 振込先 avec quatre champs distincts : Nom de la banque (銀行名), Nom de l'agence (支店名), Type de compte (口座種別 — 普通 pour ordinaire ou 当座 pour courant) et Numéro de compte (口座番号). Le comptable lit ces quatre champs sur la facture, bascule vers l'écran de banque en ligne et les saisit — les mêmes quatre champs déjà stockés dans le fichier fournisseur du système comptable, ressaisis pour chaque facture chaque mois. Trente factures en fin de mois : 120 saisies individuelles de champs bancaires qui dupliquent des données déjà enregistrées.

Lorsque le résultat par lots contient chacun des quatre champs bancaires dans sa propre colonne — Nom de la banque, Nom de l'agence, Type de compte, Numéro de compte — ces colonnes constituent l'entrée d'un fichier de lot de paiement. Les banques japonaises acceptent les fichiers de virement par lots au format 全銀フォーマット (format Zengin), un format à largeur fixe standardisé par le réseau de compensation des paiements des banques japonaises (全国銀行資金決済ネットワーク) qui permet à une entreprise de soumettre plusieurs virements furikomi en un seul téléchargement plutôt que de les saisir un par un via l'écran de banque en ligne. Le format exige, pour chaque virement : le code de l'agence émettrice, le numéro de compte émetteur, le code de la banque bénéficiaire, le code de l'agence bénéficiaire, le numéro de compte bénéficiaire, le nom du bénéficiaire et le montant du virement — le tout à des positions de caractères précises.

Un tableur avec trente lignes, chacune contenant le nom de la banque, le nom de l'agence, le type de compte, le numéro de compte, le titulaire du compte et le montant net à payer dans des colonnes séparées, peut être mappé au format Zengin via un modèle simple. Les données sont déjà structurées — le mappage est un export ponctuel du tableur vers le format à largeur fixe, pas trente cycles de ressaisie de codes bancaires. La même approche s'applique au 総合振込 (virement consolidé), où un seul ordre de virement couvre plusieurs paiements depuis un seul compte d'entreprise — la méthode la plus courante pour les entreprises japonaises qui paient plusieurs factures fournisseurs le même jour de règlement. Les coordonnées bancaires extraites, regroupées par jour de règlement, constituent l'entrée d'un lot de virement consolidé : toutes les factures clôturant le 20 avec échéance de paiement en fin de mois vont dans un seul ordre de virement, toutes celles clôturant en fin de mois avec échéance le mois suivant vont dans un autre.

Résultat 2 : Les conditions de paiement deviennent un calendrier de règlement

Le champ des conditions de paiement sur une facture japonaise est une chaîne de texte compacte que les équipes AP lisent couramment mais qui résiste au traitement par formules. « 20日締翌月末払い » — la clôture de facturation a lieu le 20, le paiement est dû à la fin du mois suivant. « 末日締翌々月10日払い » — la clôture de facturation a lieu en fin de mois, le paiement est dû le 10 du mois suivant le suivant. « 15日締翌月末払い » — la clôture de facturation a lieu le 15, le paiement est dû à la fin du mois suivant. Chaque chaîne encode deux valeurs : un jour de clôture (締日) et un décalage de paiement. Dans un flux de travail mono-fichier, un humain lit la chaîne pour chaque facture, calcule mentalement la date d'échéance du paiement et la saisit dans un calendrier. Dans un flux de travail par lots, une colonne calculée analyse ces chaînes en nombres structurés — Jour de clôture et Mois de décalage de paiement — et le tableur regroupe automatiquement les paiements par jour de clôture.

Ce regroupement est important car il contrôle les sorties de trésorerie. Les factures clôturant le 20 et payables à la fin du mois suivant drainent toutes les liquidités le même jour. Les factures clôturant en fin de mois et payables à la fin du mois suivant drainent les liquidités deux à trois semaines plus tard, un jour différent. Sans le regroupement par lots, l'équipe AP voit trente dates d'échéance individuelles. Avec le regroupement par lots, l'équipe AP voit deux ou trois jours de sortie de trésorerie avec les montants totaux associés — l'information dont la fonction de trésorerie a réellement besoin pour gérer le fonds de roulement. Le jour de clôture, et non la date de facture ou le mois civil, détermine à quelle période fiscale appartient la dépense. Une facture datée du 18 mars avec des conditions 20日締 est une dépense de mars — payable en avril, mais comptabilisée dans l'exercice fiscal se terminant le 31 mars. Une facture datée du 22 mars avec les mêmes conditions 20日締 est une dépense d'avril — payable en mai, comptabilisée dans l'exercice fiscal suivant. Le jour de clôture est la limite de la période fiscale, et le résultat par lots regroupe automatiquement selon cette limite car la colonne calculée l'a extrait sous forme de nombre.

Résultat 3 : Les totaux de taxe à la consommation alimentent directement la déclaration fiscale

Le système de taxe à la consommation du Japon applique deux taux — 10 % standard et 8 % réduit — et le système de facture qualifiée exige que chaque facture indique séparément la base imposable et le montant de la taxe par catégorie de taux. Pour une entreprise utilisant la méthode d'accumulation (積上げ計算) pour la déclaration de taxe à la consommation, la déclaration fiscale nécessite les données fiscales par facture — pas seulement un sous-total agrégé, mais les montants de taxe individuels de chaque facture qualifiée, conservés au niveau de chaque document.

Le résultat par lots capture le montant imposable à 10 %, la taxe à la consommation à 10 %, le montant imposable à 8 % et la taxe à la consommation à 8 % de chaque facture dans des colonnes séparées. Le tableur fournit des totaux regroupés par taux qui peuvent être vérifiés par rapport à la ventilation fiscale imprimée de chaque facture — la même vérification que l'équipe AP effectuerait manuellement sur chaque facture, mais effectuée automatiquement sur l'ensemble des trente factures en un seul résultat. Si le montant total de taxe à la consommation à 8 % extrait d'une facture diffère du total imprimé sur le document, l'écart est signalé dans le tableur pour examen. La pile de trente factures devient une liste de vérification plutôt que trente tâches de vérification individuelles, et les totaux regroupés par taux constituent la saisie pour la déclaration trimestrielle de taxe à la consommation sans nécessiter un passage d'agrégation manuel séparé.

Résultat 4 : La retenue à la source devient un montant net à payer

Le système de retenue à la source (源泉徴収制度), régi par l'article 204 de la Loi relative à l'impôt sur le revenu (所得税法), oblige le payeur à déduire l'impôt sur le revenu à la source lors du paiement à certains prestataires de services professionnels — experts-comptables (税理士), commissaires aux comptes (公認会計士), avocats (弁護士), greffiers judiciaires (司法書士), designers (デザイナー), écrivains (著作家) et autres catégories éligibles. Le taux de retenue est de 10,21 % pour les paiements jusqu'à 1 million de yens, et de 20,42 % pour la partie excédant 1 million de yens, comme le confirme le guide de retenue à la source de l'Agence nationale des impôts. Le payeur reverse le montant retenu au bureau des impôts et verse le solde au fournisseur.

Une facture d'un fournisseur éligible comportant une classification de retenue à la source — souvent marquée 源泉徴収あり ou affichant une ligne distincte « 源泉徴収額 » — modifie le calcul du paiement. L'équipe AP doit identifier les factures nécessitant une retenue, calculer le montant de la déduction par facture, le soustraire du paiement et comptabiliser le montant retenu comme un passif distinct de dépôt fiscal. Dans un flux de travail mono-fichier, il s'agit d'un calcul manuel par facture éligible. Dans un flux de travail par lots, deux colonnes le gèrent :

• Classification de retenue à la source — une colonne inférée qui vérifie si la facture mentionne 源泉徴収 et si le fournisseur est un professionnel éligible. Résultat : « Applicable » ou « Non applicable ».
• Montant net à payer — une colonne calculée : si la retenue est applicable et que le total est inférieur à 1 million de yens, le résultat est Total × 0,8979. Affiche le montant réel du virement pour chaque facture.

Le tableur arrive avec trois colonnes par facture éligible : Montant brut (le total de la facture), Montant de la retenue (la déduction) et Montant net à payer (le montant du virement). Le fichier de paiement par lots utilise le Montant net à payer. Le calendrier de dépôt fiscal utilise le Montant de la retenue. Les deux puisent dans les mêmes données sources — extraites une fois, calculées une fois, disponibles à la fois pour le paiement et la conformité. La même approche de traitement par lots pour les bons de commande japonais capture les mêmes conditions de paiement et champs de retenue du côté des achats, créant ainsi un pipeline de correspondance entre ce qui a été commandé et ce qui est facturé.

La chaîne des numéros de facture : du PDF à la confirmation de paiement

Un numéro de facture (請求書番号) est la clé primaire pour la recherche en comptabilité fournisseurs et le suivi des paiements. Lorsqu'une confirmation de paiement arrive de la banque — un relevé de transaction montrant un virement de 847 200 ¥ vers la succursale Shinjuku de la Mitsubishi UFJ Bank, compte 1234567 — l'équipe comptable doit le rapprocher de la facture d'origine pour confirmer que le bon montant a été envoyé au bon compte pour la bonne facture. Sans le numéro de facture, faire correspondre une transaction bancaire à une facture fournisseur devient un problème de rapprochement qui s'aggrave avec le volume : trente paiements fournisseurs par mois, douze mois par an, 360 écarts potentiels.

Le résultat du traitement par lots contient le numéro de facture dans une colonne dédiée. Chaque confirmation de paiement de la banque peut être rapprochée du tableur du lot par numéro de facture — et non par montant, qui pourrait être ambigu si deux factures portent le même total — créant ainsi une piste d'audit allant du PDF de la facture d'origine au tableur d'extraction, jusqu'au relevé de paiement bancaire. Le numéro d'enregistrement de facture qualifiée (インボイス登録番号), extrait en même temps que le numéro de facture, offre un deuxième point de vérification : le numéro en T sur les données extraites doit correspondre à celui du fichier fournisseur. Un écart signale un fournisseur dont le statut d'enregistrement a peut-être changé — une information qui, dans un flux manuel, passerait inaperçue jusqu'à ce que la déclaration de TVA déclenche une demande de vérification.

Cette chaîne — numéro de facture → virement bancaire → confirmation de paiement — transforme trente virements individuels en un seul exercice de rapprochement. Le traitement par lots ne se contente pas d'extraire les données plus rapidement. Il crée la structure de liaison qui permet de rapprocher trente paiements en un groupe plutôt que de mener trente enquêtes séparées. Ce même principe de liaison, côté achats, est à l'origine du flux de rapprochement bon de commande-livraison-facture et de l'approche par lots trimestriels pour le BAS australien — le résultat de l'extraction n'est pas un point d'arrivée, mais un point intermédiaire dans une chaîne documentaire qui commence par un bon de commande et se termine par une déclaration fiscale.

FAQ

Le traitement par lots peut-il gérer des factures de fournisseurs utilisant des formats de facturation différents ?

Oui. Le schéma de colonnes est défini une fois et appliqué à chaque facture du lot, quel que soit sa mise en page. Un fournisseur peut utiliser un PDF généré par son ERP avec les coordonnées bancaires dans un encadré en bas de page. Un autre peut envoyer une facture manuscrite scannée où les coordonnées bancaires figurent dans la section des remarques. L'IA lit chaque document en comprenant la signification de chaque champ — un nom de banque est un nom de banque où qu'il apparaisse — sans attendre une mise en page fixe par fournisseur. Les trente factures peuvent provenir de trente systèmes de facturation différents dans trente formats différents, et le résultat est un tableur cohérent.

Comment le traitement par lots gère-t-il le format du numéro de compte Japan Post Bank ?

Japan Post Bank (ゆうちょ銀行) utilise un format code-numéro (記号-番号) qui diffère des numéros de compte à 7 chiffres utilisés par les banques commerciales pour les virements furikomi. Lorsque le résultat du lot détecte ゆうちょ銀行 comme nom de banque, une colonne inférée peut convertir la paire code-numéro (記号-番号) en numéro de compte de virement à 7 chiffres requis par le système bancaire. Japan Post Bank publie la règle de conversion sur son site web. La logique de la colonne analyse les chiffres du code (記号) et du numéro (番号) et génère le numéro de compte prêt pour le virement, tout en conservant le format original pour vérification.

Que faire si certaines factures sont TTC (税込) et d'autres HT (税抜) ?

La définition de la colonne doit préciser la normalisation souhaitée en sortie. Si les prix unitaires sont TTC sur certaines factures fournisseur et HT sur d'autres, une colonne calculée les normalise lors de l'extraction : Montant de ligne HT (si la facture mentionne 税込, diviser le prix unitaire par 1,1 pour les articles à 10 % ou 1,08 pour les articles à 8 % ; sinon, utiliser tel quel). L'IA lit le contexte du document — y compris toute mention 税込 ou 税抜 — pour déterminer le traitement de la taxe et générer tous les montants de ligne sur une base cohérente. Le tableur arrive avec chaque ligne normalisée, de sorte que les totaux de taxe à la consommation pour les trente factures sont calculés à partir d'une base uniforme.

Comment la colonne de retenue à la source (源泉徴収) interagit-elle avec le calcul de la taxe sur la consommation ?

Selon les directives de l'ANR, si la rémunération et la taxe sur la consommation sont clairement séparées sur la facture, la retenue est calculée uniquement sur le montant de la rémunération — la part de taxe sur la consommation n'est pas soumise à retenue. Si elles ne sont pas séparées, le montant TTC est généralement utilisé pour le calcul de la retenue. La définition de la colonne doit préciser la règle de calcul : Base de retenue (si la facture sépare clairement 報酬 et 消費税, utiliser 報酬 ; sinon, utiliser le Total) et Montant de la retenue (Base de retenue × 0,1021, plafonné à Base de retenue × 0,1021 pour les parts jusqu'à 1M¥). Le traitement par lots applique la même règle aux trente factures, garantissant ainsi la cohérence et la vérifiabilité du calcul de la retenue.

Le résultat du traitement par lots peut-il être importé directement dans un logiciel de comptabilité japonais ?

Oui. Toutes les grandes plateformes comptables japonaises — 弥生会計 (Yayoi), freee, マネーフォワード クラウド会計 (MoneyForward Cloud), 勘定奉行 (Kanjo Bugyo) — acceptent l'import CSV des données du grand livre des achats. Le résultat du traitement par lots correspond directement : Numéro de facture → numéro de pièce comptable (伝票番号), Fournisseur → nom du vendeur (仕入先), Date d'émission → date de transaction (日付), Total → montant (金額). Les colonnes de taxe sur la consommation par catégorie de taux alimentent le module de déclaration fiscale. Le numéro d'enregistrement de facture qualifiée (インボイス登録番号) est intégré à la vérification automatique des factures qualifiées que des plateformes comme freee effectuent. Les coordonnées bancaires — dans des colonnes séparées — constituent la saisie du fichier de paiement par lots de la banque, indépendamment de l'import du logiciel de comptabilité.

De trente PDF à un grand livre prêt au paiement

La pile de factures de fin de mois dans une entreprise japonaise n'est pas simplement trente factures à payer. Ce sont trente instructions de paiement — chacune contenant des coordonnées bancaires qui doivent être ressaisies dans le système bancaire. Ce sont trente documents fiscaux — chacun contenant des montants de taxe sur la consommation par catégorie de taux qui alimentent la déclaration trimestrielle. Ce sont trente enregistrements de conformité — certains comportant des obligations de retenue à la source nécessitant des dépôts fiscaux séparés. Et ce sont trente artefacts de rapprochement — des numéros de facture qui doivent correspondre aux bons de commande, aux confirmations de livraison et aux relevés de paiement bancaires.

Un flux de travail d'extraction par lots qui traite les trente factures comme une seule unité de travail produit non pas trente lignes de feuille de calcul individuelles, mais quatre résultats prêts à l'emploi : un fichier de paiement par lots avec les coordonnées bancaires déjà dans des colonnes prêtes au transfert, un calendrier de paiement regroupé par jour de règlement, un récapitulatif de la taxe sur la consommation par catégorie de taux pour la déclaration fiscale, et un échéancier de retenue avec les montants nets de paiement déjà calculés. La tâche de fin de mois de l'équipe AP passe de la saisie de données à la vérification de données — de la saisie des quatre mêmes champs bancaires trente fois à la vérification que trente lignes extraites correspondent aux documents sources. La feuille de calcul est le résultat. La feuille de calcul est aussi l'entrée — pour le système de paiement bancaire, le logiciel de comptabilité et la déclaration fiscale. Le traitement par lots les relie en produisant des données dans la structure attendue par chaque système en aval, et non en produisant des données qu'un humain doit reformater avant chaque transfert.