Dans une entreprise du BTP, la trésorerie ne se perd presque jamais sur un gros incident. Elle s’érode sur des détails de facturation : une situation de travaux émise avec dix jours de retard, une retenue de garantie jamais relancée à l’échéance, une facture de sous-traitant payée alors que l’attestation de vigilance a expiré, un DGD (décompte général définitif) qui traîne parce que personne ne sait quelle est la dernière version du budget.
Le guide sectoriel ERP BTP et l’article sur les fonctionnalités pour piloter les chantiers décrivent ce qu’un ERP BTP doit savoir faire en général. Celui-ci descend dans le cycle financier d’un chantier, là où les paramétrages mal pensés coûtent cher : situations, retenues, sous-traitance, révisions de prix. Il s’adresse aux DAF, DSI et conducteurs de travaux qui préparent un projet ERP ou qui veulent fiabiliser un existant.
Pourquoi la facturation BTP n’est pas de la facturation classique
Dans une entreprise de négoce ou de services, on livre, on facture, on encaisse. Dans le BTP, trois particularités cassent ce schéma.
La facturation suit l’avancement, pas la livraison. Un marché de travaux se facture par acomptes successifs, les situations de travaux, calculés sur l’avancement réel de chaque ligne du marché. Le montant facturé dépend d’une validation (par le maître d’œuvre ou le maître d’ouvrage) et non d’un simple bon de livraison.
Une partie du dû est volontairement retenue. Sur les marchés de travaux, une retenue de garantie est prélevée sur chaque situation puis restituée après réception. Entre le chiffre d’affaires reconnu, le facturé, l’encaissé et le retenu, quatre montants coexistent sur chaque chantier, et ils ne se recoupent pas.
Le sous-traitant n’est pas un simple fournisseur. Il a des droits propres (paiement direct, action directe) et le donneur d’ordre a des obligations propres (agrément, vérification des pièces sociales, autoliquidation de TVA). Un ERP qui traite la facture de sous-traitance comme une facture d’achat standard crée du risque juridique.
Ces particularités expliquent pourquoi les ERP généralistes sans verticale BTP finissent entourés de tableurs. Le test à appliquer au moment du choix : l’éditeur sait-il produire une situation de travaux cumulative, gérer les retenues avec leur échéancier et bloquer un paiement de sous-traitant sur pièce manquante, en standard ? Chaque réponse négative est un développement spécifique à chiffrer.
Marché, avenants, ordres de service : structurer le budget chantier dans l’ERP
Tout part de la structure de l’affaire. Si elle est mal construite à l’ouverture du chantier, aucune situation ne sera fiable.
Le marché comme référentiel de facturation
Le marché signé doit être saisi ligne à ligne (décomposition du prix, bordereau ou DPGF selon le type de marché), avec pour chaque ligne le montant du marché, l’unité et, si besoin, le lot ou l’ouvrage. C’est ce référentiel qui servira de base de calcul des situations. Les avenants et les ordres de service doivent venir le modifier avec historique : on ne réécrit pas le marché, on ajoute des versions datées, de sorte que l’on puisse toujours reconstituer le montant contractuel à une date donnée.
La trilogie budget, engagé, réalisé
Côté coûts, trois niveaux doivent coexister dans l’ERP et rester cohérents :
- le budget (ou prix de revient prévisionnel), issu de l’étude de prix ;
- l’engagé : commandes fournisseurs, contrats de sous-traitance, heures planifiées ;
- le réalisé : factures reçues, pointages, consommations de stock.
Le point de vigilance classique : un avenant client accepté qui n’est pas répercuté sur le budget et sur les contrats de sous-traitance. Le chantier semble alors rentable sur le papier, alors que les travaux supplémentaires sont déjà commandés et pas encore facturés. Le paramétrage doit lier chaque avenant client à son impact budgétaire, avec un statut (en négociation, signé, ordre de service émis) qui conditionne ce qui est facturable.
Le suivi du reste à dépenser et de la marge à terminaison s’appuie sur ces trois niveaux. Si vous voulez voir comment ces données alimentent le suivi de rentabilité, l’article sur la comptabilité de projet dans l’ERP donne le cadre analytique.
Situations de travaux mensuelles : cumul, déduction, validation
La situation de travaux est le cœur du dispositif. Son fonctionnement est simple dans le principe et piégeux dans l’exécution.
La mécanique de calcul
Pour chaque ligne du marché, la situation de travaux se calcule en cumul :
- avancement cumulé à la date de la situation (en pourcentage ou en quantité) ;
- montant cumulé = avancement cumulé × montant de la ligne (avenants inclus) ;
- montant de la situation = montant cumulé moins le cumul des situations précédentes.
L’ERP doit donc stocker le cumul par ligne, jamais seulement le montant de la dernière facture. C’est ce qui permet de corriger un avancement surestimé le mois suivant sans avoir à émettre d’avoir artisanal : la situation N+1 sera simplement plus faible, voire négative sur certaines lignes.
Un workflow de validation, pas juste une facture
Le circuit réel d’une situation est le suivant : le conducteur de travaux saisit les avancements, le chef de chantier ou le métreur les contrôle, la situation est transmise au maître d’œuvre (ou à l’économiste), qui la vise et propose un montant, puis le maître d’ouvrage valide. Seule la situation visée devient une facture.
L’ERP doit donc distinguer au moins trois états : situation en préparation, situation transmise (avec date d’envoi, qui déclenche les délais de paiement), situation validée (avec montant accepté, parfois inférieur au montant proposé). L’écart entre proposé et accepté doit être tracé, car il alimente le suivi des litiges et la relance.
Ce que l’ERP doit calculer à chaque situation
- l’avancement et le cumul par ligne, avenants compris ;
- la retenue de garantie sur la situation (voir section suivante) ;
- la révision ou l’actualisation de prix, si le marché en prévoit ;
- les pénalités éventuelles et la quote-part du compte prorata ;
- la TVA applicable (taux, mentions, autoliquidation le cas échéant) ;
- le net à payer et la date d’échéance.
Le décalage entre avancement facturé et avancement réel doit remonter dans un tableau de bord : un chantier en retard de facturation prive l’entreprise de trésorerie, un chantier surfacturé expose à un contentieux. Sur le suivi des encaissements et des relances, notre article sur la gestion du poste client et le crédit management détaille les mécanismes de relance qui s’appliquent aussi aux situations.
Retenue de garantie et caution de substitution
Le cadre légal général
Pour les marchés de travaux privés, c’est l’article 1er de la loi n° 71-584 du 16 juillet 1971 qui encadre la retenue de garantie. Les points à retenir pour le paramétrage, à vérifier avec votre conseil juridique sur le texte consolidé sur Légifrance :
- la retenue ne peut pas dépasser 5 % du montant de chaque acompte (synthèse du régime de la retenue en marché privé) ;
- elle sert à garantir l’exécution des travaux et la levée des réserves formulées à la réception ;
- l’entrepreneur peut la remplacer par une caution personnelle et solidaire émanant d’un établissement financier ;
- à défaut de caution, le maître de l’ouvrage doit consigner la somme retenue entre les mains d’un consignataire ;
- un an après la réception, la caution est libérée ou les sommes consignées sont versées, sauf opposition motivée du maître de l’ouvrage pour inexécution.
Les marchés publics ont leur propre régime, fixé par le code de la commande publique et les CCAG, avec un plafond et des modalités de libération qui leur sont propres. Un ERP BTP qui traite des deux types de marchés doit donc porter ces règles au niveau du marché, pas en dur dans le programme.
Le paramétrage qui évite les oublis
Concrètement, l’ERP doit gérer :
- un taux de retenue par marché (0 à 5 %), avec calcul automatique sur chaque situation et plafonnement ;
- un compte de tiers dédié aux retenues, pour que le stock de retenues apparaisse au bilan chantier par chantier ;
- une caution de substitution saisie comme objet à part : établissement, numéro, montant, date d’émission, date d’échéance. Quand elle est remise, la retenue cesse d’être appliquée et les retenues déjà opérées sont restituées ;
- un échéancier de libération calculé depuis la date de réception, avec alerte à 60 et 30 jours, et un statut « opposition » lorsque des réserves ne sont pas levées ;
- une retenue côté sous-traitants, qui suit le même schéma en miroir : ce que vous retenez à vos sous-traitants doit s’inscrire dans le même échéancier.
Le piège le plus coûteux est silencieux : à l’échelle d’un portefeuille de chantiers, les retenues non relancées après réception représentent une créance dormante. Un état « retenues à libérer dans les 90 jours » dans le tableau de bord du DAF suffit souvent à retrouver une trésorerie oubliée.
Sous-traitance : paiement direct, DC4, acceptation, agrément
Ce que dit la loi du 31 décembre 1975
La sous-traitance est encadrée par la loi n° 75-1334 du 31 décembre 1975 (texte de la loi). Les principes qui pèsent sur le paramétrage :
- l’entrepreneur principal doit faire accepter chaque sous-traitant et agréer ses conditions de paiement par le maître de l’ouvrage (article 3) ;
- il doit déclarer, dès la soumission, la nature et le montant des prestations qu’il envisage de sous-traiter (article 5) ;
- le paiement direct du sous-traitant par le maître de l’ouvrage concerne les marchés publics, au-delà d’un seuil de contrat fixé par le texte (article 6) ;
- dans les marchés privés de bâtiment et de travaux publics, le maître de l’ouvrage doit exiger de l’entrepreneur principal soit une délégation de paiement, soit une caution au profit du sous-traitant (article 14-1).
En marché public, la demande d’acceptation et d’agrément passe par le formulaire DC4 (déclaration de sous-traitance), à tenir à jour en cas d’avenant.
Ce que l’ERP doit porter
La fiche de contrat de sous-traitance doit contenir : le sous-traitant, le montant et la nature des prestations, le statut d’acceptation/agrément (en attente, accepté, refusé) avec date, le mode de paiement (direct ou via l’entrepreneur principal) et les garanties (délégation, caution).
Deux règles de gestion à rendre bloquantes :
- Pas de paiement sans acceptation. Si le sous-traitant n’est pas accepté, l’ERP refuse l’émission de l’ordre de paiement ou alerte explicitement.
- Pas de paiement sans pièces sociales valides. L’attestation de vigilance est exigée pour les contrats d’un montant à partir de 5 000 € HT, avec une vérification à la signature puis tous les six mois (articles L8222-1 et D8222-5 du code du travail, synthèse CMS). L’ERP doit stocker la date de validité de chaque pièce (attestation de vigilance, Kbis, assurances, etc.) et bloquer la validation de facture quand l’une est périmée.
Pour le paiement direct, la facture du sous-traitant doit être visée par l’entrepreneur principal (accord ou refus motivé dans un délai défini par le texte), puis transmise au maître de l’ouvrage. L’ERP doit donc gérer ce visa de l’entrepreneur principal comme une étape de workflow avec échéance.
La TVA autoliquidée
Pour les travaux immobiliers sous-traités, la TVA est autoliquidée depuis le 1er janvier 2014 (article 283, 2 nonies du CGI). Le sous-traitant facture hors taxe avec la mention « autoliquidation » ; l’entrepreneur principal déclare lui-même la TVA, collectée et déductible (présentation du dispositif). Il faut donc un code TVA spécifique sur les factures de sous-traitance, qui alimente la bonne ligne de la déclaration. Une facture de sous-traitance comptabilisée avec TVA classique est l’erreur de paramétrage la plus fréquente.
Révision et actualisation de prix, pénalités, compte prorata
Révision et actualisation
Beaucoup de marchés prévoient une révision de prix indexée sur un indice (les indices BT et TP publiés pour le bâtiment et les travaux publics) ou une simple actualisation. L’ERP doit gérer :
- la table des indices avec date de publication, car ils sont connus avec retard ;
- la formule de révision du marché (partie fixe, partie variable, indices de référence) ;
- le calcul provisoire sur le dernier indice connu, puis la régularisation quand l’indice définitif est publié.
La révision est un classique des manques à gagner : si personne ne la calcule, personne ne la facture. Un contrôle qui liste les marchés à clause de révision sans calcul sur les trois dernières situations est un bon garde-fou.
Pénalités et compte prorata
Les pénalités de retard sont à prévoir comme des lignes de déduction sur la situation, avec leur référence contractuelle. Le compte prorata (frais communs de chantier répartis entre entreprises) se gère comme une charge refacturée selon une clé de répartition. Quand l’entreprise est mandataire d’un groupement, les écritures s’alourdissent : le paramétrage doit être testé en recette avec un cas réel.
Le DGD, aboutissement du cycle
Le DGD, décompte général et définitif, clôt financièrement le marché. Il consolide tout : le marché et ses avenants, les situations payées, la révision, les pénalités, le prorata, les retenues. Un ERP bien structuré génère le projet de décompte à partir de ces données au lieu de le reconstruire dans un tableur. Si ce projet de décompte est impossible à produire proprement, c’est le signe que l’un des maillons amont (avenants, révision, retenues) est mal paramétré.
Dématérialisation : facture électronique et réforme française
Les situations de travaux, les factures de sous-traitance et les factures finales sont concernées par la réforme de la facturation électronique. Dans le BTP, trois sujets méritent attention :
- les mentions et les catégories d’opérations (prestations de services, livraisons de biens) à renseigner correctement pour l’e-reporting ;
- le rattachement des situations au marché et à l’affaire, que les formats structurés doivent pouvoir porter ;
- le traitement de l’autoliquidation dans le flux, qui doit rester cohérent avec la mention figurant sur la facture.
Pour le calendrier, les plateformes agréées et les premiers retours d’expérience, reportez-vous au bilan du premier mois de facture électronique B2B en France et à la feuille de route 2026-2027. Le point pratique : testez vos situations de travaux dans le flux de votre plateforme agréée avant la mise en production, pas après le premier rejet.
Checklist de recette avant mise en production
La recette doit se faire sur un chantier test complet, rejoué de l’ouverture au DGD avec des données réalistes (un marché, deux avenants, trois situations, un sous-traitant en paiement direct, une retenue puis une caution de substitution).
| Flux à tester | Résultat attendu | Responsable de recette |
|---|---|---|
| Saisie du marché et des avenants | Versions datées, montant contractuel reconstituable | Contrôle de gestion |
| Budget, engagé, réalisé | Écarts cohérents avec le marché après avenant | Conducteur de travaux |
| Situation N puis N+1 | Cumul exact, déduction des situations précédentes, corrections d’avancement sans avoir | Conducteur de travaux |
| Validation maître d’œuvre | États préparation, transmise, validée ; écart proposé/accepté tracé | Comptabilité clients |
| Retenue de garantie | Calcul au taux du marché, plafonnement, compte dédié | DAF |
| Caution de substitution | Arrêt de la retenue, restitution du cumul, échéance de la caution suivie | DAF |
| Libération de la retenue | Échéancier depuis la réception, alertes, statut opposition | Comptabilité clients |
| Acceptation du sous-traitant | Blocage du paiement sans acceptation | Achats |
| Pièces sociales | Blocage sur attestation de vigilance périmée | Achats |
| Paiement direct | Visa de l’entrepreneur principal, transmission au maître d’ouvrage | Comptabilité fournisseurs |
| TVA autoliquidée | Code TVA spécifique, déclaration correcte | Fiscalité |
| Révision de prix | Calcul provisoire puis régularisation à l’indice définitif | Contrôle de gestion |
| Pénalités et compte prorata | Déductions et refacturations correctes | Comptabilité |
| DGD | Projet de décompte généré sans retraitement manuel | DAF et conducteur de travaux |
| Flux de facture électronique | Situation acceptée par la plateforme agréée | DSI |
| Rentabilité par chantier | Marge à date et à terminaison cohérente avec les écritures | Contrôle de gestion |
Un point d’organisation : confiez la recette à ceux qui vivent ces flux (conducteurs de travaux, comptables chantier), pas seulement à l’équipe projet. Ce sont eux qui sauront dire que « ce n’est pas comme ça qu’on fait une situation ».
FAQ
Quelle est la différence entre une situation de travaux et une facture classique ? Une situation est un acompte calculé sur l’avancement cumulé, soumis à validation, dont le montant se déduit des situations précédentes. Elle ne devient une facture exigible qu’après visa.
La retenue de garantie est-elle toujours de 5 % ? 5 % est un plafond en marché privé selon la loi du 16 juillet 1971. Le taux réel est fixé par le marché. Paramétrez-le par marché, pas globalement.
Faut-il bloquer le paiement d’un sous-traitant si l’attestation de vigilance est périmée ? C’est recommandé : l’obligation de vérification pèse sur le donneur d’ordre. Rendre ce blocage automatique dans l’ERP évite de dépendre de la vigilance de chacun.
Un ERP généraliste peut-il gérer ces flux ? Souvent avec des développements spécifiques importants. Faites chiffrer chaque point de la checklist ci-dessus avant de choisir, plutôt que de découvrir les écarts en recette.
Que faire du DGD dans l’ERP ? Le traiter comme une sortie du système : si le projet de décompte ne peut pas être produit à partir des données de l’affaire, corrigez la structure amont.
Les références légales citées ici sont un cadre général et ne remplacent pas l’avis de votre conseil juridique ou de votre expert-comptable sur un marché donné.
Aller plus loin
Vous préparez un projet ERP BTP ou une reprise de paramétrage des flux financiers de chantier ? Contactez-nous pour un audit de besoins ERP centré sur vos situations, retenues et sous-traitants. Pour structurer votre évaluation, téléchargez aussi notre grille d’évaluation ERP : 30 critères sur 100 points.
