What happens if your PDP/approved platform fails? France e-invoicing risk and continuity planning

• When an approved platform fails, the consequences reach AR, AP, tax reporting, and audit evidence simultaneously.
• Failure takes six forms: service outage, interoperability breakdown, cybersecurity incident, accreditation loss, commercial failure, and implementation failure that only looks like provider failure.
• Accreditation confirms regulatory eligibility at a point in time. It doesn’t guarantee uptime, capacity, financial viability, or support quality.
• Building and exercising a continuity plan — including accreditation-withdrawal and insolvency scenarios — lets you put recovery objectives, data portability, and exit rights into the contract before signing.

What happens if your PDP/approved platform fails?

An approved platform is not an ordinary software supplier. It sits directly in the statutory transaction path for every in-scope business-to-business (B2B) e-invoice. When it fails, invoice issuance, receipt, routing, life cycle status updates, and e-reporting can all stop at once — before regulators impose any formal sanction. The operational consequences arrive immediately.

It’s worth distinguishing between failure types. A complete outage is the most visible scenario, but degraded performance, data failure, and loss of accreditation each carry their own consequences. Even a short interruption can create a backlog for finance operations that takes significantly longer to clear than the outage itself.

Why the French mandate increases platform dependency

The French mandate requires every business subject to it to use an approved platform for invoice exchange and required reporting. That dependency runs across finance, tax, IT, procurement, treasury, and customer service.

Who remains accountable when a provider fails?

The taxpayer — not the platform. An approved platform processes and transmits data on your behalf, but it does not assume your statutory compliance obligations. If your platform fails and invoices are not issued, received, or reported on time, your business is responsible for the consequences. This makes internal governance critical. Someone in your organisation needs to be able to declare a compliance incident. Accountability across finance, tax, legal, security, and IT needs to be defined before disruption occurs — not during it.

The transaction chain and why every handoff is a failure point

Every in-scope invoice passes through a sequence of handoffs: from your ERP or billing system, through any integration layer or middleware, to your approved platform, then to the recipient’s approved platform, and finally to the public infrastructure and tax administration via the PPF — France’s government-operated public invoicing portal. Each handoff is a potential control gap, latency point, or failure trigger — and a problem at any stage can look identical from the outside regardless of where it originated. The PPF is not a direct free B2B invoicing alternative under the current model; every business subject to the mandate must contract with an approved platform.

Why accreditation is necessary but not sufficient

DGFiP approval confirms that a platform met the regulatory and technical eligibility criteria at a defined point in time. It doesn’t guarantee uptime, transaction capacity, financial viability, or support quality. Compliance testing and enterprise-grade resilience are different standards — a platform can pass one without demonstrating the other. Reliability needs to be evidenced independently, through contractual commitments, reference checks, and operational due diligence — not marketing claims.

Service outage or capacity failure

Platform unavailability stops invoice submission, receipt, validation, and status updates simultaneously. The most visible form is a complete outage, but capacity failures are equally damaging — peak-volume periods around month-end, quarter-end, and tax deadlines create bottlenecks that manifest as API throttling, growing queues, time-outs, and delayed acknowledgements. Platform availability and successful end-to-end delivery are not the same thing. A platform can be technically reachable while invoices are stacking up unprocessed. When evaluating providers, ask specifically about tested transaction capacity and performance headroom — not just uptime figures.

Interoperability and routing failure

Approved platforms must exchange invoices with one another through the PPF directory. When that exchange breaks — because of a directory lookup error, an addressing defect, or a routing failure between platforms — invoices don’t reach their destination even if your platform is functioning normally. Format transformation problems involving Factur-X, UBL, or CII can produce duplicate, rejected, misdirected, or unacknowledged invoices. Distinguishing an internal integration error from an ecosystem-level failure matters for diagnosis and remediation — the root cause determines who’s responsible for fixing it.

Cybersecurity or data-integrity incident

