Le trimestre que personne n’a envie de clôturer

Chaque trimestre, le même email du comptable arrive : envoyez-nous vos pièces.

Chez nous, le plus dur n’est jamais le côté ventes. Nos propres factures sont déjà dans Billit. Le plus dur, ce sont les achats. Des dizaines d’abonnements logiciels, des paiements par carte en dollars, des factures cloud réparties sur plusieurs comptes, des freelances payés par virement. Chaque débit bancaire a besoin de sa facture, et la facture n’est jamais là où on l’attend.

Au début de cette clôture, Billit affichait 159 débits pour le T3, dont 141 sans facture.

Ce trimestre, nous avons confié le travail à trois agents IA qui collaborent dans Buzz, notre messagerie d’équipe : Opus, Claude et Codex. Le film ci-dessus raconte l’histoire. Cet article montre la tuyauterie.

1. Comment nous nous connectons à Billit

Billit propose une API REST sur api.billit.be. Billit autorise les clés API personnelles pour les intégrations qui automatisent votre propre administration, ce qui est exactement notre cas.

Chaque appel porte deux en-têtes :

ApiKey: <votre clé API>
PartyID: <le party id de votre société>

La clé se trouve dans votre profil Billit (Mon profil, section API). Elle n’est jamais stockée dans un fichier : chez nous, elle vit dans le trousseau macOS et elle est lue à l’exécution, donc aucun agent ne l’affiche dans un chat ou un log.

Les listes utilisent des filtres OData et reviennent par pages de 120 :

GET /v1/orders?$filter=OrderDirection eq 'Cost' and OrderType eq 'Invoice'
GET /v1/financialTransactions?$filter=ValueDate ge DateTime'2026-07-01'

Deux pièges de lecture nous ont coûté du temps, les voici :

Les montants bancaires sont toujours positifs. Le sens se trouve dans TransactionType (Debet ou Credit). Une ligne avec un AssignedEntities vide n’a aucune facture liée : c’est ainsi que nous avons compté les 141.
Les e-factures Peppol peuvent afficher un montant à payer de zéro. Les factures de frais bancaires sont marquées comme prépayées par domiciliation, donc PayableAmount vaut 0,00. Le vrai total est TaxInclusiveAmount. Lisez le mauvais champ et toute une catégorie de coûts disparaît.

2. Ce que nous faisons dans Billit

Le premier travail est un seul tableau : chaque débit du T3 sans facture, avec sa date, son montant, sa contrepartie et la communication bancaire complète. Opus l’a construit depuis l’API et l’a découpé en couloirs : la boîte mail (68 lignes) et les portails fournisseurs (27 lignes). Les 46 débits restants n’ont pas de facture par nature (paiements de TVA, virements internes, frais bancaires, micro débits de vérification de carte) et doivent seulement être reconnus comme tels.

Créer les factures d’achat. Une fois un PDF trouvé et vérifié, nous créons la facture d’achat directement via l’API, avec le PDF en pièce jointe :

POST /v1/orders
{
  "OrderType": "Invoice",
  "OrderDirection": "Cost",
  "OrderNumber": "<numéro imprimé sur le PDF>",
  "OrderDate": "...", "ExpiryDate": "...",
  "Currency": "USD",
  "FXRateToForeign": 1.13688,
  "Supplier": { "PartyID": "<party du fournisseur>" },
  "OrderLines": [ ... ],
  "OrderPDF": { "FileName": "...", "MimeType": "application/pdf", "FileContent": "<base64>" }
}

Quelques règles apprises en chemin :

Les montants viennent du PDF, jamais de la ligne bancaire. Une facture d’emailing de 7 € peut être payée via une recharge PayPal de 10 €.
Les factures en dollars portent le vrai taux de change. Nous le prenons dans la communication bancaire elle-même (« x USD à 1,13688 »), pour que la valeur en euros dans les livres corresponde aux euros sortis du compte.
Les tickets TVA comprise sont encodés TVA comprise. Une seule ligne avec le total marqué TVA incluse donne 24,79 + 5,20 = 29,99 exactement, sans ligne de correction d’un centime.
Le code de ventilation est copié de la facture précédente du fournisseur, pour que le comptable retrouve le même classement qu’au trimestre dernier.

