EU E-Invoicing & Tax Reporting Knowledge Base

Italy’s e‑invoicing regime is one of the most mature in Europe — and one of the most exacting. For tech leaders and policy-makers, FatturaPA is more than an XML — it is a business process, a compliance interface, and an integration pattern with the state. This guide distills the standards into pragmatic steps you can ship, with a focus on GovTech & LegalTech integration, data governance, and operational reliability.

What FatturaPA Is — And Who Must Comply

FatturaPA is Italy’s mandatory e‑invoice format. All B2B and B2C invoices issued by Italian VAT‑registered entities route through the government’s exchange platform — the Sistema di Interscambio (SDI). Public sector invoices (B2G) also pass via SDI and follow the same core model with sector‑specific nuances.

• Scope:
  • B2G — mandatory since 2014
  • B2B/B2C — mandatory since 2019
  • Cross‑border — reported via SDI using dedicated document types
• Core artifacts:
  • FatturaPA XML file — your canonical invoice
  • SDI transport channel — how you deliver the XML
  • SDI receipts — machine‑readable acknowledgments and errors you must store

In plain terms — your ERP emits structured XML, SDI validates and forwards it, and the receipts you receive are legal evidence of status.

Architecture Overview — How Your System Talks To SDI

At a high level, you map ERP data to FatturaPA XML, validate, transmit to SDI, then consume and reconcile SDI receipts asynchronously.

• Actors:
  • Issuer — your system or service provider
  • Recipient — customer, PA, or consumer
  • SDI — validation and routing hub operated by the tax authority
• Environments:
  • Test/collaudo — available after channel accreditation
  • Production — live SDI

SDI Transport Channels — Comparison

Rule of thumb — product teams should aim for SDICoop for resilience and observability; SDIFTP if you are a batch processor.

The FatturaPA Data Model — What You Must Map

FatturaPA is a structured XML with strict cardinalities and code lists. You will map the following essentials:

• Header — `FatturaElettronicaHeader`
  • `DatiTrasmissione` — `ProgressivoInvio` (idempotency key), `FormatoTrasmissione` (FPR12 for B2B/B2C, FPA12 for PA), `CodiceDestinatario` (7‑char routing code), optional `PECDestinatario`
  • `CedentePrestatore` — supplier legal/fiscal identity, VAT ID (Partita IVA), tax code (Codice Fiscale), address
  • `CessionarioCommittente` — customer identity (VAT or CF), address
  • `TerzoIntermediarioOSoggettoEmittente` — if an intermediary submits on your behalf
• Body — `FatturaElettronicaBody`
  • `DatiGenerali` — `TipoDocumento` (e.g., TD01 invoice, TD02 advance), `Divisa`, dates, references
  • `DatiBeniServizi` — line items (`DettaglioLinee`), VAT rates, totals
  • `DatiRiepilogo` — VAT summary per rate or nature code
  • `DatiPagamento` — method, due dates, IBAN
  • Special blocks when applicable — `DatiCassaPrevidenziale`, `DatiRitenuta`, `DatiBollo`, `DatiDDT`, `DatiTrasporto`
• Totals — strictly consistent with lines and VAT summaries

Key routing fields:

• `CodiceDestinatario` — business endpoint code (7 chars); use `0000000` for private consumers
• `PECDestinatario` — certified email, used when no endpoint code is available
• Public Administration uses IPA codes and the `FPA12` format

Minimal Valid FatturaPA XML — A Compact Example

