Relevés bancaires en PDF : les lire par OCR et les contrôler

Pourquoi un relevé bancaire résiste-t-il à l'OCR classique ?

Un relevé bancaire résiste à l'OCR classique parce que l'information utile tient dans la structure du tableau, et que cette structure change d'une banque à l'autre. Un moteur de reconnaissance optique de caractères (OCR) lit très bien les chiffres. Il ne sait pas dire, seul, à quelle ligne et à quelle colonne appartient chacun d'eux.

Les difficultés que je rencontre sur ce document :

• Des tableaux sur plusieurs pages, avec des lignes « report » qu'il ne faut pas compter comme des opérations.
• Des libellés sur deux ou trois lignes (virement avec référence, prélèvement avec identifiant du créancier), que l'OCR découpe en opérations fictives.
• Une mise en page propre à chaque banque : montants signés chez l'une, colonnes débit et crédit chez l'autre, date de valeur en plus chez une troisième.
• Des scans de travers, des photocopies, des relevés pliés photographiés au téléphone.
• Des sous-totaux par période ou par carte, qui se confondent avec des mouvements.

L'extraction de données par IA (document AI) combine l'OCR, l'analyse de la mise en page et un modèle qui comprend le tableau. Le principe est décrit dans mon guide sur l'OCR et l'extraction de documents par IA. Le relevé bancaire y ajoute une contrainte forte : les chiffres doivent tomber juste au centime.

Cherchez d'abord la source structurée

La meilleure lecture d'un relevé est celle qu'on n'a pas à faire : si la banque fournit les opérations sous forme de données, elles sont exactes par construction. Je vérifie toujours ces sources avant de proposer un OCR.

La synchronisation passe par des prestataires de services d'information sur les comptes, encadrés par la deuxième directive sur les services de paiement (DSP2) et soumis à un statut délivré par l'ACPR, comme le rappelle sa page sur l'accès aux API des banques. La plupart des logiciels comptables intègrent ce flux. Pour un dossier suivi au mois, c'est la voie normale, et la page IA pour les experts-comptables détaille ce que l'IA ajoute ensuite : imputation, relances, revue avant signature.

Quatre cas où le PDF reste la seule source

L'OCR avec IA devient nécessaire chaque fois que le relevé n'existe plus, ou n'a jamais existé, sous forme de données. Dans les dossiers que je vois, cela recouvre quatre situations.

• L'historique. Reprise d'un dossier, premier exercice d'un nouveau client, revue d'exercices passés : l'historique accessible par synchronisation est limité et varie selon la banque.
• Les banques étrangères. Un compte ouvert hors de France ou dans un établissement mal couvert par les agrégateurs, avec des relevés dans une autre langue ou une autre devise.
• Les relevés papier. Associations, SCI familiales, comptes clôturés dont l'accès en ligne a disparu.
• Les pièces transmises par un tiers. Relevés fournis à l'appui d'un financement, d'une succession, d'un litige ou d'un audit d'acquisition, sans accès à la banque.

Dans ces quatre cas, la ressaisie à la main reste la solution par défaut : c'est elle qu'une lecture automatique contrôlée remplace.

De la page scannée au fichier d'import

Une extraction fiable suit six étapes, chacune avec sa vérification. Ce passage est technique ; la section suivante revient au contrôle qui intéresse le comptable.

1. Identifier le document. Banque, titulaire, IBAN, période, devise.
2. Préparer les pages. Redressement, recadrage, séparation des relevés quand un client envoie un seul PDF qui en contient plusieurs.
3. Reconstituer le tableau. L'OCR donne le texte et sa position ; un modèle multimodal (qui voit l'image et le texte) rattache chaque fragment à sa ligne et à sa colonne, recolle les libellés et écarte reports et sous-totaux.
4. Normaliser. Dates au même format, montants signés, séparateur décimal, devise, distinction entre date d'opération et date de valeur.
5. Contrôler. Soldes, continuité, doublons, dates : le détail suit.
6. Exporter. Un fichier au format attendu par le logiciel comptable (CSV aux colonnes fixées, OFX ou CAMT.053), chaque ligne gardant sa page d'origine.

Le moteur OCR se choisit par comparaison sur un échantillon de vos relevés. C'est la démarche suivie pour Lokimo sur des documents scannés d'une autre nature : plusieurs moteurs comparés sur le même jeu de test avant de trancher. Quand les banques sont nombreuses ou les scans difficiles, cette chaîne relève d'un développement IA sur mesure, confié à un freelance IA ou à une agence capable de mesurer ce qu'elle livre.

