Avec quelle précision l’IA lit-elle les pièces comptables ?

L’essentiel

Une facture fournisseur n’est exploitable en comptabilité que si sa date, son numéro, son total et son montant de TVA ont été saisis correctement. Ogment lit ces informations dans vos pièces, afin que votre équipe les contrôle au lieu de les ressaisir. Le choix des modèles d’IA qui font cette lecture, et la qualité qu’ils atteignent, se décide chez nous sur des preuves. Ce rapport est cette preuve : chaque configuration testée en entier, mesurée sur les mêmes documents, face à des valeurs de référence connues.

Une distinction traverse tout ce qui suit : lire une pièce n’est pas la comptabiliser. Les tests mesurent si les informations ont été correctement extraites. Ils ne mesurent ni le traitement de la TVA, ni le choix du compte, ni le rapprochement bancaire. Ces décisions professionnelles restent les vôtres.

des totaux de quittances et de factures lus correctement par la configuration la plus précise

99,24 %

des montants de taxe sur les quittances réelles, meilleure configuration : le résultat le plus faible sur les quittances et factures

93,18 %

le coût de la configuration la plus précise par rapport à notre configuration de production, sur les quittances et factures

11×

des dates et des soldes des transactions sur les relevés bancaires lus correctement par la configuration la plus précise, pour les transactions appariées à la référence

99,99 %

• La meilleure configuration est très précise sur les champs qui comptent le plus. Kimi K3 a lu correctement 99,89 % des types de pièce, 99,80 % des numéros de pièce, 99,24 % des totaux et 99,15 % des dates. Notre configuration de production la suit à moins de deux tiers de point de pourcentage sur chacun de ces champs.
• Les erreurs se concentrent sur les quittances réelles. Sur les documents synthétiques, les trois configurations les plus fortes (la configuration de production, Kimi K3 et le modèle partenaire) lisent correctement chacun des cinq champs clés dans au moins 99,39 % des cas. Sur de vraies quittances de magasins et de restaurants, elles lisent correctement le montant de la taxe dans 89,32 % à 93,18 % des cas.
• La précision supplémentaire coûte beaucoup plus cher. Kimi K3 coûte USD 39.49 pour 1’000 documents, contre USD 3.47 pour la configuration de production : environ 11 fois plus, pour un gain de 0,13 à 0,63 point de pourcentage sur chacun des cinq champs exacts.
• Un modèle assez petit pour tenir sur un seul serveur en Suisse ne suffisait pas. Qwen3-VL-30B est bon marché et ses poids sont ouverts, mais il n’a lu correctement que 85,19 % des montants de taxe et 93,04 % des types de pièce, et n’a mené à terme que 326 fichiers de relevés bancaires sur 400.
• Beaucoup d’erreurs sont des champs vides, pas des valeurs fausses. Dans l’essai de la configuration de production, 31 erreurs de sous-total sur 52, 18 erreurs de taxe sur 38 et 13 erreurs de date sur 40 étaient des champs laissés vides. Un champ vide se voit au contrôle ; un chiffre faux, non.

Ce que nous avons testé

Une configuration, c’est la paire de modèles qui fait le travail : l’un lit chaque page, l’autre extrait les champs comptables de cette lecture. Notre configuration de production utilise un modèle différent pour chaque étape, chacun avec un second modèle de secours. Les trois autres configurations utilisent un seul modèle pour les deux étapes, sans secours : chaque résultat montre donc ce que ce modèle fait seul. Les poids d’un modèle sont les fichiers qui constituent le modèle entraîné ; lorsqu’ils sont publiés (« ouverts »), chacun peut faire tourner le modèle sur ses propres serveurs.

Trois autres modèles n’ont pas eu droit à un essai complet. Deux d’entre eux, Qwen3.5-27B et Qwen2.5-VL-72B, ne pouvaient pas fonctionner du tout avec notre traitement documentaire. Mistral Small 3.2 a mené à terme 95 documents d’un essai de 100 documents et a lu correctement 68,10 % de leurs montants de taxe, ce qui ne justifiait pas un essai complet.

Quittances et factures

