When companies prepare for Peppol e-invoicing, testing often stops at XML validation. The file structure checks out, the Access Point accepts it so everyone assumes it will work.
But that check only proves the syntax is correct. It doesn’t show how your setup behaves in practice. We’ve seen projects where everything looked fine on paper, yet invoices piled up after go-live because the wrong scenarios were never tested.
Teams often assume that XML validation is enough. In reality, it’s only the start. To avoid surprises, Peppol testing needs to go further. A structured test plan helps you simulate the situations that cause the most trouble before customers or suppliers are affected.
Why XML validation isn’t enough
Peppol UBL testing goes beyond “does the file validate?” A UBL document can pass validation while still failing in real life:
- Tags don’t match what the receiver expects.
- Mandatory fields in your business flow are left unmapped.
Without spotting these issues upfront, you only discover them when invoices block in production. By then, it’s too late to prevent disruption.
Failures we’ve seen in real projects
Over the years, we’ve seen the same types of mistakes come back in different projects. A few examples:
Missing VAT numbers
In one project, VAT fields weren’t mapped for cross-border invoices. Nobody noticed during XML checks. At go-live, hundreds of invoices were rejected at once.
Wrong PO references
Supplier mentions the wrong PO references, leading to invoice matching errors. Clients mentions wrong PO references, leading to late payments by customers.
Lost confirmations
We’ve also seen confirmation messages disappear because the AP didn’t forward them. To the business, invoices looked like they were “in process” while customers had already rejected them.
These examples show that even small gaps in preparation can have major impact once real invoices start flowing.
Why structured testing matters
All of these failures had one thing in common: they slipped through because testing wasn’t structured. Ad-hoc testing gives a false sense of security. Someone validates a few XMLs, sees no error, and the project moves on. But the scenarios that really matter remain untested.
A Peppol test plan avoids those blind spots. It spells out:
- which flows need to be covered,
- which failure scenarios to simulate,
- who validates the outcome,
- and how results are tracked.
That way, problems are discovered when there’s still time to fix them, not after invoices are already stuck in production.
5 scenarios every Peppol project should cover
Connectivity breaks
What happens if the transfer fails halfway through? Does your system retry, or does the invoice disappear?
Wrong UBL format
One incorrect tag can trigger a rejection without anyone noticing. How does your setup detect and report it?
Access Point rejection without clear error
Some APs reject documents but don’t return a useful message. Will your team see what failed, or will they stay blind until customers complain?
Duplicate invoices
If the same invoice is sent twice, is it flagged or processed again?
Delayed responses
Customer systems don’t always reply instantly. Do your flows handle delays gracefully, or do they block the process?
The five scenarios above are the most common, but they’re not the whole picture. In practice, a solid test plan also covers cross-company flows, exception handling and monitoring responsibilities.
We’ve bundled these into a structured Peppol Test Plan template. It lists the full set of cases to cover and helps assign responsibilities, so testing becomes structured instead of improvised.
With the complete test plan, your team can validate the full range of scenarios and walk into go-live with confidence. And if you need a partner to support that process, we’re happy to guide you through it so you can fix the problems before your customers or suppliers notice them.