Solde initial + mouvements = solde final

Le contrôle central d'un relevé extrait est arithmétique : le solde initial, augmenté des crédits lus et diminué des débits lus, doit redonner exactement le solde final imprimé par la banque. S'il manque une ligne, si un montant est mal lu ou si un report a été compté comme une opération, l'égalité tombe.

Exemple illustratif : solde initial de 12 480,35 €, crédits lus de 8 210,00 €, débits lus de 9 954,12 €. Le solde final attendu vaut 12 480,35 + 8 210,00 − 9 954,12 = 10 736,23 €. Si la banque imprime 10 763,23 €, l'écart de 27,00 € signale une erreur de lecture ; un écart multiple de 9 oriente vers deux chiffres inversés.

Ce contrôle tourne à plusieurs niveaux :

• Par page, quand la banque imprime un report : l'erreur est localisée à une page près.
• Par relevé, sur les soldes et sur les totaux débit et crédit imprimés en bas.
• Entre relevés : le solde final d'un mois doit égaler le solde initial du suivant, sinon un relevé manque.
• Doublons et dates : une opération lue deux fois à cheval sur deux pages, une date hors période.

Un relevé qui passe tous les contrôles part en import. Les autres sont signalés avec la page, la ligne suspecte et l'écart. L'outil signale et source ; le collaborateur tranche, la zone du scan affichée à côté de la valeur lue.

Le rapprochement, là où se mesure le temps gagné

Le temps gagné se mesure au rapprochement : une fois contrôlé, le relevé extrait rejoint le circuit habituel (journal de banque, rapprochement avec les pièces, lettrage) sans ressaisie. L'automatisation tient en un flux :

1. un dossier partagé ou une boîte e-mail reçoit les relevés PDF ;
2. la chaîne d'extraction lit, normalise et contrôle ;
3. les relevés conformes partent en import, les autres dans une file de vérification ;
4. un récapitulatif liste, par client, les relevés traités, les écarts et les mois manquants.

Ce récapitulatif nourrit aussi les relances : un mois manquant devient une demande de pièce envoyée au client. Ce flux se monte avec un orchestrateur comme n8n et des briques d'extraction testées sur vos relevés, comme je le décris sur la page automatisation IA des processus. Les fourchettes de budget figurent sur la page coût d'une automatisation n8n.

Constaté sur ce type de tâche : la ressaisie d'un relevé de plusieurs pages se compte en dizaines de minutes, la vérification d'un relevé extrait et contrôlé en minutes. Le seul chiffre qui vous engage est celui mesuré sur vos relevés pendant un test.

Un relevé bancaire se traite comme une pièce confidentielle

Un relevé bancaire contient des données personnelles au sens du RGPD et, dans un cabinet, des informations couvertes par le secret professionnel : il ne doit passer que par des systèmes choisis, sur une infrastructure dont vous connaissez la localisation. Il raconte la vie d'une entreprise ou d'une personne : salaires, loyers, fournisseurs, parfois des dépenses de santé.

• Hébergement maîtrisé. OCR et modèle hébergés en France ou dans l'Union européenne, ou modèle ouvert sur votre serveur. Aucun relevé dans un outil grand public.
• Aucune réutilisation. Les documents n'entraînent aucun modèle et les fichiers intermédiaires sont supprimés après l'import.
• Une trace exploitable. Chaque ligne importée garde le lien vers sa page source.
• Une conservation inchangée. Les relevés restent dans votre GED avec les pièces justificatives, que le Code de commerce impose de conserver dix ans à compter de la clôture de l'exercice.

Les banques et directions financières qui analysent les relevés de leurs propres clients (dossier de crédit, connaissance client) ont les mêmes besoins, secret bancaire en plus : la page IA pour la banque et la finance couvre ces usages.

La grille : un circuit par type de relevé

Chaque type de relevé a son circuit le plus court et son contrôle minimal. Voici la grille que j'utilise.

Mon seuil de décision : tant que les relevés PDF se comptent sur les doigts d'une main chaque mois, un convertisseur et un contrôle des soldes suffisent. Quand ils arrivent par dizaines, de banques différentes, ou qu'une reprise d'historique se profile, une chaîne contrôlée se justifie. Pour en juger, réunissez dix relevés représentatifs, pires scans compris : c'est l'échantillon sur lequel je mesure ce qui passerait sans intervention.