Comprendre les formats de relevés bancaires : Le guide technique

Un relevé bancaire PDF semble simple : dates, descriptions, montants, soldes en colonnes nettes. Mais derrière cette apparence se cache un format de document (PDF) qui n'a jamais été conçu pour stocker des données structurées - et un processus de conversion qui nécessite de comprendre à la fois le format d'entrée et les nombreux formats de sortie disponibles.

Ce guide couvre les 12 sections qui apparaissent sur chaque relevé bancaire (quelle que soit la banque), la réalité technique des relevés bancaires PDF, les variations de mise en page entre les banques, tous les formats de sortie que vous rencontrerez (Excel, CSV, QBO, OFX, QFX, QIF, JSON), les différences de formatage international et les normes de l'industrie qui régissent l'échange de données financières.

Anatomie d'un relevé bancaire

Chaque relevé bancaire - Chase, Bank of America, Wells Fargo, HSBC, Deutsche Bank, peu importe - est construit à partir des 12 mêmes sections. Les étiquettes changent ("Subtractions" vs "Retraits"), les agencements des colonnes varient, mais la structure sous-jacente est cohérente. Une fois que vous pouvez identifier ces sections, chaque relevé semble familier.

Vous souhaitez utiliser cette infographie sur votre blog ? Copiez ce code d'intégration :

Pour des analyses approfondies spécifiques aux banques couvrant exactement comment chaque grande banque présente ces 12 sections, consultez :

• Relevé bancaire Chase expliqué
• Relevé bancaire Bank of America expliqué
• Relevé bancaire Wells Fargo expliqué
• Relevé bancaire Citi expliqué
• Relevé bancaire Capital One expliqué

Pourquoi le PDF n'est pas un format de données

PDF signifie Portable Document Format, standardisé sous la norme ISO 32000 (la version 2.0 est devenue ISO 32000-2:2020). Il a été conçu dans un seul but : faire en sorte que les documents soient identiques sur tous les écrans et imprimantes. C'est excellent pour la fidélité visuelle - et terrible pour l'extraction de données.

Ce qui se trouve réellement à l'intérieur d'un PDF de relevé bancaire

À l'intérieur de chaque page PDF se trouve un flux de contenu - une séquence d'opérateurs de dessin écrite dans un langage de type PostScript. Le texte est rendu à l'aide d'opérateurs spécifiques :

• BT / ET - Begin Text / End Text : limites d'un objet texte
• Tf - Définir la police et la taille
• Td / Tm - Déplacer la position du texte ou définir la matrice de transformation de texte complète
• Tj - Afficher une chaîne de texte
• TJ - Afficher du texte avec positionnement individuel des glyphes (ajustements de crénage)

L'idée cruciale : il n'y a aucun concept de "table", "ligne" ou "colonne" dans la spécification PDF. Ce qui ressemble à un tableau de transactions bien formaté est en fait des dizaines de fragments de texte placés à des coordonnées x,y spécifiques sur la page. L'outil d'extraction doit :

1. Analyser les opérateurs du flux de contenu
2. Résoudre les codages de polices pour mapper les indices de glyphes à des caractères Unicode
3. Utiliser la matrice de texte (Tm/Td) pour déterminer la position x,y de chaque caractère
4. Reconstruire les mots, les lignes et les colonnes à partir de ces coordonnées

Une colonne qui semble parfaitement alignée peut être à x=72.0 sur une ligne et x=72.5 sur la suivante. L'algorithme d'extraction doit définir les limites des colonnes avec une tolérance pour ces variations sub-pixel.

PDF balisés vs non balisés

Les PDF balisés incluent un arbre de structure logique caché (similaire aux balises HTML) qui marque le contenu comme titres, paragraphes, tables, lignes de table et cellules de table. Cela rend l'extraction beaucoup plus facile.

Les PDF non balisés n'ont aucune métadonnée structurelle - l'outil d'extraction ne reçoit que des données de position brutes et doit tout déduire.

