Choose a Peppol service provider around the invoices your team must exchange

Start with the companies, customers and suppliers that need to exchange documents, the document types involved and the accounting systems on each side. A proposal to connect to Peppol is incomplete if it does not say what the company can send, receive and process through that connection.

OpenPeppol explains that businesses use the network through accredited service providers and that Peppol itself is not a portal supplying exchange services. The buyer therefore needs to select a provider and an operating arrangement. Network access and a usable connection to the company's ledger are separate parts of that arrangement.

Identify whether the immediate need is outgoing invoices, incoming invoices, credit notes or additional document types. Include the relevant countries and customer requirements without assuming one generic format satisfies every tax or procurement obligation. Have qualified local advisers confirm requirements that depend on jurisdiction.

State the volume and workflow expected after the first connection. A company sending a few documents through a portal may need a different service from one receiving large invoice populations into an ERP. Compare the complete operating task rather than the lowest advertised document price.

Check the proposed provider against OpenPeppol's current certified-provider directory. Confirm the legal entity, the relevant service and any intermediary involved in the commercial arrangement. A software reseller may offer access through another certified party, so the proposal should name the actual operating chain.

The directory states that its country or territory field identifies the provider's legal residence, not its area of operations. Do not use that field alone to infer geographic coverage. Ask the candidate to confirm the countries, document profiles and support arrangements included for the company's requirements.

If the proposal combines access-point service, directory-related administration, format conversion and ERP integration, ask which party supplies each component. Clarify who responds when a document passes one stage but fails the next. The company should not have to discover the service boundary during a billing deadline.

Obtain the proposed onboarding steps and identity information required for each legal entity. Have the company owner review those records before registration. An incorrect participant identity can make a technically successful integration unusable for the business relationship it was intended to serve.

Use a controlled invoice from the company's actual source system in an approved test arrangement. Trace seller and buyer identities, invoice number, dates, currency, lines, taxes, payment details and references through the provider's transformation. Ask the implementer to explain any field that is defaulted or omitted.

Have the accounting owner review the structured output as well as any human-readable rendering. A PDF can look familiar while the transmitted data contains a different code or amount. The acceptance evidence should preserve the relationship between the source invoice and the exchanged document.

Include a credit note and a document requiring a purchase-order reference if those occur in the company's workflow. A successful basic invoice does not establish support for every document type or customer requirement. The proposal should list what was actually demonstrated.

On the receiving side, inspect how the document enters the ERP's supplier, approval and posting process. Network delivery should not automatically imply that a new supplier is approved or that the invoice should be paid. Keep the company's normal review and authorization stages visible.

Ask the provider to explain every status it exposes and the event behind it. A document can be created, validated, transmitted, delivered and then questioned by the recipient for a business reason. The interface should not compress those events into a single paid-looking success label.

Use a deliberately invalid test document to inspect the validation response. The finance operator should be able to identify the field needing correction, the source-system owner and whether the document was transmitted. Technical errors need enough context to resolve without sending confidential invoice contents through an uncontrolled support thread.

Test a corrected resubmission using the provider's supported process. Track the identifiers connecting the original attempt and the correction. The company needs to know how to avoid duplicate business documents when an uncertain status prompts someone to try again.

Ask how a recipient's commercial rejection or query reaches the company where the proposed service supports that response. If the service does not carry the relevant response, name the separate channel and owner. Reliable delivery can coexist with an unresolved invoice dispute.

Request a quote that separates onboarding, each entity's setup, recurring service, document volume, conversion and integration support. Ask what counts as a billable document and how rejected attempts, retries and credits are treated. The unit definition matters as much as the per-document rate.

Estimate the company's internal exception work. Some failures will originate in customer or supplier master data, others in tax coding or missing references. A provider may identify the problem without owning the source correction. Assign those tasks before describing the service as fully automated.

Clarify record retention and export. The company should be able to retrieve the structured document, relevant statuses and source references for its own records. Determine which evidence remains available after termination and whether retrieving it requires a separate fee or service.

Ask who maintains mappings when the ERP, document specification or applicable local requirement changes. The contract should state how changes are identified, tested and charged. A one-time connection fee does not explain the cost of keeping an exchange working over several years.

Have an ordinary finance user send, receive, investigate and correct the agreed sample documents. Record the external support needed and the final accounting-system result. The purchase should be assessed on that complete workflow, not only on a successful network connection test.

Discuss changing providers before signing. Ask how participant records, pending documents and historical evidence are handled during a transition and which party coordinates each step. The proposed exit procedure should be specific enough to review without promising a frictionless move under every circumstance.

Choose the provider whose certified service, document coverage and support responsibilities match the company's exchange needs. The practical outcome is a traceable path between source records and counterparties, with clear ownership of exceptions and enough retained evidence to explain what was sent or received.