Skip to main content

Dictionary

This page defines common e-invoicing and e-delivery terms you will meet when working with Peppol, NemHandel, and related standards—plus vocabulary that appears in eCourier’s REST API, webhooks, and XML payloads. eCourier is an API service, so we include technical notions (identifiers, message types, validation) where they help you integrate; you do not need to be an engineer, but familiarity with HTTP and JSON is assumed.

Access Point (AP)​

An access point is a facilitator that can be used to send and receive messages on Peppol, NemHandel, or another channel. Both the sender and receiver of a document use an access point. You can think of it as a mailserver.

API​

API (Application Programming Interface) is how you integrate with eCourier programmatically—mainly the REST API for sending and receiving documents, managing companies and participants, and related operations. See API documentation.

Application Response​

An Application Response is a UBL XML document type (root ApplicationResponse) used to answer another business document with structured status codes and references to what is being answered. In e-invoicing on Peppol and NemHandel, it is the usual technical form of an invoice response. It is not the same as your REST API “application,” and it is not an MLR (message-level feedback between access points).

B2B​

B2B (business-to-business) means commercial exchange between two companies. Much e-invoicing on networks such as Peppol is B2B.

B2C​

B2C (business-to-consumer) means a business selling or communicating with private individuals. It is distinct from B2B and B2G; Peppol and similar networks are used mainly for B2B and B2G document exchange.

B2G​

B2G (business-to-government) means a business exchanging documents with public-sector bodies—for example e-invoices to a government agency. Peppol is widely used for B2G as well as B2B flows.

Channel​

A channel is a delivery network that eCourier uses to exchange documents. eCourier supports Peppol (European and international) and NemHandel (Denmark only). See PEPPOL and NemHandel.

CIUS​

CIUS (Core Invoice Usage Specification) is a national or regional “flavour” of the European semantic model for e-invoicing (EN 16931): it spells out how invoices should look and mean in practice in that market—codes, business rules, and examples—on top of the common core. Peppol BIS and UBL documents are often aligned with a CIUS; the customization and profile tell software which CIUS applies.

Company​

A company is a legal entity that can have multiple participants.

Corner 1​

Corner 1 is the sender’s business system in the four-corner model—for example ERP or accounting software where a document is created before it is handed to an access point.

Corner 2​

Corner 2 is the sender’s access point in the four-corner model. It registers participants in the SMP, routes outbound messages, and delivers documents toward corner 3 across the network.

Corner 3​

Corner 3 is the receiver’s access point in the four-corner model. It receives documents from the network (from corner 2) and passes them inward to corner 4.

Corner 4​

Corner 4 is the receiver’s business system in the four-corner model—where inbound documents are approved, booked, or archived.

CVR​

CVR (Centrale Virksomhedsregister) is the Danish Central Business Register company number. It is commonly used as a recipient identifier on NemHandel and in Peppol schemes such as DK:CVR.

Customization​

Customization is a marker in UBL XML (usually the CustomizationID field) that names which edition of the rules your document follows—for example OIOUBL versus Peppol BIS billing. Receiving software uses it with the profile and schema to validate and interpret the file correctly.

Document​

A document is a structured business message exchanged through eCourier (for example an invoice). In the documentation and API, “document” and “message” mean the same thing unless stated otherwise.

EAN invoice​

EAN invoice is an informal term—often used in Denmark and the Nordics—for electronic invoices delivered through networks like Peppol. It is not the same as a retail EAN barcode number; addressing on Peppol typically uses schemes such as GLN, VAT, or national identifiers.

EAN number​

EAN number is an older name for the organisation identifier that is now standardised and referred to as GLN (Global Location Number) in Peppol and NemHandel addressing. If you see “EAN number” in legacy materials, treat it as the same role as a GLN for network routing.

E-delivery​

