France — CTC 5-corner model vs PEPPOL 4-corner

France made an architecture choice unique in Europe: a hybrid CTC (Continuous Transaction Controls) model with five corners, where the DGFiP receives tax data in near-real time, in parallel to the business routing between PDPs.

What is CTC?

Continuous Transaction Controls refers to any e-invoicing model where the tax administration (or a trusted third party) validates or receives transaction data in near-real time, rather than after the fact via periodic returns (VAT monthly statements, etc.). The term is formalised by the OECD in its Tax Administration 3.0 report (2020) and by the IETF in the draft-ietf-vatcontrols-models document.

OECD distinguishes four CTC families:

1. Periodic e-reporting (historical European model, pre-2014): taxpayers submit aggregated monthly returns. Not CTC strictly speaking.
2. Real-time e-reporting (Spain SII, Hungary NAV): invoices are transmitted in real time to the administration after issuance, without prior validation.
3. Centralised clearance (Italy SdI, Turkey GIB, Egypt ETA, Poland KSeF from 2026): the invoice must be deposited on a state platform that validates and forwards it to the recipient.
4. Decentralised CTC + e-reporting (France PPF/PDP, projected Belgium PEPPOL+, Germany Wachstumschancengesetz): business routing stays decentralised (PEPPOL 4-corner or variant) but the administration receives the aggregated tax data in parallel.

Recap: PEPPOL 4-corner

The PEPPOL 4-corner model, standardised by OpenPEPPOL and used by default in Norway, Belgium B2G, Sweden, the Netherlands, and many countries in B2G scope, relies on four actors and an SMP/SML directory:

┌──────────────┐       ┌───────────────┐       ┌──────────────┐
│  SP-Sender   │──AS4─>│  SMP/SML      │<──AS4─│ SP-Receiver  │
│  (corner 1)  │       │  (directory)  │       │  (corner 4)  │
└──────┬───────┘       └───────────────┘       └──────▲───────┘
       │                                                │
       │                AS4 / SBDH                      │
       └────────────────────────────────────────────────┘
        Corner 2 (sender Access Point) → Corner 3 (receiver AP)

• Corner 1: SP-Sender — the sender's Service Provider (invoicing software or SaaS).
• Corner 2: Sender Access Point — AS4 gateway of the sender SP.
• Corner 3: Receiver Access Point — AS4 gateway of the receiver SP, resolved via SMP+SML.
• Corner 4: SP-Receiver — Service Provider of the recipient (ERP, accounting).

The SMP/SML directory (Service Metadata Publisher / Service Metadata Locator) plays a billing-DNS role: a business identifier (SIRET, VAT, GLN, ...) is resolved to the URL of the relevant receiver Access Point. Transport uses AS4 (SOAP 1.2 + WS-Security) with the SBDH (Standard Business Document Header) wrapper. The tax administration has no direct technical role.

France 5-corner: the fifth corner DGFiP

The French model reuses the 4-corner structure but adds a parallel loop to the DGFiP, called by the AIFE specifications the "fifth corner". The PPF (Portail Public de Facturation) plays a dual role: it hosts the central resolution directory (functional equivalent of PEPPOL SMP/SML) and aggregates tax data bound for the DGFiP.

┌──────────┐    ┌───────┐    ┌───────────────┐    ┌───────┐    ┌──────────┐
│ Seller   │───>│ PDP   │───>│ PPF Directory │───>│ PDP   │───>│ Buyer    │
│ ERP      │    │ Sender│    │ + aggregator  │    │ Recv. │    │ ERP      │
│ corner 1 │    │ corn.2│    │ corner X      │    │ corn.3│    │ corner 4 │
└──────────┘    └───┬───┘    └───────┬───────┘    └───────┘    └──────────┘
                    │                │
                    │      lifecycle │
                    │                ▼
                    │       ┌────────────────┐
                    │       │  DGFiP         │
                    └──────>│  (5th corner)  │
                            │  e-reporting   │
                            │  near-real-time│
                            │  VAT controls  │
                            └────────────────┘

Three distinct flows circulate in this architecture:

