Fichiers QBO : INTU.BID, FITID, et pourquoi les imports échouent

Un fichier .qbo, c’est de l’OFX 1.02 avec deux particularités Intuit boulonnées dessus. Ce sont elles qui provoquent les deux plaintes que les gens ont réellement. Tout ce qui suit est lu dans l’exporteur de ce convertisseur, src/export/qbo.ts — pas sur la page marketing d’un autre convertisseur.

QuickBooks étiquette mon import avec la mauvaise banque

À cause d’un seul nombre. Un fichier .qbo porte un élément <INTU.BID>, et QuickBooks le vérifie contre le registre Intuit des banques ayant un accord Web Connect. Un identifiant arbitraire est refusé : chaque convertisseur livre donc un identifiant enregistré par défaut — et le plus courant, 3000, appartient à Wells Fargo. Voilà pourquoi un relevé Chase peut s’importer sous une étiquette Wells Fargo.

Ce convertisseur utilise 3000 pour la même raison que tout le monde, le dit sur la page au lieu de le cacher, et vous laisse le remplacer : le champ Identifiant banque QBO à côté des boutons de téléchargement, ?intuBid= dans l’API, ou --intu-bid en ligne de commande. Pour trouver l’identifiant de votre banque, ouvrez un .qbo que votre banque a elle-même produit et lisez la ligne <INTU.BID> — c’est la source qui fait foi, et la seule vers laquelle nous vous enverrons.

J’ai reconverti le relevé et rien ne s’est importé

C’est <FITID> qui fait son travail. Chaque opération porte un identifiant d’opération d’établissement, et QuickBooks retient — définitivement — ceux qu’il a déjà vus pour un compte. Une opération dont la FITID a déjà été importée est ignorée en silence. C’est exactement ce qui empêche une réimportation de dupliquer votre journal.

L’identifiant doit donc être stable d’un export à l’autre du même relevé, et unique à l’intérieur d’un même relevé. Ici c’est sha1(numéro de compte | date | montant en centimes | 48 premiers caractères du libellé), tronqué à 24 caractères hexadécimaux, avec un compteur -1, -2 ajouté quand un relevé liste réellement deux fois la même opération le même jour.

La conséquence à connaître : l’identifiant dérive de l’opération. Si vous corrigez un montant avant l’export, la FITID de cette ligne change et QuickBooks la traite comme une nouvelle opération. Corrigez d’abord, importez une seule fois.

Les champs dont dépend l’ouverture du fichier

Source : src/export/qbo.ts.

Une carte de crédit n’est pas un compte bancaire

OFX range les relevés de carte dans un autre jeu de messages : <CREDITCARDMSGSRSV1> avec <CCACCTFROM>, et non <BANKMSGSRSV1> avec <BANKACCTFROM>. Exportez un relevé de carte en Compte courant et QuickBooks proposera de l’importer dans un compte bancaire. Choisir Carte de crédit change toute l’enveloppe, pas seulement une étiquette.

DTSTART et DTEND peuvent faire disparaître des lignes en silence

Un importeur a le droit d’ignorer les opérations datées hors de la plage déclarée, et les relevés listent régulièrement une ligne comptabilisée la veille du début de période. Ce convertisseur élargit la plage pour couvrir chaque opération réellement présente dans le fichier — un bug que nous avons trouvé et corrigé, pas une fonctionnalité.

Le fichier paraît malformé à un validateur XML

C’est voulu. OFX 1.02 est du SGML, pas du XML : les éléments feuilles n’ont pas de balise fermante, donc <TRNAMT>-84.97 se termine au saut de ligne. Un validateur qui attend </TRNAMT> lit la mauvaise spécification. L’en-tête au-dessus de <OFX> est de même une suite de lignes clé–valeur.

Les accents ressortent aplatis

L’en-tête déclare ENCODING:USASCII, le corps doit donc être réellement de l’ASCII. Les caractères latins accentués sont translittérés (Zürich → Zurich), le cyrillique est romanisé (Оплата → Oplata) ; ce qui n’a pas d’équivalent ASCII devient ?. Les noms de bénéficiaires sont en outre limités à 32 caractères — la limite OFX pour <NAME> — le libellé complet étant écrit dans <MEMO>, où part le reste d’une description tronquée.

QuickBooks Online accepte aussi le CSV — une autre bête

Le fichier .qbo vise Web Connect de QuickBooks Desktop. L’envoi manuel de QuickBooks Online prend du CSV et n’accepte qu’exactement deux dispositions : trois colonnes (Date, Description, Amount, sorties en négatif) ou quatre (Date, Description, Credit, Debit). Deux choses y surprennent tout le monde :

• Le sens des 4 colonnes est inversé. La consigne d’Intuit elle-même est de mettre les paiements sous Credit et les encaissements sous Debit — la vue du grand livre sur le compte, pas celle de la banque. Les fichiers construits « à l’évidence » s’importent avec tous les signes inversés, et comme l’import réussit, personne ne s’en aperçoit avant le rapprochement.
• Les envois sont plafonnés à 1 000 lignes et 350 Ko. Un relevé plus long doit être découpé, chaque partie avec sa propre ligne d’en-tête.

L’export CSV de ce convertisseur propose un préréglage QuickBooks Online qui produit les deux dispositions dans le sens d’Intuit, retire les colonnes sur lesquelles QuickBooks butterait, et découpe automatiquement les longs relevés en parties importables.

Ce que cette page ne vous dira pas

Quel INTU.BID correspond à votre banque précise. Des listes circulent, elles sont officieuses, et un mauvais identifiant produit exactement la confusion que cette page existe pour expliquer. Lisez-le dans un .qbo émis par votre propre banque.