Connecter votre Plateforme Agréée

Facturino suit le modèle BYOPA (Bring Your Own PA) : vous gardez la main sur votre compte PA et Facturino s'y connecte en votre nom via les identifiants que vous fournissez. Aucun dépôt n'est transmis sans votre accord explicite via cette connexion.

Choisir votre PA

Comment ça marche

1. Créez un compte chez la PA de votre choix en suivant son processus standard. Les guides ci-dessus détaillent l'inscription et la génération des identifiants techniques pour chaque PA supportée.
2. Renseignez les identifiants dans Facturino depuis l'interface Paramètres → Facturation électronique. Les identifiants sont chiffrés au repos avec AES-256-GCM et utilisés exclusivement pour router vos factures.
3. Testez la connexion en un clic depuis le même écran. Facturino interroge la PA pour valider les identifiants et confirmer la santé de la liaison.
4. Émettez vos factures normalement. Une fois la facture finalisée, l'envoi à la PA est déclenché par POST /v1/invoices/:id/send et le cycle de vie DGFiP (déposée → transmise → reçue → approuvée…) est relevé auprès de la PA une minute après l'envoi, puis toutes les quinze minutes ; un rejet porte le code et le motif de la plateforme.

Avant le dépôt, le CII passe le validateur EN 16931 et les règles CIUS-FR locales. Un validateur absent, altéré ou inexécutable bloque le dépôt. La version, l’empreinte du validateur et celle du CII sont enregistrées à côté de l’artefact. La validation UBL couvre EN 16931 ; elle ne constitue pas une attestation CIUS-FR pour UBL.

Obligations couvertes par plateforme

État du connecteur au 13/09/2026. « Implémenté » désigne du code vérifié localement sur les contrats archivés, à qualifier en bac à sable ; « non couvert » interdit de considérer l’obligation comme transmise. Aucune ligne de ce train ne vaut preuve de réception distante. Les statuts 200 et 213 sont lus ; 210 et 212 exigent aussi une émission.

• Super PDP : Flux 10 réel du 11/09, retours acheteur, encaissement négatif et nouvelle version à vérifier sur la plateforme. support/docs/SUIVI.md — relevé du 07/09 : dépôts disponibles, quatre fr:212 relus ; rejets réels du 07/09 repris dans les fixtures. Preuve historique, avant ce train.
• Iopole : Date d’encaissement = date de saisie du statut chez Iopole (émission) ; les montants par taux sont transmis. Routes natives transactions et encaissements intégrées (Operator Reporting 1.0.0) ; rapprochement après réponse perdue et résultat final restent à qualifier. Contrat Operator Invoicing 1.0.0 archivé le 09/09/2026 ; fixtures lifecycleContracts.test.ts. À qualifier en bac à sable.
• B2Brouter : Paiements partiels transmis avec montant et date réelle ; ventilation par taux laissée à B2Brouter. Déclaration 212 conditionnée à l’autorité DGFiP active du compte. Import F10 et suivi intégrés ; activation exclusive du mode fichier sur le compte requise avant émission, sans cohabitation avec une agrégation native. Contrat Payments 2026-04-20 archivé le 09/09/2026 ; fixtures lifecycleContracts.test.ts. À qualifier en bac à sable.
• Seqino : Date d’encaissement = date de saisie du statut chez Seqino (émission) ; les montants par taux sont transmis. Le paiement acheteur 211 accepte un seul taux par émission partielle. Contrat OpenAPI 0.30.3 archivé le 09/09/2026 ; fixtures lifecycleContracts.test.ts. À qualifier en bac à sable.
• AFNOR standard : L’implémentation de la plateforme choisie doit être qualifiée ; aucune compatibilité universelle constatée par un test local. connectors/afnor-standard.ts ; tests afnor-standard, cdar et frr.
• Simulateur : Bac à sable seulement ; la simulation ne vaut pas preuve de conformité distante. __tests__/api/platformJourney.test.ts — scénario local simulé, aucune plateforme réelle.

Iopole : la réception utilise GET /v1.1/invoice/search et sa pagination distante (contrat invoicing 1.0.0 archivé le 09/09/2026). Le contrat limite offset à 1 000 et limit à 200. Facturino lit 100 factures par page : au-delà de 1 100 résultats, le suivi signale la limite sans considérer l’arriéré épuisé. Aucun curseur stable ni ordre de recherche n’est garanti par ce contrat ; un export ou un mécanisme de parcours exhaustif reste à qualifier avec Iopole.

