Cette page s'adresse au comptable ou à l'expert-comptable qui contrôle les écritures d'un client utilisant Dirigia. Elle décrit le cycle de vie d'une transaction bancaire, les règles de rapprochement automatique, et l'audit trail disponible pour vos contrôles.
1. Source des données
Les transactions bancaires sont importées via Ponto Connect (filiale d'Ibanity NV/SA, prestataire AISP agréé par la BNB sous PSD2). Dirigia n'a jamais accès aux identifiants bancaires du client : le consentement est donné directement à la banque via Itsme, Digipass ou Card reader.
- Consentement : valable 90 jours glissants (DSP2 RTS art. 10). Au-delà, le client doit re-consenter pour que la synchronisation continue. Aucun refresh ne prolonge cette durée.
- Fréquence : synchronisation automatique déclenchée par webhook Ponto à chaque mouvement détecté côté banque, plus un cron de secours toutes les 6 heures.
- Comptes: seuls les comptes que le client a explicitement activés (case « Inclure » dans la modale de qualification post-OAuth) sont synchronisés. Les comptes décochés restent visibles mais sans flux entrant.
2. Champs disponibles par transaction
Pour chaque ligne bancaire, Dirigia stocke (cf. table bank_transactions) :
- booking_date : date d'enregistrement bancaire (clé de tri primaire)
- value_date : date de valeur SEPA (si exposée par la banque)
- execution_date : date d'ordre du donneur d'ordre
- amount : montant signé (+ crédit, − débit), en numeric(14,2)
- counterpart_name / counterpart_reference : contrepartie + IBAN si disponible
- remittance_information : libellé libre du donneur d'ordre
- structured_communication : OGM/VCS belge canonisé (12 digits, sans
+++ ni /) — clé principale de matching - internal_reference / bank_transaction_code : référence interne et code SEPA
3. Rapprochement automatique (5 règles en cascade)
À chaque synchronisation, Dirigia tente de lier chaque nouvelle transaction à une facture ou une dépense via une cascade de règles ordonnées du plus fiable au moins fiable :
- OGM exact — confidence 100. Match strict sur la communication structurée VCS belge. Auto-applique le statut
auto_matchedet marque la facture comme payée à la date de la transaction. - IBAN + montant — confidence 90. Match sur le couple (IBAN contrepartie, montant exact) si une seule facture ouverte correspond. Auto-matched.
- Montant unique dans fenêtre — confidence 70. Une seule facture/dépense ouverte avec ce montant dans une fenêtre de ±5 jours. Suggéré, jamais auto-matched sans confirmation utilisateur.
- Nom contrepartie + montant approximatif— confidence 50-65. Fuzzy match sur le nom et tolérance ±1% sur le montant. Suggéré.
- Match manuel— confidence custom. Le user associe explicitement la transaction à une facture/dépense via l'UI.
Une transaction matchée pointe vers EXACTEMENT UN des trois types de documents (FK polymorphe en table transaction_matches) : invoice_id (facture émise), peppol_received_invoice_id (facture fournisseur Peppol) ou expense_id (dépense déjà saisie).
4. Auto-création de dépenses depuis débits
Quand un débit bancaire n'est pas matché par les 5 règles ci-dessus mais correspond à une règle de catégorisation configurée par le client (table expense_category_rules), Dirigia peut créer une dépense en arrière-plan avec le statut « à valider ».
- Seules les règles avec
source='company_rule' (créées explicitement par le client, pas les seeds globaux) et confidence ≥ 80% déclenchent l'auto-création. - La dépense créée est flaggée
status='auto_matched' avec un signal auto_created_expense=truedans la table de matching. Visible dans l'onglet « À valider » jusqu'à validation par le client. - La TVA est laissée à 0 par défaut (la dépense doit être validée + complétée par le client avant inscription dans la déclaration TVA).
5. Statuts d'une transaction
- Matchée auto (auto_matched) — règle 1 ou 2 ; transaction et document liés irréversiblement, sauf rejet manuel par le user.
- Suggérée (suggested) — règle 3, 4 ou 5 non confirmée ; rapprochement proposé en attente de validation utilisateur.
- Rejetée (rejected) — le user a refusé explicitement la suggestion. La même cascade ne sera plus appliquée à cette transaction (respecte la décision humaine).
- Non matchée— aucune règle n'a déclenché, aucun match manuel. La transaction reste dans le journal mais n'est pas liée à un document.
6. Impact comptable
Dirigia ne génère PAS automatiquement d'écritures comptables PCMN à partir des transactions bancaires. Les écritures (compte 550/580 banque, 700 ventes, 600 achats, etc.) sont dérivées des factures et dépenses, pas des lignes bancaires.
- Une transaction matchée à une facture déclenche le passage de la facture au statut « payée » avec date de paiement = booking_date.
- Le rapprochement bancaire pour le compte 550 (banque) se fait via le module Comptabilité > Rapprochement bancaire (et non via cette table directement).
- Les transactions non matchées N'ENTRENT PAS dans les déclarations TVA tant qu'une facture ou dépense n'est pas liée. La piste d'audit reste néanmoins traçable.
7. Audit trail (RGPD + ITAA)
Toutes les opérations bancaires utilisateur sont tracées dans la table audit_log (append-only, 10 ans de rétention, cf. notre politique de confidentialité). Actions enregistrées :
banking.connect.initiated / .completed / .failedbanking.disconnect et banking.wipe (effacement RGPD)banking.sync.succeeded / .failedbanking.refresh.requested (rafraîchissement attended PSD2)banking.account.qualified / .reauthorized / .details_updatedbanking.reauth.notified (notification J-30 / J-7 / J-1)banking.export (export RGPD demandé par le user)
8. Export pour contrôle ou archivage
Le client peut à tout moment télécharger l'intégralité de ses données bancaires (transactions + rapprochements + audit_log) au format machine-readable :
- JSON complet — toutes les sections, pour archivage ou ré-import.
- CSV (Excel FR)— transactions enrichies avec colonnes en français, séparateur « ; » (locale BE).
- CSV (technique EN) — pour intégration dans un autre logiciel comptable.
Voir la section Vos droits RGPDde la page d'aide bancaire pour les liens directs.
9. Limitations et bonnes pratiques
- Une transaction inversée (refund) crée DEUX lignes (un débit + un crédit). Dirigia ne fusionne pas automatiquement les deux ; le rapprochement avec une facture d'avoir doit être fait manuellement si nécessaire.
- Les comptes multi-devises (USD, GBP…) sont synchronisés mais l'agrégat du solde affiché est calculé EUR-only (pas de conversion FX). Les comptes non-EUR restent visibles séparément.
- Les transactions strictement antérieures au consentement PSD2 ne sont pas disponibles via Ponto. Pour un historique plus ancien, l'import manuel via CSV ou la saisie classique de factures/dépenses reste la voie.
- Les transactions affichées dans le module Banque sont le reflet exact des données fournies par la banque. Si une discordance apparaît avec un relevé papier, signalez-la d'abord à la banque puis à support@dirigia.app.