Le premier jeu de test compte 4’801 documents issus de trois jeux de données de recherche publics : 1’987 quittances réelles de magasins et de restaurants d’Indonésie et de Malaisie, et 2’814 factures et quittances synthétiques (générées par ordinateur). Chaque document est accompagné de valeurs de référence. Pour chaque champ, un résultat est la part des valeurs de référence que la configuration a correctement extraites, moyennée sur les jeux de données qui contiennent une valeur de référence pour ce champ, chaque jeu de données comptant autant. Les quittances réelles sont étrangères : « montant de la taxe » désigne donc la taxe de vente ou de service qui y est imprimée, et non la TVA suisse.

Trois des quatre configurations sont proches. Kimi K3 est en tête, seul ou à égalité, sur chaque ligne ; la configuration de production et le modèle partenaire se disputent la deuxième place, et les trois se tiennent à moins de deux points sur chaque champ exact. Qwen3-VL-30B, c’est une autre histoire : compétitif sur les dates et les numéros de pièce, nettement en retrait sur la taxe, les totaux et le type de pièce.

Un résultat porte sur un seul champ à la fois. 99,24 % pour le total signifie qu’environ 99 totaux sur 100 ont été correctement extraits. Cela ne signifie pas que 99,24 % des pièces étaient entièrement correctes, et cela ne dit rien de la part d’écritures comptables correctes.

Le constat est le même pour les trois configurations les plus fortes : les documents synthétiques sont presque résolus, les quittances réelles non. Cela compte pour lire toute affirmation de précision, y compris la nôtre. Un test fait uniquement de factures propres et générées aurait placé chacune des trois configurations les plus fortes au-dessus de 99 % sur chacun des cinq champs exacts.

Relevés bancaires

Le second jeu de test compte 400 fichiers de relevés bancaires : 200 relevés synthétiques, sur le modèle de relevés bancaires d’entreprises indiennes, chacun en PDF numérique et en copie scannée. Un relevé est une tâche plus difficile qu’une quittance : plusieurs pages, de nombreuses transactions, et chaque ligne doit être retrouvée avant que ses champs puissent être justes.

Aucune configuration n’a mené tous les fichiers à terme. Au-delà de ces douze fichiers, la configuration de production a échoué sur 6 fichiers, Kimi K3 sur 4, le modèle partenaire sur 16 et Qwen3-VL-30B sur 62.

Sur les transactions retrouvées, les trois configurations les plus fortes lisent correctement les dates, les montants et les soldes dans au moins 99,59 % des cas. Les écarts sont ailleurs. La configuration de production confond débits et crédits plus souvent que Kimi K3 ou le modèle partenaire : 98,60 % contre 99,98 % et 99,83 %. Qwen3-VL-30B a le score des lignes le plus bas et n’a trouvé la bonne période de relevé que sur à peine la moitié des fichiers.

Les scans coûtent environ trois points au modèle partenaire et quatorze à Qwen3-VL-30B. Si vos clients envoient des scans et des photos plutôt que des exports bancaires, c’est ce tableau qu’il faut regarder.

Coût et vitesse

La précision est une face de la décision. L’autre, c’est ce qu’une configuration coûte à faire tourner et le temps que prend un document.

La configuration la plus précise est aussi, de loin, la plus chère : Kimi K3 coûte 11,4 fois la configuration de production sur les quittances et factures, et 5,3 fois sur les relevés bancaires, sur la consommation déclarée par les fournisseurs. Pour les relevés bancaires, nous avons regardé ce que cela achète — 0,50 point de fichiers menés à terme en plus, 0,36 point sur le score des lignes, 1,38 point sur le débit et le crédit — et nous avons gardé la configuration de production.

Qwen3-VL-30B est la configuration la moins chère sur les quittances et l’une des deux plus rapides. Sur les relevés bancaires, il n’est ni l’un ni l’autre : c’est la configuration la plus lente, et elle coûte plus cher que la configuration de production.

Où se situent les erreurs

