--- title: "France · The 45 B2B use cases (cas d'usage · XP Z12-014)" description: "Every AFNOR XP Z12-014 B2B use case (cas d" canonical: "https://docs.get-flowie.com/compliance/fr/use-cases" source: "https://docs.get-flowie.com/compliance/fr/use-cases.html" --- # France · The 45 B2B use cases (cas d'usage · XP Z12-014) Compliance · 🇫🇷 France # The B2B use cases of the French reform — _cas d'usage_ XP Z12-014 The reform doesn't just say "send a structured invoice". It enumerates the concrete **business scenarios** a French e-invoice can encode — advance payments, self-billing, factoring, reverse charge, margin VAT, e-reporting, and so on — as the **cas d'usage** of AFNOR **XP Z12-014**. This page is the complete referential: **all 45 cases** as of v1.4 (published 2026-06-30), a plain-English deep dive on every theme, and exactly how to model each one with Flowie — cross-checked against the public DGFiP and FNFE-MPE sources listed at the [bottom](<#references>). **v1.0** · 2025-06-13 · 36 cas **v1.2** · 2025-10-31 · 42 (adds 37–42) **v1.3** · 2026-02-26 · 44 (adds 43, 44) **v1.4** · 2026-06-30 · 45 (adds 45) The referential grows with each revision; we track every version and update this page. The authoritative `Cas d'usage → titre` list is **Annexe A** of XP Z12-014 (public via FNFE-MPE / the DGFiP _Spécifications externes B2B_) — the numbering and titles below follow it. ## What a _cas d'usage_ actually is A cas d'usage is a named, numbered **business scenario** plus the rules that make it work on the network: which document(s) are exchanged, which fields or attributes carry the specifics, which party emits what, and how the [200–213 lifecycle]() is affected. It is _not_ a new invoice format — every case still travels as Factur-X / UBL / CII (EN 16931) and its lifecycle still uses the same 14 statuses. The case tells you _how to fill and route_ the invoice for that situation. You do **not** pass a "use-case number" to Flowie. You send the invoice with the right structured data (a deposit amount, a self-billing mandate reference, a reverse-charge VAT category, a link to the original invoice…) and Flowie produces a compliant flow. The case list is the map of _what data a given situation needs_ — read it as requirements, not as an API parameter. ## What it is _not_ — three vocabularies people conflate Vocabulary| What it is| Belongs to ---|---|--- **Cas d'usage** (1–45)| B2B business scenarios of the reform| AFNOR XP Z12-014 — _this page_ **Cadres de facturation** (`A1`–`A25`)| _What_ document is deposited and by _whom_| Legacy **Chorus Pro** (B2G public sector) — [below](<#cadres>) **Circuits** (`A`, `B1`, `B2`, `C`)| Who uses the PPF vs a PA — the _schéma en Y_| DGFiP transmission architecture — _not_ invoice types The big split: e-invoicing vs e-reporting Domestic **B2B** invoices flow as structured e-invoices through PA platforms (_e-invoicing_). **B2C, international and intra-community** operations are covered by _e-reporting_ — you transmit transaction / payment **data** to the DGFiP, you do not exchange a structured invoice through the PPF/PA network. Several cases below (marked e-reporting) live on the e-reporting side. ## The three families XP Z12-014 sorts the cases into three families: Family 1 ### Facturation « data » Cases needing extra data or a rule tweak on the invoice itself — multi-order/multi-delivery, advance invoices, discounts & escompte, margin VAT, sub-lines and groupings. Family 2 ### Intervention d'un tiers Cases where a third party is in the loop — factoring, distributor/depositary, marketplaces, payment mandates, self-billing, débours — with document- and lifecycle-sharing mechanics. Family 3 ### Impact sur le cycle de vie Cases that change the lifecycle — partial collection, monthly payments, restaurant & toll receipts, operations under professional secrecy — often flowing from a third party or a special VAT regime. ## All 45 cases, numbered The complete referential (XP Z12-014 v1.4, Annexe A), grouped by practical theme so you can find the one you need. Cases on the e-reporting side are tagged e-reporting; the v1.4 addition is tagged v1.4. #| Cas d'usage (FR)| What it covers & how Flowie models it ---|---|--- Acompte & paiement échelonné 20| Facture d'acompte| Advance / deposit invoice. Send it as its own invoice; the final invoice (21) references it. 21| Facture définitive après acompte| Final invoice that nets out the deposit — `link` it to invoice 20 so the deducted amount is traceable. 24| Gestion des arrhes| _Arrhes_ (forfeitable earnest) vs acompte — different legal effect on cancellation; carried as the deposit's nature. 32| Paiements mensuels| Recurring monthly instalments against one engagement; each collection is a `212` (partial). 34| Encaissement partiel et annulation| Partial collection then cancellation — drives `partially_paid` then a corrective / avoir. Autofacturation & mandats de facturation 19a| Facture émise par un tiers facturant avec mandat| A mandated third party issues on the seller's behalf — carry the mandate reference. 19b| Auto-facturation| The buyer issues the invoice for the seller (self-billing) under agreement. 23| Auto-facturation entre particulier et professionnel| Self-billing where one side is a private individual (e.g. producer buy-back). 45| Auto-facture bidirectionnelle v1.4| Both parties self-bill each other — the v1.4 addition. Affacturage, tiers payeurs & intermédiaires 2| Facture déjà payée par l'acheteur ou un tiers payeur| Already-settled invoice (e.g. lodged card) — emitted _paid_. 3| Facture à payer par un tiers payeur connu| A known third party settles for the buyer. 4| Facture à payer par l'acheteur avec prise en charge partielle| Buyer pays part; a third party covers the rest. 8| Facture à payer à un tiers déterminé à la facturation| Payee resolved at invoicing time (assignment of receivable). 9| Facture à payer à un distributeur / dépositaire| Payment routed to a distributor or depositary. 10| Facture à payer à un tiers bénéficiaire inconnu (affactureur)| **Factoring** : the factor is the beneficiary; the buyer pays them. 11| Facture reçue et traitée par un tiers pour l'acheteur| A third party receives/processes on the buyer's behalf. 12| Intermédiaire transparent, gestionnaire de facture| Transparent intermediary manages the invoice without being a party to the sale. 15| Facture de vente suite à commande d'un tiers| Sale invoiced after a third party placed the order. 17a| Facture à payer à un tiers, intermédiaire de paiement| Payment intermediary in the settlement path. 17b| Facture à payer à un tiers avec mandat de facturation| Third-party payee combined with a billing mandate. 39| Intermédiaire transparent (multi-vendeurs)| Marketplace-style transparent intermediary across several sellers. Frais des collaborateurs & cartes 5| Frais payés par des collaborateurs avec facture| Employee expenses backed by an invoice. 6| Frais payés par des collaborateurs sans facture| Employee expenses without a supplier invoice → e-reporting / receipt path. e-reporting 7| Facture suite à un achat payé avec carte logée| Purchase settled via a lodged corporate card. Sous-traitance, co-traitance & débours 13| Facture de sous-traitance avec paiement direct| Direct-payment subcontracting (public works style). 14| Facture de co-traitance B2B| Joint contractors invoicing together. 16| Facture de débours| _Débours_ : costs advanced in the client's name, re-billed at cost, outside the VAT base. Avoir, notes & escompte 18| Gestion des notes de débit| Debit notes alongside the invoice flow. 22a| Facture payée avec escompte (TVA à l'encaissement)| Early-payment discount, services / VAT-on-collection. 22b| Facture payée avec escompte (livraisons de biens)| Early-payment discount, goods. —| Avoir / facture rectificative| _Not its own numbered case_ : a credit note is a first-class document type that must reference the original and travel the same circuit. Régimes de TVA particuliers 25| Gestion des bons et cartes cadeaux| Single- vs multi-purpose vouchers and gift cards. 29| Assujetti unique| VAT group / single taxable person. 30| TVA déjà collectée (bridge e-reporting B2C)| VAT already collected on a B2C leg feeding into B2B. e-reporting 33| Régime de TVA sur la marge bénéficiaire| Margin-scheme VAT (used goods, travel, art…). 42| Gestion de la détaxe| Tax-free / détaxe handling. —| Autoliquidation (reverse charge)| _Not a dedicated case_ : modelled as a VAT category / mention on the invoice (e.g. subcontracting 13, co-contracting 14). E-reporting — B2C & international 27| Gestion des tickets de péage| Toll tickets reported as data. e-reporting 28| Gestion des notes de restaurant| Restaurant receipts reported as data. e-reporting 43| E-reporting B2B international| Cross-border B2B reported as data. e-reporting 43a| Opérations triangulaires| Triangular international operations. e-reporting 43b| Transferts de stocks| Cross-border stock transfers. e-reporting 44| Transactions avec DROM / COM / TAAF| French overseas territories. e-reporting Contractual, special & edge cases 1| Multi-commande / multi-livraison| One invoice spanning several orders / deliveries. 26| Factures avec clause de réserve contractuelle| Retention-of-title / contractual reserve clause. 31| Factures « mixtes »| Mixed invoices (e.g. goods + services, or B2B + e-reporting lines). 35| Notes d'auteur| Author's fee notes (specific professions). 36| Opérations soumises au secret professionnel| Professional-secrecy operations — restricted line detail. 37| Sociétés en participation (SEP)| Joint-venture (SEP) invoicing. 38| Factures avec sous-lignes et regroupements| Sub-lines and line groupings on the invoice. 40| Paiements groupés / compensation| Netting / set-off across invoices. 41| Pratiques du « barter »| Barter / exchange of goods or services. Titles follow XP Z12-014 Annexe A as published; where a concept is handled as an attribute rather than a numbered case (avoir, autoliquidation) the row is marked `—`. The three-family split is AFNOR's; the theme grouping above is ours, for navigation. ## Deep dive · acompte & paiement échelonné ### 20 · 21Deposit then final invoice The most common "two-document" pattern. The supplier issues a _facture d'acompte_ (20) when a deposit is agreed, then a _facture définitive_ (21) on completion that restates the full amount and **deducts the deposit already invoiced**. The final invoice must reference the deposit invoice so the deducted amount and its VAT are traceable. With Flowie: send both as normal invoices and use a [`link` action](<../../reference/index.html#document-actions>) from the final to the deposit; the deducted line carries the reference. ### 24Arrhes vs acompte Legally distinct from an acompte: _arrhes_ can be forfeited (buyer walks away, loses them) or doubled (seller cancels, repays double), whereas an acompte firmly commits both sides. The distinction changes the VAT and cancellation treatment, so it is carried explicitly as the nature of the down-payment rather than left implicit. ### 32 · 34Instalments & partial collection Case 32 covers recurring monthly payments against a single engagement; case 34 covers a partial collection followed by cancellation. Both are **lifecycle-impacting** : each collection is an [`212 Encaissée`]() (use `partially_paid` \+ `remainingAmount` for partials, repeatable), and a cancellation resolves via a corrective invoice and, if already accepted, an avoir. ## Deep dive · autofacturation & mandats Self-billing inverts the usual emitter: the **buyer** (or a mandated third party) issues the invoice on the supplier's behalf, under a prior agreement. The reform keeps this legal but demands the arrangement be explicit on the flow. * **19b Auto-facturation** — buyer issues for the seller. The buyer's platform is the emitter; the seller must be able to contest. * **19a / 17b Mandat de facturation** — a third party issues under an explicit mandate reference; 17b combines this with a third-party payee. * **23** — self-billing where one party is a private individual (classic in agriculture / producer buy-back). * **45 Auto-facture bidirectionnelle** v1.4 — the newest case: both parties self-bill each other, which needs careful de-duplication so a single economic operation isn't reported twice. ## Deep dive · affacturage & tiers payeurs This is the largest family — anything where **someone other than the buyer** pays, receives, or manages the invoice. The mechanics hinge on _who the payee is_ and _who sees the lifecycle_. * **10 Affacturage (factoring)** — the receivable is assigned to a factor; the buyer pays the factor, not the supplier. The invoice names the factor as beneficiary, and the supplier's collection status reflects the factor's receipt. * **3 · 8 · 9 · 17a Tiers payeur / payee** — a known third party, a payee fixed at invoicing, a distributor/depositary, or a payment intermediary settles the invoice. * **2 · 4** — already-paid invoices, and split payment where the buyer covers part and a third party the rest. * **11 · 12 · 39 Intermédiaires** — a third party receives/processes for the buyer (11), a transparent intermediary manages the invoice (12), or a multi-vendor transparent intermediary (39) — the marketplace pattern. Débours ≠ tiers payeur Don't confuse the payee patterns with [débours (16)](<#credit>): a débours is a cost advanced _in the client's name_ and re-billed at cost, sitting **outside** the VAT base — a data concern on the invoice, not a routing concern. ## Deep dive · sous-traitance, co-traitance & débours * **13 Sous-traitance avec paiement direct** — the subcontractor is paid directly (public-works pattern); typically carries **autoliquidation** (reverse charge) as a VAT mention, since reverse charge is not a numbered case of its own. * **14 Co-traitance B2B** — joint contractors invoice together, each for their share, coordinated by the lead. * **16 Débours** — costs advanced in the client's name and re-billed at cost, excluded from the VAT base; modelled as dedicated lines flagged as débours. ## Deep dive · avoir, notes de débit & escompte **Avoir / facture rectificative (credit note)** is deliberately _not_ a numbered case: it is a first-class **document type**. It must reference the original invoice, travel the same circuit, and — if the original was already accepted — accompany the corrective. Send it through the normal document pipeline with the credit-note type and the link to the original. **18 Notes de débit** handles debit notes alongside the invoice. **22a / 22b Escompte** cover early-payment discounts, split by VAT treatment: 22a for services (VAT on collection), 22b for goods (VAT on delivery) — the split matters because the discount changes the taxable base differently in each regime. ## Deep dive · régimes de TVA particuliers * **33 TVA sur la marge** — VAT charged only on the margin (used goods, art, antiques, travel agencies). The taxable base is the margin, not the sale price; carried as a margin-scheme VAT category. * **42 Détaxe** — tax-free sales / refund handling. * **29 Assujetti unique** — the VAT-group "single taxable person": intra-group flows are outside VAT, which the invoice must signal. * **25 Bons & cartes cadeaux** — single-purpose vouchers (VAT at issue) vs multi-purpose (VAT at redemption). * **30 TVA déjà collectée** e-reporting — bridges VAT already collected on a B2C leg into a B2B flow. * **Autoliquidation (reverse charge)** — again, an attribute/mention, not a case; the buyer self-assesses the VAT. ## Deep dive · e-reporting (B2C & international) These cases are **not invoice exchange** — they transmit transaction / payment **data** to the DGFiP. An integration must not try to route them as structured invoices through the PA network: * **27 Péage · 28 Restaurant · 6 Frais sans facture** — B2C-style receipts reported as data. * **30 TVA déjà collectée** — the B2C→B2B VAT bridge. * **43 (43a/43b) International** — cross-border B2B, triangular operations, and stock transfers reported as data. * **44 DROM / COM / TAAF** — French overseas territories, whose VAT territoriality differs from the metropole. See the [France overview]() for how e-reporting timing (24 h for payment data) ties into the mandatory lifecycle statuses. ## Deep dive · special & edge cases * **1 Multi-commande / multi-livraison** — one invoice covering several orders or deliveries; needs the order/delivery references per line. * **31 Factures mixtes** — an invoice mixing regimes (e.g. B2B lines + e-reporting lines, or goods + services). * **38 Sous-lignes & regroupements** — hierarchical line structure. * **26 Clause de réserve** — retention-of-title / contractual reserve. * **40 Compensation** — netting / set-off across invoices. * **41 Barter** — exchange of goods/services with reciprocal invoices. * **35 Notes d'auteur · 36 Secret professionnel · 37 SEP** — profession-specific and structure-specific cases; 36 restricts line-level detail for confidentiality. ## Legacy — cadres de facturation (Chorus Pro / B2G) If you see `A1`…`A25` in a flow, that is the **Chorus Pro (public-sector)** mapping — _what_ document is deposited and by _whom_ — carried over for B2G, **not** part of the B2B reform's cas d'usage. The most common: Cadre| Meaning ---|--- `A1`| Dépôt par un fournisseur d'une facture (à régler ou avoir) — the standard case, the vast majority. `A2`| Dépôt d'une facture déjà payée (e.g. carte d'achat). `A3`| Dépôt d'un mémoire de frais de justice. `A4` / `A5` / `A7` / `A8`| Works contracts: projet de décompte mensuel (A4), état d'acompte (A5), projet de décompte final (A7), décompte général & définitif signé (A8). `A9` / `A10`| Demande de paiement d'un sous-traitant (A10 = marchés de travaux). `A12`| Facture / demande de paiement d'un cotraitant, validée par le mandataire. `A13`–`A25`| Further works décomptes by cotraitant, MOE (maîtrise d'œuvre) or MOA (maîtrise d'ouvrage). _(No`A11` or `A21` exist in the transmission table.)_ ## How Flowie models them The through-line: **you never send a case number.** You send well-formed structured data and Flowie produces the compliant flow. The building blocks that cover the 45 cases: Mechanism| Covers| API ---|---|--- Document type (invoice / credit note)| Avoir, notes de débit (18)| [`POST /v1/documents/send`](<../../reference/index.html#send-document>) Structured fields & VAT categories| Reverse charge, margin VAT (33), détaxe (42), acompte (20)| Invoice body on send Document links| Deposit↔final (20/21), corrective↔original, factoring (10)| [`POST …/actions {"action":"link"}`](<../../reference/index.html#document-actions>) Party roles & payee| Tiers payeurs (2–17), self-billing (19), marketplaces (39)| Parties on the invoice body Lifecycle statuses| Partial collection (34), instalments (32)| [Lifecycle cheat-sheet]() E-reporting path| B2C (27/28), international (43/44)| Reported as data — not the PA invoice flow Accuracy & version note The normative source is **AFNOR XP Z12-014, Annexe A** (the norm text is on the AFNOR boutique; the annexes are public via FNFE-MPE and referenced from the DGFiP _Spécifications externes B2B_). This page reflects **v1.4 (2026-06-30, 45 cases)**. The count and titles evolve between versions — always confirm against the current annex for a specific case before building to it, and treat the theme grouping here as navigational, not normative. ## References — public sources * [DGFiP · Spécifications externes B2B]() — the official hub linking XP Z12-012 / 013 / 014 and their annexes. * [DGFiP actualité]() — official publication of the dossier des cas d'usage (AFNOR commission). * [AFNOR · XP Z12-014]() — the normative standard, "B2B use cases applicable within the framework of the electronic invoice reform". * [FNFE-MPE]() — publishes the XP Z12-014 _Annexe A_ (cas d'usage) and the Z12-012/013 annexes and Schematrons. * [France overview · use cases summary]() · [Lifecycle explorer]() · [Integration playbook]().