Chez Iopole et Seqino, la date d’encaissement est la date de saisie du statut (émission à la plateforme) ; la date réelle reste conservée dans le registre des paiements. B2Brouter reçoit le montant du paiement, même partiel, et sa date réelle puis assure la ventilation par taux, sous réserve de l’activation DGFiP du compte. Ces limites sont consignées dans l’historique. Les routes d’e-reporting disponibles sont intégrées ; leurs limites de qualification et d’activation sont précisées dans le tableau ci-dessous.

L’enregistrement d’un paiement, d’une approbation ou d’un refus écrit une obligation durable qui déclenche une tâche immédiate par établissement. Les reprises utilisent la même file ; le passage quotidien reste le filet de sécurité. Une tâche déjà créée n’est pas doublée au rejeu.

Après le dépôt : lire un rejet

La consultation utilise 0009:<SIRET> pour un SIRET à 14 chiffres, sinon 0225:<SIREN>. Le connecteur retient l’adresse active renvoyée par l’annuaire. Le routage ne change ni BT-46 ni BT-47 ; seul BT-49 du CII soumis reçoit cette adresse.

Un refus HTTP 4xx définitif du statut d’encaissement écrit fr212.state: blocked, lastErrorCode: pa_lifecycle_rejected et le motif brut dans lastErrorReason. Le vendeur reçoit une notification. Les délais dépassés, erreurs de transport et réponses 5xx restent reconciliation_required.

Un refus explicitement transitoire laisse l’encaissement dû en fr212.state: pending, avec lastErrorCode: pa_lifecycle_not_ready et le motif brut conservé, sans notification d’échec. Une nouvelle tentative est prévue après 5 minutes, puis 20 minutes, 80 minutes et au plus toutes les 6 heures ; une progression de la transmission peut la déclencher plus tôt. Un encaissement déjà accepté n’est pas réémis ; une réponse ambiguë reste à rapprocher.

Le code structuré de la plateforme est lu en priorité. Seqino 0.30.3 documente précisément un HTTP 409 sur mark_as_cashed lorsque la facture n’est pas encore encaissable. Pour Super PDP, la formulation « La facture liée est en cours de traitement. Réessayer plus tard » est reconnue en repli ; aucun code numérique correspondant n’est publié dans son contrat. Les contrats Iopole invoicing 1.0.0 et B2Brouter 2026-04-20 ne donnent pas de code spécifique à cette attente : un HTTP 400 ou 409 seul n’y prouve pas un refus transitoire. Les codes de montant, schéma ou autorisation reconnus restent définitifs.

Un HTTP 429 laisse également l’obligation en attente, conformément à son catalogue d’erreurs : la reprise respecte le délai prévu, même si la facture progresse entre-temps. Un code connu d’autorisation, de paramètres invalides ou de doublon reste prioritaire sur une phrase invitant à réessayer.

Les anciens items bloqués sous pa_lifecycle_rejected dont le motif indique explicitement cette attente sont repris par le travailleur. Il relit d’abord le reçu distant : présent, l’obligation est marquée envoyée ; absent, elle est remise en file ; indéterminé, elle reste à rapprocher et conserve le dernier motif reçu, y compris sur le suivi du paiement. Ce rattrapage actualise ce suivi, sans modifier les montants, les dates d’encaissement ni le document émis.

Les cinq connecteurs lisent les champs de motif usuels, dont errorCode et errorMessage de l’API AFNOR utilisée par Super PDP. Les détails joints sont conservés ; un corps de forme inconnue est conservé en JSON compact, ou tel quel s’il n’est pas JSON. Un corps non reçu ne peut pas être reconstitué. Ces contenus ne sont pas inscrits dans les journaux techniques.

Les rejets buyer_not_in_directory sont revérifiés chaque jour à 04:00 (Europe/Paris), pour les établissements live dont la PA est connectée et le dépôt autorisé : une consultation par SIREN, dans la limite de 200 par établissement et par jour. einvoicing.directoryCheckedAt date le contrôle ; einvoicing.buyerReachableAt indique une adresse active retrouvée. Une notification quotidienne réglable (application et e-mail) signale les adresses retrouvées. Facturino redépose automatiquement les documents éligibles, après exclusion d’un refus de l’acheteur et de toute réception déjà connue ou incertaine ; les deux dates sont effacées à l’ouverture de la nouvelle tentative. Les avoirs partagent le plafond de 200 SIREN avec les factures.

Le signal « Paiement transmis par le destinataire (fr:211) » ajoute seulement une mention à l’historique : il ne change ni les axes ni le statut résumé et ne produit aucun événement webhook.