Ransomware, credential compromise, API abuse, and denial-of-service attacks all present distinct risk profiles for an approved platform. Each can result in alteration, loss, disclosure, or duplication of invoice data. The sensitivity of that data — pricing, counterparty details, bank account information, and tax data — makes confidentiality a compliance concern as well as a commercial one. Recovery must preserve the authenticity, integrity, and auditability of invoice records. Incident notification obligations and evidence-preservation expectations should be defined in the contract before an incident occurs.

Loss, withdrawal, or expiry of PDP accreditation

DGFiP registration is not permanent. Repeated regulatory failures, inability to provide required technical evidence or reports, and nonrenewal can each result in suspension, expiry, or withdrawal of approved status. A platform that loses its accreditation can no longer legally fulfil the approved-platform role — and businesses using it face an urgent, unplanned migration. The DGFiP official list of approved platforms should be monitored throughout the contract term, not just at the point of selection. Define internal escalation triggers for any change in a provider’s accreditation status.

Commercial failure, acquisition, or market exit

Insolvency, product discontinuation, withdrawal from France, and abrupt restructuring each create immediate migration pressure. Acquisition can lead to platform consolidation that forces migration on someone else’s timeline. Reduced support quality, slower development, and changing commercial terms can signal strategic instability before a formal exit occurs. Dependence on critical subcontractors and cloud infrastructure introduces further concentration risk. A provider can remain technically live while becoming strategically unreliable — contract protections need to account for that scenario as well as outright failure.

Implementation failure that resembles provider failure

Not all failures originate with the platform. Incorrect data mapping, master-data configuration errors, ERP release incompatibility, poor exception management, and unresolved rejection queues can all produce compliance failures that are initially misattributed to the provider. Distinguishing a vendor defect, a customer defect, and shared responsibility requires structured diagnosis. Avoid selecting a new provider before identifying the true failure domain — switching platforms doesn’t fix a data quality problem.

Accounts receivable and cash collection disruption

When outbound invoices can’t reach customers, revenue recognition stalls. Valid invoices get trapped in queues without reliable status updates, delaying approval, dispute resolution, and payment. Days sales outstanding grows. Cash forecasting weakens. Customer service teams carry an increased burden as counterparties chase invoices they can’t locate in their own systems.

Accounts payable and supplier continuity risk

Missing incoming invoices interrupt approval workflows and cause late supplier payments. Uncertainty about whether an invoice has been received leads to duplicate submissions, creating reconciliation problems that persist long after the platform recovers. Strategically important vendors may interrupt supply if payment terms aren’t met. Email-based work-arounds introduce new control failures and are not a compliant substitute for structured invoice exchange.

Tax reporting and audit-evidence gaps

E-reporting submissions can’t be made on schedule when platform data flows stop. Reconciliation breaks between ERP records, platform records, and public acknowledgements are difficult to unpick after the fact. Proving when an invoice was issued, transmitted, received, or rejected becomes harder when status histories are incomplete. Incident logs and corrective-action evidence need to be preserved from the moment a failure is declared — not reconstructed afterwards.

IT backlog and integration instability

Queue accumulation after an outage creates replay complexity. Duplicate invoice risk increases during recovery if resubmission isn’t controlled carefully. Manual file handling introduces new security and control gaps. Competing priorities across ERP, integration, security, and service-management teams slow resolution. Duplicate-prevention controls, reconciliation keys, and a defined resubmission process need to be designed before an incident occurs — not improvised during one.

Customer, supplier, and reputational consequences

Counterparties can’t complete their own compliance workflows when your invoices don’t arrive. Contract disputes follow when invoices are missing or late. Confidence in finance operations falls. Escalations reach procurement, sales, and executive leadership quickly. For groups using a shared European invoicing architecture, a single platform failure can create cross-border complications that extend well beyond France.

Direct costs of a PDP failure