<?xml version=”1.0″ encoding=”UTF-8″?>
<p:FatturaElettronica versione=”FPR12″ xmlns:p=”http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2″>
<FatturaElettronicaHeader>
<DatiTrasmissione>
<IdTrasmittente>
<IdPaese>IT</IdPaese>
<IdCodice>01234567890</IdCodice>
</IdTrasmittente>
<ProgressivoInvio>INV-2025-000123</ProgressivoInvio>
<FormatoTrasmissione>FPR12</FormatoTrasmissione>
<CodiceDestinatario>ABCDEF1</CodiceDestinatario>
</DatiTrasmissione>
<CedentePrestatore>
<DatiAnagrafici>
<IdFiscaleIVA>
<IdPaese>IT</IdPaese>
<IdCodice>01234567890</IdCodice>
</IdFiscaleIVA>
<Anagrafica><Denominazione>Acme S.r.l.</Denominazione></Anagrafica>
<RegimeFiscale>RF01</RegimeFiscale>
</DatiAnagrafici>
<Sede><Indirizzo>Via Roma 1</Indirizzo><CAP>00100</CAP><Comune>Roma</Comune><Provincia>RM</Provincia><Nazione>IT</Nazione></Sede>
</CedentePrestatore>
<CessionarioCommittente>
<DatiAnagrafici>
<IdFiscaleIVA><IdPaese>IT</IdPaese><IdCodice>09876543210</IdCodice></IdFiscaleIVA>
<Anagrafica><Denominazione>Client S.p.A.</Denominazione></Anagrafica>
</DatiAnagrafici>
<Sede><Indirizzo>Corso Italia 10</Indirizzo><CAP>20100</CAP><Comune>Milano</Comune><Provincia>MI</Provincia><Nazione>IT</Nazione></Sede>
</CessionarioCommittente>
</FatturaElettronicaHeader>

<FatturaElettronicaBody>
<DatiGenerali>
<DatiGeneraliDocumento>
<TipoDocumento>TD01</TipoDocumento>
<Divisa>EUR</Divisa>
<Data>2025-10-19</Data>
<Numero>2025-123</Numero>
<ImportoTotaleDocumento>122.00</ImportoTotaleDocumento>
</DatiGeneraliDocumento>
</DatiGenerali>

<DatiBeniServizi>
<DettaglioLinee>
<NumeroLinea>1</NumeroLinea>
<Descrizione>Software subscription — 1 month</Descrizione>
<Quantita>1.00</Quantita>
<PrezzoUnitario>100.00</PrezzoUnitario>
<PrezzoTotale>100.00</PrezzoTotale>
<AliquotaIVA>22.00</AliquotaIVA>
</DettaglioLinee>
<DatiRiepilogo>
<AliquotaIVA>22.00</AliquotaIVA>
<ImponibileImporto>100.00</ImponibileImporto>
<Imposta>22.00</Imposta>
<EsigibilitaIVA>I</EsigibilitaIVA>
</DatiRiepilogo>
</DatiBeniServizi>

<DatiPagamento>
<CondizioniPagamento>TP02</CondizioniPagamento>
<DettaglioPagamento>
<ModalitaPagamento>MP05</ModalitaPagamento>
<DataScadenzaPagamento>2025-11-18</DataScadenzaPagamento>
<ImportoPagamento>122.00</ImportoPagamento>
</DettaglioPagamento>
</DatiPagamento>
</FatturaElettronicaBody>
</p:FatturaElettronica>

Tip — keep amounts at two decimals, ensure line totals sum to taxable base and VAT summaries exactly.

Validation & Pre‑Flight — What To Check Before Sending

• XSD compliance — validate against the official FatturaPA XSDs
• Controlled vocabularies — `TipoDocumento`, `Natura` (e.g., N2.x, N3.x, N4), `ModalitaPagamento`, `RegimeFiscale`
• Identity data — supplier’s VAT/CF, customer’s VAT/CF or CF for consumers
• Routing — `CodiceDestinatario` or `PECDestinatario`, use `0000000` for B2C
• Tax math — per‑line totals, VAT per summary bucket, global totals
• Special flags — `EsigibilitaIVA` (I immediate, D deferred, S split payment for PA), `DatiBollo` for virtual stamp when applicable
• Idempotency — unique `ProgressivoInvio` per submission

