In brief: the direct answer
What an access point does, what it must not own, and the questions to ask before signing. Access points is best approached through provider as a route, not as the record owner. For access points, the exit and data return terms decides the outcome. For access points, the exit and data return terms missing means rejection. For access points, the exit and data return terms wrongly mapped means wrong meaning. This guide keeps returning to one check for access points: ask about exit terms before signing.
The route stage for access points is Route. At Route, the exit and data return terms is what follows next. For access points, a Route decision cannot be repaired later. For access points, a Route decision cannot be repaired cheaply. Check the exit and data return terms for access points before moving on.
The record at this stage
Follow the invoice as a record through access points. At Route, the record for access points carries the exit and data return terms. Answer the exit and data return terms for access points with evidence. Then the rest of networks, access points and peppol becomes easier. Then the rest of access points becomes easier to check.
Describe the record before the system for access points. Systems change, but the exit and data return terms for access points stays. Providers change, but the exit and data return terms for access points stays. Formats change, but the exit and data return terms for access points stays. For access points, ask what record a system produces. For access points, ask what record a system accepts. For access points, ask what status evidence it returns.
What the data must carry
The data that matters most for access points is the exit and data return terms. That is not a slogan for access points. It is what the next access points check looks at. If the exit and data return terms for access points is missing, expect rejection. If the exit and data return terms for access points is ambiguous, expect rejection. If the exit and data return terms for access points is wrongly formatted, expect rejection.
Check the exit and data return terms as the receiver reads access points. For access points, screen correctness is not enough. For access points, file correctness is not enough. For access points, mapping correctness matters too. Use the mapping table for access points first. Use the receiver test for access points second. Use a sample invoice for access points third.
Validation and evidence
For access points, validation has three gates. Access points structure comes first. Access points business rules come second. Access points receiver rules come third. Each access points gate has its own failure message.
A access points rejection should name its rule. A access points rejection should name its field. A access points rejection should name the value sent. A access points rejection should name the value expected. Without those facts, a access points rejection is a delay. Return a access points rejection with that request.
Evidence for access points is what remains afterwards. Keep the access points invoice as exchanged. Keep access points status messages with it. Keep any access points correction linked to it. An auditor for access points asks for that set.
Where it breaks, and the check to make first
The common access points break is simple. For access points, ask about exit terms before signing was skipped. For access points, the receiver found the problem. For access points, the sender must now correct it. For access points, the sender must resend it. For access points, the sender must explain it.
Illustration, with round numbers only, for access points: A seller sends 20 invoices for access points. 2 fail on the exit and data return terms for access points. Checking the exit and data return terms first for access points costs minutes. A access points receiver rejection costs days. Sometimes a access points rejection costs a payment cycle. That is why access points repeats one check: ask about exit terms before signing.
What to verify before acting
Before acting on access points, verify three things. First, jurisdiction and transaction for access points. First, buyer and country for access points. Second, OpenPeppol: Peppol BIS Billing 3.0 for access points today. Third, the access points buyer requirement in writing.
A guide on access points organises those questions. A guide on access points cannot answer a specific transaction. This guide on access points gives general information only. This guide on access points is not advice for a specific invoice. For a specific invoice about access points, check OpenPeppol: Peppol BIS Billing 3.0. For a specific question about access points, ask a qualified adviser.
How this guide is layered
Every guide on this site is read through the same twelve layers, in the order that fits its topic: network, validation, tax, accounting, lifecycle, evidence, direct intent, transaction, jurisdiction, obligation, data, format. The layers are a reading method, not a claim about any single system.
Evidence basis: Primary sources named in the sources section, checked 2026-10-27; country guides are dated research routes, not mandate calendars. Scope: General educational information only; no individual legal, tax, accounting or compliance advice; jurisdiction and transaction specific checks remain with the reader.
Related guides
- Networks and access points explained: how an invoice is routed - Direct exchange, providers, platforms and the Peppol network, compared by addressing, acknowledgement and responsibility.
- Service metadata and capability lookup - How a sender learns what a receiver can accept, before the first invoice is sent.
- Message status and acknowledgements across a network - Transport acknowledgement, delivery and business acceptance are three different statuses, and confusing them hides failures.
Back to the pillar guide: Networks and access points explained: how an invoice is routed.
In this topic
- Networks and access points explained: how an invoice is routed
- Direct exchange vs network exchange
- Government platforms and portals as routes
- Message status and acknowledgements across a network
- Multi-network strategy for sellers with many buyers
- Network costs and contracts to check
- Network failures and retries: a safe retry rule
- Peppol ids and addressing: getting the recipient right
- Peppol network: how it works, in plain terms
- Service metadata and capability lookup
Primary sources and further reading
These official resources support the standards and regulatory context. Check their current versions before implementation.
- OpenPeppol: Peppol BIS Billing 3.0 - Billing profile, information elements and validation
- OpenPeppol: Billing validation rules - Technical and business rule examples