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
We process 100K+ documents a month for lending teams across Europe. Here's what the infrastructure looks like.
Infrastructure
~40 seconds per statement
Upload to validated JSON. Multi-segment documents process in parallel, so a 12-segment PDF doesn't take 12x longer.
REST API + webhooks
Upload via API, get a webhook when it's done. Batch upload supported.
European infrastructure, GDPR-compliant
99.9% uptime SLA. Configurable retention. Data never leaves the EU.
Banks we cover
French banks
BNP Paribas, Société Générale, Crédit Agricole, Crédit Mutuel, La Banque Postale, Boursorama, CIC, LCL, Caisse d'Épargne
German banks
Deutsche Bank, Commerzbank, Sparkasse, Volksbank, N26, DKB, ING DiBa, HypoVereinsbank
Pan-European & international
ING, HSBC, Revolut, Wise, Barclays, Lloyds, NatWest, UniCredit, Rabobank, ABN AMRO, Santander
UK & US banks
Chase, Bank of America, Wells Fargo, Citi, HSBC UK, Barclays UK, Monzo, Starling
Don't see your bank? It probably works anyway.
We don't use templates. The extraction engine reads layout from the document itself. New issuers work without setup.
FAQ
The questions we get most from lending and accounting teams.
Holofin processes native PDF bank statements from any issuer worldwide, including all major European, UK, and US banks. It handles both digitally-generated and scanned statements. No templates or issuer-specific configuration needed. The system learns layout from the document itself. We actively cover 100+ issuers with validated extraction accuracy, and new issuers typically work without any configuration.
Holofin's segmentation engine detects account boundaries (IBAN, account number, period markers) and splits combined PDFs into individual statement segments before extraction. A 47-page PDF with 3 accounts across 4 quarters becomes 12 individual, independently validated segments. Each segment is extracted and balance-reconciled separately, then aggregated into a unified JSON response.
Field-level accuracy exceeds 97% on native PDF bank statements across tested issuers. But raw accuracy isn't the full story. Every extraction includes automatic balance reconciliation (opening + credits − debits = closing), providing mathematical validation that catches extraction errors a simple accuracy metric would miss. When reconciliation fails, the extraction is flagged for human review rather than silently passed through.
Yes. Scanned bank statements are processed through OCR with font decoding and layout recognition. Accuracy depends on scan quality (300 DPI or higher recommended). The balance reconciliation step catches most OCR errors that affect financial totals. For degraded scans, the system flags low-confidence values so reviewers focus on the fields that need attention, not the entire document.
Yes. Holofin provides a REST API for programmatic document submission and result retrieval. Upload a PDF, receive a webhook when extraction completes, fetch the structured JSON result. Batch processing is supported: submit hundreds of documents in a single API call and collect results as they complete. Authentication uses API keys with organization-level scoping.
After extraction, Holofin verifies the accounting equation: opening balance + total credits − total debits = closing balance, within a tolerance of €0.01 in the statement currency. Running balance continuity is also checked: each transaction's running balance must equal the previous balance plus or minus the transaction amount. Date ordering and duplicate detection round out the validation suite. When any check fails, the extraction is flagged with specific error details rather than a generic failure.
Holofin handles all major number formats automatically: European comma decimals (1.234,56), US/UK period decimals (1,234.56), space-separated thousands (1 234.56), parenthesized negatives, and D/C indicators. Format detection is per-document, not per-issuer. The system reads the actual format used in the statement and parses accordingly. No configuration or locale settings required.
Yes. Holofin processes all data on European infrastructure. Document retention is configurable per organization. Data is encrypted at rest and in transit. No document content is used for model training. Holofin can execute data deletion requests in compliance with GDPR Article 17 (right to erasure). A Data Processing Agreement (DPA) is available for enterprise customers.
Data You Can
Bank On.
Send us the bank statements that broke your last tool. The 47-page multi-account PDFs. The degraded scans. The obscure German Sparkasse format. We'll show you what comes out the other side.