# How to turn a Peppol connection into a working invoice process Begin with the transaction you need to support. Identify its country, legal entity, customer or supplier, document type and reporting obligation. Then choose the network and provider that support that scenario. [Peppol](https://erplocalization.com/glossary/core/#core-peppol-and-openpeppol) gives businesses a way to exchange documents through service providers. OpenPeppol's specifications and governance describe that exchange. A national tax authority determines the relevant tax obligations. [OpenPeppol, information for end users](https://peppol.org/about/for-end-users/) This guide takes you through the implementation checks between buying a connection and operating it reliably. The controls are recommendations. Country-specific obligations need their own source evidence. **Diagram:** Create, validate, send, deliver and report are separate events. Conceptual workflow. Events and their order vary by national model; reporting can use a parallel route. ## Verify the provider and proposed service Find the supplier's legal name in the relevant register. OpenPeppol's certified-provider list distinguishes Access Point and Service Metadata Publisher roles. It also explains that the listed country is the provider's legal residence, rather than its operating territory. Record the identity and status that match the company signing your contract. [OpenPeppol, certified service providers](https://peppol.org/members/peppol-certified-service-providers/) Ask the provider to name the document profiles, countries, directions and tax-reporting services it will support for you. Record any separate national accreditation. A provider's ability to deliver one document profile says little about a different national reporting service. Ask who registers participant identifiers, publishes receiving capabilities and handles a provider change. Put ownership and exit assistance into the implementation scope. ## Confirm recipients through the supported discovery process Collect the participant identifier and its scheme. Preserve both fields in the ERP. A national business number without its scheme can be ambiguous. Have the provider confirm the recipient's document capabilities. Do not use a missing public-directory search result as the sole reason to declare the recipient unreachable. OpenPeppol says directory publication is optional and the directory does not include every registered receiver. [OpenPeppol, Peppol Directory](https://peppol.org/tools-support/peppol-directory/) Test one known recipient and one unknown or incompatible recipient. Record what the ERP tells the user and how the exception reaches the support team. Decide whether the workflow blocks posting, queues a document or creates a task. Those are business design decisions that need explicit agreement. ## Pin the document profile and validation release Store the required profile, syntax, code lists and validation release with the mapping. Use the released validation artifacts appropriate to the transaction. OpenPeppol publishes syntax rules, business rules and examples for BIS Billing. [Peppol BIS Billing documentation](https://docs.peppol.eu/poacc/billing/3.0/) Separate three checks: whether the file is structurally valid, whether business rules pass and whether the document represents the correct commercial transaction. A valid XML file can still contain the wrong buyer or tax treatment. Ask who updates validation artifacts when a release changes. Keep the tested release with the results so a later rejection can be investigated against the correct version. ## Define the events your ERP records Use separate events for creation, validation, provider acceptance, delivery, recipient response and tax reporting where applicable. Preserve the original response, correlation identifier and timestamp for each event. Do not assume that "sent" means every later step succeeded. Ask the provider what its acknowledgement establishes. Define which event releases each business action and which failures need a human decision. For inbound documents, agree how the ERP matches a supplier, detects duplicates, handles purchase-order references and creates a draft or posted bill. Test a document arriving before its supplier master record exists. Include credit documents and attachments in the scope decision. ## Configure tax-data submission separately If a national scenario requires a reporting feature, identify that feature explicitly. Singapore's IRAS guidance, for example, describes obtaining a Peppol ID and activating GST InvoiceNow submission through an accredited solution. The tax-data feature needs its own setup and evidence. [IRAS, GST InvoiceNow requirement](https://www.iras.gov.sg/taxes/goods-services-tax-%28gst%29/gst-invoicenow-requirement) Map every source application into the reporting population. Sales can originate in an ERP, subscription platform or point-of-sale system. Assign one reporting owner for each population and document how overlaps are prevented. Test invoice delivery and required tax-data reporting separately. Record what happens if one succeeds and the other fails. Ask the finance owner to approve the recovery procedure. ## Reconcile and recover At an agreed interval, compare source documents with provider records and relevant authority records. Reconcile document counts and amounts by status. Keep timing differences visible, including queued documents and corrections after period end. When a request times out, check its status using the provider's supported lookup before resubmitting. Preserve the original business-document identifier. Agree how the connector prevents duplicate financial documents and reports. For an outage, use a country-specific procedure approved by the finance owner. Record which documents can be issued, what evidence must be retained and how the backlog is submitted. A generic manual email process cannot establish that every national fallback rule is met. ## Accept the process Retain a test pack containing a normal invoice, credit document, invalid identifier, incompatible recipient, duplicate delivery and uncertain timeout. Add tax-reporting cases where required. Include inbound matching and a reconciliation sample. Acceptance should name the provider, participants, document profile, release, directions and tested reporting functions. Review that record when any of those components changes. Use the [provider selection guide](https://erplocalization.com/guides/choose-and-replace-e-invoicing-provider/) for the contract and migration questions. Use the [master-data guide](https://erplocalization.com/guides/localization-master-data-readiness/) for the fields that make the connection work. ## Related on this site - [Country pages](https://erplocalization.com/countries/): key facts with sources - [E-invoicing matrix](https://erplocalization.com/e-invoicing/): country × ERP support - [All guides](https://erplocalization.com/guides/) Vendor documentation is cited only as an example of the level of evidence to ask for; it is not a recommendation or a ranking. This guide is general information, not tax or legal advice. Checked 2026-10-17. Related: [Glossary](https://erplocalization.com/glossary/) – abbreviations and terms used in these guides (SAF-T, Peppol, CTC, EN 16931, IFRS and more). --- Canonical: https://erplocalization.com/guides/peppol-tax-compliance-checklist/ · Last updated: 2026-10-17 · Informational only; not tax, legal or implementation advice. Featured placements are paid or promotional and do not affect the compliance data. Data: CC BY-NC 4.0 (commercial use needs a licence: https://erplocalization.com/data-licence/), attribution "ERP Localization (erplocalization.com)".