Submission Flow — From XML To Receipt

1. Generate XML — map ERP data, normalize decimals, encode UTF‑8.
2. Optional signing — some PA workflows may still require a signature; B2B/B2C typically accept unsigned XML.
3. Transmit via chosen channel — SDICoop, SDIFTP, or PEC.
4. Poll/receive SDI outcomes — parse and persist machine‑readable receipts.
5. Forwarding to recipient — SDI delivers to the endpoint code or PEC; for consumers, SDI stores the invoice in the tax portal.
6. Reconciliation — match SDI protocol numbers to your invoice records, update status, and trigger downstream actions (posting, dunning, archiving).

SDI Receipts — What They Mean

• Scarto (Reject) — file rejected, not delivered; fix and resend with a new `ProgressivoInvio`
• Ricevuta di Consegna (Delivery Receipt) — delivered to recipient endpoint
• Notifica di Mancata Consegna (Failed Delivery) — undeliverable; SDI makes it available in the tax portal; your duty is still met
• Decorrenza Termini (Timeout) — no recipient acknowledgment in PA flows; treat as delivered after the legal window
• Esito Committente (Customer Outcome) — applicable in PA flows within a defined period

Persist all receipts — they are part of your legal audit trail.

Error Handling — Typical SDI Error Categories

Build deterministic, human‑readable error mapping so support can resolve issues in minutes — not hours.

Security, Privacy & Retention — What Compliance Entails

• Transport security — mTLS for SDICoop; strict IP allowlisting; certificate rotation
• Data minimization — only legally required invoice fields; avoid free‑text PII
• Logging — redact sensitive fields, hash identifiers where possible
• Archiving (conservazione digitale) — preserve invoices and SDI receipts for statutory periods, with time‑stamps and integrity guarantees; consider a certified conservator or the tax authority’s service
• GDPR & eIDAS — define lawful basis, data processor roles, and e‑signature policies where used
• Access control — least privilege in ERP, invoicing service, object storage

Cross‑Border & Special Cases — Don’t Miss These

• Reverse charge & split payment — model via `TipoDocumento`, `Natura` and `EsigibilitaIVA`
• Virtual stamp duty — `DatiBollo` when thresholds or document types require it
• Cross‑border reporting — use dedicated document types (e.g., TD17/TD18/TD19) per official tables for purchases and services with foreign counterparties
• Withholding & social funds — `DatiRitenuta`, `DatiCassaPrevidenziale` for specific professions
• Public Administration specifics — `FPA12`, IPA codes, and possible customer outcome messages

Design your rules engine so document type and tax scenarios are fully data‑driven — not hard‑coded.

Build vs Buy — Connecting To SDI Directly Or Via A Provider

• Direct SDI accreditation — maximum control, no vendor lock‑in, but requires certificates, compliance ops, and 24/7 monitoring
• Intermediary/provider — faster time‑to‑market, managed updates and archiving, but recurring fees and vendor dependency

Decision criteria — volume, in‑house Ops maturity, required SLAs, and regulatory posture. Many teams start with a provider, then insource SDICoop when scale and stability justify it.

Implementation Plan — A Practical, Low‑Risk Path

1. Discovery — map business flows, document types, code lists, and edge cases
2. Data model — define a canonical invoice schema; add a strict adapter to FatturaPA
3. Validation — embed XSD checks and business rules in CI; add test fixtures
4. Transport — choose SDICoop; prepare mTLS, IP ranges, retries, backoff, and DLQs
5. Observability — correlation ids, receipt parsing, dashboards, alerts
6. Archiving — immutable storage of XML and receipts; retention policies
7. Rollout — pilot a subset of customers, compare SDI totals to ERP ledgers, expand gradually

Go‑Live Checklist — Pin Down The Last Mile

