Teams sometimes talk about Peppol as if it will replace every invoice delivery path immediately. In practice, many products still need email fallback next to Peppol for a while.

That does not make the rollout weaker. It just means your delivery model needs to match real customer reach and onboarding maturity.

When fallback is usually needed

Email fallback is often relevant when:

  • not every receiver is onboarded to Peppol yet
  • rollout is phased by country or customer segment
  • your product needs broad delivery coverage before full network adoption

The important part is not fallback itself. It is whether the product makes the delivery outcome visible and understandable.

What teams should avoid

The weak version of fallback is when the product quietly changes channels and leaves support teams guessing what happened.

A stronger model usually makes clear:

  • whether Peppol delivery was possible
  • why a fallback path was used
  • what status the user should actually trust

A practical takeaway

Email fallback can be a sensible part of a rollout model, especially early on. The mistake is not using fallback. The mistake is hiding it inside an opaque delivery flow.

If your team is designing that model now, read How to check if a company is on Peppol , What status events your Peppol API should expose , and How Peppol registration actually works .