The immediate costs of a platform failure are visible and accumulate quickly. Emergency technical support and specialist consulting fees arrive before the incident is resolved. Manual invoice handling and reconciliation require overtime for finance, tax, and IT teams. If migration to a secondary provider becomes necessary, expedited onboarding, dual-running costs, and parallel integration work add further expense. Legal review, customer communication, and formal incident response each carry their own cost — and none of them appear in the original platform fee.

The total cost of a failure scales with invoice volume, revenue concentration, and how long the disruption runs. A two-hour outage at month-end can cost more than a two-day outage in a quiet period. That relationship between timing and cost is worth building into your risk assessment.

Indirect cash-flow and working-capital costs

Delayed invoice issuance means delayed payment receipt. Depending on payment terms, even a short disruption can push a significant proportion of monthly receivables into the following period. Late-payment interest obligations or supplier penalty clauses can follow if your own outbound payments are disrupted. Increased short-term borrowing needs may arise if cash collection falls short of forecast.

Treasury intervention to cover working-capital gaps has its own cost. Lost early-payment discounts — where suppliers offer terms conditional on prompt payment — represent a further indirect loss that doesn’t appear in any incident report but affects the P&L nonetheless.

Potential statutory and tax exposure

Platform failure does not automatically trigger penalties. The nature, duration, and documentation of the incident all affect how French tax authorities assess the situation. Missed e-reporting deadlines, late invoice submissions, incomplete data transmissions, and recordkeeping failures each carry different risk profiles — and the consequences depend on the specific facts.

Documenting reasonable steps taken during an incident, and preserving evidence of remediation efforts, is relevant to how any subsequent regulatory review proceeds. Businesses facing a significant platform incident should take advice from French tax advisers on the specific consequences — the analysis is fact-dependent and unsupported generalisations about relief are not a substitute for proper guidance.

Contractual and commercial liability

Customer and supplier service commitments don’t pause during a platform failure. Where contracts include invoicing timelines, delivery confirmation requirements, or payment terms tied to invoice receipt, a platform failure can create contractual exposure alongside the operational disruption.

Review your provider contract carefully on four points:

• Whether regulatory fines or statutory costs are recoverable under the provider agreement — most contracts exclude them.
• Whether consequential-loss exclusions remove cash-flow claims arising from delayed billing.
• How liability caps interact with the actual scale of a significant incident.
• Where subcontractor failure sits — if your platform relies on a third-party infrastructure provider, pass-through liability terms determine whether your losses have any contractual remedy at all.

How to use the risk scorecard

Score each domain from 1 (strong control) to 5 (critical weakness). Require documented evidence rather than verbal assurance — a confident sales conversation is not evidence. Assign named owners across finance, tax, IT, security, procurement, and legal before you begin. Weigh high-volume or high-revenue business units more heavily when aggregating findings, and set remediation deadlines for any domain scoring 4 or 5.

Beyond a standard selection scorecard, demand the following: service-specific SLAs measured end to end, not at the API gateway; tested Recovery Time Objective (RTO) and Recovery Point Objective (RPO) figures by function; cross-platform interoperability evidence at live volumes; customer participation in recovery exercises; and operational transparency in the form of dashboards, logs, and root-cause reporting.

The PDP/approved platform resilience diagnostic table

Calculate concentration risk

Identify what percentage of your French invoice volume depends on a single provider. Then map the revenue and supplier spend exposed to that single integration path. Look for legal entities using identical credentials or shared infrastructure, and critical counterparties who happen to use the same platform as you. Hidden concentration is common in multibrand groups where several brands rely on the same back-end platform without that dependency being visible at the group level.

Define diagnostic outcomes

• Low risk: controls are evidenced and recovery has been tested.
• Moderate: manageable gaps exist with funded remediation in place.
• High: single points of failure are present or recovery is unproven.
• Critical: accreditation status is unclear, exit rights are absent, or no recoverable audit trail exists.

Each outcome has a corresponding executive decision path: accept, remediate, diversify, or replace. The diagnostic result should drive a documented decision — not sit in a spreadsheet awaiting a future review cycle.