• Unique `ProgressivoInvio` strategy — deterministic, collision‑safe
• Code lists up‑to‑date — `TipoDocumento`, `Natura`, payment modes
• Totals parity — unit tests for rounding and VAT per bucket
• Receipt consumption — every receipt mapped to a terminal status
• Retries & idempotency — safe re‑submission without double‑posting
• Backfilling plan — late or corrected invoices with credit notes (TD04) as needed
• Conservazione — archiving vendor or state service enabled and tested

Aligning With EU Directions — Future‑Proof Your Stack

Italy’s model is converging with broader EU digital reporting and e‑invoicing initiatives. Keep your architecture adaptable — externalize code lists, version transformation logic, and isolate SDI transport behind an interface so migrating to additional networks (e.g., PEPPOL) or future EU schemas is incremental — not a rewrite.

Key Takeaways

• FatturaPA is a precise XML plus an integration with SDI — treat both data quality and transport as first‑class concerns.
• Build a canonical invoice model and a strict, tested adapter — then add SDI transport with robust observability and archiving.
• Start with SDICoop for programmatic control or a provider for speed — but design for portability and evolving EU requirements.

Overview — What KSeF Is and Why It Matters

• KSeF is Poland’s National e‑Invoicing System for structured B2B invoices. It assigns a unique KSeF ID to each accepted invoice and provides lifecycle statuses and auditability for tax compliance.
• Businesses integrate via KSeF APIs to submit, receive, and query invoices, handle corrections, and maintain compliant archives. Vendors and SaaS platforms often embed KSeF as part of their billing or ERP flows.
• Scope continues to evolve — always validate current go‑live phases, exemptions, and contingency procedures against official Ministry of Finance communications before committing timelines.

Legal and Compliance Scope — Entities, Transactions, Evidence

• KSeF focuses on structured e‑invoices for domestic B2B transactions; specific rules may apply to cross‑border scenarios, self‑billing, and special VAT treatments.
• Acceptance in KSeF yields a KSeF ID and official processing acknowledgment — this acts as the authoritative evidence that the invoice exists in the system.
• Your compliance posture should cover authenticity and integrity of data, timely delivery, correction/cancellation workflows, and retention with audit trails.

Data Models — KSeF Logical Structure vs JPK_FA

• KSeF uses a dedicated “FA” logical XML model for invoice content and metadata; it is optimized for transactional exchange, statuses, and reference to prior documents.
• JPK_FA (SAF‑T for invoices) is an aggregate reporting/extract format used for audit/reporting, not for operational exchange. Its tags and normalization differ from KSeF’s FA structure.
• Practical implication — do not “dump” JPK_FA into KSeF. Instead, map ERP fields to the KSeF FA schema and treat JPK_FA as a separate reporting pipeline.

JPK_FA XML Mapping — Field‑By‑Field Considerations

• Parties — map Seller/Buyer NIP, legal name, addresses; ensure normalization (street, building, premise, postal code, country). JPK_FA naming and address blocks may differ.
• Identification — ensure invoice number sequences comply with your policy; reference prior KSeF ID for corrections (faktura korygująca) and linked documents.
• Tax lines — map each VAT rate category (e.g., 23, 8, 5, 0, “ZW”, “NP”) with base, tax, and totals; ensure precise rounding rules as per KSeF expectations.
• Lines — items with quantity, unit price, discounts/charges; align unit codes and decimal precision to KSeF constraints (JPK_FA sometimes allows different scales).
• References — purchase order, delivery note, contract numbers; transport/delivery dates for supply; payment terms and methods.
• Totals — taxable base per rate, VAT per rate, grand totals; verify that numeric tolerances pass KSeF validation to avoid rejects.
• Metadata — supply dates of issue/supply, currency, exchange rates; include annotations required by special regimes where applicable.

Tip: Build a canonical invoice model in your system, then implement dedicated mappers: ERP → Canonical → KSeF FA, and separately ERP → JPK_FA for audits.

Security and Identity — Authorizations and Tokens