Le statut « Encaissée » attend en awaiting_deposit si la tentative courante est rejetée ou sans identifiant ; seul un dépôt accepté ou déposé le remet en file, et un refus définitif de la plateforme le bloque avec son motif conservé.

Si l’annuaire renvoie une adresse active différente, Facturino régénère le CII avec cette adresse de réception, sans changer les identifiants légaux ni l’original archivé ; einvoicing.routingIdentifier indique l’adresse utilisée pour le dépôt, sous la même clé d’idempotence.

Pour le vendeur, einvoicing.senderRoutingIdentifier expose en lecture seule l’adresse électronique résolue dans l’annuaire pour BT-34. Lorsque le CII doit être régénéré avec cette adresse, einvoicing.submissionArtefact.sellerRoutingIdentifier conserve la valeur employée dans cet artefact. Ces champs sont absents lorsqu’aucune adresse vendeur spécifique n’a été résolue ; les identifiants légaux et l’original archivé restent conservés.

Avant tout dépôt, Facturino consulte l'annuaire de la facturation électronique. Un acheteur absent est rejeté localement, sans appel de plateforme, avec la catégorie buyer_not_in_directory : aucune adresse active n’a été trouvée pour cet acheteur. Facturino surveille l’annuaire et reprend automatiquement le dépôt lorsque l’adresse revient, après vérification de l’éligibilité. Le résultat de l’annuaire ne valide pas le contenu de la facture. Un annuaire injoignable ne bloque jamais : le dépôt est tenté et la plateforme décide.

Tout rejet ou refus est lu une fois par le serveur en une catégorie stable (einvoicing.rejectionCategory, liste et prochaines étapes) reprise par l'e-mail, la notification, l'historique de la facture et l'événement webhook. Le motif brut de la plateforme reste disponible dans einvoicing.rejectionReason. Les encaissements d'une facture déposée remontent à la plateforme sous le statut « Encaissée » (fr:212) : chaque paiement porte l'état de cette transmission (fr212.state), en attente tant que la facture n'a pas de dépôt accepté.

Changer de PA en cours de route

Facturino n'enferme pas votre comptabilité dans une PA donnée. À tout moment :

• Déconnectez la PA active depuis Paramètres → Facturation électronique — les identifiants chiffrés sont supprimés du stockage.
• Connectez une autre PA en suivant son guide. Les factures déjà envoyées restent traçables (statuts DGFiP figés sur la PA précédente).
• Les obligations dont aucun envoi n’a commencé peuvent utiliser la nouvelle connexion. Une réception connue ou incertaine reste liée à l’ancienne connexion ; Facturino doit la rapprocher avant tout nouvel envoi.

Prise en charge automatique

Après acceptation durable d’une demande métier, Facturino prend en charge le dépôt, son suivi et les reprises techniques. L’intégrateur n’installe aucun cron : les routes manuelles de dépôt et de reprise rejoignent les mêmes services idempotents et restent facultatives pour les reprises. Une réception incertaine impose une recherche de preuve ; une recherche indisponible ou incomplète n’autorise jamais un nouvel envoi.

Le suivi einvoicing.obligation distingue l’état opérationnel du paiement comptable et du verdict fiscal. Il porte state, reasonCode, reasonSource, owner, action et nextAttemptAt. Facturino reprend les indisponibilités en respectant Retry-After. Un refus inexpliqué ou une anomalie de génération relève d’un diagnostic Facturino ; seuls des faits source incorrects démontrés justifient une correction demandée au client.

L’e-reporting est préparé selon le calendrier fiscal figé, sans option d’activation supplémentaire. Les déclarations refusées et leurs tentatives sont conservées ; aucun remplacement fiscal d’une déclaration acceptée n’est improvisé. Un document bloqué avant préparation expose ereportingBlock.obligation. La consultation de l’e-reporting par API est facultative ; les événements annoncent ses résultats et les changements de prise en charge.

Couverture locale et limites de qualification

Ce tableau décrit le code et les contrats consultés au 13/09/2026 ; il ne constitue pas une campagne d’acceptation en production. « Intégré » signifie testé localement, pas prouvé auprès d’une plateforme.

Les limites restantes laissent l’obligation sous responsabilité Facturino ; elles ne deviennent ni une fausse acceptation ni une demande de cron chez l’intégrateur. Les appels Iopole et B2Brouter de recherche de facture ne prouvent pas une absence exhaustive. Un changement de compte ou de plateforme ne déplace pas une réception incertaine.