Extraction de relevés bancaires
Du PDF aux données structurées et vérifiées
L'OCR lit le texte. Mais un relevé bancaire n'est pas du texte, c'est un tableau. L'OCR vous donne "1.250,00" mais pas si c'est un débit, un crédit ou un solde progressif. Il vous donne "VIREMENT RECU / ÜBERWEISUNG" mais pas à quelle ligne ça appartient. Une seule erreur d'affectation et tous les soldes suivants sont faux. Holofin reconstruit la structure du tableau, affecte chaque valeur à sa ligne et sa colonne, et prouve le résultat en réconciliant le solde.
Planifier une démoPourquoi l'OCR générique
se trompe systématiquement
Un relevé bancaire ressemble à un simple tableau. Ce n'en est pas un. Chaque émetteur formate les choses différemment, et le format PDF lui-même joue contre vous. Voici ce qui pose réellement problème.
Chaque banque fait différemment
Il n'existe aucune norme pour la mise en page des relevés bancaires. BNP Paribas met les dates à gauche et utilise des colonnes Débit/Crédit séparées. Deutsche Bank utilise une seule colonne Montant avec des indicateurs D/C. Revolut n'inclut même pas de soldes progressifs. Un modèle entraîné sur une banque produit n'importe quoi sur une autre.
« 1.250 », c'est mille ou 1,25 ?
Les banques françaises écrivent "1 250,00 €". Les allemandes "1.250,00 EUR". Les britanniques "£1,250.00".
Le même point signifie "milliers" à Francfort et "décimales" à Londres. La même virgule signifie l'inverse. Un espace est un séparateur de milliers à Paris et rien du tout à New York.
Lisez un seul séparateur de travers et un loyer de 1 250 € devient 1,25 €. Votre contrôle de solde ne le détectera pas. Les chiffres s'additionnent toujours, mais arrivent au mauvais total.
Quelle colonne est le débit ?
Une colonne ou deux ? Des nombres négatifs ou un indicateur "D/C" ? Un signe moins à gauche, à droite, ou des parenthèses ? Les banques allemandes utilisent "S" et "H". Certaines laissent simplement l'autre colonne vide. Le tableau paraît évident pour un humain. C'est un cauchemar à parser automatiquement.
Des tableaux qui se coupent entre les pages
200 transactions ne tiennent pas sur une page. Le tableau continue en page 2, parfois avec les en-têtes répétés, parfois sans. Une transaction peut commencer sur une page et se terminer sur la suivante. Il faut reconstruire le tableau avant de pouvoir extraire quoi que ce soit.
Plusieurs comptes dans un seul PDF
Votre client envoie un seul PDF de 47 pages. Il contient trois comptes (courant, épargne, carte de crédit) sur quatre trimestres. C'est 12 relevés distincts dans un seul fichier. Traitez-le comme un tableau continu et vous obtenez n'importe quoi.

