Comment Scell calcule-t-il le montant du solde ?

Le montant du solde = total TTC du devis − somme des acomptes déjà facturés. Scell lit automatiquement parent_invoice_ids pour sommer les acomptes. Vous ne recalculez rien : un appel convertToBalance suffit.

Qu'est-ce que BG-22 dans le contexte d'une facture de solde ?

BG-22 est le groupe de balises EN16931 "Preceding Invoice Reference". Il liste les factures d'acompte déjà émises, avec leurs montants déduits. Sans BG-22, le destinataire ne peut pas savoir que la TVA a déjà été partiellement acquittée. Scell génère BG-22 automatiquement.

Peut-on émettre une facture de solde sans avoir émis d'acompte ?

Oui. Si aucun acompte n'a été émis depuis le devis, convertToBalance génère une facture de solde pour le montant total. La section BG-22 est absente (aucun acompte à référencer). Le comportement est adaptatif selon l'historique de facturation.

La facture de solde entre-t-elle dans le ledger ISCA ?

Oui. Comme toute facture émise, elle est enregistrée dans la chaîne SHA-256 avec un sequence_number contigu. L'intégrité de la chaîne est vérifiable via GET /api/v1/fiscal/integrity. Le cycle complet (devis → acompte → solde) est tracé.

Peut-on émettre un avoir sur une facture de solde ?

Oui. L'avoir hérite automatiquement des champs de la facture source (acheteur, vendeur, buyer_is_individual). La chaîne ISCA est maintenue. Un avoir ne casse jamais la chaîne fiscale.

Scell supporte-t-il les devis avec plusieurs acomptes à des taux différents ?

Oui. Vous pouvez émettre un acompte de 30%, puis un deuxième de 20%, puis le solde pour les 50% restants. Chaque acompte a son propre numéro FAC-YYYY-NNNN et sa propre TVA exigible. BG-22 référence tous les acomptes dans la facture de solde.

Quelle est la deadline pour émettre la facture de solde après le devis ?

Il n'y a pas de limite technique. La date de facturation (due_date) est libre. En pratique, la facture doit être émise à la livraison ou à l'achèvement de la prestation. C'est votre contractuel, pas une contrainte API.

Le PDF de la facture de solde est-il différent de celui d'un acompte ?

Structurellement identique (PDF/A-3b + XML CII), mais le type change (invoiceTypeCode: 380 vs 386), la section BG-22 est présente, et le montant reflète le résiduel. Visuellement, les deux PDFs sont générés par le même moteur Factur-X.

Factur-X type 380 · BG-22 auto · parent_invoice_ids

Facture de solde Factur-X — déduction BG-22 calculée automatiquement.

Le solde = total devis - somme des acomptes. Calculé et écrit en XML. Type 380, BG-22, référence acomptes parent_invoice_ids. Zéro recalcul manuel.

Générer ma facture de solde →Voir les SDKs

$balance = $api->quotes()->convertToBalance('quote-uuid', [
    'due_date' => '2026-07-10',
]);

echo 'Balance invoice: ' . $balance->invoice_number;
echo 'Remaining to pay: ' . $balance->total_ttc;
echo 'References deposits: ' . json_encode($balance->parent_invoice_ids);

Le problème

→BG-22 manquant ou mal formé — sans la section "Preceding Invoice Reference", le destinataire ne sait pas que la TVA a déjà été partiellement acquittée. Rejet possible au contrôle fiscal.
→Double facturation de TVA — si la TVA est recalculée sur le total du devis au lieu du résiduel, le client paie la TVA deux fois. Erreur comptable majeure, redressement fiscal probable.
→Calcul manuel du solde — référencer N acomptes avec leurs montants HT respectifs manuellement est source d'erreur. Aucun outil grand public n'automatise BG-22.

Notre solution

→BG-22 généré automatiquement — convertToBalance lit parent_invoice_ids et construit la section BG-22 avec références exactes de chaque acompte. Validation schematron FNFE garantie.
→Solde = total devis − somme acomptes — calcul automatique, TVA uniquement sur le résiduel. 0 double facturation, 0 recalcul côté client.
→Type 380 + chaîne ISCA continue — la facture entre dans la chaîne SHA-256 avec sequence_number contigu. Cycle complet devis → acomptes → solde tracé et vérifiable.

6 garanties type 380

Calcul automatique du solde

total_devis - sum(acomptes) calculé sans intervention. Scell lit parent_invoice_ids et fait l'arithmétique. 0 erreur comptable, 0 recalcul manuel.

0 erreur comptable

BG-22 conforme EN16931

Le groupe de balises BG-22 (Preceding Invoice Reference) est généré automatiquement avec les références exactes de chaque acompte. Validation schematron FNFE garantie.

0 rejet FNFE

Type 380 (Final invoice)

Distinction claire acompte (386) / solde (380) dans l'EDI. Comptabilité client transparente. invoiceTypeCode correctement positionné dans le XML CII.

Comptabilité client claire

Référence croisée parent_invoice_ids

Chaque acompte cité individuellement dans la section BG-22 du solde. Audit en 30 secondes : un seul endpoint pour voir le cycle complet (devis → acomptes → solde).

Audit en 30 secondes

Chaîne ISCA continue

Le solde entre dans la même chaîne SHA-256 que le devis et les acomptes. Sequence_number contigu. Intégrité du cycle complet vérifiable via /fiscal/integrity.

Intégrité cycle complet

Compatible buyer registry

La facture de solde hérite du buyer_id snapshoté au moment de l'émission. Les données acheteur sont figées — une modification du registre buyers n'impacte pas les documents émis.

Données acheteur figées

Hébergé en FranceScaleway Paris

RGPDDonnées FR

Factur-X conformeDGFiP EN16931

eIDAS SESRègl. 910/2014

ISCA SHA-256Ledger immuable

TLS 1.3Chiffrement bout-à-bout

Questions fréquentes

Prêt à clôturer votre premier cycle acompte/solde ?

Sandbox gratuit. Aucune carte de crédit requise. BG-22 calculé en 1 appel.

Essayer gratuitement Voir les SDKs