How to test a Peppol integration before production

A Peppol integration test plan should prove that your product can handle a document throughout its lifecycle. It needs to cover the invoice data, participant setup, processing history and the information your customer sees when something goes wrong.

Use a provider-approved test environment and test identities. Do not send invented commercial invoices to real trading partners simply to see whether delivery works.

Define the scope before assembling test documents

Write down the sending and receiving roles, supported document types, intended markets and applicable specification release. Do not treat “Peppol” as one interchangeable format for every country and process.

For a BIS Billing implementation, the official Peppol BIS Billing documentation provides invoice and credit-note syntax, validation rules and examples. Record which rule set you use so the same test can be repeated after an update.

A practical acceptance matrix

Test	What to exercise	Evidence to retain
Valid invoice	A document representative of your first customer group	Original document, validation result and processing references
Credit note	An appropriate correction scenario	Document references and a clear distinction from a new invoice
Invalid content	A deliberate missing field or inconsistent total	Actionable error detail and no false success message
Receiver mismatch	Incorrect or unsupported receiver setup in the test environment	A clear failure path and instructions for the next check
Repeated request	The same intended submission attempted again	The provider’s documented duplicate-handling behaviour
Uncertain outcome	Timeout after submission may have reached the provider	A way to investigate before blindly resending
Delayed or repeated event	Status updates arriving late or more than once	Stable customer-facing state and a traceable event history
Access boundary	Users from different organisations	Evidence that one customer cannot inspect another customer’s documents

These are acceptance goals, not Nexbal API endpoints or a guarantee of a specific retry mechanism. Agree the actual API contract, identifiers and event behaviour with the provider.

Do not collapse every status into “delivered”

Submission accepted by an API, successful transport and a buyer’s business decision are different facts. A buyer may still dispute a technically delivered invoice.

The Peppol Invoice Response specification distinguishes transport acknowledgements from business responses. Invoice Response support and use must be established for the parties involved; do not assume every recipient will send one.

Your interface should say only what the available evidence supports. A delivery signal alone does not prove that the customer accepted the invoice or that money reached the seller’s bank.

Work through one timeout scenario

Imagine your application submits an invoice and the network connection fails before it receives a response. There are at least two possibilities: the provider did not receive the request, or it received and processed it while the response was lost.

The correct recovery depends on the provider’s contract. Before retrying, the application needs a documented way to resolve the uncertainty, such as querying a known reference or using an agreed idempotency mechanism. Do not invent a new invoice number to make the error disappear.

Ask support to explain this case using the product interface and permitted diagnostics. If only the developer who wrote the integration can tell what happened, operational readiness is incomplete.

Keep a compact evidence record

For each case, retain the test identifier, expected result, actual result, relevant references, environment and follow-up owner. Use synthetic data and avoid placing credentials or unnecessary customer information in logs.

A test that failed and was corrected should be rerun. Preserve enough history to understand what changed rather than replacing the failure record with a green checkbox.

Decide when the first customer can go live

Release only the scope you have exercised. Confirm who handles validation errors, who investigates uncertain submissions, and how the team pauses further sends if outcomes become unclear.

Use the onboarding checklist alongside this matrix. For the distinction between business software and infrastructure, see ReAI and Nexbal . Contact Nexbal to discuss the first flow and its acceptance criteria.