2026 is just around the corner. And if you’re in Finance or IT, you’ve probably already felt the pressure. The deadline is clear but what often isn’t clear is how to actually start.
We’ve seen projects stall for weeks because: IT waits for business requirements, Finance assumes IT will handle it, Management thinks “it’s just compliance, how hard can it be?”.
Meanwhile, nothing concrete moves forward. Stress builds up and when the first invoices finally flow, small mistakes turn into big delays.
Peppol itself isn’t the issue. The problems come from the basics: no clear plan, scope that doesn’t match reality, the wrong people involved, poor testing, or missing KPIs.
That’s why we work with a 6-step structure in every Peppol project, supported by templates that help you get moving instead of staring at a blank page.
Step 1: Start with a clear Peppol project plan
The most common problem at the start? Everyone knows something needs to happen, but nobody is sure who moves first. Without structure, deadlines slip and small tasks keep bouncing around between teams.
A project plan doesn’t magically solve everything, but it forces clarity:
- which steps come first,
- who carries which responsibility,
- and where dependencies will block progress if you don’t act.
That’s why we built a Peppol Project Plan template so your team can start structuring work from day one.
Step 2 – Define your scope realistically
Scope mistakes cost months. We’ve seen companies over-scope: “let’s roll out in all countries at once” when only Belgium was required. And under-scope: only looking at SAP Finance, forgetting flows running through Procurement.
Both lead to the same thing: frustration and rework just before go-live. A realistic scope balances what’s mandatory with what your organisation can actually deliver.
Our Scope Overview template helps you capture what’s in, what’s out, and what can wait for later so you don’t discover missing flows when it’s already too late.
Step 3 – Involve the right stakeholders
Peppol touches multiple teams. Forget one, and you’ll feel it later.
One project we supported had Finance in the lead but Customer Service wasn’t told that rejections would come in through their mailbox. Result: they ignored them, invoices piled up, and suppliers stopped sending.
Another case: Procurement wasn’t involved until the end. Only then did anyone realise that a big share of invoices ran outside SAP Finance. By that time, testing was already done.
That’s why we use a simple Communication Checklist to clarify who’s involved, when and why. It avoids the “nobody told us” moments that derail projects.
Step 4 – Choose an Peppol Access Point that fits
Every Access Point has the same job: connect you to Peppol. But the way they do it differs.
Some are basic providers, perfect for freelancers or small accounting firms who just need to exchange low volumes. Others offer API-based connections, flexible for mid-sized businesses but still limited in support. And then there are full-service solutions like SAP DRC or Doctis, built to handle integration with complex SAP landscapes.
The choice depends on invoice volume, SAP version and the support your teams need. We’ve seen hidden costs trip companies up, like APs charging per message, not per document, which means even acceptance responses get billed. Our Access Point Scoring Template helps you weigh what matters most so you don’t underbuy or overpay.
Step 5 – Test beyond XML validation
“XML valid” doesn’t mean your invoices will flow. Real testing is about simulating what can actually go wrong. And it always does:
- a connection breaks halfway through,
- a UBL tag is wrong and silently rejected,
- a duplicate invoice slips through,
- a customer system delays its response.
If you don’t run these scenarios upfront, you’ll only discover them once invoices pile up in production.
We developed a test plan that covers the critical cases step by step. It makes testing tangible for both IT and Finance, instead of leaving it at “let’s hope the XML passes”.
Step 6 – Track KPIs after Peppol go-live
Going live doesn’t mean the job is done. If you don’t measure, you can’t improve. And without numbers, every discussion turns into guesswork. The KPIs that matter most:
- Adoption rate → are invoices really going through Peppol?
- Error rate → how many are rejected?
- Turnaround time → how fast do invoices reach your customer?
- Fallback usage → how often do teams fall back to PDFs?
- Cost per invoice → including hidden AP fees.
We’ve seen adoption stall because Procurement kept using old channels. Or error rates spike because field mapping wasn’t consistent. These metrics make problems visible so you can act before frustration builds up across teams.
If you want a benchmark for your industry, we’re happy to compare notes.
When Peppol projects get into trouble, it’s hardly ever the network. It’s the everyday things: – unclear scope, the wrong people missing in the room, testing skipped, or KPIs forgotten – that end up causing the stress.
These 6 steps won’t remove the deadline, but they will remove the chaos. And with the templates, you don’t have to start from scratch.