• Authorization is role‑based at the taxpayer entity level. Onboard authorized representatives and generate API tokens for server‑to‑server integrations under your organization.
• Maintain least‑privilege scopes, rotate tokens regularly, and segregate credentials per environment (sandbox, pre‑prod, prod).
• If you support multi‑tenant SaaS, isolate token stores and enforce per‑tenant rate limits and audit logs.

Transport and Packaging — Submission Patterns

• Submissions are asynchronous: you send a structured invoice package, KSeF validates and processes, then you retrieve status and the assigned KSeF ID if accepted.
• Use idempotent submission with stable correlation IDs to avoid duplicates; implement retries with exponential backoff and jitter for transient errors or throttling.
• Compress large payloads, sign where required by your policy, and always capture the raw request/response for evidence and troubleshooting.

Processing and Statuses — From Draft to Accepted

• Typical states include received, validating, accepted, or rejected with error codes and diagnostics. Rejections cite schema/business‑rule violations to fix and resubmit.
• Upon acceptance, the system returns or exposes the official KSeF ID and processing timestamp — store both in your ERP to ensure perfect reconciliation.
• For buyers, implement retrieval/subscription to inbound invoices; for suppliers, subscribe to status callbacks or poll efficiently to keep UIs and ledgers in sync.

Corrections and Cancellations — Reference Integrity

• Polish practice uses correction invoices to amend prior invoices. Always reference the original invoice number and, where required, the original KSeF ID.
• Support partial and full corrections, tax base adjustments, and text annotations explaining the reason. Keep a linked list in your database to show the entire correction chain.
• If a cancellation flow exists for specific edge cases, implement the required reference and evidence emission to satisfy audits.

Validation — Preventing KSeF Rejects

• Schema validation — validate against the current KSeF FA XSD before submission; maintain a versioned validator to handle spec updates.
• Business rules — pre‑check tax logic, rate applicability, exemption codes, date consistency, and totals/rounding.
• Address quality — standardize and validate address fields; normalize country codes, postal formats, and diacritics to reduce rejects.

Observability — Monitoring, Alerts, and Auditability

• Metrics — submission throughput, acceptance ratio, time‑to‑acceptance, and top rejection reasons.
• Alerts — notify on spikes of rejects, SLA breaches, or API outages; implement dead‑letter queues with replay tooling.
• Evidence — store normalized JSON/XML, raw source payloads, responses, timestamps, hashes, and the KSeF ID; produce regulator‑ready exports on demand.

Archiving and Retention — Integrity and Proof

• Retain invoices and all acknowledgments for statutory periods with integrity controls (hashes, timestamps, write‑once storage where feasible).
• Maintain a verifiable audit trail tying each ledger entry to a KSeF ID and its acceptance evidence.
• Periodically test restorability and traceability — simulate audits to ensure your evidence bundle is complete.

Multi‑Company and Multi‑Channel — Enterprise Patterns

• Multi‑entity (multi NIP) — partition tokens, sequences, and archives per legal entity; enforce per‑entity configuration and routing.
• Hybrid channels — if you exchange via KSeF and other networks (e.g., PEPPOL for foreign buyers), converge into one canonical model with channel‑specific adapters.
• Tenant isolation — for SaaS, isolate storage and keys per tenant; expose per‑tenant dashboards and download APIs for evidence packs.

KSeF API Integration — Step‑by‑Step