E-delivery (electronic delivery) is the exchange of structured electronic documents between organisations using regulated networks such as Peppol and NemHandel, with access points routing traffic and participants as the network-wide addresses. It covers more than invoices—other profiles and message types use the same infrastructure—but e-invoicing is the most visible example. eCourier is an e-delivery service: it operates as an access point and exposes documents through the API and webhooks.

E-invoicing​

E-invoicing (electronic invoicing) means sending and receiving invoices as structured electronic documents via networks such as Peppol or NemHandel, instead of informal channels like e-mail PDFs. The main difference between electronic invoicing and classic invoicing is that the files are machine-readable and structured consistently in XML instead of a PDF or similar.

E2E​

E2E (end-to-end) means the whole journey of a document from the sender’s system to the receiver’s system across the four-corner model—not just one hop. People also say E2E for tests or checks that follow that full Peppol or NemHandel path, as a trading partner would experience it.

EN 16931​

EN 16931 is the European standard (CEN) for the semantic data model of structured e-invoices—what information an electronic invoice must carry and how it is meant to be understood, independent of a specific XML syntax. Member states implement it through national CIUS profiles; Peppol BIS billing specifications and much UBL-based e-invoicing on Peppol are aligned with EN 16931.

Four-corner model​

The four-corner model is the standard picture for Peppol and NemHandel e-invoicing: corner 1 (sender’s system) → corner 2 (sender’s access point) → corner 3 (receiver’s access point) → corner 4 (receiver’s system). The two business applications never connect directly; SML and SMP help the access points find each other. eCourier can serve as your access point (corner 2 when you send, corner 3 when you receive).

GLN​

GLN (Global Location Number) is a GS1 identifier (ISO 6523 ICD code 0088) commonly used to identify participants on Peppol and NemHandel.

ICD code​

An ICD code (International Code Designator, from ISO/IEC 6523) is the numeric code that identifies what type of organisation or participant ID you are using—for example 0088 for a GLN, 0184 for a Danish CVR in DK:CVR. Peppol and NemHandel use ICD codes together with the actual ID value so participants can be addressed and looked up in the SMP unambiguously.

Invoice response​

An invoice response is a structured document—in UBL often an Application Response—where the receiver tells the sender what they think of a specific invoice: accepted, under query, rejected, and similar, sometimes with line-level detail. On Peppol and NemHandel it is a separate profile from billing; it answers the business content of the invoice. Do not confuse it with an MLR, which only reports how the message was handled at the access-point layer.

MLR​

MLR (Message Level Response) is a document type that reports whether the message (the XML payload handed between access points) was received and passed initial technical checks—or failed before deeper processing. It is transport- and validation-oriented. An invoice response is different: it responds to the commercial invoice itself (accept/reject for business reasons).

NemHandel​

NemHandel is Denmark’s national network for exchanging structured electronic business documents (for example invoices). It is aligned with the same kind of access point model as Peppol but is limited to Denmark and uses OIOUBL with Danish identifier schemes such as DK:CVR (the Danish CVR number). See NemHandel.

OIOUBL​

OIOUBL (Offentlig Information Online; Universal Business Language) is the Danish XML standard for electronic business documents. NemHandel uses OIOUBL; see NemHandel.

Open Peppol​

Open Peppol is the non-profit association (OpenPeppol) that develops and maintains Peppol rules and specifications—including Peppol BIS—and coordinates how the framework is used across countries. Day-to-day message delivery still happens through access points and national Peppol authorities. More information: openpeppol.org.

Participant​

A participant is an address on a channel that can send or receive documents (messages). To exchange a document, your trading partner must have a participant as well; that participant may be registered at any access point—not necessarily eCourier. You can think of a participant like an e-mail address or phone number: a stable identity that is reachable network-wide on Peppol or NemHandel, independent of which provider hosts it.

In the eCourier platform, a company can have multiple participants.

PASR​

PASR (Peppol Authority Specific Requirements) is the extra layer of rules a Peppol authority adds on top of the shared Peppol specifications—covering topics such as accreditation of service providers, local identifier schemes, security, and service expectations in that country. Open Peppol coordinates the overall framework; each authority publishes its PASR for that market.

