Avoirs et acomptes : préparer les flux ERP

Inventorier les pratiques avant les exceptions

La facture standard ne représente pas tous les documents émis par une entreprise. Listez les avoirs, acomptes, annulations et régularisations réellement utilisés. Décrivez le motif, le document d’origine et le rôle de chaque application. Les cas d’usage publiés dans le cadre des travaux AFNOR servent de référence technique ; leur application à vos pratiques doit être examinée avec la comptabilité et le prestataire.

Ne déduisez pas le traitement d’un document de son seul intitulé dans l’ERP. Un écran peut utiliser le mot « acompte » pour des opérations différentes. Identifiez ce qui est comptabilisé et ce qui constitue seulement une demande ou une information commerciale. Le dossier doit distinguer ces objets pour éviter qu’un connecteur transmette un document au mauvais moment.

Conserver les références de l’opération

Un avoir doit pouvoir être rapproché de l’opération qu’il corrige selon le cas retenu. Décrivez les références disponibles dans l’ERP et celles utilisées par le destinataire. Une correction portant sur plusieurs documents demande une analyse spécifique. Ne généralisez pas un scénario de démonstration à toutes les pratiques du service comptable.

Le mapping doit expliquer le traitement des signes, des lignes et des totaux. Faites vérifier le résultat par un comptable sur un jeu fictif. Un montant négatif ne suffit pas à qualifier un avoir dans toutes les interfaces. L’identité du document et son lien avec les pièces d’origine doivent rester explicites. Les règles fiscales précises sont validées par l’équipe compétente et avec les références applicables.

Relier les acomptes et les règlements

Un acompte peut intervenir avant la facture finale et être associé à un encaissement. Inventoriez les événements dans votre processus : demande, facturation, paiement et imputation. Ces étapes peuvent appartenir à plusieurs applications. Le connecteur doit utiliser la donnée correspondant au flux qualifié, plutôt que déduire un paiement d’un simple état commercial.

Décrivez les règlements partiels et les cas de modification de la commande. L’équipe fiscale valide le traitement de TVA ; l’intégrateur documente la transformation et la transmission. Cette séparation évite d’automatiser une hypothèse non validée. Demandez comment une information corrigée est rapprochée d’un document déjà envoyé et comment les preuves restent consultables dans le dossier.

Avoir, refus et nouvelle facture

Un avoir n’est pas la réponse automatique à un refus. Selon le guide de démarrage de la DGFiP, un statut « refusée » ne tranche pas le différend entre les parties : si le refus révèle une erreur, le vendeur la corrige et émet, si nécessaire, une nouvelle facture avec un nouveau numéro ; s’il accepte un refus fondé, il peut neutraliser la facture dans ses propres systèmes, par un avoir interne, un remboursement ou une régularisation ultérieure ; s’il conteste le refus, il ne crée ni nouvelle facture ni avoir avant d’avoir instruit le désaccord avec l’acheteur. Le paramétrage de l’ERP doit donc empêcher qu’un refus déclenche seul la création d’un avoir.

Côté acomptes, la DGFiP cite les acomptes parmi les opérations dont la TVA est exigible à l’encaissement : elles relèvent du e-reporting de paiement, avec la date d’encaissement, le montant encaissé par taux de TVA et le numéro de facture lorsqu’il existe. L’événement d’encaissement de l’acompte doit donc être identifiable dans l’ERP, distinct de la facture finale.

Écrire une recette propre à chaque variante

Pour un avoir, testez la présence de la référence d’origine et la conservation des lignes utiles. Pour un acompte, testez son lien avec l’opération et le rapprochement ultérieur. Pour une facture finale, vérifiez que les informations comptables attendues correspondent au document produit. Utilisez des jeux fictifs représentant votre activité, sans inventer des pratiques que l’entreprise n’applique pas.

Ajoutez un cas avec référence absente et un cas de réponse tardive. Le système doit présenter l’erreur à la bonne personne et conserver les éléments nécessaires au diagnostic. La reprise doit distinguer correction d’une donnée et création d’un nouveau document. Une relance technique ne doit pas être utilisée pour remplacer une décision comptable.

Prévoir les limites dans le devis

Demandez au prestataire quelles variantes sont couvertes, quelles variantes nécessitent un paramétrage et lesquelles restent hors périmètre. Associez chaque réponse à une preuve ou à un engagement de recette. Une fonction générique d’avoir ne prouve pas le traitement d’une opération comportant plusieurs références ou un paiement particulier.

Le contrat doit attribuer la maintenance des règles lorsque l’entreprise change ses pratiques. Conservez le dictionnaire et les jeux de régression. Si un cas ne peut pas être testé avant achat, indiquez-le dans la décision avec la validation attendue avant production. La DAF peut alors décider sur une information explicite au lieu de découvrir l’exclusion lors de la première correction client.

Grille à joindre à la consultation

Livrable attendu

Le dossier remis au candidat contient une fiche par variante pratiquée et des exemples fictifs. Faites préciser la correspondance avec les références techniques actuelles. Le résultat attendu doit montrer la pièce, les données transmises et les réponses utilisées dans l’ERP. Ajoutez les cas non qualifiés au registre du projet avec leur responsable. Les exclusions doivent être inscrites dans l’offre et examinées avant la décision de bascule, plutôt que traitées comme des anomalies imprévues.