Tout ce qui ressemble à une transaction n'en est pas une
Les banques remplissent les relevés de tableaux auxiliaires qui ressemblent exactement à des transactions : détails de paiements par carte listant chaque paiement sans contact, récapitulatifs de virements SEPA répétant chaque prélèvement, grilles de frais, calculs d'intérêts. Extrayez-les et vous comptez en double. Sautez le mauvais et votre solde est faux.
Les vraies transactions se trouvent dans le tableau principal. Tout le reste n'est que du bruit déguisé en données.
Comment ça marche
Chaque relevé bancaire passe par quatre étapes. Pas de templates, pas de configuration spécifique par émetteur. Le même pipeline traite BNP Paribas et Chase.
Classification
Notre classifieur identifie plus de 100 émetteurs bancaires à partir d'indices visuels et textuels : positions des en-têtes, structures de colonnes, logos, patterns de texte. Aucun template à configurer par banque.
Segmentation
Les PDF multi-comptes sont découpés avant l'extraction. Nous détectons les limites de compte par IBAN, numéro de compte et marqueurs de période. Ce PDF de 47 pages devient 12 segments, traités en parallèle.
Extraction
Un modèle visuel lit la mise en page et extrait les données de transaction : date, libellé, débit, crédit, solde progressif et métadonnées de compte. Pas de règles de template. Le modèle comprend la structure du tableau.
Chaque extraction produit un JSON comme celui-ci :
{
"bank_name": "Qonto",
"currency": "EUR",
"account_type": "current",
"usage_type": "business",
"client_names": ["Starflight Dynamics GmbH"],
"account_number": "DE15100101232339317943",
"start_balance": 3071.69,
"end_balance": 3030.39,
"start_date": "2025-05-01",
"end_date": "2025-05-31",
"validation_status": "OK",
"transactions": [
{
"transaction_date": "2025-05-02",
"value_date": "2025-05-02",
"amount": -963.9,
"description": "Schmittlein Kloster Arbeitsrecht Partnerschaft",
"credit": null,
"debit": 963.9,
"page": 1,
"row": 1
}
]
}Validation
C'est là que la plupart des outils s'arrêtent, et là que nous commençons. Chaque segment extrait est vérifié :
- Réconciliation des soldes : solde d'ouverture + total crédits − total débits = solde de clôture, avec une tolérance de 2 €. Si l'équation ne s'équilibre pas, l'extraction est signalée.
- Continuité du solde progressif : le solde progressif de chaque transaction doit être égal au solde précédent plus/moins le montant de la transaction. Les ruptures indiquent des lignes manquantes ou mal extraites.
- Ordre chronologique : les dates de transaction doivent suivre l'ordre chronologique au sein de la période du relevé. Des dates désordonnées suggèrent des erreurs d'affectation de lignes.
- Détection des doublons : les transactions identiques (même date, libellé, montant) sont signalées pour revue plutôt que silencieusement incluses.
Équation de réconciliation des soldes :
Montrez votre travail
Chaque valeur extraite porte des coordonnées qui pointent vers sa position exacte sur la page source. Pas simplement « ça vient de la page 3 » mais le bounding-box au pixel près autour du texte original. Vous pouvez vérifier n'importe quel chiffre en cliquant dessus.
Les auditeurs adorent ça
Quand un auditeur demande « d'où vient ce chiffre ? », vous lui montrez. L'emplacement exact sur le PDF source, surligné. Pas de « c'est le système qui l'a dit ».
Corrigez les erreurs en quelques secondes
Votre vérificateur repère un montant erroné. Il clique sur la valeur. La zone source se surligne sur le document original. Comparer, corriger, passer au suivant.
Traçabilité complète des données
Remontez n'importe quel chiffre depuis la décision de crédit jusqu'au relevé bancaire original, à la page et à la ligne. La chaîne complète est documentée. Les régulateurs n'ont pas à vous croire sur parole.
Scale and Coverage
Nous traitons plus de 100 000 documents par mois pour des équipes de crédit à travers l'Europe. Voici à quoi ressemble l'infrastructure.
Infrastructure
~40 secondes par relevé
De l'upload au JSON validé. Les documents multi-segments sont traités en parallèle, donc un PDF de 12 segments ne prend pas 12 fois plus de temps.
API REST + webhooks
Upload via API, réception d'un webhook en fin de traitement. Upload par lots pris en charge.
Infrastructure européenne, conforme RGPD
SLA de 99,9 % de disponibilité. Rétention configurable. Les données ne quittent jamais l’UE.
Banques couvertes
Banques françaises
BNP Paribas, Société Générale, Crédit Agricole, Crédit Mutuel, La Banque Postale, Boursorama, CIC, LCL, Caisse d'Épargne
Banques allemandes
Deutsche Bank, Commerzbank, Sparkasse, Volksbank, N26, DKB, ING DiBa, HypoVereinsbank
Pan-européennes & internationales
ING, HSBC, Revolut, Wise, Barclays, Lloyds, NatWest, UniCredit, Rabobank, ABN AMRO, Santander
Banques britanniques & américaines
Chase, Bank of America, Wells Fargo, Citi, HSBC UK, Barclays UK, Monzo, Starling
Vous ne voyez pas votre banque ? Elle fonctionne probablement quand même.
Nous n'utilisons pas de modèles. Le moteur d'extraction lit la mise en page directement dans le document. Les nouveaux émetteurs fonctionnent sans configuration.
FAQ
Les questions qui reviennent le plus souvent de la part des équipes de crédit et de comptabilité.
Holofin traite les relevés bancaires PDF natifs de tout émetteur dans le monde, y compris toutes les grandes banques européennes, britanniques et américaines. Il gère aussi bien les relevés générés numériquement que les relevés scannés. Aucun modèle ni configuration spécifique à l'émetteur n'est nécessaire. Le système apprend la mise en page à partir du document lui-même. Nous couvrons activement plus de 100 émetteurs avec une précision d'extraction validée, et les nouveaux émetteurs fonctionnent généralement sans aucune configuration.
Le moteur de segmentation d'Holofin détecte les frontières entre comptes (IBAN, numéro de compte, marqueurs de période) et découpe les PDF combinés en segments de relevé individuels avant extraction. Un PDF de 47 pages avec 3 comptes sur 4 trimestres devient 12 segments indépendants, validés séparément. Chaque segment est extrait et réconcilié individuellement, puis agrégé dans une réponse JSON unifiée.
La précision au niveau des champs dépasse 97 % sur les relevés bancaires PDF natifs parmi les émetteurs testés. Mais la précision brute ne dit pas tout. Chaque extraction inclut une réconciliation automatique des soldes (solde d'ouverture + crédits − débits = solde de clôture), offrant une validation mathématique qui rattrape des erreurs d'extraction qu'une simple métrique de précision laisserait passer. Lorsque la réconciliation échoue, l'extraction est signalée pour revue humaine plutôt que passée silencieusement.
Oui. Les relevés scannés sont traités par OCR avec décodage de polices et reconnaissance de mise en page. La précision dépend de la qualité du scan (300 DPI ou plus recommandé). L'étape de réconciliation des soldes rattrape la plupart des erreurs OCR qui affectent les totaux financiers. Pour les scans dégradés, le système signale les valeurs à faible confiance afin que les relecteurs se concentrent sur les champs qui nécessitent leur attention, et non sur l'ensemble du document.
Oui. Holofin fournit une API REST pour la soumission programmatique des documents et la récupération des résultats. Uploadez un PDF, recevez un webhook à la fin de l'extraction, récupérez le JSON structuré. Le traitement par lots est pris en charge : soumettez des centaines de documents en un seul appel API et collectez les résultats au fur et à mesure. L'authentification utilise des clés API avec un périmètre au niveau de l'organisation.
Après extraction, Holofin vérifie l'équation comptable : solde d'ouverture + total des crédits − total des débits = solde de clôture, à une tolérance de 0,01 € près dans la devise du relevé. La continuité du solde courant est également contrôlée : le solde courant de chaque transaction doit égaler le solde précédent plus ou moins le montant de la transaction. L'ordre des dates et la détection des doublons complètent la suite de validations. En cas d'échec d'une vérification, l'extraction est signalée avec des détails d'erreur précis, et non par un échec générique.
Holofin gère automatiquement tous les principaux formats numériques : décimales à virgule européennes (1.234,56), décimales à point anglo-saxonnes (1,234.56), milliers séparés par un espace (1 234.56), négatifs entre parenthèses et indicateurs D/C. La détection du format se fait par document, pas par émetteur. Le système lit le format réellement utilisé dans le relevé et parse en conséquence. Aucune configuration ni paramétrage régional requis.
Oui. Holofin traite toutes les données sur une infrastructure européenne. La rétention des documents est configurable par organisation. Les données sont chiffrées au repos et en transit. Aucun contenu de document n'est utilisé pour l'entraînement des modèles. Holofin peut exécuter les demandes de suppression de données en conformité avec l'article 17 du RGPD (droit à l'effacement). Un Accord de Traitement des Données (DPA) est disponible pour les clients entreprise.
Data You Can
Bank On.
Envoyez-nous les relevés bancaires qui ont mis en échec votre précédent outil. Les PDF multi-comptes de 47 pages. Les scans dégradés. Les formats Sparkasse allemands obscurs. Nous vous montrerons ce qui en ressort.