1) Readiness and scoping — inventory legal entities, volumes, peak windows, and inbound vs outbound needs. 2) Authorization setup — onboard representatives, create API tokens, define roles and least‑privilege scopes. 3) Canonical model — define a neutral invoice schema covering parties, lines, tax, totals, references, and metadata. 4) Mapping — implement ERP → Canonical → KSeF FA mappers; separately build ERP → JPK_FA for audits. 5) Validation — XSD validation for KSeF FA, business‑rule checks, tax calculators, and rounding verification. 6) Connectivity — implement endpoints, idempotent submissions, retries/backoff, and correlation IDs; wire sandbox first. 7) Status orchestration — callbacks/polling, state machine, and reconciliation that writes KSeF IDs into ERP. 8) Evidence and archiving — store payloads, responses, timestamps, and logs; enable on‑demand export for audits. 9) Monitoring — dashboards, alerts, DLQs, and playbooks for incident response. 10) Go‑live — performance tests, failover rehearsal, runbook, and hyper‑care with daily stability reports.

Testing Matrix — What Good Looks Like

• Positive flows — standard invoices across all VAT rates, with and without exemptions; multi‑currency with exchange rates.
• Negative flows — schema violations, rounding mismatches, invalid NIP, date inconsistencies, missing references.
• Lifecycle — corrections, cancellations, and buyer refusals; inbound receipt handling.
• Non‑functional — bursts and throttling, idempotency checks, recovery from partial outages, and data integrity under load.

Pricing and Product Strategy — For SaaS Vendors

• Pricing model — base subscription per legal entity (NIP) plus tiered volume per accepted invoice; add premium for advanced monitoring, analytics, and regulatory update SLAs.
• Bundles — “KSeF Core” (submission + status + archiving), “KSeF Plus” (inbound inbox + approvals), and “Compliance Updates” (schema/business‑rule tracking).
• Roadmap — connectors to popular ERPs, low‑code mapping UI, evidence export APIs, and alert webhooks; publish time‑to‑acceptance and acceptance‑rate KPIs.

Common Pitfalls — And How to Avoid Them

• Treating JPK_FA as a submission format — it is not; build a dedicated KSeF FA mapper and validation pipeline.
• Weak idempotency — duplicates arise during retries; always use stable correlation IDs and dedupe logic.
• Ignoring rounding rules — tiny discrepancies cause rejects; align tax and total calculators with KSeF expectations.
• Sparse observability — without DLQs and alerts, transient errors escalate into compliance incidents.
• Single‑tenant assumptions — for SaaS, lack of tenant isolation and per‑entity archives creates audit and security risks.

Summary — What to Remember

• KSeF is a transactional e‑invoicing platform — treat it separately from JPK_FA reporting and build a robust FA mapper.
• Invest in validation, idempotent transport, status orchestration, and evidence‑grade archiving for compliance and auditability.
• For ksef api integration and poland einvoicing ksef compliance, center your design on a canonical model, strict validators, and strong observability; for jpk fa xml mapping, implement a dedicated reporting mapper independent from KSeF flows.

France’s E‑Invoicing Landscape — PPF, PDP, OD

• France is rolling out a domestic B2B e‑invoicing and e‑reporting regime centered on two pillars: the public platform PPF (Portail Public de Facturation) and certified private platforms PDP (Plateformes de Dématérialisation Partenaires).
• PPF — the state hub — routes, validates, and collects reporting data. PDPs — certified intermediaries — exchange invoices between suppliers and buyers and submit e‑reporting to PPF when required.
• A third role, OD (Opérateur de Dématérialisation), is a non‑certified service provider that can prepare and relay invoices but must connect via a PDP or the PPF. A central directory (Annuaire) maps recipients by SIREN/SIRET and their chosen channel.

Standards and Formats — EN 16931 at the Core

• Semantic compliance is based on EN 16931 — the EU standard for e‑invoice data. France adds national business rules and profile constraints.
• Accepted formats typically include UBL 2.1, UN/CEFACT CII (D16B profile), and Factur‑X — a hybrid PDF/A‑3 with embedded EN 16931 XML.
• Authenticity and integrity must be guaranteed — via qualified e‑signature, EDI controls, or a documented reliable audit trail — with PDP/PPF validation adding technical and business checks.

What Gets Exchanged vs What Gets Reported — E‑Invoicing and E‑Reporting