Define the critical e-invoicing services

Start by listing every e-invoicing service your business depends on: outbound invoice generation; inbound receipt; validation and format conversion; directory lookup and routing; life cycle status updates; e-reporting and payment-data reporting; and archiving, logs, and audit evidence. Rank each by maximum tolerable outage. The services at the top of that list drive your recovery objectives and your fallback design.

Set measurable recovery objectives

Define a Recovery Time Objective (RTO) — the maximum acceptable time to restore each process after a failure — and a Recovery Point Objective (RPO) — the maximum acceptable gap in invoice and status data before records become incomplete for compliance purposes. Set a maximum tolerable backlog and a maximum acceptable reconciliation break. Identify priority legal entities, customers, and suppliers — and set escalation thresholds based on time elapsed, transaction volume, and financial value at risk. Objectives that aren’t documented and agreed before an incident are not objectives. They’re aspirations.

Design fallback options without creating noncompliant work-arounds

Every fallback option must remain within the statutory framework. A secondary approved platform with prenegotiated emergency onboarding is the most robust option. An alternate integration route or controlled queuing until compliant transmission resumes may be appropriate depending on the failure type. Manual procedures must be limited to approved incident actions. Treating emailed PDFs as a statutory substitute for structured invoice exchange is not a compliant fallback — it must be explicitly prohibited in your incident procedures.

Plan for invoices already in flight

When a platform fails mid-process, the first priority is identifying invoices that were submitted but not acknowledged. Freeze uncontrolled resubmissions immediately. Compare records across your ERP, middleware, platform, and recipient systems before taking any recovery action. Preserve original identifiers and timestamps. Apply duplicate-detection and replay rules before releasing any recovery batches. Confirm successful delivery before closing the incident.

Establish a cross-functional incident command structure

Assign named owners before an incident occurs. Finance owns billing and payables priorities. Tax owns reporting obligations and any regulator-facing communication. IT owns integrations and technical recovery. Security owns cyber incidents. Legal and procurement own contract enforcement. A communications owner manages customer and supplier notification. Executive authority is required for failover or migration decisions. Ambiguity about any of these roles during an active incident will slow every subsequent action.

Exercise the plan before the mandate

Five scenarios should be included in your exercise programme:

• A four-hour outage at month-end
• A failed invoice replay
• Missing e-reporting acknowledgements
• An accreditation withdrawal notice
• Provider insolvency

Each exercise should capture findings, owners, remediation deadlines, and retest dates. Technical continuity procedures should be validated as part of your broader e-invoicing testing programme. Accreditation withdrawal and provider insolvency should each be rehearsed as separate planning sessions — where finance, tax, IT, and legal teams work through exactly what they would do if either scenario occurred.

Separate your compliance processes from a single platform connection

A flexible compliance layer sits between your ERP systems and your approved platform — handling data mapping, validation, and monitoring centrally rather than through separate, custom-built connections. When platform or country requirements change, that central layer absorbs the change without requiring a rebuild of your core ERP integration. If you need to switch approved platforms, your underlying compliance processes don’t have to be rebuilt from scratch.

This approach reduces integration complexity and makes migration easier. It does not eliminate continuity risk entirely — recovery objectives, contractual protections, and tested fallback procedures remain necessary regardless of how your architecture is structured.

Connect resilience features to business outcomes

A single API and prebuilt ERP connectors reduce the integration complexity that creates hidden failure points. Flexible deployment options support different operating models across entities and geographies. Centralised transaction visibility means exceptions are diagnosed faster — and the difference between a platform failure and a configuration error is identified before it becomes a prolonged incident.

Multicountry capability reduces dependence on fragmented local solutions, each with its own SLAs, exit terms, and recovery procedures. Regulatory updates are managed centrally rather than requiring entity-by-entity intervention. And building your compliance architecture around a flexible central layer means provider migration — whether planned or forced — doesn’t require rebuilding your integration from scratch.

