France, 1 September 2026: what the mandate actually asks of you

France is moving B2B invoicing onto structured electronic formats, and the first binding date is weeks away. The reform is usually described as one deadline, which is where most of the confusion starts. It is really three obligations with different scopes, and only one of them applies to everybody at once.

Three obligations, not one

Receiving applies to everyone on the first date, whatever your size. From September your systems have to accept a structured invoice from any supplier and do something sensible with it. There is no small-business grace period here, because this obligation is the mirror image of a large supplier’s duty to issue.

Issuing is phased by company size. Large and mid-size companies first, the rest a year later.

E-reporting is the one that gets left out of summaries, and it catches people. Alongside issuance, in-scope companies transmit transaction data to the tax authority for the flows that structured B2B invoicing does not cover: sales to consumers, and cross-border transactions. It runs on the same clock as issuance, so if you are in scope for one you are in scope for both.

How an invoice actually travels

Invoices do not move directly between trading partners, and they do not move through a free government portal either. They move through an accredited platform: a Plateforme Agréée (PA), the term that officially replaced Plateforme de Dématérialisation Partenaire (PDP) in the 2025 specification revisions and became law in February 2026. If you are reading vendor material that still says PDP, it predates that change.

Your platform validates the invoice, converts between the accepted formats when the two sides differ, transmits it to your counterparty’s platform, and reports the required data onward. The public portal keeps the central directory that records which platform a given company receives on, which makes registration there a prerequisite rather than a formality.

The practical consequence: choosing a platform is a procurement decision with a lead time, and it is separate from the question of whether your software can produce a compliant file.

Three formats, one semantic model

The reform accepts three formats, and every accredited platform has to handle all three:

• Factur-X, a PDF/A-3 that carries a structured XML invoice inside it
• UBL, pure XML in the OASIS syntax
• CII, pure XML in the UN/CEFACT syntax

They are not three different invoices. All three express the same EN 16931 semantic model, which is why a platform can convert between them without asking you anything. Picking one is a question of what the rest of your stack prefers, not of what is more compliant.

Where Factur-X fits

Factur-X is the hybrid. One file, two readers: a page the person approving the invoice can look at, and an embedded XML payload the booking system can post without retyping. For French B2B that combination is usually the path of least resistance, because it survives contact with the humans in the approval chain who were never going to open a UBL file.

The trade-off is that the two halves can disagree. A total rendered on the page that does not match the total in the XML is a valid PDF and an invalid invoice. That is a validation problem, and it is the part worth automating.

Generating a compliant file

You send invoice data. Beliq returns a PDF/A-3 with EN 16931 XML embedded, with the schema and business rules already checked against a pinned ruleset.

curl -X POST https://api.beliq.eu/v1/generate \
  -H "Authorization: Bearer $BELIQ_KEY" \
  -H "Content-Type: application/json" \
  --output invoice.pdf \
  -d '{
    "standard": "facturx",
    "profile":  "en16931",
    "output":   "pdf",
    "invoice": {
      "number":         "INV-2026-00481",
      "issueDate":      "2026-09-01",
      "currencyCode":   "EUR",
      "buyerReference": "FR-PO-4471",
      "seller": {
        "name":    "Beliq Example SARL",
        "vatId":   "FR40123456789",
        "address": { "street": "10 rue de Rivoli", "city": "Paris", "postalCode": "75001", "countryCode": "FR" }
      },
      "buyer": {
        "name":    "Client Exemple SAS",
        "vatId":   "FR55810365091",
        "address": { "street": "5 avenue de Lyon", "city": "Lyon", "postalCode": "69002", "countryCode": "FR" }
      },
      "lines": [
        {
          "description":     "SDK Pro licence",
          "quantity":        1,
          "unitCode":        "C62",
          "unitPrice":       990.00,
          "lineTotal":       990.00,
          "vatRate":         20,
          "vatCategoryCode": "S"
        }
      ],
      "taxSummary": [
        { "vatCategoryCode": "S", "vatRate": 20, "taxableAmount": 990.00, "taxAmount": 198.00 }
      ],
      "totalNetAmount":   990.00,
      "totalTaxAmount":   198.00,
      "totalGrossAmount": 1188.00
    }
  }'

taxSummary is the VAT breakdown, and it is not optional in practice: EN 16931 requires a breakdown group per VAT category and rate, so omitting it fails validation even when the document totals add up. The profile field selects how much of the model the file has to carry. en16931 is the sensible default; pick extended-ctc-fr only when your counterparty specifically asks for the French CTC overlay.

The soft landing is not a delay

The DGFiP has signalled tolerance for companies that hit temporary difficulties and can show a genuine, documented compliance effort. That is worth knowing, and it is worth reading carefully.

What Beliq does, and what it does not

Beliq builds and validates the file. You send invoice data, you get back a compliant Factur-X, UBL or CII document, and you get a verdict against the published rules with the ruleset version it checked against recorded in the response.

Beliq does not transmit it. Sending the invoice to your counterparty goes through your accredited platform, and Beliq is not one. That separation is deliberate. Your platform choice carries accreditation, contracts and connectivity that should not be bundled into the tool that gets the file right, and swapping platforms should not mean rewriting how your invoices are built.

Where to start

1. Check your scope. Everyone receives from September 2026. Whether you also issue and report depends on your size classification, so establish which tier you fall into before anything else.
2. Pick an accredited platform and register in the directory. This has the longest lead time of anything on the list, and nothing else can be tested end to end until it is done.
3. Decide which format you produce. Factur-X if humans are in your approval chain, UBL or CII if the exchange is machine to machine.
4. Validate before you are obliged to. A file your own system accepts is not the same as a file that passes EN 16931 and the French rules. That gap is cheap to find in August and expensive to find in September.

If you want to see where your current output stands, run one invoice through /v1/validate and read the verdict.