1. Business invoice flow (UBL/CII/Factur-X): seller ERP → issuing PDP → inter-PDP routing via the central directory → receiving PDP → buyer ERP. The full business content circulates only between the PDPs.
2. Tax flow to DGFiP: the issuing PDP must extract and forward to the PPF a tax subset (net/VAT/gross amounts per rate, party identifiers, operation date, operation code). Detailed business content (line descriptions, internal references) is not sent to DGFiP.
3. Lifecycle flow: status changes (submitted, received, accepted, refused, paid, cashed, ...) propagate symmetrically through both PDPs and are also aggregated at the PPF. Example lifecycle-status payload:

{
  "messageType": "INVOICE_LIFECYCLE_STATUS",
  "schemaVersion": "PPF-1.2",
  "invoiceId": "FR-2026-09142",
  "issuer": { "siret": "80214579500024" },
  "recipient": { "siret": "52145201400018" },
  "status": "PAID",
  "statusCode": "203",
  "statusTimestamp": "2026-11-15T14:32:01+01:00",
  "issuingPdp": "PDP-FR-007",
  "receivingPdp": "PDP-FR-022",
  "dgfipReportingFlag": true,
  "reportingTimestamp": "2026-11-15T14:32:05+01:00"
}

Pros and cons

Pros of the French choice

• Real-time tax visibility — the DGFiP has an aggregated view of transactions before the monthly VAT return, paving the way for the pre-filled tax return announced for 2028.
• PDP competition preserved — unlike the Italian SdI model where a single state platform is mandated, the private PDP ecosystem keeps its pricing and functional freedom.
• Continuity with PEPPOL — PDPs can reuse their existing PEPPOL AS4 stack with a limited French overlay (SIREN directory, recommended Factur-X format, status profiles).
• No single SPOF — the unavailability of one PDP does not stop the whole ecosystem (assuming the central directory itself achieves ≥ 99.95% availability).

Cons and risks

• Protocol complexity — every actor (ERP vendor, PDP, integrator) must master two parallel protocols (inter-PDP business routing + tax e-reporting) and their orchestration.
• Increased latency — resolving the destination PDP via the central directory adds an RTT hop, and tax aggregation imposes an extra read/transform on the invoice on the PDP side.
• Central directory dependency — central PPF directory downtime blocks any new invoicing: this is the residual SPOF of the model (mitigated by a 24h TTL cache on PDPs).
• PDP integration cost — the PDP accreditation procedure (AIFE audit, RGS*** compliance, financial guarantee deposit) creates a significant entry barrier.

International benchmarks

Comparison of the main models in 2026, in increasing order of centralisation:

Technical implications for vendors

1. Dual-track architecture: design from day one with two distinct message queues (inter-PDP business routing and tax e-reporting toward PPF). Volumes and SLAs differ: e-reporting tolerates an async delay of several minutes, business routing must meet contractual client SLAs.
2. Directory caching: AIFE specifications recommend a 24h TTL on the PPF resolution cache held by each PDP. This requires an event-driven invalidation policy (DGFiP → PDP webhook). See the dedicated page Central directory.
3. Status management: ~10 lifecycle statuses are standardised (submitted, received, refused, paid, ...) and must be relayed in both directions between PDPs, plus a copy to the PPF. A lost status = an invoice that appears stuck on the DGFiP side.
4. Pivot format for tax aggregation: PDPs must extract tax data from UBL, CII, or Factur-X, and submit it in a JSON pivot format specified by AIFE. Any Schematron version change on the FNFE-MPE side can impact the extraction pipeline — plan a versioning strategy.
5. Local PDP resilience: the unavailability of a destination PDP must not block the sender. Decree 2024-266 requires a degraded mode with automatic re-routing to a fallback PDP after a T+15 minute timeout.

Cross-links

• France — Mandate overview 2026/2027.
• France — Factur-X FNFE-MPE specification.
• France — Central directory (API + spec).
• France — Chorus Pro and PPF transition.
• Standards — PEPPOL (BIS Billing 3.0 + AS4 + SBDH).
• Standards — AS4 / ebMS3 — transport protocol between Access Points.
• Sources: DGFiP — External B2B specifications, OECD Tax Administration 3.0 (2020), Ordinance 2021-1190 (Legifrance), Decree 2024-266 of 25 March 2024, OpenPEPPOL eDelivery (AS4).