Ce trimestre, 69 factures d’achat ont été créées ainsi, avec 0 écart de montant au second contrôle.

Lire la file d’entrée. Billit a aussi une file de documents en attente d’OCR (/v1/toProcess). La liste ne renvoie que des identifiants de fichiers, donc nous téléchargeons chaque fichier (/v1/files/{id}) et le lisons : les PDF en texte, les documents Peppol en XML UBL. C’est ainsi que nous avons découvert que la file répétait les mêmes fichiers (68 entrées, 60 uniques) et qu’une réimportation OCR avait créé une facture en double sans numéro. Nous avons supprimé le doublon après en avoir gardé une sauvegarde.

Ce que l’API ne sait pas faire. Aucun endpoint ne lie une ligne bancaire à une facture. L’API peut lire un lien, pas en créer un. Billit fait son propre rapprochement automatique en quelques heures (31 des 68 factures en euros le lendemain matin), mais il se trompe sur les paiements récurrents de même montant : il peut accrocher la facture de juillet au débit d’août. Chaque lien, automatique ou manuel, est donc relu et vérifié sur la date autant que sur le montant.

3. Ce que nous faisons dans la boîte mail

Le travail dans la boîte mail part de la liste, pas de la boîte de réception. Avant que quiconque n’ouvre Gmail, nous avions les 68 lignes bancaires marquées pour la boîte mail. Nous avons cherché ces 68, et rien d’autre.

Chercher via l’API, jamais via l’écran. Nous interrogeons Gmail par son API, une recherche par ligne bancaire : l’adresse d’envoi du fournisseur, une fenêtre de dates autour du débit et un filtre sur les pièces jointes. Nous tenons une carte d’une trentaine de fournisseurs récurrents, qui indique ceux qui envoient un PDF (Anthropic, Google Workspace et Cloud, Cloudflare, GitHub, HeyGen, Calendly, GTranslate, Infomaniak et tout ce qui est facturé via Stripe) et ceux qui n’en envoient jamais (OpenAI, Notion, Google Ads, ElevenLabs, CapCut, AWS). Les lignes du second groupe partent directement dans le couloir navigateur.

Certaines factures ne sont pas des pièces jointes. Infomaniak met un lien direct vers le PDF dans le corps de l’email, et certains reçus Stripe renvoient seulement vers une page hébergée. Nous suivons le lien et enregistrons le PDF. Quand un email affiche le montant mais aucune facture, nous imprimons l’email en PDF et le marquons comme reçu, pour que le comptable sache que ce n’est pas une vraie facture. Dix documents ont reçu cette mention.

Chaque PDF est comparé à sa ligne bancaire. Nous lisons le montant dans le PDF et le comparons au débit, au centime près. Pour les paiements par carte en devise étrangère, nous comparons avec le montant original en USD écrit dans la communication bancaire, pas avec le montant converti en euros. Les paiements aux freelances passent par Wise, donc nous associons chaque virement à la facture du freelance avec le même total en USD.

Le résultat, sept minutes plus tard : 48 sur 68 trouvées et vérifiées, 7 sans facture par mail (un leasing, un portail de sécurité sociale, des paiements PayPal) et 13 sans aucun email de facturation, transmises au couloir portails. Chaque fichier est enregistré sous date_fournisseur_montant.pdf et sa ligne est mise à jour dans le tableau partagé. Rien ne part vers Billit depuis la boîte mail : les fichiers vont à l’agent qui crée les factures via l’API.

4. Des portails fournisseurs à la bonne ligne bancaire

Tous les fournisseurs n’envoient pas une facture exploitable par email. Pour les trous restants, notre agent navigateur a travaillé dans notre propre session de navigateur connectée et a téléchargé les documents depuis Google Ads, AWS, Orange Business, Doccle pour la sécurité sociale, Trustindex, Higgsfield et le bon espace Notion. Chaque PDF a été vérifié sur les coordonnées de la société, la période facturée, la devise d’origine et le débit bancaire correspondant. Le processus a aussi fait ressortir des exceptions : CapCut n’affichait aucun historique de factures, AWS demandait une double authentification, et l’abonnement Notion payant appartenait à un second espace portant le même nom.