La plupart des PDF de relevés générés par les banques ne sont pas balisés. Les banques génèrent des relevés à l'aide de systèmes de traitement par lots (Oracle BI Publisher, SAP Crystal Reports, ou pipelines personnalisés d'impression vers PDF). Les réglementations sur l'accessibilité (ADA/WCAG) poussent les banques vers les PDF balisés, mais l'adoption est lente. Les téléchargements standard de la plupart des grandes banques restent non balisés.

Variations de mise en page des relevés bancaires

Il n'existe pas de norme industrielle pour la façon dont les banques formatent leurs relevés PDF. Les cinq mêmes informations - date, description, débit, crédit, solde - sont arrangées différemment par chaque banque.

Colonne de montant unique (signée)

Date Description Montant Solde
01/15/26 DIRECT DEP PAYROLL +3,500.00 5,200.00
01/16/26 POS PURCHASE GROCERY -87.50 5,112.50

Les débits sont négatifs, les crédits sont positifs (ou vice versa). Courant chez les petites banques, les coopératives de crédit et les banques numériques. Plus simple à analyser car il n'y a qu'une seule colonne de montant à extraire.

Colonnes de débit/crédit séparées

Date Description Retraits Dépôts Solde
01/15/26 DIRECT DEP PAYROLL 3,500.00 5,200.00
01/16/26 POS PURCHASE GROCERY 87.50 5,112.50

Utilisé par Chase, Bank of America et de nombreuses banques traditionnelles. L'outil d'extraction doit identifier quelle colonne contient le montant et déterminer le signe en conséquence.

Groupé par type de transaction

Les comptes professionnels et commerciaux regroupent souvent les transactions :

DÉPÔTS ET AUTRES CRÉDITS 01/15  Virement entrant REF#12345 10,000.00 01/18  Dépôt de chèque #4567 2,500.00 Total Dépôts 12,500.00
 
CHÈQUES PAYÉS 01/16  Chèque #1234 850.00 01/17  Chèque #1235 1,200.00 Total Chèques Payés 2,050.00
 
TRANSACTIONS ÉLECTRONIQUES 01/19  Paiement ACH - Vendor Corp 3,200.00 01/20  Virement en ligne vers Épargne 1,000.00 Total Électronique 4,200.00

Les en-têtes de section déterminent si les transactions sont des débits ou des crédits. Les lignes de résumé ("Total Dépôts") doivent être identifiées et exclues des données de transaction.

Caractéristiques spécifiques à la banque

• Chase - Colonnes de débit/crédit séparées ; regroupe par "DÉPÔTS ET ADDITIONS" et "PAIEMENTS ÉLECTRONIQUES" et "FRAIS" ; descriptions sur plusieurs lignes courantes pour les détails du commerçant
• Bank of America - Colonnes de retrait/dépôt séparées ; inclut une section "Solde journalier" à la fin ; en-tête complet avec numéro de compte, période de relevé, numéro de routage
• Wells Fargo - Colonnes séparées ; inclut une section "RÉSUMÉ DU SOLDE JOURNALIER" ; appelle son téléchargement CSV "Comma Delimited"
• Capital One - Disposition nette avec montant unique pour les cartes de consommation ; informations d'en-tête minimales
• Citi - Inclut souvent des détails de transactions internationales avec les montants en devise d'origine et les taux de conversion sur des lignes séparées

Variations d'agencement des colonnes

Au-delà de la question débit/crédit, l'ordre des colonnes n'est pas standardisé :

• Ordre des colonnes : Date-Description-Montant-Solde vs Date-Montant-Description-Solde
• Numéro de chèque : Présent dans les comptes professionnels, absent dans les comptes personnels
• Numéro de référence : Courant dans les relevés professionnels, rare dans les relevés personnels
• Solde courant : Par transaction (le plus courant) vs sous-totaux journaliers vs absent complètement

PDF numériques vs numérisés

Le facteur le plus important affectant la précision de la conversion est de savoir si votre PDF est numérique ou numérisé.

PDF numériques (natifs)

Créés par programme par le système de votre banque lors du téléchargement d'un relevé. Le texte est stocké sous forme d'opérateurs de flux de contenu avec des codages de polices.