• E‑invoicing applies to domestic B2B transactions — invoices flow supplier → PDP/PPF → buyer (via buyer’s PDP or PPF). Statuses and acknowledgments travel back to the supplier.
• E‑reporting applies where invoices are not fully exchanged domestically through the network — B2C, and cross‑border B2B. Summaries and payment statuses are reported to PPF at mandated intervals.
• Key identifiers are SIREN/SIRET, VAT numbers, and the directory routing entry. Line‑level VAT, exemptions, and delivery details must align with EN 16931 and French specifics.

Integration Models — Direct to PPF, Via PDP, or Through an OD

1) PPF Direct

• Use when you want a state‑managed channel — fewer external contracts, but you must build to PPF’s APIs and constraints.
• Pros — official hub, baseline capabilities, direct compliance. Cons — feature set is generic, you own more orchestration.

2) PDP Integration

• Contract with a certified PDP — they handle interoperability, validations, directory updates, and e‑reporting on your behalf.
• Pros — richer APIs, dashboards, advanced monitoring, and partner tooling. Cons — commercial terms, vendor selection, platform limits.

3) OD + PDP

• Keep your existing billing stack (OD role) and connect to one or more PDPs via adapters — useful for multi‑tenant SaaS.
• Pros — flexibility, vendor portability. Cons — you must manage mapping, routing, and multi‑PDP nuances.

EN 16931 Mapping — Practical Data Checklist

• Parties — supplier and buyer with SIREN/SIRET, VAT IDs, and addresses; delivery and ordering parties if different.
• Document core — invoice number, issue date, due date, currency, payment terms, references (order/contract/delivery).
• Lines — item identifiers, quantities, unit prices, allowances/charges, tax category and rate, exemptions with legal references.
• Totals — taxable bases per rate, VAT totals per rate, grand total including tax, rounding rules.
• Attachments and profiles — Factur‑X PDF, structured XML, and any procurement references required by the buyer.

Lifecycle and Statuses — What to Handle

• Technical validation — schema and business rules (EN 16931 + French rules). Failures produce rejects with error codes.
• Business acceptance — buyer acceptance, refusal, or dispute; update statuses back to supplier.
• Payment and adjustments — credit notes, cancellations, and payment status reporting for e‑reporting scenarios.

Security, Integrity, and Archiving — Compliance Foundations

• Authenticity and integrity — ensure via qualified signature, EDI controls, or reliable audit trail. PDP/PPF validations complement but do not replace your evidence policy.
• Archiving — retain invoices and evidence for statutory periods (typically up to 10 years in France) with immutable logs, hash chains, and time‑stamps.
• Privacy — handle personal data in invoices under GDPR principles — minimization, lawful basis, retention, and access control.

API Integration — Step‑by‑Step for PPF / PDP

1) Discovery and scoping

• Identify flows — domestic B2B e‑invoicing vs B2C / cross‑border e‑reporting. Inventory legal entities, volumes, and peak loads.

2) Directory readiness

• Collect SIREN/SIRET, buyer routing preferences, and PDP affiliations. Synchronize with the Annuaire to ensure correct delivery.

3) Data mapping

• Map ERP/billing fields to EN 16931. Implement pre‑submission validation to avoid PDP/PPF rejects. Support UBL, CII, and Factur‑X.

4) Connectivity

• Establish OAuth/mTLS or PDP‑specific auth. Configure environments — sandbox, pre‑prod, prod. Implement idempotent submission with correlation IDs.

5) Eventing and statuses

• Subscribe to callbacks or poll for statuses. Normalize states — submitted, accepted, rejected, refused, disputed, canceled, paid.

6) E‑reporting

• Build report packages for B2C and cross‑border B2B — amounts, VAT breakdowns, payment updates — per cadence and schema.

7) Observability

• Dashboards for throughput and failure rates, alerting on rejects and SLA breaches, dead‑letter queues and auto‑retries with exponential backoff.