Les moyennes cachent ce qu’un comptable a le plus besoin de savoir : à quelles erreurs s’attendre. Nous avons passé les erreurs en revue champ par champ. Voici les schémas qui reviennent, avec des décomptes tirés de l’essai de la configuration de production, sauf mention d’une autre configuration.

• Montants de taxe sur les quittances réelles

  Le résultat le plus faible sur les quittances et factures. Sur les 440 quittances réelles qui ont un montant de taxe de référence, la configuration de production en a lu 405 correctement, Kimi K3 410 et le modèle partenaire 393. Les quittances qui posent problème ont typiquement une ligne de taxe absente ou une taxe nulle ambiguë ; sur d’autres, un chiffre est mal lu ou le montant est mal déduit. Près de la moitié des erreurs de taxe de la configuration de production, 18 sur 38, sont des champs laissés vides plutôt que des montants faux.

• Séparateurs de milliers et ordre de grandeur

  Les quittances indonésiennes écrivent trente-six mille sous la forme 36.000, et une version antérieure en lisait certaines comme 36. Les instructions demandent désormais au modèle de lire ces séparateurs en cohérence avec les calculs imprimés sur la quittance. Avec les autres changements du même cycle, cela a fait passer les totaux corrects sur ces quittances de 83,13 % à 97,63 %. La même ambiguïté existe partout où les conventions diffèrent : 1’234.50 et 1.234,50 désignent le même montant.

• Dates

  La configuration de production s’est trompée sur 40 dates sur 3’801, dont treize laissées vides. 23 de ces 40 erreurs concernent des quittances scannées, où la cause habituelle est un chiffre mal lu ou une date compacte qui peut se lire de deux façons ; 17 concernent des documents synthétiques.

• Numéros de pièce

  Une version antérieure renvoyait souvent le libellé imprimé avec le numéro : « Order #INV-2024-089 » au lieu de « INV-2024-089 ». Cela causait 19 de ses 34 erreurs et c’est corrigé. Les 15 erreurs qui restent sont trois champs vides et des caractères omis ou remplacés.

• Quittances prises pour des factures

  Dans une version antérieure, 736 des 987 quittances d’un jeu de données étaient classées comme factures. Depuis que nous avons réécrit la manière de distinguer les deux, 981 de ces 987 quittances sont reconnues comme telles. Le graphique ci-dessous montre le changement pour chaque groupe de documents.

• Champs vides

  Quand la configuration de production échoue sur un champ, elle ne renvoie souvent rien plutôt qu’une valeur fausse : 31 erreurs de sous-total sur 52, 18 erreurs de taxe sur 38, 13 erreurs de date sur 40 et 10 erreurs de total sur 41 étaient des champs vides. Pour la personne qui contrôle, c’est le meilleur type d’erreur : un champ vide se voit, un chiffre faux non.

• Essais qui n’aboutissent pas

  Tout modèle échoue parfois à renvoyer un résultat exploitable : un appel de lecture de page expire, ou la réponse n’a pas la structure requise. Sur les quittances et factures, la configuration de production a eu besoin de 3 nouvelles tentatives, Kimi K3 a connu 6 échecs au premier passage et le modèle partenaire 12, et les trois ont terminé tous les documents. Qwen3-VL-30B a échoué sur 128 documents au premier passage et en avait encore 46 inachevés après une nouvelle tentative.

• Fichiers en échec et sens sur les relevés bancaires

  Sur les relevés bancaires, la perte la plus lourde est un fichier qui échoue entièrement. Parmi les fichiers menés à terme, la principale faiblesse de la configuration de production est le sens : elle s’est trompée entre débit et crédit sur 1,40 % des transactions retrouvées, contre 0,02 % pour Kimi K3.

Un second regard sur les calculs

Une facture se contrôle elle-même : sous-total plus taxe donne le total, et les lignes de détail donnent le sous-total. Après la comparaison ci-dessus, nous avons construit ce contrôle, accompagné d’un second passage d’extraction, et relancé la configuration de production avec les deux le 10 septembre, sur un ensemble plus large de 5’301 documents qui ajoute 500 tickets de paiement par carte synthétiques (des tickets de terminal de paiement, et non des bulletins de versement suisses).