• Précision : 99 %+ pour l'extraction de texte - aucune erreur de reconnaissance
• Vitesse : Millisecondes par page
• Confidentialité : Peut être traité entièrement dans votre navigateur - le fichier ne quitte jamais votre appareil
• Taille du fichier : Généralement 50 Ko - 500 Ko par page
• Comment identifier : Vous pouvez sélectionner et surligner des mots individuels

PDF numérisés

Images de relevés papier - créées en numérisant ou en photographiant un document physique. Le contenu est stocké sous forme d'images rasterisées (JPEG, JPEG2000, CCITT ou compressées Flate).

• Précision : 95–99 % avec OCR professionnel ; 65–70 % avec OCR générique
• Vitesse : Secondes par page (nécessite un traitement d'image)
• Confidentialité : Nécessite généralement un traitement côté serveur (le fichier doit être téléchargé pour l'OCR)
• Taille du fichier : 200 Ko - 2 Mo+ par page
• Comment identifier : Vous ne pouvez sélectionner aucun texte ; zoomer à 400 % montre une pixellisation

Pourquoi la précision de la numérisation est plus importante pour les données financières

Un taux de précision de 97 % des caractères semble excellent jusqu'à ce que vous l'appliquiez aux données financières. Sur un relevé de 1 000 caractères de montants, cela représente 30 caractères mal lus. Un seul chiffre mal lu modifie un montant de transaction : "1 234,56 €" devient "1 234,86 €" ou "7 234,56 €". L'OCR avancé atteint une précision de près de 99 %, mais les erreurs restantes tombent de manière disproportionnée sur des caractères qui se ressemblent : 0/O, 1/l/I, 5/S, 8/B, 6/G, et surtout, virgule/point.

Préférez toujours les téléchargements numériques. Téléchargez les relevés depuis le site Web de votre banque plutôt que de numériser du papier. Cela élimine complètement les erreurs d'OCR.

Formats de sortie : Analyse approfondie

Lorsque vous convertissez un relevé bancaire, vous choisissez un format de sortie. Chaque format a des forces, des limitations et des cas d'utilisation idéaux différents.

Excel (.xlsx)

Norme : Office Open XML (OOXML), standardisé sous ECMA-376 et ISO/IEC 29500.

Qu'est-ce que c'est : Un fichier .xlsx est en fait une archive ZIP contenant des fichiers XML - structure du classeur, données des cellules, styles et chaînes partagées. C'est pourquoi il peut stocker des types de données (dates comme dates, nombres comme nombres), du formatage, des formules et plusieurs feuilles.

Pourquoi il est populaire pour les relevés bancaires :

• Les dates restent des dates (triables, filtrables)
• Les nombres restent des nombres (sommables, formatables)
• Formules pour la réconciliation (SOMME, RECHERCHEV)
• Tableaux croisés dynamiques pour la catégorisation des dépenses
• Mise en forme conditionnelle pour mettre en évidence les écarts
• Partage avec des clients qui ont besoin d'une feuille de calcul lisible

Limitations :

• Maximum 1 048 576 lignes (rarement pertinent pour les relevés bancaires)
• Non importable directement dans la plupart des logiciels comptables (utilisez plutôt QBO/OFX)
• Nécessite Excel, Google Sheets ou LibreOffice Calc pour être ouvert

Idéal pour : Revue manuelle, analyse personnalisée, réconciliation, archivage, rapports clients.

CSV (Comma-Separated Values)

Norme : RFC 4180 (2005) - "Common Format and MIME Type for Comma-Separated Values."

Règles de base :

• Enregistrements délimités par CRLF (retour chariot + saut de ligne)
• Champs séparés par des virgules
• Les champs contenant des virgules, des guillemets ou des sauts de ligne doivent être entourés de guillemets doubles
• Les guillemets doubles à l'intérieur des champs sont échappés en les doublant

Variations de délimiteurs dans la nature :

• Virgule (,) - Standard, utilisé aux États-Unis/Royaume-Uni
• Point-virgule (;) - Utilisé dans les pays où la virgule est le séparateur décimal (France, Allemagne, Italie, Espagne, Brésil)
• Tabulation (\t) - Format TSV, évite les conflits de délimiteurs

Problèmes d'encodage :

• UTF-8 est recommandé pour l'interopérabilité
• BOM UTF-8 (Byte Order Mark) : Non requis par la norme, mais Excel sous Windows l'exige pour afficher correctement les caractères non ASCII (lettres accentuées, symboles de devise). Sans BOM, Excel peut interpréter UTF-8 comme Windows-1252, corrompant les caractères.
• Excel utilise des points-virgules au lieu de virgules comme séparateurs de champs dans les locales européennes

Limitations :

• Pas de types de données - tout est texte (les nombres avec des zéros non significatifs sont corrompus, les longs numéros de compte deviennent de la notation scientifique)
• Pas de support multi-feuilles
• Pas de formatage ni de formules
• Pas de métadonnées (pas d'informations de compte, pas d'identifiants de détection de doublons)

Idéal pour : Compatibilité maximale - presque tous les programmes comptables, bases de données et tableurs peuvent importer du CSV. Solution de repli universelle lorsque QBO/OFX n'est pas disponible.

QBO (QuickBooks Web Connect)

Qu'est-ce que c'est : Le format d'importation pour QuickBooks (Desktop et Online). Les fichiers QBO sont basés sur la spécification OFX avec des extensions spécifiques à QuickBooks.

Clarification importante : ".QBO" ne signifie PAS "QuickBooks Online" - il signifie format QuickBooks Web Connect et fonctionne avec QuickBooks Desktop et QuickBooks Online.

Champs requis par transaction :

• TRNTYPE - Type de transaction (DEBIT, CREDIT, CHECK, DEP, DIRECTDEP, DIRECTDEBIT, ATM, POS, XFER, PAYMENT, FEE, SRVCHG, INT, OTHER)
• DTPOSTED - Date au format YYYYMMDD
• TRNAMT - Montant (négatif pour les débits)
• FITID - Identifiant de transaction de l'institution financière
• NAME - Bénéficiaire/description

Pourquoi FITID est important : QuickBooks suit chaque FITID jamais importé pour chaque compte. Si une transaction avec le même FITID est importée à nouveau, QuickBooks l'ignore silencieusement - empêchant les doublons lorsque les utilisateurs réimportent des périodes de relevé qui se chevauchent. Cette détection automatique de doublons est le plus grand avantage de QBO par rapport au CSV.

Données supplémentaires : QBO transporte également l'ID du compte, l'ID de la banque (numéro de routage), la devise, le numéro de chèque, le mémo et le solde de fin - l'ensemble de données le plus riche de tous les formats d'importation pour QuickBooks.

Idéal pour : Utilisateurs de QuickBooks (Desktop et Online). Offre l'expérience d'importation la plus riche avec détection automatique des doublons et classification des types de transactions.

OFX (Open Financial Exchange)

Historique : Créé par Microsoft, Intuit et CheckFree. Version 1.0 publiée en février 1997.

Évolution de la version :

• OFX 1.0–1.6 (1997–1999) : Syntaxe basée sur SGML (pas de balises de fermeture requises)
• OFX 2.0+ (2000–présent) : Basé sur XML (balises de fermeture correctes, XML bien formé)

De nombreuses banques produisent encore OFX 1.x (SGML) pour une compatibilité maximale.

Gouvernance actuelle : En 2019, le consortium OFX a fusionné avec le consortium Financial Data Exchange (FDX), qui gère désormais la spécification. FDX compte plus de 200 organisations membres et 76 millions de comptes clients.

Pourquoi OFX est la norme universelle : OFX est le même format utilisé lorsque vous connectez votre compte bancaire directement à un logiciel comptable via des flux bancaires - le même format fonctionne pour les importations de fichiers.

Idéal pour les utilisateurs de Xero : Xero importe automatiquement les fichiers OFX sans nécessiter de mappage manuel des colonnes. Téléchargez le fichier et les transactions apparaissent immédiatement avec les bonnes dates, montants et descriptions. Fonctionne également avec Wave, Sage, FreshBooks et la plupart des logiciels comptables.

QFX (Quicken Financial Exchange)

Qu'est-ce que c'est : La variante propriétaire d'OFX d'Intuit, utilisée exclusivement avec Quicken. Un fichier QFX est un fichier OFX standard avec des champs propriétaires supplémentaires.

Champ propriétaire clé : INTU.BID - Identifiant bancaire Quicken. Cet ID numérique est mappé à une banque dans la base de données interne de Quicken. Sans lui, Quicken refuse d'importer le fichier.

Différences par rapport à OFX standard :

• Nécessite INTU.BID dans l'en-tête
• Peut inclure d'autres champs préfixés par INTU.*
• Les institutions financières paient une redevance de licence à Intuit pour fournir le téléchargement QFX
• Quicken n'importera pas les fichiers OFX standard sans le champ INTU.BID

Idéal pour : Utilisateurs du logiciel de finances personnelles Quicken. Format requis - aucune alternative ne fonctionne.

QIF (Quicken Interchange Format)

Qu'est-ce que c'est : Un format texte brut hérité développé à l'origine par Intuit pour Quicken. Paires clé-valeur, une par ligne, avec des balises d'un seul caractère : D pour la date, T pour le montant, P pour le bénéficiaire, L pour la catégorie, M pour le mémo, N pour le numéro de chèque, ^ pour la fin de l'enregistrement.

Pourquoi il a été remplacé : QIF n'a pas de mécanisme de détection de doublons (pas d'équivalent FITID), n'a pas de champs d'identification de compte, pas d'informations de routage bancaire, pas de données de solde, et un formatage de date incohérent entre les implémentations.

Toujours pertinent : Certains logiciels comptables (Xero, Sage, GnuCash) acceptent toujours les importations QIF. Utile pour les migrations de systèmes hérités.

JSON (JavaScript Object Notation)

Statut actuel : JSON n'est pas encore une norme pour les fichiers de relevés bancaires, mais il est de plus en plus utilisé dans :

• API Open Banking (UK Open Banking Standard, PSD2 Berlin Group)
• API FDX (Financial Data Exchange - successeur d'OFX, 200+ organisations membres)
• API Plaid, Yodlee, MX et autres agrégateurs de données
• Flux de travail de développement et d'automatisation

Adoption croissante : Les réglementations Open Banking (PSD2 en Europe, Section 1033 du CFPB aux États-Unis) accélèrent l'adoption des API JSON. L'API FDX utilise JSON/REST avec OAuth 2.0, représentant la direction future de l'échange de données financières.

Idéal pour : Développeurs créant des flux de travail automatisés, des intégrations fintech, des tableaux de bord personnalisés et des intégrations d'API Open Banking.

Comparaison des formats en un coup d'œil

Compatibilité des logiciels comptables

Quel format votre logiciel comptable accepte-t-il ?

Règle générale : Utilisez QBO pour QuickBooks, QFX pour Quicken, OFX pour tout le reste, et CSV comme solution de repli universelle.

Différences de formatage internationales

Si vous travaillez avec des relevés bancaires internationaux, vous rencontrerez des différences de formatage qui déroutent la plupart des outils de conversion.

Formats de date

Le problème de l'ambiguïté : "03/04/2026" est le 3 avril aux États-Unis mais le 4 mars en Europe. Lorsque toutes les dates d'un relevé ont des valeurs de jour inférieures ou égales à 12, il n'y a aucun moyen algorithmique de déterminer le format correct sans connaître le pays d'origine. Les outils de conversion doivent analyser toutes les dates du relevé, à la recherche de valeurs supérieures à 12 pour déterminer le format.

Formats numériques

"10.000,45" d'une banque européenne signifie dix mille et quarante-cinq centimes - pas dix virgule zéro zéro zéro quatre cinq. Se tromper sur ce point entraîne des erreurs d'un facteur 10 000.

Placement du symbole de devise

• États-Unis/Royaume-Uni : Symbole avant le montant : $1,234.56 / £1,234.56
• France, Allemagne, Espagne : Symbole après le montant : 1.234,56 €
• Irlande, Pays-Bas : Symbole avant : €1,234.56
• Japon : Symbole avant : ¥123,456

Encodages de caractères

• UTF-8 - Norme universelle, prend en charge tous les scripts
• GBK/GB2312 - Chinois simplifié (utilisé par les banques chinoises)
• Shift_JIS - Japonais (utilisé par les banques japonaises)
• Big5 - Chinois traditionnel (Taïwan, Hong Kong)
• EUC-KR - Coréen
• ISO 8859-1 - Européen occidental
• Windows-1252 - Européen occidental (hérité)
• Windows-1256 - Arabe

Ouvrir un relevé bancaire chinois ou japonais sur un système américain sans le bon encodage produit des caractères illisibles. PDFSub gère plus de 130 langues avec détection automatique des formats de date, des formats numériques et des encodages de caractères - y compris l'arabe et l'hébreu de droite à gauche, les caractères CJK et tous les jeux de caractères européens.

Éléments courants des relevés bancaires

Date de transaction vs Date de comptabilisation vs Date de valeur

Les relevés bancaires peuvent inclure plusieurs dates pour une seule transaction :

• Date de transaction - Date à laquelle l'achat ou le transfert a réellement eu lieu
• Date de comptabilisation - Date à laquelle la banque l'a traité et enregistré (généralement 1 à 3 jours ouvrables plus tard pour les achats par carte de crédit)
• Date de valeur - Date à laquelle les fonds sont effectivement devenus disponibles (affecte les calculs d'intérêts, courant dans la banque internationale)

La plupart des relevés de consommation n'affichent que la date de comptabilisation. Les relevés professionnels incluent souvent les dates de transaction et de comptabilisation.

Représentation des débits/crédits

Les banques représentent les débits et les crédits différemment :

• Montants signés : -87,50 € pour les débits, +3 500,00 € pour les crédits
• Colonnes séparées : "Retraits" et "Dépôts"
• Abréviations : "DR" pour débit, "CR" pour crédit (courant au Royaume-Uni/Commonwealth)
• Parenthèses : (87,50 €) pour les débits (convention comptable)

Solde courant

• Solde par transaction - Mis à jour après chaque transaction (le plus courant dans les relevés de consommation américains)
• Solde journalier uniquement - Solde affiché à la fin de chaque jour (courant dans les relevés professionnels)
• Pas de solde courant - Seulement les soldes d'ouverture et de clôture (certains relevés internationaux)

Les soldes courants sont utiles pour la validation : vous pouvez vérifier que chaque transaction déplace correctement le solde d'une ligne à la suivante.

Informations d'en-tête standard

La plupart des relevés bancaires incluent : le nom du titulaire du compte, le numéro de compte (souvent partiellement masqué), la période du relevé, les soldes d'ouverture et de clôture, le total des dépôts et des retraits, et le code de routage/code tri/BIC SWIFT de la banque.

Protection par mot de passe

Comment les banques chiffrent les PDF

Les banques utilisent généralement le chiffrement AES-128 ou AES-256. Deux modes de protection existent :

• Mot de passe utilisateur (mot de passe d'ouverture) : Requis pour ouvrir le fichier
• Mot de passe propriétaire (mot de passe d'autorisation) : Le PDF s'ouvre mais la modification/copie peut être restreinte

Motifs de mots de passe courants

D'autres motifs courants incluent les 4 derniers chiffres du numéro de compte, l'identifiant client ou le numéro de membre. Les banques communiquent généralement le motif du mot de passe lorsque vous activez pour la première fois les relevés électroniques.

Défis des relevés multi-pages

Les relevés longs (comptes professionnels avec des centaines de transactions) créent plusieurs défis d'extraction :

Transactions fractionnées

La description d'une transaction peut commencer en bas d'une page et se poursuivre en haut de la suivante. Le convertisseur doit détecter les lignes de continuation et les fusionner en une seule transaction.

En-têtes et pieds de page répétés

La plupart des banques répètent les en-têtes de colonne sur chaque page, ainsi que les numéros de page, les avertissements légaux et le texte marketing. Ceux-ci doivent être identifiés et exclus des données de transaction.

Lignes de continuation

De nombreuses transactions ont des descriptions sur plusieurs lignes :

01/15  DÉBIT ÉLECTRONIQUE ACH VENDOR CORP 3 200,00 €  2 000,00 € REF#123456789 FACTURE 2026-001 VENDOR CORP COMPTABLE FOURNISSEURS

Les lignes 2 et 3 sont des lignes de continuation appartenant à la transaction de la ligne 1. Elles manquent généralement de date et de montant, apparaissant en retrait à la même coordonnée x que la colonne de description.

Report du solde

Certaines banques incluent des lignes "Solde reporté" ou "Solde reporté" en haut des pages de continuation. Celles-ci sont informatives, pas des transactions, et doivent être exclues des données extraites.

Abréviations courantes des relevés bancaires

Les relevés bancaires utilisent des abréviations qui varient selon les institutions :

Normes industrielles à connaître

Ces formats sont utilisés dans la banque d'entreprise et la gestion de trésorerie. Vous les rencontrerez rarement directement, mais leur compréhension explique pourquoi les relevés bancaires fonctionnent comme ils le font.

BAI2 (Bank Administration Institute)

Utilisé pour la gestion automatisée de trésorerie et la réconciliation bancaire dans les systèmes ERP (SAP, Oracle). Un format ASCII à largeur fixe avec des codes de type de transaction (par exemple, 165 = crédit ACH préautorisé, 455 = débit ACH, 495 = virement sortant). Initialement publié en 1987, maintenant maintenu par ASC X9.

SWIFT MT940 / MT942

Relevés bancaires de fin de journée (MT940) et intra-journaliers (MT942) utilisés par les banques du monde entier pour les clients professionnels et les départements de trésorerie. SWIFT traite environ 45 millions de messages par jour. Format basé sur des balises avec des identifiants de champ délimités par des deux-points.

ISO 20022 (camt.053)

Le remplacement moderne basé sur XML du MT940. Fait partie de la norme universelle de messagerie financière ISO 20022. Données plus riches que MT940, pas de limites de longueur de champ, XML analysable par machine avec validation XSD. SWIFT migre des messages MT vers ISO 20022. SEPA (Single Euro Payments Area) impose le format camt pour les paiements européens.

NACHA ACH

Le format de fichier pour les transactions Automated Clearing House aux États-Unis. ASCII à largeur fixe, exactement 94 caractères par ligne. ACH traite environ 30 milliards de transactions par an aux États-Unis. Lorsque votre relevé bancaire indique "ACH CREDIT" ou "ACH DEBIT", la transaction sous-jacente a été transmise au format NACHA entre les banques.

Choisir le bon format pour votre flux de travail

Guide de décision

Utilisez QBO si : Vous utilisez QuickBooks (Desktop ou Online). Vous obtenez la classification du type de transaction, la détection des doublons via FITID et les métadonnées d'importation les plus riches.

Utilisez OFX si : Vous utilisez Xero, Sage, Wave ou un autre logiciel compatible OFX. Xero mappe automatiquement les champs sans configuration manuelle des colonnes.

Utilisez QFX si : Vous utilisez Quicken. C'est le seul format que Quicken accepte.

Utilisez Excel si : Vous avez besoin de consulter, d'analyser ou de manipuler les données avant de les importer. Créez des tableaux croisés dynamiques, exécutez des formules ou préparez des rapports.

Utilisez CSV si : Votre logiciel n'est pas listé ci-dessus, ou si vous avez besoin d'une compatibilité maximale entre les systèmes. Soyez prêt à mapper manuellement les colonnes.

Utilisez JSON si : Vous créez des flux de travail automatisés, des intégrations d'API ou des systèmes de reporting personnalisés.

Conseils de pro

• Utilisez toujours QBO/OFX plutôt que CSV lorsque votre logiciel le prend en charge - la détection des doublons à elle seule évite des heures de nettoyage
• Conservez le PDF original à côté de votre fichier converti - c'est votre piste d'audit et votre document source
• Vérifiez après chaque importation - vérifiez les soldes d'ouverture/clôture et quelques transactions aléatoires
• Faites correspondre le format au logiciel - utiliser le format natif de votre plateforme comptable évite le mappage manuel des colonnes et active les fonctionnalités automatiques

Essayez gratuitement

Prêt à convertir votre premier relevé ? Téléchargez un PDF maintenant - PDFSub convertit en Excel, CSV, QBO, OFX, QFX et JSON. Les relevés numériques sont traités entièrement dans votre navigateur pour une confidentialité maximale. Commencez un essai gratuit de 7 jours avec un accès complet à tous les formats.