8) Evidence and archiving

• Store source XML/PDF, PDP/PPF receipts, qualified timestamps, and normalized audit logs for regulators and customers.

PDP Provider Onboarding — France‑Specific Considerations

• Role decision — clarify whether you aim to become a certified PDP, integrate with one or more PDPs, or operate as an OD. Certification entails security, interoperability, and compliance audits.
• Technical compliance — implement EN 16931 semantic validations, French business rules, directory sync, status orchestration, and e‑reporting payloads.
• Interoperability — prove exchanges with PPF and multiple PDPs, support Factur‑X, UBL, and CII, and demonstrate end‑to‑end delivery and error handling.
• Security and governance — mTLS, key management, logging, incident response, and data retention policies aligned with French requirements.
• Operational readiness — monitoring, customer support runbooks, SLA commitments, and change‑management for evolving schemas and rules.

Testing and Certification — What Good Looks Like

• Test matrix — valid/invalid invoices, multi‑rate VAT, exemptions, credit notes, cancellations, directory routing, and boundary cases.
• Non‑functional — throughput under peak loads, resilience to 429/rate limits, replay safety, idempotency, and disaster recovery.
• Evidence — test reports, trace IDs, and message receipts to demonstrate reliable processing to customers and auditors.

Costing and Commercials — Build vs Buy

• Direct to PPF — lowest external cost but higher engineering effort and feature ownership.
• Single PDP partner — faster time‑to‑market, consolidated SLAs, and tooling — balanced by platform fees and vendor dependency.
• Multi‑PDP strategy — portability and leverage on pricing — traded off against integration complexity and maintenance.
• Pricing model for SaaS — base platform fee per legal entity + usage tiering per invoice/report + compliance update Surcharge for schema changes.

Common Pitfalls — And How to Avoid Them

• Assuming “PDF only” is enough — you need structured EN 16931 data, not just visual rendering.
• Skipping pre‑validation — avoid downstream rejects by validating business rules prior to submission.
• Ignoring directory sync — outdated routing leads to misdelivery or failures.
• Underestimating e‑reporting — B2C and cross‑border flows require separate pipelines, schedules, and payment status updates.
• Thin observability — without retries, DLQ, and alerting, small glitches cascade into compliance breaches.

Implementation Timeline — A Pragmatic 8‑Week Plan

1) Weeks 1–2 — Discovery, directory onboarding, and EN 16931 mapping with validation rules. 2) Weeks 3–4 — Build submission, status, and evidence services; wire Factur‑X / UBL / CII. 3) Weeks 5–6 — E‑reporting pipeline, monitoring, alerts, and archiving with LTV signatures/timestamps. 4) Weeks 7–8 — End‑to‑end testing with buyer samples, performance tests, go‑live runbook, and hyper‑care.

Glossary — Quick Reference

• PPF — Portail Public de Facturation, the state platform for routing and reporting.
• PDP — Certified Partner Dematerialization Platform that exchanges invoices and reports to PPF.
• OD — Non‑certified operator assisting with preparation and routing via PDP/PPF.
• EN 16931 — EU semantic standard for e‑invoicing.
• Factur‑X — Hybrid PDF/A‑3 with embedded EN 16931 XML.
• Annuaire — Central directory of recipients and routing choices.
• SIREN/SIRET — French company identifiers for entities and establishments.

Summary — What to Remember

• France’s model hinges on EN 16931 structured data, a central directory, and two channels — PPF and PDP — with ODs assisting.
• Choose integration based on your scale, deadlines, and control needs — direct to PPF, via a PDP, or OD + PDP — and build strong validation, status, and evidence layers.
• For “france e invoicing ppf pdp integration” and “facturation electronique en16931”, emphasize canonical mapping, directory sync, and resilient APIs. For “pdp provider onboarding france”, highlight role choice, interoperability proofs, and security governance.