Put continuity obligations into the contract

Every continuity commitment needs to be in the contract before you sign — not agreed informally during onboarding. Service-specific SLAs should be measured end to end, not at the API gateway. RTO and RPO targets need to be defined per function and backed by documented recovery-testing results. Incident notification deadlines, root-cause analysis requirements, and capacity and change-management obligations all need explicit contractual treatment. Critically, the contract must require the provider to notify you immediately of any change to its regulatory status — including any DGFiP review, suspension, or accreditation change — with enough lead time to begin contingency planning.

Negotiate meaningful remedies

Service credits are a starting point, not a sufficient remedy. Negotiate termination rights for repeated or material failures, and for loss of accreditation — with transition support obligations attached. Define how liability is treated for data loss, confidentiality breaches, and compliance failures separately from general service disruption. Require the provider to carry adequate insurance and confirm the scope of that cover. Secure audit rights over the resilience controls that matter most — uptime evidence, recovery test results, and subprocessor arrangements — rather than relying solely on self-certification or third-party attestations.

Secure data portability and audit continuity

Data portability rights need to cover every category of record your compliance position depends on:

• Invoice data
• Lifecycle statuses
• E-reporting submissions
• Logs
• Configuration settings
• Mapping rules

Export formats must be open and documented — proprietary formats that require the provider’s own tools to read are not portable in any meaningful sense. Agree timelines for returning data on exit, and confirm that access continues during the transition period. After termination, evidentiary records must be preserved in a form that satisfies DGFiP retention requirements. Before signing, validate that records exported from the platform can actually be ingested by a successor platform — not just technically exported.

Create a practical exit plan

Define the decision triggers that distinguish remediation from migration — the threshold at which a performance problem or accreditation change becomes a replacement event. Maintain a shortlist of successor providers with pre-assessed integration and commercial terms. Map the technical dependencies that determine migration timeline:

• Legal entities in scope
• ERP landscape
• Supported formats
• Transaction volume
• Data quality
• Current contract exit terms

Plan the operational steps: directory updates and electronic address changes in the PPF, counterparty communication, parallel-run controls, cutover sequencing, post-migration reconciliation, and decommissioning of the outgoing integration. Each step has a dependency. The migration timeline is the sum of those dependencies — not an aspirational target set before the work is scoped.

How quickly can a company switch PDPs/approved platforms?

There’s no universal answer. The variables that determine migration timeline include the number of legal entities in scope, the ERP landscape and integration architecture, the invoice formats and volume involved, the quality of master data, and the exit terms in the current contract.

Emergency failover to a precontracted secondary provider is faster than a full strategic migration — but only if the commercial and technical groundwork has been done in advance. A cold migration with no prior preparation, in a complex multi-entity environment, takes months. Internal readiness is best measured in executable steps with named owners and tested procedures — not in aspirational dates set without reference to the actual scope of work.

Selecting an approved platform is the start, not the end, of the risk management process. Provider approval status, SLA performance, incident history, and financial stability are live risk indicators that change. Schedule quarterly reviews, run an annual recovery exercise, and reassess your platform position after any acquisition, significant platform change, or new country mandate.

Build compliance that’s ready for what comes next

Avalara E-Invoicing and Live Reporting is certified as an approved platform by the DGFiP — one of the first providers to achieve that designation. It connects to your existing ERP, billing, and commerce systems through a single API, handling invoice exchange, e-reporting, life cycle status management, and regulatory updates across France and other mandate markets.

Powered by agentic AI, Avalara continuously monitors compliance obligations, adapts to regulatory change, and surfaces exceptions before they become incidents — so your teams spend less time managing the compliance process and more time running the business.

Resilience built for France is the foundation for wider European e-invoicing compliance. The architecture decisions you make now — how to connect ERP and approved platforms, where compliance logic sits, how to standardise across markets — apply to every mandate your business enters next.