Comme l’API ne peut pas créer de lien bancaire, l’association s’est faite dans l’écran Banque de Billit. Un tableau préparé reliait chaque facture à sa ligne bancaire exacte : le travail consistait à sélectionner et vérifier, pas à chercher et ressaisir.

Nous avons commencé par trois paiements simples en euros. Après chaque lien, un second agent relisait le résultat via l’API. Pour les factures en dollars, Billit peut plafonner l’allocation à la valeur en euros du débit et laisser un petit solde ouvert (0,64 USD en moins dans un cas). Nous avons détaché l’allocation plafonnée, relié le montant complet en dollars au taux bancaire exact, rétabli le taux d’origine de la facture, puis vérifié à nouveau.

5. Comment les emails et les PDF arrivent dans la comptabilité

Il y a trois portes d’entrée dans Billit, et nous utilisons chacune pour une raison.

Les e-factures Peppol arrivent toutes seules. Les fournisseurs présents sur le réseau Peppol (frais bancaires, le comptable, plusieurs fournisseurs belges) arrivent directement dans Billit. Nous les lisons seulement, pour éviter de les créer deux fois.
La boîte d’entrée dédiée de Billit. Chaque compte Billit a sa propre adresse email. Tout PDF transféré à cette adresse entre dans la file OCR, où il attend d’être revu. C’est notre route de tous les jours : les factures reçues par email pendant le trimestre y sont transférées par lots. C’est simple, mais le résultat de l’OCR demande encore une vérification humaine, et un document transféré deux fois devient deux documents.
La création directe via l’API. Pour un rattrapage comme celui-ci, nous sautons la file. L’agent connaît déjà le fournisseur, le numéro, la date, la devise, le taux et le montant grâce au PDF qu’il vient de vérifier, donc il crée la facture finale avec le PDF joint. Pas de devinette OCR, pas d’étape de revue, et l’agent vérifie d’abord qu’aucune facture n’existe déjà avec le même numéro.

La règle que nous suivons : un document, une porte. Avant de créer quoi que ce soit, l’agent vérifie la boîte Peppol, la file OCR et les factures existantes pour le même fournisseur et le même numéro. C’est grâce à cette règle que nous avons trouvé des doublons au lieu d’en créer.

6. Aucun agent ne fait confiance au travail d’un autre

Ce qui a rendu tout cela sûr, ce n’est pas la vitesse. C’est le contrôle croisé.

Claude a trouvé les PDF dans la boîte mail. Opus a créé les 69 factures. Ensuite, Claude a rouvert chaque facture créée et l’a comparée à son PDF : fournisseur, devise, montant. Résultat : aucun fournisseur, aucune devise, aucun montant erroné.
Codex a fait les associations bancaires dans le navigateur. Après chaque lot, Opus relisait les liens via l’API. Sur un lot, la réponse a été « 7 sur 8 sont corrects, 1 ne l’est pas » : la facture en dollars allouée avec 0,64 USD en moins. Codex l’a corrigée, et elle a été revérifiée.
Chaque tâche est réservée dans le fil avant que quiconque ne commence, donc deux agents ne créent jamais la même facture.
Rien n’est sorti sans validation. L’email au comptable a été préparé en brouillon. Un humain a appuyé sur Envoyer.

À la fin de la clôture, chaque débit du T3 était soit lié à sa facture, soit sans facture par nature (paiements de TVA, virements internes, frais bancaires), et le comptable a reçu un seul email avec tout dedans.

Ce que ça change

Le trimestre dernier, clôturer les comptes m’a pris environ dix heures à fouiller les boîtes mail et les portails. Ce trimestre, mon propre temps a été d’environ une heure : le message de lancement, quelques réponses, un « go » et le bouton Envoyer. Le trimestre prochain, avec les requêtes, la carte des fournisseurs et les contrôles déjà en place, nous visons vingt minutes.

Les agents n’ont pas remplacé le comptable, et ils n’ont pas remplacé le jugement. Ils ont remplacé les recherches, la ressaisie et le doute, et ils ont rendu chaque étape vérifiable.

Si votre comptabilité tourne sur Billit, ou sur tout outil doté d’une API correcte, ce type de clôture est possible dès aujourd’hui. Parlons-en pour automatiser votre propre administration.