--- title: "France · UBL generator for every e-invoice business case" description: "Generate a compliant French e-invoice for every business case of the reform — all 45 cas d" canonical: "https://docs.get-flowie.com/compliance/fr/ubl-generator" source: "https://docs.get-flowie.com/compliance/fr/ubl-generator.html" --- # France · UBL generator for every e-invoice business case Compliance · 🇫🇷 France # UBL generator — every French business case, as a document you can run The reform gives you a list of business situations an invoice can encode — the [**cas d'usage** of XP Z12-014]() — and a spreadsheet of fields. What it does not give you is _a compliant invoice for each one_. So the first time you build a deposit invoice, a factored invoice or a self-billed invoice, you find out whether you got it right by having it rejected. This page closes that gap. Pick a business situation, read what is actually happening in it and why the reform treats it as its own case, and take away the **EN 16931 UBL 2.1 XML** and the exact [`POST /v1/documents/send`](<../../reference/index.html#send-document>) call that produces it. **59 scenarios** , covering **all 45 numbered cas d'usage** plus the nine foundations every French integration needs on day one. **59** scenarios **45** cas d'usage covered **UBL 2.1** EN 16931 syntax **FNFE v1.3.0** schematrons validated ## Why a generator and not just a field list A French e-invoice is not one document with optional extras. The same €10,000 of work produces a materially different document depending on whether it is a deposit, a final invoice netting that deposit, a self-billed invoice, a factored one or a subcontractor's reverse-charged one — different type code, different _cadre de facturation_ , different parties, different VAT category, different lifecycle. Each of those choices has a legal consequence, and each has a rule that rejects you for getting it wrong. Three things go wrong most often, and all three are business decisions before they are technical ones: Wrong document, right data A deposit sent as an ordinary invoice (type `380` instead of `386`) reports the VAT in the wrong period and double-counts the revenue when the final invoice lands. [See case 20](<#generator>). Right parties, wrong roles When a factor, a payer or a billing agent is involved, moving them into the seller or buyer block moves the VAT liability with them. The payee is its own party for a reason. [See case 10](<#generator>). Missing the French mentions [BR-FR-05](<#mentions>) requires three legal mentions on _every_ French invoice. Most ERPs built for EN 16931 elsewhere omit all three, and every invoice fails. [See the baseline](<#generator>). ## How to use it 1. **Find your situation.** Filter by theme, or search for what you are actually doing — "deposit", "factoring", "self-billing", "reverse charge", "Réunion". 2. **Read the business description.** What happens, why the reform cares, what goes wrong, and which fields carry it. If that section doesn't match your situation, you have the wrong case — keep looking before you write code. 3. **Take the artefacts.** The UBL XML to validate against, and the send request to fire. Both are already compliant, so a diff against your own output is a list of exactly what you are missing. These samples are checked, not asserted Every scenario on this page was run through the official FNFE **XP Z12-012 v1.3.0** schematrons — XSD, then the EN 16931 profile rules, then the French `BR-FR` rules — plus the complementary CIUS-FR field checks. All of them pass, except one that [deliberately does not](<#validate>), because a B2C receipt is not an e-invoice. ## The generator Simple All business cases59 Your parties and your lines — the reform's part is worked out for you and **explained** : the type code, the _cadre de facturation_ , the tax point, the VAT category with its exemption reason, and the three legal mentions French law requires. Nine out of ten French invoices are this, not one of the 45 numbered cases. Seller — you Legal name BT-27 SIRET BT-34 / BT-30 VAT number BT-31 Legal form & share capital BT-33 Street BT-35 Postal code BT-38 City IBAN BT-84 Buyer — your customer Legal name BT-44 SIRET BT-49 / BT-47 VAT number BT-48 Street BT-38 Postal code BT-40 City What you sold Description| Qty| Unit price | VAT %| Kind| ---|---|---|---|---|--- \+ Add a line The invoice Invoice number BT-1 Document BT-3 Invoice Credit note VAT situation BT-151 Standard French VAT Reverse charge — construction subcontracting Franchise en base Intra-community supply Export outside the EU Issue date BT-2 Due date BT-9 Deliver-to country BT-80 Already paid TVA sur les débits Advanced fields Advanced Currency BT-5 Buyer reference BT-10 Purchase order BT-13 Already paid amount BT-113 BIC BT-86 Payment terms BT-20 Corrects invoice BT-25 …issued on BT-26 Note BT-22 Everything here is optional. The three legal mentions, the cadre, the tax point and the VAT reason are still worked out for you — these only add what the reform lets you state on top. Generate the invoice Loading the referential… Pick a business case on the left. ## The _cadre de facturation_ — the most business-shaped field on the invoice Every French e-invoice declares what kind of transaction it is, in one code (`BT-23`, carried in `cbc:ProfileID`). The first letter says **B** iens (goods), **S** ervices or **M** ixte; the digit says what kind of situation. It is the reform's own answer to "what am I looking at?", and it drives the rules that apply — which is why the generator sets it per scenario rather than defaulting everything to `S1`. Code| What it means in business terms ---|--- Loading… Source: `BR-FR-08`. Sending an invoice with no cadre, or with a cadre that contradicts the tax point (`BT-8`), is the quiet mismatch that puts the VAT in the wrong CA3 period on both sides. ## Invoice types — and why "just send 380" breaks France accepts a closed list of document types (`BT-3`, `BR-FR-04`). Anything else in UNTDID 1001 is rejected. The list is short but load-bearing: it is what tells everyone downstream that a document is a deposit, a self-billed invoice, a factored one or a correction — before anybody reads a single amount. Code| What it is ---|--- Loading… ## The three mentions every French invoice must carry `BR-FR-05` requires at least three notes, each tagged with a subject code (`BT-21`), on _every_ French invoice. They are legal mentions from the Code de commerce, not formatting — and they are the single most common reason an otherwise-correct EN 16931 invoice fails in France, because ERPs built for other markets have no field for them. [code] #PMT#Indemnité forfaitaire pour frais de recouvrement en cas de retard de paiement : 40 EUR (art. L441-10 du Code de commerce). #PMD#Pénalités de retard : trois fois le taux d'intérêt légal, exigibles le jour suivant la date d'échéance. #AAB#Escompte pour paiement anticipé : néant. #BAR#B2B [/code] In UBL the subject code and the text share one `cbc:Note`, with the code carried as a `#CODE#` prefix. The fourth note above is not required by `BR-FR-05` but matters just as much: `BAR` declares which side of the reform the document belongs to (`BR-FR-20`). Subject code| What it carries ---|--- Loading… ## VAT — the categories France accepts, and when VAT becomes due France narrows EN 16931's VAT category list (`BR-FR-15`) and fixes the accepted rates (`BR-FR-16`). Every category other than `S` and `Z` needs a reason and a `VATEX` code — an invoice that charges no VAT without saying why is rejected, and rightly so: the reason is what makes the exemption defensible in an audit. Category| When you use it| Typical VATEX code ---|---|--- `S`| Standard taxable supply — 20%, 10%, 5.5% or 2.1%.| — `AE`| Autoliquidation — the buyer accounts for the VAT. Construction subcontracting, and most B2B services from abroad.| `VATEX-FR-AE` `E`| Exempt — franchise en base, medical and training exemptions, margin scheme, disbursements.| `VATEX-FR-FRANCHISE`, `VATEX-EU-79-C` `K`| Intra-community supply — goods leaving France for another member state.| `VATEX-EU-IC` `G`| Export outside the EU — including the DROM, which are outside the EU VAT territory.| `VATEX-EU-G` `O`| Outside the scope of VAT. Boxed in hard: it cannot share an invoice with any other category (`BR-O-11`) and forbids the seller's VAT number (`BR-O-02`).| `VATEX-EU-O` ### When the VAT becomes chargeable (`BT-8`) This one code decides which VAT return period the invoice lands in, for both parties. Goods are taxable on delivery; services on collection, unless the seller has opted for _TVA sur les débits_. Getting it wrong doesn't fail validation — it just puts the VAT in the wrong month. Code| Meaning ---|--- Loading… ## Use it from the API The same catalogue is served by the API, so you can wire it into your own test suite rather than copying XML out of a browser. The catalogue and the generator need **no API key** — they are pure functions with no access to anyone's data. ### List every business case [code] curl https://back.flowie.ink/exchange/v1/tools/fr/ubl/scenarios [/code] Filter with `?theme=`, `?family=`, `?channel=e-reporting`, `?case=20`, or search the business descriptions with `?q=factoring`. ### Generate a case with your own parties [code] curl -X POST https://back.flowie.ink/exchange/v1/tools/fr/ubl/generate \ -H "Content-Type: application/json" \ -d '{ "scenarioId": "uc-21-final-after-deposit", "number": "FA-2027-0042", "issueDate": "2027-03-01", "seller": { "name": "Ma Société SAS", "siret": "55210055400013" }, "buyer": { "name": "Mon Client SA", "siret": "39158000400021" } }' [/code] The response carries the business description, the invoice model, the UBL XML, the computed totals, and the `POST /v1/documents/send` body that sends it. Identifier _schemes_ stay fixed, so an override can never produce a party whose SIRET and SIREN disagree (`BR-FR-09`). ### Generate and validate in one call [code] curl -X POST https://back.flowie.ink/exchange/v1/tools/fr/ubl/generate-and-validate \ -H "Authorization: Bearer $KEY" \ -H "Content-Type: application/json" \ -d '{ "scenarioId": "uc-10-factoring" }' [/code] This one needs a key, because it calls the schematron service on your behalf. Use it as the reference answer when your own output for the same case is rejected: generate the scenario, validate both, and diff. To validate an invoice you built yourself, use [`POST /v1/documents/validate`](<../../reference/index.html#validate-document>). ## What "valid" means here Each generated document goes through the same four gates a real invoice does: 1. **XSD** — is it structurally a UBL 2.1 invoice? UBL is sequence-typed, so an element in the wrong order fails here, before a single business rule runs. 2. **EN 16931 profile schematron** — do the totals add up (`BR-CO-*`), does every exempt line give a reason, is each VAT breakdown consistent? 3. **BR-FR rules** — the French layer: the legal mentions, the closed type-code and cadre lists, SIRET/SIREN consistency, the accepted VAT rates. 4. **CIUS-FR field checks** — the fields France makes legally mandatory that EN 16931 leaves optional: the tax point code, the due date, the seller's legal form and share capital, the buyer's SIREN and routing address. One scenario fails on purpose The B2C restaurant receipt (`uc-28-restaurant-receipts`) does not pass e-invoice validation, and cannot: a consumer has no SIREN and no routing address, both of which France makes legally mandatory on an e-invoice. A B2C sale belongs to **e-reporting** — you transmit transaction data to the DGFiP, you do not exchange a structured invoice. The generator still renders the document, because that record is what feeds your e-reporting; it just marks `validatesAsEInvoice: false` rather than pretending. Confusing the two channels is the most common structural mistake in French implementations. ## What the generator does not do * **It does not check your data against the annuaire.** `BR-FR-10` and `BR-FR-11` require the seller's and buyer's SIREN to be present and active in the PPF directory. That is a live lookup — see [routing & the annuaire](). * **It does not emit lifecycle statuses.** Each scenario lists the 200–213 statuses it drives, but emitting them is your integration's job — see the [lifecycle explorer]() and the [integration playbook](). * **It does not produce Factur-X.** The samples are UBL. Flowie generates Factur-X from the same data on send; if you need the CII syntax, [send with `format: "cii-xml"`](<../../reference/index.html#send-document>). * **The multi-seller cases are a starting shape, not a finished answer.** Cadres `S8`/`B8`/`M8` turn on a whole extra rule family (`BR-FR-MV-01` to `BR-FR-MV-12`) with per-line seller identifiers and grouping lines. Validate before you build on them. ## References * [The 45 cas d'usage, in full]() — the referential this generator implements, with the deep dives per theme. * [France · PPF & PA overview]() — deadlines, required fields, routing, e-reporting. * [Lifecycle explorer]() — statuses 200–213, who owes which. * [Integration playbook]() — onboard, send, e-report, go live. * [Document types](<../../reference/document-types.html>) — every type Flowie sends, plus self-billing. * [FNFE-MPE]() — the association that publishes the French CIUS and the schematrons. * [impots.gouv.fr · facturation électronique]() — the DGFiP's own reference pages and the _Spécifications externes B2B_.