Executive Overview — France PPF 2026
The operational guide for finance, tax, IT and ERP teams delivering France PPF compliance. Structured for practitioners — not introductory reading.
From 1 September 2026, every domestic B2B invoice involving a French-established entity must flow through a government-certified Plateforme Agréée in structured XML format. PDF invoices by email are no longer legally valid. The mandate is confirmed — the National Assembly rejected a postponement in April 2025.
€15 per non-compliant invoice, capped at €15,000/year. €250 per missing e-report, same cap. DGFiP Director confirmed no automatic day-one penalties for good-faith efforts — but the legal obligation and audit risk begin 1 September 2026.
Select and contract a certified PA. Assign a PPF compliance owner. Approve ERP integration budget. All require CFO or board authorisation.
12–20 weeks for complex ERP environments. 6–10 weeks for simpler setups. Companies starting in Q3 2026 are on a very compressed schedule.
Master data (SIRET gaps). Lifecycle status management. PA selected without ERP compatibility verified. Budget approved too late to test properly.
Calibrate your current state honestly before working through this workbook. Most organisations engaging for the first time are at Level 2.
The most frequent and costly error. A PA was selected based on commercial relationships. Integration revealed the connector was certified for S/4HANA, not ECC 6.0. Added 8–12 weeks to the timeline. Mitigation: require written confirmation of ERP version compatibility before shortlisting any PA.
Lifecycle status obligation — Paiement transmis and Paiement reçu — requires a data flow from treasury back through the PA. Discovered 6 weeks before go-live. For TVA sur encaissements entities, created direct VAT compliance risk. Mitigation: payments team must be in the project from week one.
Team assumed clean SIRET data from onboarding. Audit revealed 28% of French customer records had missing or invalid SIRETs. Data collection took 6 weeks. Mitigation: run the SIRET completeness audit in week one, not month three.
Project scope defined as "e-invoicing." E-reporting was TBD. The B2C reporting pipeline was not built until after e-invoicing go-live. Mitigation: e-reporting must be in scope from project initiation with its own workstream and owner.
UAT covered the standard invoice and passed. Production revealed failures on credit notes, advance payment invoices, and zero-rated invoices. First month spent in exception management. Mitigation: UAT must cover every invoice type in your transaction profile.
Project team disbanded after go-live. A DGFiP query arrived 8 weeks later with a 10-day response window. Response was late. Mitigation: appoint a named PPF compliance owner before go-live with formal ongoing responsibilities documented.
| Company type | Must receive | Must issue | E-reporting |
|---|---|---|---|
| Large enterprises (GE) — ≥5,000 employees or >€1.5B turnover | 1 Sep 2026 | 1 Sep 2026 | 1 Sep 2026 |
| Mid-size enterprises (ETI) — 250–5,000 employees or €50M–€1.5B | 1 Sep 2026 | 1 Sep 2026 | 1 Sep 2026 |
| SMEs & micro-enterprises — <250 employees or <€50M | 1 Sep 2026 | 1 Sep 2027 | 1 Sep 2027 |
| Foreign companies — French VAT only — no establishment | Not required | Not required | 1 Sep 2027 |
Every company must receive structured e-invoices from 1 September 2026 — regardless of size or issuance deadline. A 15-person SME whose issuance deadline is September 2027 must still receive and process structured invoices from large suppliers from September 2026. This requires PA registration, Annuaire listing, and AP system configuration — all before September 2026.
France uses a decentralised architecture. Every invoice passes through certified Plateformes Agréées at each end, with the PPF as the central directory and DGFiP data concentrator. Click each node to learn more.
Click any node to learn more
Click on any step above to see what happens at that stage of the invoice journey.
| Step | Party | What happens |
|---|---|---|
| 1 | Supplier ERP | Generates structured invoice (Factur-X, UBL, or CII) with all mandatory DGFiP fields. Invoice never goes directly to buyer. |
| 2 | Supplier PA | Validates against AFNOR XP Z12-014 and DGFiP G1/G6 rules. Routes to buyer PA via PPF Annuaire. Reports to DGFiP concentrator. |
| 3 | PPF | Central directory — maps every French entity to their registered PA. Acts as DGFiP data hub. Does not transmit invoices directly. |
| 4 | Buyer PA | Receives invoice, makes it available to buyer AP system, manages return of all lifecycle statuses including payment statuses. |
| 5 | Buyer ERP | AP system receives structured invoice, processes it, and sends lifecycle statuses back through the buyer PA including payment events. |
Legal Framework — What the Law Actually Requires
France's mandate is grounded in Article 153 of the Loi de Finances 2020, refined through Décret n°2022-1299, AFNOR XP Z12-014 (May 2025), and DGFiP External Specification v3.1. This chapter covers what the law requires — not what vendors say it requires.
| Date | Event | Impact |
|---|---|---|
| 2020 | Article 153, Loi de Finances 2020 | Legal mandate created |
| Oct 2024 | PPF scope reduced — no longer transmits invoices | All invoices must go via PA. PPF = Annuaire + concentrator only. |
| Apr 2025 | National Assembly rejects postponement | 1 September 2026 confirmed definitively |
| May 2025 | AFNOR XP Z12-014 published | Minimum technical standard for formats, profiles, statuses, business rules |
| Jul 2025 | PDP officially renamed PA (Plateforme Agréée) | Terminology change only — same function |
| 1 Sep 2026 | Phase 1 mandatory start | All companies must receive. Large & ETI must issue. |
| 1 Sep 2027 | Phase 2 — SMEs and micro-enterprises | All companies must issue e-invoices |
Seller SIRET — 14-digit establishment identifier. Not the SIREN (9 digits). Buyer SIRET — same requirement, registered in the PPF Annuaire. Seller VAT number — FR + 11 digits, active and valid at invoice date. Buyer VAT number — EU VAT number for intra-EU transactions. Legal names and addresses — as registered with the Registre du Commerce.
Invoice number — sequential, unique per series. Invoice type code — 380 (standard), 381 (credit note), 384 (corrected), 386 (prepayment), 389 (self-billing). Invoice date — ISO 8601 (YYYY-MM-DD). Currency code — ISO 4217. Transaction category — domestic B2B, intra-EU supply, export, self-billing, or other DGFiP flags.
VAT rate per line — 20%, 10%, 5.5%, 2.1%, or 0% per line. VAT amount per rate — total VAT for each rate applied. Total excl. VAT, total VAT, total incl. VAT. VAT exemption reason — if zero-rated or exempt, the legal basis must be stated (e.g. Article 293B).
Payment terms — due date and conditions. Maximum 60 days under LME. Payment method code — virement, prélèvement, chèque, carte etc. Bank account IBAN and BIC — required for bank transfer invoices. Late payment interest rate and €40 recovery fee — mandatory legal mention on every B2B invoice, required in structured data from September 2026.
Description of goods or services — specific enough to identify the supply. Quantity and unit of measure. Unit price excl. VAT. Discounts and allowances — per line.
| Status | Meaning | Sent by | Timeframe |
|---|---|---|---|
| Déposée | Invoice deposited on supplier PA | Supplier PA | Automatic on submission |
| Envoyée | Transmitted to buyer PA | Supplier PA | Automatic on routing |
| Mise à disposition | Available to buyer | Buyer PA | Automatic on receipt |
| Rejetée | Rejected — format/content error | Buyer via PA | On decision |
| Refusée | Refused — commercial dispute | Buyer via PA | On decision |
| Approuvée | Approved for payment | Buyer via PA | On approval |
| Paiement transmis | Payment initiated | Buyer via PA | On payment run |
| Paiement reçu | Payment confirmed received | Supplier via PA | On bank confirmation |
| Comptabilisée | Posted in buyer accounts | Buyer via PA | On ERP posting |
The DGFiP uses lifecycle statuses to validate VAT declarations — particularly payment statuses for companies on TVA sur les encaissements. Failure to send payment statuses creates discrepancies between DGFiP data and your VAT filings. This is a direct audit risk, not an operational nicety.
PA Architecture — Choosing and Connecting Your Platform
Every company subject to the mandate must use a certified Plateforme Agréée. This chapter covers what a PA must do, how to evaluate one using a weighted scorecard, and how to complete Annuaire registration.
The PA must validate incoming invoices against the XSD schema (structural), Schematron business rules (BR-FR from AFNOR spec), and DGFiP G1/G6 validation rules. It must convert between accepted formats — Factur-X, UBL 2.1, and CII — on behalf of the sender or receiver.
The PA must look up the buyer's registered PA in the PPF Annuaire using the buyer's SIRET, then route the invoice to that PA. If buyer and seller are on different PAs, the two PAs must interoperate — a requirement enforced through the PPF interoperability framework.
The PA must transmit all mandatory lifecycle statuses between buyer and seller PAs, and report relevant statuses to the DGFiP via the PPF concentrator — including both invoice statuses and payment statuses used by the DGFiP for VAT validation.
For transactions not covered by e-invoicing (B2C, exports, cross-border services), the PA must transmit e-reporting data to the DGFiP via the PPF within the required timeframe. This is a separate obligation from e-invoicing and requires a separate data flow from your ERP to the PA.
The PA must ensure integrity and traceability of all invoices — no alteration after transmission is possible. Many PAs offer 10-year certified archiving as an additional service. Confirm what is included in your contract and verify the retrieval SLA for tax audit scenarios.
Score each criterion 1–5 and multiply by the weight. A total above 300 indicates a strong candidate. Require all PAs to respond in writing.
| Criterion | Weight | What to verify | Score (1–5) | Weighted |
|---|---|---|---|---|
| DGFiP certification status | ×5 | Full certification (not provisional). Confirm on official DGFiP list. Ask for certificate number. | ___ | ___ |
| ERP version compatibility | ×5 | Written confirmation for your exact ERP version — not "we support SAP." | ___ | ___ |
| Format support | ×4 | Native Factur-X, UBL 2.1, and CII. Current schema version. Conversion capability. | ___ | ___ |
| Lifecycle status management | ×4 | All 9 statuses including payment. API for buyer AP integration. Tested in sandbox. | ___ | ___ |
| E-reporting capability | ×4 | Contract explicitly covers e-reporting. B2C aggregated, cross-border, payment data confirmed. | ___ | ___ |
| Multi-country support | ×3 | Poland KSeF, Belgium PEPPOL, Germany — single platform vs multiple vendors. | ___ | ___ |
| Network reach | ×3 | How many of your top 50 French suppliers are already on their network? | ___ | ___ |
| Sandbox environment | ×3 | Full sandbox available before contract? Matches production behaviour? | ___ | ___ |
| Archiving SLA | ×3 | 10-year compliant archiving. Retrieval SLA for tax audit. Accessible after leaving PA? | ___ | ___ |
| Support SLA | ×3 | Response time for P1 production failure. Named account manager. | ___ | ___ |
| Pricing transparency | ×2 | Per-invoice, per-entity, or flat fee at your exact volume. Annual increase caps. | ___ | ___ |
| Financial stability | ×2 | Audited accounts. PA certification is non-transferable — PA failure means migration. | ___ | ___ |
Criteria marked ×4 or ×5 are non-negotiable. A PA scoring below 3 on any ×5 criterion should be eliminated regardless of total score. Commercial relationships do not override technical fit.
Confirm SIRET for each French entity
The SIRET is a 14-digit number — 9-digit SIREN + 5-digit NIC. Confirm each entity's SIRET at sirene.insee.fr before registration.
Select and contract your PA first
Registration links your SIRET to your PA's routing information. You must have a contracted PA before you can register in the Annuaire.
Register via the PPF portal
Access portail-facturation.dgfip.finances.gouv.fr. Required: SIRET, legal entity name, address, PA identifier, and e-invoicing routing addresses (both provided by your PA).
Confirm routing with your PA
Your PA provides specific routing identifiers to enter in the Annuaire. Verify these are correct — incorrect routing causes 100% of invoices to fail.
Test with a live counterparty
Once registered, test with at least one supplier in the voluntary pilot. Verify that an invoice from their PA reaches your PA correctly and appears in your AP system.
Invoice Formats — Factur-X, UBL, and CII
Three structured formats are accepted under the French mandate. All must conform to EN 16931 and the French socle minimal in AFNOR XP Z12-014. This chapter provides a complete, fully annotated example of each format using the same invoice — €5,000 excl. VAT at 20% — so you can compare field by field.
| Format | Type | Best for | ERP support | Human readable? |
|---|---|---|---|---|
| Factur-X | Hybrid — PDF/A-3 + embedded XML (CII syntax) | Companies transitioning from PDF. Readable in any PDF viewer. | SAP (add-on), Oracle (add-on), Chorus Pro | Yes — PDF layer |
| UBL 2.1 | Pure XML — OASIS standard | Multi-country: PEPPOL, Belgium, Netherlands, Spain. Pan-European default. | SAP, Oracle, D365, NetSuite — native | Machine only |
| UN/CEFACT CII | Pure XML — UN standard (same syntax as Factur-X XML) | German entities (XRechnung). SAP-native output. Cross-industry. | SAP native, Oracle, some ERPs default | Machine only |
All three examples below represent the same transaction: Acme France SAS (seller, SIRET 12345678912345) invoices Client SARL (buyer, SIRET 98765432198765) for consulting services — €5,000.00 excl. VAT, 20% VAT = €1,000.00, total €6,000.00. Invoice number INV-2026-00142, dated 1 September 2026, due 30 days.
Factur-X embeds a CII XML file named factur-x.xml inside a PDF/A-3 container. The PDF is the human-readable version; the XML is the machine-readable structured data. Both are legally equivalent. The XML below is the embedded file — it uses UN/CEFACT Cross Industry Invoice (CII) syntax with Factur-X namespaces.
factur-x.xml — complete annotated example (EN16931 profile)
<?xml version="1.0" encoding="UTF-8"?> <rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100" xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100" xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100"> <!-- ① PROFILE — tells the PA which EN16931 profile to validate against --> <rsm:ExchangedDocumentContext> <ram:GuidelineSpecifiedDocumentContextParameter> <ram:ID>urn:factur-x.eu:1p0:en16931</ram:ID> </ram:GuidelineSpecifiedDocumentContextParameter> </rsm:ExchangedDocumentContext> <!-- ② INVOICE HEADER — number, type, date --> <rsm:ExchangedDocument> <ram:ID>INV-2026-00142</ram:ID> <!-- unique invoice number --> <ram:TypeCode>380</ram:TypeCode> <!-- 380=invoice · 381=credit note · 384=correction · 386=prepayment --> <ram:IssueDateTime> <udt:DateTimeString format="102">20260901</udt:DateTimeString> <!-- format 102 = YYYYMMDD --> </ram:IssueDateTime> </rsm:ExchangedDocument> <rsm:SupplyChainTradeTransaction> <!-- ③ LINE ITEM --> <ram:IncludedSupplyChainTradeLineItem> <ram:AssociatedDocumentLineDocument> <ram:LineID>1</ram:LineID> </ram:AssociatedDocumentLineDocument> <ram:SpecifiedTradeProduct> <ram:Name>PPF Implementation Consulting — September 2026</ram:Name> </ram:SpecifiedTradeProduct> <ram:SpecifiedLineTradeAgreement> <ram:NetPriceProductTradePrice> <ram:ChargeAmount>5000.00</ram:ChargeAmount> <!-- unit price excl. VAT --> </ram:NetPriceProductTradePrice> </ram:SpecifiedLineTradeAgreement> <ram:SpecifiedLineTradeDelivery> <ram:BilledQuantity unitCode="HUR">1</ram:BilledQuantity> <!-- unitCode: HUR=hour · DAY=day · C62=unit --> </ram:SpecifiedLineTradeDelivery> <ram:SpecifiedLineTradeSettlement> <ram:ApplicableTradeTax> <ram:TypeCode>VAT</ram:TypeCode> <ram:CategoryCode>S</ram:CategoryCode> <!-- S=standard · E=exempt · AE=reverse charge · Z=zero-rated --> <ram:RateApplicablePercent>20</ram:RateApplicablePercent> </ram:ApplicableTradeTax> <ram:SpecifiedTradeSettlementLineMonetarySummation> <ram:LineTotalAmount>5000.00</ram:LineTotalAmount> <!-- line total excl. VAT --> </ram:SpecifiedTradeSettlementLineMonetarySummation> </ram:SpecifiedLineTradeSettlement> </ram:IncludedSupplyChainTradeLineItem> <!-- ④ TRADE AGREEMENT — seller and buyer --> <ram:ApplicableHeaderTradeAgreement> <ram:SellerTradeParty> <ram:ID schemeID="0002">12345678912345</ram:ID> <!-- SIRET — schemeID 0002 = FR company registry --> <ram:Name>Acme France SAS</ram:Name> <ram:PostalTradeAddress> <ram:LineOne>12 rue de la Paix</ram:LineOne> <ram:PostcodeCode>75001</ram:PostcodeCode> <ram:CityName>Paris</ram:CityName> <ram:CountryID>FR</ram:CountryID> <!-- ISO 3166-1 alpha-2 --> </ram:PostalTradeAddress> <ram:SpecifiedTaxRegistration> <ram:ID schemeID="VA">FR12345678901</ram:ID> <!-- VAT number — schemeID VA --> </ram:SpecifiedTaxRegistration> </ram:SellerTradeParty> <ram:BuyerTradeParty> <ram:ID schemeID="0002">98765432198765</ram:ID> <!-- buyer SIRET --> <ram:Name>Client SARL</ram:Name> <ram:PostalTradeAddress> <ram:LineOne>45 avenue Victor Hugo</ram:LineOne> <ram:PostcodeCode>69001</ram:PostcodeCode> <ram:CityName>Lyon</ram:CityName> <ram:CountryID>FR</ram:CountryID> </ram:PostalTradeAddress> <ram:SpecifiedTaxRegistration> <ram:ID schemeID="VA">FR98765432109</ram:ID> </ram:SpecifiedTaxRegistration> </ram:BuyerTradeParty> </ram:ApplicableHeaderTradeAgreement> <!-- ⑤ DELIVERY --> <ram:ApplicableHeaderTradeDelivery> <ram:ActualDeliverySupplyChainEvent> <ram:OccurrenceDateTime> <udt:DateTimeString format="102">20260901</udt:DateTimeString> </ram:OccurrenceDateTime> </ram:ActualDeliverySupplyChainEvent> </ram:ApplicableHeaderTradeDelivery> <!-- ⑥ SETTLEMENT — VAT, payment terms, totals --> <ram:ApplicableHeaderTradeSettlement> <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode> <!-- ISO 4217 --> <!-- VAT breakdown per rate — mandatory for each applicable rate --> <ram:ApplicableTradeTax> <ram:CalculatedAmount>1000.00</ram:CalculatedAmount> <!-- VAT amount for this rate --> <ram:TypeCode>VAT</ram:TypeCode> <ram:BasisAmount>5000.00</ram:BasisAmount> <!-- taxable base for this rate --> <ram:CategoryCode>S</ram:CategoryCode> <ram:RateApplicablePercent>20</ram:RateApplicablePercent> </ram:ApplicableTradeTax> <!-- Payment terms — mandatory under French commercial law --> <ram:SpecifiedTradePaymentTerms> <ram:Description>30 jours net. Taux des pénalités de retard : 3 fois le taux d'intérêt légal. Indemnité forfaitaire pour frais de recouvrement : 40 EUR.</ram:Description> <ram:DueDateDateTime> <udt:DateTimeString format="102">20261001</udt:DateTimeString> <!-- due date --> </ram:DueDateDateTime> </ram:SpecifiedTradePaymentTerms> <!-- Monetary totals --> <ram:SpecifiedTradeSettlementHeaderMonetarySummation> <ram:LineTotalAmount>5000.00</ram:LineTotalAmount> <!-- sum of line totals excl. VAT --> <ram:TaxBasisTotalAmount>5000.00</ram:TaxBasisTotalAmount> <!-- total taxable base --> <ram:TaxTotalAmount currencyID="EUR">1000.00</ram:TaxTotalAmount> <!-- total VAT --> <ram:GrandTotalAmount>6000.00</ram:GrandTotalAmount> <!-- total incl. VAT --> <ram:DuePayableAmount>6000.00</ram:DuePayableAmount> <!-- amount due — after any prepayments --> </ram:SpecifiedTradeSettlementHeaderMonetarySummation> </ram:ApplicableHeaderTradeSettlement> </rsm:SupplyChainTradeTransaction> </rsm:CrossIndustryInvoice>
The XML above must be embedded in a PDF/A-3 file with the AFRelationship set to Alternative and the file attachment named exactly factur-x.xml. The PDF must be PDF/A-3 compliant — not merely PDF/A-1 or PDF/A-2. Generating this correctly requires a library such as pyfpdf, fpdf2, or Apache PDFBox. Most PA vendors handle the PDF/A-3 embedding automatically once you supply the XML.
UBL 2.1 is the format used in PEPPOL and across most European countries (Belgium, Netherlands, Spain, Denmark, Finland). It is a pure XML format — no PDF layer. If your company operates across multiple EU countries, UBL on PEPPOL BIS Billing 3.0 is the most interoperable choice. France accepts UBL with the customizationID pointing to the PEPPOL billing profile.
invoice.xml — UBL 2.1 complete annotated example (PEPPOL BIS Billing 3.0 / France)
<?xml version="1.0" encoding="UTF-8"?> <Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"> <!-- ① PROFILE IDENTIFICATION --> <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID> <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID> <!-- ② INVOICE HEADER --> <cbc:ID>INV-2026-00142</cbc:ID> <!-- unique invoice number --> <cbc:IssueDate>2026-09-01</cbc:IssueDate> <!-- ISO 8601 date --> <cbc:DueDate>2026-10-01</cbc:DueDate> <!-- payment due date --> <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode> <!-- 380=invoice · 381=credit note · 384=correction --> <cbc:Note>Taux pénalités retard : 3x taux légal. Indemnité recouvrement : 40 EUR.</cbc:Note> <!-- mandatory FR legal mention --> <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode> <!-- ③ SELLER (AccountingSupplierParty) --> <cac:AccountingSupplierParty> <cac:Party> <cbc:EndpointID schemeID="0002">12345678912345</cbc:EndpointID> <!-- SIRET — schemeID 0002 = FR company --> <cac:PartyIdentification> <cbc:ID schemeID="0002">12345678912345</cbc:ID> <!-- SIRET again in PartyIdentification --> </cac:PartyIdentification> <cac:PartyName><cbc:Name>Acme France SAS</cbc:Name></cac:PartyName> <cac:PostalAddress> <cbc:StreetName>12 rue de la Paix</cbc:StreetName> <cbc:CityName>Paris</cbc:CityName> <cbc:PostalZone>75001</cbc:PostalZone> <cac:Country><cbc:IdentificationCode>FR</cbc:IdentificationCode></cac:Country> </cac:PostalAddress> <cac:PartyTaxScheme> <cbc:CompanyID>FR12345678901</cbc:CompanyID> <!-- VAT number --> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:PartyTaxScheme> <cac:PartyLegalEntity> <cbc:RegistrationName>Acme France SAS</cbc:RegistrationName> <cbc:CompanyID schemeID="0002">12345678912345</cbc:CompanyID> <!-- SIRET third time — required in PartyLegalEntity --> </cac:PartyLegalEntity> </cac:Party> </cac:AccountingSupplierParty> <!-- ④ BUYER (AccountingCustomerParty) --> <cac:AccountingCustomerParty> <cac:Party> <cbc:EndpointID schemeID="0002">98765432198765</cbc:EndpointID> <!-- buyer SIRET --> <cac:PartyName><cbc:Name>Client SARL</cbc:Name></cac:PartyName> <cac:PostalAddress> <cbc:StreetName>45 avenue Victor Hugo</cbc:StreetName> <cbc:CityName>Lyon</cbc:CityName> <cbc:PostalZone>69001</cbc:PostalZone> <cac:Country><cbc:IdentificationCode>FR</cbc:IdentificationCode></cac:Country> </cac:PostalAddress> <cac:PartyTaxScheme> <cbc:CompanyID>FR98765432109</cbc:CompanyID> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:PartyTaxScheme> <cac:PartyLegalEntity> <cbc:RegistrationName>Client SARL</cbc:RegistrationName> <cbc:CompanyID schemeID="0002">98765432198765</cbc:CompanyID> </cac:PartyLegalEntity> </cac:Party> </cac:AccountingCustomerParty> <!-- ⑤ PAYMENT MEANS --> <cac:PaymentMeans> <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode> <!-- 30=bank transfer · 49=direct debit · 48=card --> <cac:PayeeFinancialAccount> <cbc:ID>FR7614508320001234567890143</cbc:ID> <!-- IBAN --> <cac:FinancialInstitutionBranch><cbc:ID>BNPAFRPPXXX</cbc:ID></cac:FinancialInstitutionBranch> <!-- BIC --> </cac:PayeeFinancialAccount> </cac:PaymentMeans> <!-- ⑥ VAT TOTAL --> <cac:TaxTotal> <cbc:TaxAmount currencyID="EUR">1000.00</cbc:TaxAmount> <cac:TaxSubtotal> <cbc:TaxableAmount currencyID="EUR">5000.00</cbc:TaxableAmount> <cbc:TaxAmount currencyID="EUR">1000.00</cbc:TaxAmount> <cac:TaxCategory> <cbc:ID>S</cbc:ID> <!-- S=standard · E=exempt · AE=reverse charge --> <cbc:Percent>20</cbc:Percent> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:TaxCategory> </cac:TaxSubtotal> </cac:TaxTotal> <!-- ⑦ MONETARY TOTALS --> <cac:LegalMonetaryTotal> <cbc:LineExtensionAmount currencyID="EUR">5000.00</cbc:LineExtensionAmount> <!-- sum of lines excl. VAT --> <cbc:TaxExclusiveAmount currencyID="EUR">5000.00</cbc:TaxExclusiveAmount> <!-- total excl. VAT --> <cbc:TaxInclusiveAmount currencyID="EUR">6000.00</cbc:TaxInclusiveAmount> <!-- total incl. VAT --> <cbc:PayableAmount currencyID="EUR">6000.00</cbc:PayableAmount> <!-- amount due --> </cac:LegalMonetaryTotal> <!-- ⑧ LINE ITEM --> <cac:InvoiceLine> <cbc:ID>1</cbc:ID> <cbc:InvoicedQuantity unitCode="HUR">1</cbc:InvoicedQuantity> <!-- unitCode: HUR=hour · DAY=day · C62=unit (UN/ECE Rec 20) --> <cbc:LineExtensionAmount currencyID="EUR">5000.00</cbc:LineExtensionAmount> <!-- line total excl. VAT --> <cac:Item> <cbc:Description>PPF Implementation Consulting — September 2026</cbc:Description> <cbc:Name>Consulting Services</cbc:Name> <cac:ClassifiedTaxCategory> <cbc:ID>S</cbc:ID> <cbc:Percent>20</cbc:Percent> <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme> </cac:ClassifiedTaxCategory> </cac:Item> <cac:Price> <cbc:PriceAmount currencyID="EUR">5000.00</cbc:PriceAmount> <!-- unit price excl. VAT --> </cac:Price> </cac:InvoiceLine> </Invoice>
UBL requires the SIRET in EndpointID, PartyIdentification/ID, and PartyLegalEntity/CompanyID — all with schemeID="0002". Missing any one of these three is a common PA validation failure. Your ERP or middleware must populate all three from the same SIRET source field.
CII uses the same namespace and element structure as Factur-X, but is delivered as a standalone XML file — there is no PDF envelope. This is the format used in Germany's XRechnung, and it is what SAP natively generates from its Document Compliance module. Many PA vendors accept CII directly. The structure is identical to Factur-X XML; the difference is the profile ID and the absence of a PDF container.
invoice.xml — UN/CEFACT CII complete annotated example (EN16931)
<?xml version="1.0" encoding="UTF-8"?> <rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100" xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100" xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100"> <!-- ① PROFILE — CII uses urn:cen.eu:en16931:2017 (not the Factur-X urn) --> <rsm:ExchangedDocumentContext> <ram:BusinessProcessSpecifiedDocumentContextParameter> <ram:ID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</ram:ID> </ram:BusinessProcessSpecifiedDocumentContextParameter> <ram:GuidelineSpecifiedDocumentContextParameter> <ram:ID>urn:cen.eu:en16931:2017</ram:ID> <!-- CII profile — different from Factur-X --> </ram:GuidelineSpecifiedDocumentContextParameter> </rsm:ExchangedDocumentContext> <!-- ② INVOICE HEADER --> <rsm:ExchangedDocument> <ram:ID>INV-2026-00142</ram:ID> <ram:TypeCode>380</ram:TypeCode> <ram:IssueDateTime> <udt:DateTimeString format="102">20260901</udt:DateTimeString> </ram:IssueDateTime> <!-- Included note for French mandatory late payment mention --> <ram:IncludedNote> <ram:Content>Pénalités de retard : 3x le taux légal. Indemnité forfaitaire recouvrement : 40 EUR.</ram:Content> </ram:IncludedNote> </rsm:ExchangedDocument> <rsm:SupplyChainTradeTransaction> <!-- ③ LINE ITEM --> <ram:IncludedSupplyChainTradeLineItem> <ram:AssociatedDocumentLineDocument><ram:LineID>1</ram:LineID></ram:AssociatedDocumentLineDocument> <ram:SpecifiedTradeProduct> <ram:Name>PPF Implementation Consulting — September 2026</ram:Name> </ram:SpecifiedTradeProduct> <ram:SpecifiedLineTradeAgreement> <ram:NetPriceProductTradePrice> <ram:ChargeAmount>5000.00</ram:ChargeAmount> </ram:NetPriceProductTradePrice> </ram:SpecifiedLineTradeAgreement> <ram:SpecifiedLineTradeDelivery> <ram:BilledQuantity unitCode="HUR">1</ram:BilledQuantity> </ram:SpecifiedLineTradeDelivery> <ram:SpecifiedLineTradeSettlement> <ram:ApplicableTradeTax> <ram:TypeCode>VAT</ram:TypeCode> <ram:CategoryCode>S</ram:CategoryCode> <ram:RateApplicablePercent>20</ram:RateApplicablePercent> </ram:ApplicableTradeTax> <ram:SpecifiedTradeSettlementLineMonetarySummation> <ram:LineTotalAmount>5000.00</ram:LineTotalAmount> </ram:SpecifiedTradeSettlementLineMonetarySummation> </ram:SpecifiedLineTradeSettlement> </ram:IncludedSupplyChainTradeLineItem> <!-- ④ SELLER and BUYER --> <ram:ApplicableHeaderTradeAgreement> <ram:SellerTradeParty> <ram:ID schemeID="0002">12345678912345</ram:ID> <!-- SIRET --> <ram:Name>Acme France SAS</ram:Name> <ram:SpecifiedLegalOrganization> <ram:ID schemeID="0002">12345678912345</ram:ID> <!-- SIRET in legal org --> </ram:SpecifiedLegalOrganization> <ram:PostalTradeAddress> <ram:LineOne>12 rue de la Paix</ram:LineOne> <ram:PostcodeCode>75001</ram:PostcodeCode> <ram:CityName>Paris</ram:CityName> <ram:CountryID>FR</ram:CountryID> </ram:PostalTradeAddress> <ram:URIUniversalCommunication> <ram:URIID schemeID="0002">12345678912345</ram:URIID> <!-- electronic routing address — SIRET again for PA routing --> </ram:URIUniversalCommunication> <ram:SpecifiedTaxRegistration> <ram:ID schemeID="VA">FR12345678901</ram:ID> <!-- VAT number --> </ram:SpecifiedTaxRegistration> </ram:SellerTradeParty> <ram:BuyerTradeParty> <ram:ID schemeID="0002">98765432198765</ram:ID> <!-- buyer SIRET --> <ram:Name>Client SARL</ram:Name> <ram:SpecifiedLegalOrganization> <ram:ID schemeID="0002">98765432198765</ram:ID> </ram:SpecifiedLegalOrganization> <ram:PostalTradeAddress> <ram:LineOne>45 avenue Victor Hugo</ram:LineOne> <ram:PostcodeCode>69001</ram:PostcodeCode> <ram:CityName>Lyon</ram:CityName> <ram:CountryID>FR</ram:CountryID> </ram:PostalTradeAddress> <ram:URIUniversalCommunication> <ram:URIID schemeID="0002">98765432198765</ram:URIID> <!-- buyer PA routing address --> </ram:URIUniversalCommunication> <ram:SpecifiedTaxRegistration> <ram:ID schemeID="VA">FR98765432109</ram:ID> </ram:SpecifiedTaxRegistration> </ram:BuyerTradeParty> </ram:ApplicableHeaderTradeAgreement> <!-- ⑤ DELIVERY --> <ram:ApplicableHeaderTradeDelivery> <ram:ActualDeliverySupplyChainEvent> <ram:OccurrenceDateTime><udt:DateTimeString format="102">20260901</udt:DateTimeString></ram:OccurrenceDateTime> </ram:ActualDeliverySupplyChainEvent> </ram:ApplicableHeaderTradeDelivery> <!-- ⑥ SETTLEMENT — VAT breakdown, payment, totals --> <ram:ApplicableHeaderTradeSettlement> <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode> <!-- VAT breakdown --> <ram:ApplicableTradeTax> <ram:CalculatedAmount>1000.00</ram:CalculatedAmount> <ram:TypeCode>VAT</ram:TypeCode> <ram:BasisAmount>5000.00</ram:BasisAmount> <ram:CategoryCode>S</ram:CategoryCode> <ram:RateApplicablePercent>20</ram:RateApplicablePercent> </ram:ApplicableTradeTax> <!-- Payment terms — mandatory under French commercial law --> <ram:SpecifiedTradePaymentTerms> <ram:Description>30 jours net. Pénalités : 3x taux légal. Indemnité forfaitaire : 40 EUR.</ram:Description> <ram:DueDateDateTime><udt:DateTimeString format="102">20261001</udt:DateTimeString></ram:DueDateDateTime> </ram:SpecifiedTradePaymentTerms> <!-- Bank details --> <ram:SpecifiedTradeSettlementPaymentMeans> <ram:TypeCode>30</ram:TypeCode> <!-- 30=bank transfer --> <ram:PayeePartyCreditorFinancialAccount> <ram:IBANID>FR7614508320001234567890143</ram:IBANID> </ram:PayeePartyCreditorFinancialAccount> <ram:PayeeSpecifiedCreditorFinancialInstitution> <ram:BICID>BNPAFRPPXXX</ram:BICID> </ram:PayeeSpecifiedCreditorFinancialInstitution> </ram:SpecifiedTradeSettlementPaymentMeans> <!-- Monetary totals --> <ram:SpecifiedTradeSettlementHeaderMonetarySummation> <ram:LineTotalAmount>5000.00</ram:LineTotalAmount> <ram:TaxBasisTotalAmount>5000.00</ram:TaxBasisTotalAmount> <ram:TaxTotalAmount currencyID="EUR">1000.00</ram:TaxTotalAmount> <ram:GrandTotalAmount>6000.00</ram:GrandTotalAmount> <ram:DuePayableAmount>6000.00</ram:DuePayableAmount> </ram:SpecifiedTradeSettlementHeaderMonetarySummation> </ram:ApplicableHeaderTradeSettlement> </rsm:SupplyChainTradeTransaction> </rsm:CrossIndustryInvoice>
The XML syntax is identical. The differences are: (1) Profile URI — CII uses urn:cen.eu:en16931:2017, Factur-X uses urn:factur-x.eu:1p0:en16931. (2) Delivery container — CII is a standalone XML file; Factur-X embeds the same XML inside a PDF/A-3. (3) Routing element — CII uses ram:URIUniversalCommunication/ram:URIID for the electronic routing address (the SIRET for French PA routing), whereas Factur-X commonly omits this in favour of the ram:ID schemeID="0002". Some PAs require both.
| Your situation | Recommended format | Why |
|---|---|---|
| Transitioning from PDF, AP team needs to see invoices | Factur-X | PDF layer readable in any viewer. Same XML as CII underneath. |
| Operating across multiple EU countries (PEPPOL) | UBL 2.1 | Single format for France, Belgium, Netherlands, Spain, Nordics. |
| SAP S/4HANA with Document Compliance | CII | SAP's native output. No transformation required. |
| German parent company using XRechnung | CII | XRechnung is CII with a German profile. Same file, different profile URI. |
| Mid-market system (QuickBooks, Sage, NetSuite) | Factur-X | Easiest to generate via PA connector or middleware. PDF output familiar. |
fnfe-mpe.org/validateur — the FNFE-MPE validator. Validates Factur-X, UBL, and CII against EN 16931 and French business rules (BR-FR). Free, no registration. PPF portal sandbox — portail-facturation.dgfip.finances.gouv.fr — test submission environment. Your PA's sandbox — every certified PA must provide one. Test all 11 UAT scenarios here before production. Validate during development, not just before go-live. A format error found in development costs hours. The same error found in production costs weeks.
ERP Integration — SAP, Oracle, D365
Every PA vendor will say they integrate with your ERP. This chapter covers what that actually means for each major platform, the known gaps, and the mandatory UAT testing protocol before go-live.
Third-party PA connector (recommended)
Most PA vendors provide an SAP ECC-compatible connector — an ABAP add-on intercepting the standard invoice output. Ask: "Do you have a certified connector for SAP ECC 6.0 and which enhancement package versions do you support?"
Middleware layer
An integration middleware (MuleSoft, SAP Integration Suite, Dell Boomi) extracts invoice data from SAP ECC, transforms it to the required format, and sends it to the PA API. More complex but gives vendor independence.
Migrate to S/4HANA
SAP's recommended path. SAP Document Compliance includes France-specific PA integration. But do not delay PPF compliance waiting for S/4HANA — September 2026 will not wait.
Most ECC instances have accumulated customisations since go-live. A PA connector that works in a standard ECC environment may fail against your specific document types, number range configurations, or custom VAT codes. Budget 4–8 weeks for ECC integration testing — not 4–8 days.
| Platform | PPF approach | Effort |
|---|---|---|
| SAP S/4HANA | SAP Document Compliance (DRC) with France content package + PA connector | Medium |
| Oracle Fusion Cloud | Native e-invoicing framework + PA REST API connector | Medium |
| Oracle EBS 12.2 | Middleware (Oracle Integration Cloud or third-party) | High |
| Microsoft D365 Finance | Electronic Reporting (ER) framework + PA connector or Power Automate | Medium-High |
| SAP ECC 6.0 | Third-party PA connector or middleware | High |
The following scenarios must all pass in the PA sandbox before production go-live is approved. Any scenario not tested is a known risk carried into production.
| Test scenario | Invoice type | Key validation | Tested? | Result |
|---|---|---|---|---|
| Standard domestic B2B — single VAT rate | TypeCode 380 | SIRET, VAT amount, PA acceptance, status flow | ||
| Standard domestic B2B — multiple VAT rates | TypeCode 380 | VAT breakdown per rate, line-level assignment, G1/G6 rules | ||
| Credit note referencing original | TypeCode 381 | Original reference, negative amounts, PA routing | ||
| Corrected invoice | TypeCode 384 | Original reference, corrected values, buyer receives correction | ||
| Advance payment invoice | TypeCode 386 | Advance amount, settlement reference | ||
| Zero-rated / VAT exempt | FV with exemption code | VAT category "E", exemption reason code and text | ||
| Reverse charge (autoliquidation) | FV with AE code | VAT category "AE", 0% rate, legal reference | ||
| PA rejection — correction and resubmission | Any | Error code received, correction applied, resubmission succeeds | ||
| Full lifecycle status cycle (AP side) | Any | Received → Approved → Paiement transmis → Paiement reçu | ||
| E-reporting — B2C aggregated daily | E-reporting | Aggregated by VAT rate, correct period, PA accepts | ||
| E-reporting — cross-border supply | E-reporting | Per-transaction, buyer ID, correct period |
Production go-live must not be approved unless all scenarios above have passed in the PA sandbox, PA acceptance confirmations have been received for all test invoices, at least one full lifecycle status cycle has been completed end-to-end, and the rejection handling and resubmission process has been tested and documented.
Accounting Systems — QuickBooks, Sage, NetSuite
Mid-market accounting platforms do not natively support Factur-X or PA API submission. This chapter covers the recommended integration architecture with a detailed QuickBooks Online worked example.
Accounting system → Webhook/API → Transformation middleware → PA API → DGFiP
The middleware extracts invoice data via the accounting system API, transforms it to Factur-X XML, enriches it with SIRET and VAT data, and submits to the PA REST API. PA responses are written back to the accounting system as invoice notes or status tags.
Check if your PA has a connector
Ask your PA: "Do you have a certified QuickBooks Online / Sage / NetSuite connector?" Several certified PAs have connectors through Zapier, Make, or as native app integrations. This is the fastest path — no code required.
Add SIRET as a custom field
Accounting platforms don't have a SIRET field by default. Add it as a custom field on the Customer record ("SIRET Number", text, 14 characters). Populate for every French B2B customer.
Configure submission trigger and field mapping
Set the connector to trigger on invoice approval (not creation). Map: invoice number → XML Invoice ID, customer SIRET → ram:ID schemeID="0002", VAT number → tax registration element, line amounts and VAT rates → line-level fields.
Test in PA sandbox before production
Run 10–20 test invoices through the PA sandbox. Verify: format validation passes, SIRET lookup succeeds in PPF Annuaire, VAT calculation is correct, PA response is received and logged.
QuickBooks Online → Factur-X → PA submission (Python)
# Extract invoice from QBO API GET https://quickbooks.api.intuit.com/v3/company/{realmId}/invoice/{id} Authorization: Bearer {access_token} # Python: transform and submit to PA def qbo_to_facturx_and_submit(qbo_invoice, seller_config, pa_config): siret = next((f['StringValue'] for f in qbo_invoice.get('CustomField', []) if f['Name'] == 'SIRET Number'), None) if not siret or len(siret) != 14: raise ValueError(f"Missing SIRET for invoice {qbo_invoice['Id']}") payload = { "invoiceFormat": "FACTURX_EN16931", "invoiceData": base64.b64encode( generate_facturx_xml(qbo_invoice, seller_config, siret)).decode(), "routing": { "buyerSiret": siret } } response = requests.post( f"{pa_config['api_url']}/invoices", json=payload, headers={"Authorization": f"Bearer {pa_config['api_key']}"} ) return response.json()['invoiceId']
Master Data — SIRET, VAT Numbers, and the Data Debt Problem
Master data quality is the most common cause of e-invoicing go-live failures. A missing or incorrect SIRET causes every invoice to fail at the PA before reaching the buyer. There is no workaround — only correction of the source data.
Run a completeness audit
Export all French customer and supplier records. Count how many have a SIRET. In a typical French B2B customer base, 20–40% of records have SIRET issues. The gap is your remediation scope.
Validate against INSEE SIRENE API
Use api.insee.fr to validate every SIRET in bulk. Check: does it exist? Is it active? Does the name and address match? Companies that have restructured may have a different current SIRET.
Collect missing SIRETs from counterparties
Frame it as: "To comply with the French e-invoicing mandate from 1 September 2026, we require your SIRET to route invoices correctly." Most counterparties respond quickly — this is their compliance problem too.
Verify your entities in the PPF Annuaire
Verify that your own entities are correctly registered and that key customers and suppliers are also registered. An invoice to a buyer not yet in the Annuaire cannot be routed.
Build ongoing governance
Integrate the INSEE SIRENE API into your CRM and procurement onboarding. Validate SIRET at point of record creation. One validation at creation is worth more than ten retroactive cleanses.
SIRET audit completed for all French customers
Completeness report run, validated against INSEE SIRENE API, gaps contacted
SIRET audit completed for all French suppliers
Required for invoice matching and Annuaire routing
VAT numbers validated for all French trading partners
Active validation via VIES (ec.europa.eu/taxation_customs/vies)
All French entities registered in PPF Annuaire
Registration required before any e-invoice can be routed
All mandatory invoice fields mapped in ERP master data
SIRET, VAT number, payment terms, delivery address all populated
SIRET validation built into new customer/supplier onboarding
Prevents future data quality degradation — governance not just cleanse
Master data synchronised across CRM, ERP, and PA systems
Single source of truth for SIRET and VAT data established
Tax Obligations and e-Reporting
The PPF mandate is fundamentally a tax initiative. Tax must own the outcome. This chapter covers e-reporting obligations in full — scope, frequencies, foreign entity rules, payment reporting — plus VAT implications, archiving, and the reconciliation control the DGFiP expects.
E-invoicing replaces the invoice document itself — the structured invoice flows through a PA to the buyer. E-reporting is a data transmission — you send transaction data to the DGFiP via your PA, but no invoice document is exchanged. A company can be subject to e-reporting without being subject to e-invoicing — and most companies are subject to both simultaneously.
| Entity type | E-invoicing? | E-reporting? | From |
|---|---|---|---|
| French-established company | Yes — domestic B2B | Yes — B2C, exports, cross-border | 1 Sep 2026 (GE/ETI) 1 Sep 2027 (SME) |
| Foreign — French fixed establishment | Yes — from establishment | Yes — French-taxable transactions | 1 Sep 2026 (GE/ETI) |
| Foreign — French VAT number only | No | Yes — French-taxable B2B and B2C | 1 Sep 2027 |
| Foreign — OSS/IOSS registered | No | No — OSS/IOSS declarations substitute | N/A |
| No French VAT nexus | No | No | N/A |
French overseas departments (DOM) — Guadeloupe, Martinique, Réunion, Guyane, Mayotte — are within French VAT territory: e-invoicing scope. French overseas collectivities (COM) — French Polynesia, New Caledonia — are outside French VAT territory: e-reporting scope. Misclassifying DOM vs COM is one of the most common scope errors.
| VAT regime | Transaction data | Payment data | Deadlines |
|---|---|---|---|
| Régime réel normal mensuel (monthly filer) | Every 10 days | Monthly | Transaction: by 10th, 20th, last day of month |
| Régime réel normal trimestriel (quarterly filer) | Monthly | Monthly | By last day of following month |
| Régime simplifié (RSI) (annual VAT return) | Monthly | Monthly | By last day of following month |
| Foreign company — French VAT only | Per VAT filing frequency | Monthly where applicable | Aligned with VAT return deadlines |
Monthly VAT filers must submit e-reporting data three times per month. A manual monthly export will not meet this requirement. Your PA must receive transaction data from your ERP or POS system automatically at least every 10 days. If you are a monthly filer and have not built an automated e-reporting feed, this is a critical gap.
Map your transaction flows to obligations
| Flow | Est. monthly volume | Obligation | In scope? |
|---|---|---|---|
| Domestic B2B sales to French companies | E-invoicing via PA | ||
| B2C sales to French consumers | E-reporting (aggregated daily) | ||
| Sales to EU customers (intra-EU) | E-reporting (per transaction) | ||
| Sales to non-EU customers (exports) | E-reporting (simplified) | ||
| Cross-border services to non-French entities | E-reporting (per transaction) | ||
| Intra-EU purchases (reverse charge) | E-reporting as buyer | ||
| Transactions with DOM territories | E-invoicing (French VAT scope) | ||
| Transactions with COM territories | E-reporting (outside French VAT) | ||
| B2G transactions to French public administration | Chorus Pro (unchanged) |
All e-invoices — sent and received — must be archived for 10 years from the invoice date with guaranteed integrity. No modification is possible after archiving.
Archiving is a Tax obligation but routinely left as an IT default. Tax must define the archiving policy, confirm the 10-year retention period, verify the archive solution meets DGFiP integrity requirements, and document the retrieval process for a tax audit. If relying on your PA's archiving service, get the SLA in writing — specifically: what is the retrieval time for a specific invoice in a tax audit scenario? Is the archive accessible after you leave the PA?
If your French entity accounts for VAT on a cash basis, the payment status reporting obligation becomes tax-critical. The moment you report Paiement reçu, you create a VAT liability event the DGFiP can see. Missing or late payment status reporting creates a discrepancy between DGFiP data and your VAT filing — a direct audit trigger. Your PA must receive payment confirmation events from your treasury system automatically.
French commercial law requires that invoices include the late payment interest rate and the flat-rate debt recovery cost (€40). These must appear in the structured invoice data from September 2026 — not only in the PDF rendering. Map them to the ram:SpecifiedTradePaymentTerms field in your ERP configuration.
Reverse charge invoices must carry VAT category code "AE" with 0% rate and the legal reference (e.g. "Article 283-2 du CGI"). ERP tax code configurations rarely map cleanly to EN 16931 category codes without explicit work. Validation errors on reverse charge invoices are among the most common failures in PA testing.
France has four non-zero VAT rates: 20% (standard), 10% (intermediate), 5.5% (reduced), 2.1% (super-reduced). EN 16931 requires a separate VAT breakdown section per rate, and a separate line-level rate on every invoice line. Mixed-rate invoices with incorrectly aggregated VAT will pass schema validation but fail DGFiP G1/G6 business rule validation — a category of error only found in PA testing.
Administrative Requirements and Governance
Compliance is not a project — it is an ongoing state. This chapter covers the RACI matrix, administrative obligations, governance structures, supplier communication template, and the ongoing monitoring calendar.
R = Responsible (does the work) · A = Accountable (owns the outcome) · C = Consulted · I = Informed · Every row must have exactly one A.
| Activity | CFO | Tax | Finance/AP | IT | Procurement | Payments |
|---|---|---|---|---|---|---|
| PA selection and contract | A | C | C | R | C | I |
| PPF Annuaire registration | I | A/R | C | R | I | I |
| ERP integration design | I | C | C | A/R | I | C |
| SIRET master data audit | I | C | A/R | R | R | I |
| Invoice format configuration | I | C | C | A/R | I | I |
| Lifecycle status management | I | C | A/R | R | I | R |
| Payment status e-reporting | I | A | C | R | I | R |
| E-reporting pipeline | I | A | C | R | I | C |
| UAT sign-off (Go/No-Go) | A | R | R | R | I | R |
| Supplier communication | I | C | A/R | I | R | I |
| Archiving policy and SLA | I | A/R | C | R | I | I |
| DPA with PA (GDPR) | A | C | I | C | R | I |
| Ongoing compliance monitoring | I | A/R | R | R | I | R |
| DGFiP query response | A | R | C | C | I | I |
| Staff training | I | C | A/R | C | I | R |
| Specification updates (PPF Ext. Spec) | I | A | I | R | I | I |
Appoint a PPF Compliance Owner
Named individual in Tax or Finance with formal ongoing responsibility: monitoring PA performance, Annuaire maintenance, DGFiP queries, specification updates, staff training. Cannot be shared informally across teams.
Sign PA Data Processing Agreement (DPA)
Your PA processes personal and commercial data under GDPR. A DPA must be in place before processing begins. Confirm: data location (EU/France preferred), retention limits, and your right to audit.
Update T&Cs and contract templates
Commercial terms should reference e-invoicing: invoices issued in structured format via a certified PA, PDF invoices not accepted for B2B post-mandate, lifecycle status responses are part of the contractual process.
Train all teams that touch invoices
AP, AR, Tax, Payments, IT. Training is not a one-off — repeat for new staff and update as specifications evolve. Document the new process in writing before go-live.
Establish monthly compliance review
Monthly: PA rejection rates, unresolved exceptions, e-reporting status, archiving completeness, DGFiP communications. Present to CFO. Under a regime where DGFiP has real-time data, compliance monitoring must be a standing agenda item.
Template — notify French suppliers of e-invoicing requirements
Subject: France e-invoicing mandate — required changes from 1 September 2026
Dear [Supplier name],
France's mandatory B2B e-invoicing reform comes into effect from 1 September 2026. From this date, invoices must be transmitted through a government-certified Plateforme Agréée in structured format (Factur-X, UBL, or CII).
To ensure uninterrupted invoice processing, we require:
1. Your SIRET number (14-digit establishment identifier)
2. The name of your certified PA (Plateforme Agréée)
3. Confirmation of your planned go-live date
Our entity details: Company: [Your entity name] · SIRET: [Your SIRET] · PA: [Your PA name]
Please provide the above by [date]. PDF invoices sent by email will not be accepted as legally valid after your mandate date.
Kind regards, [Your name]
| Frequency | Task | Owner |
|---|---|---|
| Daily | Monitor PA rejection rate. Escalate if above 2% of daily volume. | AP / IT |
| Weekly | Review unresolved exceptions. Confirm e-reporting submissions on schedule. | AP Manager |
| Monthly | PA performance review. VAT filing vs PA data reconciliation. DGFiP correspondence. Archiving completeness. | Tax / Finance |
| Quarterly | Master data audit — SIRET and VAT re-validation. PA contract review. PPF External Spec updates. | Compliance Owner |
| Annually | Full compliance audit. Staff training refresh. Contract template update. PA market review. | CFO / Tax |
90-Day Action Plan
A structured plan from today to enforcement-ready. Tick each item as completed. Download as PDF to include your notes and completed items.
Contract a certified PA
Sign and execute PA contract. Confirm on DGFiP official approved list. Get sandbox credentials immediately.
Register all French entities in PPF Annuaire
Without Annuaire registration no invoice can be routed to or from your entities.
Complete SIRET audit — customers and suppliers
Completeness report, INSEE SIRENE validation, data collection campaign for gaps.
Run mandatory field gap analysis on ERP invoice output
Map every EN 16931 mandatory field against current ERP output. Document gaps and assign remediation.
Appoint PPF Compliance Owner
Named individual in Tax or Finance with formal ongoing responsibility documented.
Send supplier communication
Collect SIRETs and PA information from all French suppliers. Use the template from Chapter 9.
Confirm e-reporting scope for each entity
Use the scope decision tool in Chapter 8. Document obligations and reporting frequencies.
Configure ERP to output compliant invoice format
Factur-X, UBL, or CII — all mandatory fields populated from ERP master data.
Connect ERP to PA API
Install PA connector or build API bridge. Confirm authentication and sandbox submissions working.
Configure AP system to receive structured invoices
PO matching, three-way match, approval workflow — all working from structured XML data.
Implement lifecycle status management including payment statuses
Configure automatic status responses. Payments team confirms payment event feed to PA.
Build e-reporting pipeline for B2C and cross-border transactions
Separate data feed to PA for e-reporting. Test with historical data before production.
Sign DPA with PA · Confirm archiving solution
DPA signed. Archiving policy documented. Retrieval process tested.
Complete all 11 UAT scenarios from Chapter 5
Every invoice type tested in the PA sandbox. Go/No-Go criteria all met.
End-to-end pilot with real suppliers and customers
Real invoices, real data, real PAs. Confirm receipt, routing, status responses end-to-end.
Train all internal teams — AP, AR, Tax, Payments, IT
Formal training, documented process. Rejection handling procedures confirmed.
Go-live with monitoring plan in place
PA rejection rate dashboard live. Exception escalation process defined. Hypercare team identified.
Establish monthly compliance review cadence
First review scheduled. Compliance owner confirmed. Reporting to CFO agreed.
Lumara Advisory runs structured France PPF Readiness Scans — covering all streams, your specific ERP landscape, and PA selection. Vendor-neutral: we receive no referral fees from any PA. Visit lumara-consulting.com to book a free 30-minute discovery call.
This workbook is produced by Lumara Advisory and is provided solely for informational and educational purposes. It does not constitute legal, tax, accounting, or regulatory advice and does not create any professional relationship.
No liability: Lumara Advisory expressly disclaims all liability — direct, indirect, incidental, or consequential — for any loss, penalty, fine, or expense arising from use of or reliance on this workbook, including VAT penalties, compliance failures, missed deadlines, or incorrect system configurations.
Accuracy: All content is based on publicly available DGFiP specifications, AFNOR XP Z12-014, and PPF External Specification v3.1 as of the production date. Requirements change. Always verify at impots.gouv.fr and portail-facturation.dgfip.finances.gouv.fr.
Intellectual property: © 2026 Lumara Advisory. All rights reserved. Licensed for individual use by the purchaser only. Not for redistribution.