des 5’301 documents dont les montants extraits ne concordaient pas

709

sous-totaux modifiés par le second passage

232

montants de taxe modifiés par le second passage

43

des totaux de tickets de paiement par carte lus correctement

99,80 %

Cet essai utilise un autre ensemble de documents ; ses résultats ne peuvent donc pas être fusionnés avec les tableaux ci-dessus. Il montre à quelle fréquence les calculs ne concordent pas, et qu’un second passage modifie bel et bien des valeurs : le plus souvent le sous-total (232 documents), puis l’adresse du fournisseur (62), la monnaie (60), le numéro de pièce (44) et le montant de la taxe (43). Savoir si chaque modification est une correction est une mesure à part.

L’IA pourrait-elle tourner en Suisse ?

Les fiduciaires demandent si les modèles d’IA eux-mêmes pourraient tourner en Suisse, et pas seulement le stockage. Nous avons regardé ce que cela demanderait pour les deux configurations dont les poids du modèle sont ouverts.

• Qwen3-VL-30B tient sur un seul serveur. Ses poids pèsent 62,2 Go et tiennent sur une seule carte graphique de 96 Go. Un serveur doté de cette carte est affiché à CHF 2’632 par mois chez un fournisseur suisse et à moins de CHF 2’993 chez un autre, avant l’exploitation, les sauvegardes et un second serveur pour la disponibilité. Mais c’est la configuration qui a lu correctement 85,19 % des montants de taxe et mené à terme 326 fichiers de relevés sur 400.
• Kimi K3 demande une grappe de serveurs. Ses poids pèsent environ 1,4 To. Seize cartes graphiques dans un centre de données suisse reviennent à environ CHF 24’800 par mois au prix catalogue, pour une capacité que nous estimons à cinq à dix utilisateurs simultanés. Ce n’est pas une base pour servir un produit.
• La configuration de production et le modèle partenaire ne peuvent pas être hébergés par nos soins. Leurs poids ne sont pas publiés.

Aujourd’hui, parmi les configurations que nous avons testées, le choix est donc entre un modèle que nous pourrions héberger en Suisse et un modèle assez précis, et nous avons choisi la précision. Vos documents sont stockés en Suisse ; le traitement par IA a lieu dans l’Union européenne, aux conditions décrites plus bas.

Prix : Prix catalogue publics en francs suisses, relevés le 4 septembre 2026 pour la grappe Kimi K3 et le 9 septembre 2026 pour le serveur unique. Les capacités sont des estimations, et non des mesures.

Notre méthode de mesure

1. Des documents aux valeurs connues. Nous avons utilisé des jeux de données de recherche publics dans lesquels chaque document est accompagné de valeurs de référence : la date, le total ou les transactions qui y figurent réellement. Aucun document client n’a été utilisé. Parmi les quittances et factures, 1’987 sont des quittances réelles et 2’814 des documents synthétiques ; tous les fichiers de relevés bancaires sont synthétiques.
2. Le traitement. Chaque configuration a traité chaque document comme le fait le produit : chaque page est lue, puis les informations comptables sont extraites dans des champs définis, tels que la date, le numéro de pièce, le total et le montant de la taxe.
3. La comparaison avec la référence. Chaque valeur extraite a été comparée à la valeur de référence. Les différences courantes de format de date ne comptaient pas comme des erreurs : 31.03.2024 et 2024-03-31 désignent la même date. Les montants devaient correspondre au centime près ; les numéros de pièce devaient correspondre, abstraction faite des espaces, de la ponctuation, des majuscules et des minuscules.
4. Le décompte. Pour chaque champ, nous avons compté combien de valeurs de référence ont été correctement extraites. Les documents sans valeur de référence pour un champ n’ont pas été pris en compte pour celui-ci ; lorsqu’une valeur de référence existait mais que rien n’avait été extrait, cela comptait comme une erreur. Comme 59 % des quittances et factures sont synthétiques, chaque score a d’abord été calculé au sein de chaque jeu de données, puis les jeux de données ont reçu le même poids : les quittances réelles pèsent ainsi autant que les documents synthétiques.

