Pourquoi mon fichier OFX est refusé par Sage, EBP ou Isacompta (2026)
Un OFX refusé par Sage 50, EBP ou Isacompta est presque toujours un problème de version ou d'encodage : ces logiciels attendent un OFX 1.02 en SGML, encodé Windows-1252, avec fins de ligne CRLF et sans BOM, alors que beaucoup de convertisseurs produisent de l'OFX 2.0 en XML UTF-8. Viennent ensuite les erreurs de contenu : « & » non échappé dans un libellé, NAME de plus de 32 caractères, bloc LEDGERBAL absent, FITID en double ou BANKID vide. Isacompta refuse l'OFX 2.0 XML de façon systématique ; Sage 50 rejette les fichiers UTF-16 ou avec BOM.
OFX 1.02 SGML et OFX 2.0 XML : deux fichiers différents
| OFX 1.02 (SGML) | OFX 2.x (XML) | |
|---|---|---|
| En-tête | 9 lignes CLÉ:VALEUR (OFXHEADER:100, DATA:OFXSGML, VERSION:102, SECURITY:NONE, ENCODING:USASCII, CHARSET:1252, COMPRESSION:NONE, OLDFILEUID:NONE, NEWFILEUID:NONE), puis une ligne vide, puis <OFX> | Déclaration <?xml version="1.0"?> et <?OFX OFXHEADER="200" VERSION="2xx" ...?> |
| Tags feuilles | Non fermés : <TRNAMT>-45.20 | Fermés : <TRNAMT>-45.20</TRNAMT> |
| Encodage usuel | Windows-1252 | UTF-8 |
| Accepté par Isacompta | Oui | Non |
| Accepté par Sage 50, EBP | Oui | Variable selon version |
Les logiciels français ont été conçus autour de la version 1.02 ; c'est celle qu'il faut viser.
Les causes de refus, une par une
Version et syntaxe
- OFX 2.0 XML envoyé à Isacompta : refus immédiat. Il faut regénérer en 1.02 SGML.
- En-tête incomplet : les 9 lignes doivent être présentes, suivies d'une ligne vide avant
<OFX>. Un en-tête tronqué ou collé au corps fait échouer la lecture. - Tags feuilles fermés dans un fichier déclaré SGML : certains parseurs tolèrent, d'autres non. En SGML 1.02, ne pas fermer
<DTPOSTED>,<TRNAMT>,<FITID>,<NAME>,<MEMO>; fermer uniquement les blocs (<STMTTRN>…</STMTTRN>).
Encodage et fins de ligne
- UTF-8 avec BOM ou UTF-16 : Sage 50 rejette le fichier. Les trois octets EF BB BF en tête ou les octets nuls de l'UTF-16 empêchent de reconnaître la ligne
OFXHEADER:100. - UTF-8 sans BOM avec accents : le fichier passe mais les libellés arrivent avec des caractères corrompus (« é » au lieu de « é ») si le logiciel lit en 1252.
- Fins de ligne LF seules : certaines versions de Sage et EBP attendent CRLF (octets 0D 0A). Convertir avant import.
Contenu des transactions
- Esperluette « & » non échappée dans NAME ou MEMO (« M&M'S », « P&O ») : erreur d'analyse. Remplacer par
&; même traitement pour « < » (<). - NAME de plus de 32 caractères : tronqué ou refusé selon le logiciel. Garder le libellé court dans NAME et le libellé complet dans MEMO (255 caractères maximum).
- DTPOSTED hors format
YYYYMMDD(par exemple12/03/2026) : date non reconnue, transaction rejetée ou datée au 1er janvier. - TRNAMT avec virgule décimale (
-45,20) ou espace de milliers (1 250.00) : montant lu à zéro ou fichier refusé. Utiliser le point et aucun séparateur de milliers ; débits négatifs. - FITID absent, vide ou dupliqué : les logiciels dédoublonnent sur ce champ ; deux opérations avec le même FITID n'en font qu'une. Un FITID unique de 32 caractères au plus, construit par hachage de la date, du montant et du libellé, évite le problème. QuickBooks, pour mémoire, garde en mémoire les FITID même après suppression des transactions.
Blocs structurels
- LEDGERBAL manquant : le bloc
<LEDGERBAL><BALAMT>…<DTASOF>…</LEDGERBAL>est obligatoire ; sans lui, le logiciel ne peut pas contrôler le solde et refuse ou importe sans solde. - BANKACCTFROM incomplet : BANKID = code banque sur 5 chiffres, BRANCHID = code guichet, ACCTID = numéro de compte sur 11 caractères, ACCTTYPE = CHECKING. Un BANKID vide ou un ACCTID avec espaces empêche le rapprochement avec le compte paramétré dans le logiciel.
- Plusieurs comptes dans un fichier : un compte par fichier pour les logiciels français.
Tableau cause, symptôme, correction
| Cause | Symptôme observé | Correction |
|---|---|---|
| OFX 2.0 XML | Isacompta : « format non reconnu » ; Sage/EBP : import vide | Regénérer en OFX 1.02 SGML |
| BOM UTF-8 ou UTF-16 | Sage 50 : fichier non reconnu dès la première ligne | Enregistrer en Windows-1252 sans BOM |
| UTF-8 sans BOM | Libellés avec « é », « è » | Convertir en Windows-1252 |
| LF au lieu de CRLF | Lecture partielle, première transaction seule | Convertir les fins de ligne en CRLF |
| « & » non échappé | Arrêt de l'import sur une transaction précise | Remplacer par & |
| NAME > 32 caractères | Libellé tronqué ou ligne refusée | Limiter NAME à 32, mettre le reste dans MEMO |
| DTPOSTED mal formé | Dates au 01/01 ou transaction absente | Format YYYYMMDD |
| TRNAMT avec virgule | Montants à 0,00 | Point décimal, sans séparateur de milliers |
| FITID dupliqués | Transactions manquantes après import | FITID unique par ligne |
| LEDGERBAL absent | Solde non calculé, import refusé selon logiciel | Ajouter le bloc avec BALAMT et DTASOF |
| BANKID ou ACCTID vide | « Compte introuvable » | Renseigner code banque, guichet, numéro de compte |
Vérifier un OFX avant import
- Ouvrir le fichier dans un éditeur de texte brut (pas Word) et contrôler que la première ligne est exactement
OFXHEADER:100. - Vérifier l'encodage affiché par l'éditeur : Windows-1252 (parfois nommé ANSI), pas UTF-8.
- Rechercher
&: chaque occurrence doit être&. - Rechercher
<LEDGERBAL>et vérifier que BALAMT correspond au solde final imprimé sur le relevé. - Compter les
<STMTTRN>et comparer au nombre d'opérations du relevé.
Si le fichier vient d'un relevé PDF, l'outil de conversion Relevé bancaire PDF → Excel, OFX génère l'OFX 1.02 SGML dans ces conventions (1252, CRLF, sans BOM, FITID uniques, LEDGERBAL renseigné) et compare le solde calculé au solde imprimé avant export.
FAQ
Comment savoir si mon OFX est en 1.02 ou en 2.0 ? Ouvrez-le dans un éditeur de texte. S'il commence par OFXHEADER:100 suivi de VERSION:102, c'est du 1.02 SGML. S'il commence par <?xml, c'est de l'OFX 2.x XML.
Puis-je convertir un OFX 2.0 en 1.02 à la main ? Oui pour un petit fichier : remplacer l'en-tête XML par les 9 lignes SGML, retirer les balises fermantes des tags feuilles, enregistrer en Windows-1252 avec CRLF. Au-delà de quelques dizaines de lignes, regénérer le fichier est plus sûr.
Pourquoi Isacompta refuse-t-il l'OFX 2.0 alors que d'autres l'acceptent ? Son analyseur est écrit pour la syntaxe SGML de la version 1.02 ; la déclaration XML n'est pas reconnue. C'est une contrainte documentée par l'éditeur.
Le BANKID doit-il être le code banque ou le BIC ? Le code banque à 5 chiffres tel qu'il figure sur le RIB, pas le BIC.
Que se passe-t-il si deux transactions ont le même FITID ? Le logiciel considère qu'il s'agit de la même opération et n'en importe qu'une. Les doublons légitimes (deux achats identiques le même jour) doivent avoir des FITID distincts.