PINT​

PINT (Peppol International) is Peppol’s approach for electronic documents—especially billing—across many countries and legal settings. It defines a common base model that jurisdictions can specialize (for example tax and layout rules) so the same network idea works outside the original EU-centric Peppol BIS profiles. See Peppol’s PINT documentation.

Peppol​

Peppol (Pan-European Public Procurement On-Line) is an international framework and network for exchanging electronic business documents—especially e-invoices—between organisations and public-sector bodies. Exchanged documents are usually in Peppol BIS formats, but other supported document types exist. Delivery is via access points. See PEPPOL.

Peppol authority (PA)​

A Peppol authority (PA) is the organisation responsible for Peppol in a given country or region: accrediting service providers, publishing PASR, and making sure local practice matches the rules maintained by Open Peppol.

Peppol BIS​

Peppol BIS (Business Interoperability Specifications) defines the XML document formats used on the Peppol network—for example Peppol BIS Billing 3.0 for invoices. See PEPPOL.

Profile​

A profile is a named combination on Peppol (and similar networks) of document type and business process—for example “invoice in the standard billing flow.” The SMP lists which profiles a participant supports so senders know which documents can be delivered. The customization value in the XML ties the file to the exact technical rules for that profile.

Schema​

A schema is a machine-readable description of how a document must be structured—what pieces it may contain, which parts are required, and how they fit together. For XML invoices and similar files, the schema is often written as XSD; extra business rules may be checked with Schematron.

Schematron​

Schematron is a rule-based way to validate XML—for example “this field must appear when that code is used.” It complements a schema such as XSD. Rules are commonly executed using XSLT.

SML​

SML (Service Metadata Locator) is the shared “switchboard” for Peppol and NemHandel. When a sender needs to reach a recipient, the network first asks the SML where to look next—it points to the right SMP for that participant, a bit like directory assistance telling you which phone book to open.

SMP​

SMP (Service Metadata Publisher) is a directory used on Peppol and NemHandel. It lists who can receive which kinds of documents and which access point they use—so senders can look you up and route traffic correctly. eCourier keeps this information up to date when you manage participants on Peppol or NemHandel; you normally do not interact with the SMP directly.

UBL​

UBL (Universal Business Language) is a standard XML vocabulary for business documents such as invoices and credit notes. OIOUBL is Denmark’s UBL-based profile for NemHandel; Peppol BIS uses UBL as the basis for documents on Peppol.

ULID​

ULID (Universally Unique Lexicographically Sortable Identifier) is a compact, time-sortable unique identifier (often 26 characters in Crockford’s base32). eCourier uses ULIDs for most resource references in the API (paths, IDs in JSON, webhooks, and similar), so you will usually see a ULID rather than a UUID when identifying platform objects.

UUID​

UUID (Universally Unique Identifier) is a standard 128-bit identifier, usually written as a hyphenated hexadecimal string (for example in API paths and JSON payloads) so resources can be referenced uniquely without a central allocator.

Webhook​

A webhook is an outbound HTTP callback: eCourier POSTs a JSON payload to a URL you configure when something happens (for example a document is received or its status changes). Webhooks complement the API for event-driven integrations. See Webhook documentation and API & webhooks.

XML​

XML (Extensible Markup Language) is a text format for structured data: nested tags with a defined meaning, readable by both people and software. E-invoicing on Peppol and NemHandel typically uses XML files—often UBL-based profiles such as OIOUBL or Peppol BIS.

XSD​

XSD (XML Schema Definition) is a standard language for describing and checking the structure of an XML file (allowed elements, order, and simple data types). An XSD file is the usual form of schema for many invoice and document formats.

XSLT​

XSLT (Extensible Stylesheet Language Transformations) is a language for turning one XML document into another XML document, HTML, or plain text. It is often used to run Schematron checks or other validation and transformation steps on business documents.