À titre d’illustration, pas un cas de test : Si une facture indique un total de CHF 108.10, un total extrait de 108.10 est correct, alors que 108.01 ou 1’081.00 compte comme une erreur.

Sur les relevés bancaires, une ligne extraite n’a été appariée à une ligne de référence que si les deux concordaient largement pour la date, le montant, le solde, le sens (débit ou crédit) et le libellé, et les paires devaient suivre l’ordre du relevé. La date, le montant et le solde ont ensuite été contrôlés sur les lignes appariées. Une ligne lue de manière trop différente pour être appariée ne compte pas comme un montant erroné : elle abaisse le score des lignes, comme ligne manquée et, si elle a été extraite, comme ligne ajoutée.

Les jeux de données sont CORD v2 (1’000 quittances réelles d’Indonésie), ICDAR 2019 SROIE (987 quittances réelles scannées de Malaisie), Invoice OCR Synthetic (2’814 factures et quittances synthétiques) et Indian Bank Statements (400 fichiers synthétiques). Les trois premiers sont publiés sous licence CC BY 4.0 et le quatrième sous licence Apache 2.0 ; nous en avons utilisé des versions figées.

Ce que cela signifie pour votre contrôle

• Les résultats décrivent les documents testés. Les quittances réelles sont des tickets de magasins et de restaurants d’Indonésie et de Malaisie, et non des documents suisses. Les mises en page, les langues et la qualité de numérisation des pièces de vos fournisseurs peuvent différer.
• Une partie des données de test est synthétique. Les numéros de pièce n’ont été mesurés que sur des documents synthétiques, et tous les relevés bancaires sont synthétiques, et non de vrais relevés suisses. Comme le montrent les résultats ci-dessus, les documents synthétiques sont plus faciles que les vrais.
• Un champ exact ne rend pas toute la pièce correcte. Chaque champ est mesuré séparément.
• Les scans sont plus difficiles. Sur les relevés bancaires, les résultats sur les copies scannées étaient jusqu’à trois points inférieurs à ceux des originaux numériques pour les trois configurations les plus fortes.
• Des résultats de test ne sont pas une promesse. Ils décrivent ces essais de septembre 2026, pas chaque document, et la configuration qui traite vos documents peut changer lorsqu’une autre fait mieux dans ces tests.
• Le jugement professionnel vous appartient. Les tests ne portaient ni sur le traitement de la TVA, ni sur l’imputation comptable, ni sur le rapprochement, ni sur l’exactitude des écritures comptables.

Concrètement : vérifiez les montants de taxe et les totaux extraits — en particulier sur les quittances — avant de vous y fier, regardez à deux fois les champs vides, et contrôlez les données de relevés comme toute autre donnée utilisée pour un rapprochement.

Où sont traitées les données de vos clients

Les documents de vos clients sont confidentiels. Trois questions distinctes déterminent ce qu’il en advient, et nous répondons à chacune séparément.

• Où les documents sont-ils stockés ?

  En Suisse. Les documents que vous déposez dans Ogment sont stockés en Suisse.

• Où le traitement par IA a-t-il lieu ?

  Uniquement dans l’Union européenne. Lorsqu’un document est lu et que ses informations sont extraites, ce traitement par IA a lieu exclusivement dans l’UE.

• Que conservent les fournisseurs d’IA ?

  Pas le contenu de vos documents. Selon notre politique Zero Data Retention (aucune conservation des données par les fournisseurs d’IA après le traitement), nos fournisseurs d’IA ne conservent ni le contenu des documents qu’ils reçoivent ni les réponses qu’ils génèrent, une fois le traitement terminé. Par ailleurs, ils n’utilisent pas ce contenu pour entraîner des modèles d’IA.

La politique Zero Data Retention s’applique aux fournisseurs d’IA. Elle ne signifie pas qu’Ogment supprime vos documents : ils restent stockés dans votre espace Ogment en Suisse, afin que votre équipe puisse continuer à les utiliser. Et « non utilisé pour l’entraînement » et « non conservé » sont deux engagements différents — nous prenons les deux.