How does Scell calculate the balance amount?

Balance amount = quote total TTC − sum of already-invoiced deposits. Scell automatically reads parent_invoice_ids to sum deposits. You recalculate nothing: one convertToBalance call is enough.

What is BG-22 in the context of a balance invoice?

BG-22 is the EN16931 "Preceding Invoice Reference" tag group. It lists already-issued deposit invoices with their deducted amounts. Without BG-22, the recipient cannot know that VAT was partially already paid. Scell generates BG-22 automatically.

Can I issue a balance invoice without having issued a deposit?

Yes. If no deposit was issued from the quote, convertToBalance generates a balance invoice for the full amount. The BG-22 section is absent (no deposit to reference). Behavior adapts based on billing history.

Does the balance invoice enter the ISCA ledger?

Yes. Like any issued invoice, it is recorded in the SHA-256 chain with a contiguous sequence_number. Chain integrity is verifiable via GET /api/v1/fiscal/integrity. The full cycle (quote → deposit → balance) is traced.

Can I issue a credit note on a balance invoice?

Yes. The credit note automatically inherits fields from the source invoice (buyer, seller, buyer_is_individual). The ISCA chain is maintained. A credit note never breaks the fiscal chain.

Does Scell support quotes with multiple deposits at different rates?

Yes. You can issue a 30% deposit, then a 20% second one, then the balance for the remaining 50%. Each deposit has its own FAC-YYYY-NNNN number and its own due VAT. BG-22 references all deposits in the balance invoice.

What is the deadline for issuing the balance invoice after the quote?

No technical limit. The billing date (due_date) is free. In practice, the invoice should be issued at delivery or service completion. That is your contractual obligation, not an API constraint.

Is the balance invoice PDF different from a deposit?

Structurally identical (PDF/A-3b + XML CII), but the type changes (invoiceTypeCode: 380 vs 386), the BG-22 section is present, and the amount reflects the residual. Visually, both PDFs are generated by the same Factur-X engine.

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

Factur-X balance invoice — BG-22 deduction automatically calculated.

Balance = quote total - sum of deposits. Calculated and written in XML. Type 380, BG-22, deposit reference parent_invoice_ids. Zero manual recalculation.

Generate my balance invoice →View 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);

The problem

→Missing or malformed BG-22 — without the "Preceding Invoice Reference" section, the recipient doesn't know VAT was partially already paid. Possible rejection at tax audit.
→Double VAT invoicing — if VAT is recalculated on the quote total instead of the residual, the client pays VAT twice. Major accounting error, likely tax audit adjustment.
→Manual balance calculation — referencing N deposits with their respective pre-tax amounts manually is error-prone. No consumer tool automates BG-22.

Our solution

→Automatic BG-22 generation — convertToBalance reads parent_invoice_ids and builds the BG-22 section with exact references for each deposit. FNFE schematron validation guaranteed.
→Balance = quote total − sum of deposits — automatic calculation, VAT only on residual. 0 double invoicing, 0 client-side recalculation.
→Type 380 + continuous ISCA chain — the invoice enters the SHA-256 chain with contiguous sequence_number. Full cycle quote → deposits → balance traced and verifiable.

6 type 380 guarantees

Automatic balance calculation

quote_total - sum(deposits) calculated without intervention. Scell reads parent_invoice_ids and does the arithmetic. 0 accounting errors, 0 manual recalculation.

0 accounting error

EN16931-compliant BG-22

The BG-22 tag group (Preceding Invoice Reference) is automatically generated with exact references of each deposit. FNFE schematron validation guaranteed.

0 FNFE rejection

Type 380 (Final invoice)

Clear distinction deposit (386) / balance (380) in EDI. Transparent client accounting. invoiceTypeCode correctly positioned in CII XML.

Clear client accounting

Cross-reference parent_invoice_ids

Each deposit cited individually in the BG-22 section of the balance. 30-second audit: a single endpoint to see the complete cycle (quote → deposits → balance).

30-second audit

Continuous ISCA chain

The balance enters the same SHA-256 chain as the quote and deposits. Contiguous sequence_number. Full cycle integrity verifiable via /fiscal/integrity.

Full cycle integrity

Compatible buyer registry

The balance invoice inherits the buyer_id snapshotted at issuance. Buyer data is frozen — modifying the buyers registry does not impact issued documents.

Frozen buyer data

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

Frequently asked questions

Ready to close your first deposit/balance cycle?

Free sandbox. No credit card required. BG-22 calculated in 1 call.

Start for free View SDKs