Peppol Participant Lookup – Reachability Monitor

What does Peppol Participant Lookup do?

Peppol participant lookup for ERP, accounting and invoicing software: before you send an e-invoice, find out whether the customer can receive it. Give a list of KvK, VAT, KBO, GLN or SIREN numbers and get, per company, whether it is reachable on Peppol, under which participant ID, which document types and processes it accepts, and which access point receives them. Monitor mode follows your counterparties and new registrations and tells you only what changed.

The problem: can this customer receive an e-invoice?

Belgium and France are moving invoices between companies to structured e-invoicing (e-facturatie in Belgium), with Peppol as one of the networks that carries them; check the dates and rules that apply to you with each country's tax administration. If you build an ERP or invoicing tool, "send via Peppol" only works when you know three things about the counterparty:

1. Is it registered and reachable? Being listed in the Peppol Directory is optional; being registered in the network (SML) with an access point is what counts.
2. Under which participant ID? A Belgian company can be registered under its enterprise number (0208) or its VAT number (9925). A Dutch one under KvK (0106) or VAT (9944).
3. Does it accept what you send? A UBL invoice, a credit note, an NLCIUS or XRechnung variant, invoice responses?

This Actor answers all three from the live network, in bulk, and keeps watching.

How the check works

1. Peppol network (SML). The identifier is looked up in the Peppol production SML (edelivery.tech.ec.europa.eu) through DNS. Not found means not reachable, whatever the directory says. Test participants are not covered.
2. The participant's SMP. Its service metadata lists the document types, processes and access point endpoints, with the access point certificate that names the provider.
3. Peppol Directory. The public business card adds the registered name, country and registration date. The Directory REST API is queried at no more than 2 requests per second.

Identifiers are validated first, so a malformed number never costs a lookup: KBO/BCE and Belgian VAT numbers, GLN and SIREN are checked by their check digit, the other types by length and format only. A typo that keeps the format of a type without a check digit, such as a KvK number, is looked up and charged, and normally comes back not-registered. Belgian companies are registered under their enterprise number, their VAT number or both: the scheme of the number you give is tried first (0208 for a KBO/BCE number, 9925 for a VAT number), the other only when the first is not registered, and the first registered one is used. participantIdsChecked lists both IDs in that order, also when the first one was registered and the second was not queried.

Supported identifiers

Type	Identifier	Example	Peppol scheme(s) checked
nl-kvk	Netherlands KvK number	12345678	0106
nl-vat	Netherlands VAT number (btw-id)	NL123456789B01	9944
nl-oin	Netherlands OIN (government organisations)	00000001234567890000	0190
be-enterprise	Belgium enterprise number (KBO/BCE)	0403.170.701	0208, 9925
be-vat	Belgium VAT number	BE0403170701	9925, 0208
fr-siren	France SIREN	784301772	0002
fr-siret	France SIRET	78430177200025	0009, 0002
fr-vat	France VAT number	FR40303265045	9957
de-vat	Germany VAT number (USt-IdNr.)	DE123456789	9930
de-leitweg	Germany Leitweg-ID	991-01234-56	0204
gln	GLN (Global Location Number)	8712345678906	0088
duns	D-U-N-S number	123456789	0060
dk-cvr	Denmark CVR number	12345678	0184
se-orgnr	Sweden organisation number	5560360793	0007
no-orgnr	Norway organisation number	987654321	0192
it-vat	Italy VAT number (Partita IVA)	IT12345678901	0211

Any Peppol participant ID in the form 0106:12345678 or iso6523-actorid-upis::0106:12345678 also works.

Features

• Bulk Peppol reachability check by KvK, VAT, KBO, GLN, SIREN number or participant ID, from the live network
• Peppol participant ID lookup: which scheme the company is registered under (0106, 0208, 9925, 9944 and the other ISO 6523 schemes)
• Document types and processes per participant from its SMP, with canReceiveInvoices and canReceiveCreditNotes ready to branch on
• Access point identification: provider, Peppol seat ID and endpoint URL from the access point certificate
• Monitor mode: only what changed for your counterparties, plus new registrations per country in a look-back window
• Registration-pending detection: business cards that are not yet resolvable in the network are re-checked every run
• Invalid identifiers and failed lookups are never charged
• Runs through the Apify API, on a schedule, or from Make, Zapier and n8n

Use cases

ERP and invoicing vendors: bulk e-invoicing reachability check

Put your identifiers in the input and run. Every identifier gets one record, every run. A typical onboarding job: your customer file has 500 KvK numbers, and you want a CSV telling you who can receive invoices over Peppol, and through which access point.

// npm install apify-client
import { readFileSync, writeFileSync } from 'node:fs';
import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });

// kvk.txt: one KvK number per line (500 lines)
const identifiers = readFileSync('kvk.txt', 'utf8').split(/\r?\n/).map((line) => line.trim()).filter(Boolean);

const run = await client.actor('lwsdjfls/peppol-participant-monitor').call({
    mode: 'lookup',
    identifiers,
    defaultIdentifierType: 'nl-kvk',
    includeProcesses: false, // faster; the access point is still included
});

const { items } = await client.dataset(run.defaultDatasetId).listItems({ clean: true });
const quote = (value) => `"${String(value ?? '').replace(/"/g, '""')}"`;
const rows = items.map(({ payload: p }) =>
    [p.input, p.status, p.reachable, p.name, p.participantId, p.canReceiveInvoices, p.canReceiveCreditNotes, p.accessPoint?.provider, p.accessPoint?.seatId].map(quote).join(','),
);
writeFileSync('reachability-report.csv', ['kvk,status,reachable,name,participant_id,invoices,credit_notes,access_point,ap_seat_id', ...rows].join('\n'));

const reachable = items.filter((item) => item.payload.reachable).length;
console.log(`${reachable} of ${items.length} companies can receive e-invoices over Peppol.`);

500 lookups cost $0.50. Numbers that are not registered need no Directory query; the run mostly waits on the 2 requests per second at which the Actor queries the Peppol Directory, for the companies that are registered: about 4 minutes when all 500 are.

Accounts payable automation: know when counterparties change

Schedule a task daily with "mode": "monitor" and your identifiers. The first run records every company. After that you receive a record only when something changed: a company became reachable (switch it to Peppol delivery), is no longer reachable (fall back to e-mail), changed its access point, or added or dropped document types. A lookup that fails (an SMP that is down, a DNS error) never counts as a change: the last known state is kept and the company is checked again next run.

E-invoicing providers: new registrations per country

Add countries to a monitor task and every run reports participants registered in the look-back window: leads for e-invoicing providers, or early warning that a customer is about to go live. A participant can have a business card in the Directory before it resolves in the network; those are delivered as registration-pending and reported again the day they become reachable.

How to use it

1. Start in Mode lookup and paste the numbers you already have into Company identifiers: KvK, VAT, KBO, GLN or SIREN, with the prefix shown in the field description. Set Default identifier type when your list is all one kind and carries no prefixes. Each identifier becomes one record telling you whether that company can receive an e-invoice today.
2. Switch to Mode monitor once you want to be kept up to date. Give the monitor a name in Monitor name, and it will follow the identifiers you listed, or every new registration in the Countries to follow, and report only what changed since the previous run.
3. Schedule the monitor daily and point Webhook URL at your own endpoint. Onboarding a supplier is worth doing the day they become reachable, not the next time somebody remembers to check.

Read the result through the views. reachability answers the practical question per company, documentTypes shows which invoice and order formats that participant actually accepts, and changes is the feed a monitor produces. The status message after each run counts new, changed and unchanged participants, so an empty result is visibly a quiet day rather than a failure.

One distinction matters more than any other here, and it is the reason this Actor exists. Being listed in the Peppol Directory is not the same as being reachable. A participant can be published in the directory while no access point answers for them yet, which is the state reported as registration-pending. Sending to that company will fail, so treat reachable as the only green light.

{
  "mode": "lookup",
  "identifiers": ["KVK:27124701", "BE0403170701", "KBO:0202.239.951"]
}

Input

Field	What it does	Example
mode	lookup checks every identifier on each run; monitor delivers only changes plus new registrations in the followed countries.	"lookup"
identifiers	One per line: KvK numbers, VAT numbers, prefixed numbers (KBO:0403170701, GLN:8712345678906, SIREN:784301772) or Peppol participant IDs (0106:12345678).	["KVK:27124701", "BE0403170701"]
defaultIdentifierType	How to read identifiers without a prefix or country code.	"nl-kvk"
countries	Two-letter country codes in capitals whose new registrations are followed in monitor mode.	["BE"]
lookbackDays	How many registration days to follow per country; pending registrations are re-checked within this window.	7
includeProcesses	Read the process identifiers of every document type from the participant's SMP. With it off, every document type is still listed, but their processes stay null.	true
maxDocumentTypesPerParticipant	Participants with very many document types are checked for this many; all are still listed, up to 200, the rest without their processes.	50
maxLookupsPerRun	Caps the charged lookups in one run. Each run checks identifiers in list order and stops at the cap, so set it to at least the number of identifiers in your list. The Actor queries the Peppol Directory at no more than 2 requests per second, which caps the run at about 7,000 registered participants per hour, and it keeps time free to deliver its records before the run's timeout, so a run with a one-hour timeout checks at most about 5,800 in lookup mode or a first monitor run (nearly 7,000 in a later monitor run that finds few changes). The default run timeout of 24 hours holds the 100,000 identifiers lookup mode accepts; with a shorter timeout, split a larger list into several runs.	10000
maxNewRegistrationsPerRun	Caps how many new and pending registrations are looked up in the network per run, country by country and newest registration day first. A monitor run delivers at most maxLookupsPerRun + maxNewRegistrationsPerRun changes. What a run holds back is left for later runs, which pick up a registration only while its registration day is within lookbackDays.	2000
maxConcurrency	Participants checked in parallel; the Directory itself is always queried at 2 requests per second.	8
webhookUrl	In monitor mode, receives a JSON summary with one line per change after each run that found changes; a public URL, stored encrypted.	https://hooks.example.com/peppol
stateKey	Keeps separate monitors apart, for example one per customer. Defaults to the task ID; runs started without a task and without a name share one state.	customer-acme

Lookup:

{
  "mode": "lookup",
  "identifiers": ["KVK:27124701", "BE0403170701", "KBO:0202.239.951", "SIREN:552081317"],
  "includeProcesses": true
}

Monitor:

{
  "mode": "monitor",
  "identifiers": ["KVK:27124701", "BE0403170701"],
  "countries": ["BE"],
  "lookbackDays": 7,
  "webhookUrl": "https://hooks.example.com/peppol"
}

Output

One record per identifier in lookup mode; in monitor mode one record per change, plus one per new registration in a followed country:

• status: reachable, registered-without-document-types, registration-pending, not-registered, invalid-identifier or lookup-failed. registered-without-document-types covers both a participant whose SMP publishes no document types at all and one whose document types have no access point endpoint: nothing can be sent to either, and statusReason says which of the two it is. lookup-failed covers both a lookup that could not be completed and, in lookup mode, an identifier the run did not reach before its timeout (while the run still had time to deliver that record); statusReason says which, and neither is charged
• participantId, name, country, registrationDate
• documentTypes: every document type, up to 200 per participant, as documentTypeId, documentTypeName (the name from the Peppol code lists, null for an identifier the lists do not name) and processes; documentTypesTruncated is true when the SMP publishes more. processes is null for a document type whose metadata was not read: those past maxDocumentTypesPerParticipant, or all of them when includeProcesses is off
• canReceiveInvoices, canReceiveCreditNotes: EN 16931 invoices and credit notes, ready to branch on
• accessPoint: the receiving access point provider, its Peppol seat ID (for example PNL000151) and endpoint URL
• accessPointCount: how many distinct access point endpoints were seen in the document types whose metadata was read - with includeProcesses off that is the preferred document type only, so treat it as a lower bound
• statusReason: why the status is what it is, in plain words (not in the network registry, a business card without a registration, an SMP without document types, document types without an access point endpoint, why a lookup failed, or how many of the published document types were checked); null when a participant is plainly reachable
• In monitor mode: changeType (added, changed, removed) with the old and new values

Document type names come from the Peppol Code Lists v9.7.

{
  "envelopeVersion": 1,
  "id": "0106:34218276",
  "scope": "country:NL:2026-09-15",
  "changeType": "changed",
  "sourceUrl": "https://directory.peppol.eu/public/locale-en_US/menuitem-search?q=iso6523-actorid-upis%3A%3A0106%3A34218276",
  "scrapedAt": "2026-09-16T08:00:00.000Z",
  "firstSeenAt": "2026-09-15T08:00:00.000Z",
  "hash": "811f872153b236042608ce03b82196daa4361a800c0c9443e9996061db84d5d3",
  "previousHash": "9966c2e316605ad0ebeb40238fdf4b968ac98368167cf4a7012d4c36c28a4ad6",
  "changes": [
    {
      "path": "documentTypes[busdox-docid-qns::urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100::CrossIndustryInvoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::D16B]",
      "change": "added",
      "newValue": {
        "documentTypeId": "busdox-docid-qns::urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100::CrossIndustryInvoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::D16B",
        "documentTypeName": "Peppol BIS Billing CII Invoice V3",
        "processes": [
          "cenbii-procid-ubl::urn:fdc:peppol.eu:2017:poacc:billing:01:1.0"
        ]
      }
    }
  ],
  "summary": "Appelman Events (0106:34218276): +1 document type (Peppol BIS Billing CII Invoice V3)",
  "diffText": "+ documentTypes[busdox-docid-qns::urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100::CrossIndustryInvoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::D16B]: {\"documentTypeId\":\"busdox-docid-qns::urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100::CrossIndustryInvoice…",
  "payload": {
    "input": null,
    "identifierType": null,
    "status": "reachable",
    "statusReason": null,
    "reachable": true,
    "participantId": "iso6523-actorid-upis::0106:34218276",
    "participantIdsChecked": [
      "iso6523-actorid-upis::0106:34218276"
    ],
    "name": "Appelman Events",
    "country": "NL",
    "registrationDate": "2026-09-15",
    "listedInDirectory": true,
    "smpUrl": "https://smp.peppol.storecove.com",
    "accessPoint": {
      "provider": "Storecove (Datajust B.V.)",
      "seatId": "PNL000151",
      "providerCountry": "NL",
      "endpointUrl": "https://ap.storecove.com/as4",
      "transportProfile": "peppol-transport-as4-v2_0",
      "certificateValidTo": "2028-02-28T23:59:59.000Z"
    },
    "accessPointCount": 1,
    "documentTypes": [
      {
        "documentTypeId": "busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##urn:fdc:peppol.eu:poacc:trns:invoice_response:3::2.1",
        "documentTypeName": "Peppol Invoice Response transaction 3.0",
        "processes": [
          "cenbii-procid-ubl::urn:fdc:peppol.eu:poacc:bis:invoice_response:3"
        ]
      },
      {
        "documentTypeId": "busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##urn:fdc:peppol.eu:poacc:trns:mlr:3::2.1",
        "documentTypeName": "Peppol Message Level Response transaction 3.0",
        "processes": [
          "cenbii-procid-ubl::urn:fdc:peppol.eu:poacc:bis:mlr:3"
        ]
      },
      {
        "documentTypeId": "busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0::2.1",
        "documentTypeName": "SI-UBL 2.0 Credit Note",
        "processes": [
          "cenbii-procid-ubl::urn:fdc:peppol.eu:2017:poacc:billing:01:1.0"
        ]
      },
      {
        "documentTypeId": "busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1",
        "documentTypeName": "Peppol BIS Billing UBL Credit Note V3",
        "processes": [
          "cenbii-procid-ubl::urn:fdc:peppol.eu:2017:poacc:billing:01:1.0"
        ]
      },
      {
        "documentTypeId": "busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0::2.1",
        "documentTypeName": "SI-UBL 2.0 Invoice",
        "processes": [
          "cenbii-procid-ubl::urn:fdc:peppol.eu:2017:poacc:billing:01:1.0"
        ]
      },
      {
        "documentTypeId": "busdox-docid-qns::urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1",
        "documentTypeName": "Peppol BIS Billing UBL Invoice V3",
        "processes": [
          "cenbii-procid-ubl::urn:fdc:peppol.eu:2017:poacc:billing:01:1.0"
        ]
      },
      {
        "documentTypeId": "busdox-docid-qns::urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100::CrossIndustryInvoice##urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::D16B",
        "documentTypeName": "Peppol BIS Billing CII Invoice V3",
        "processes": [
          "cenbii-procid-ubl::urn:fdc:peppol.eu:2017:poacc:billing:01:1.0"
        ]
      }
    ],
    "canReceiveInvoices": true,
    "canReceiveCreditNotes": true
  }
}

Pricing

Pay per result, priced for bulk use.

Event	Name	What it means	Price
apify-actor-start	Actor start	Charged by Apify when a run starts: once for a run of up to 1 GB of memory, and once more for every extra GB. It covers the first five seconds of compute.	$0.00005 per run up to 1 GB of memory ($0.05 per 1,000)
participant-lookup (primary)	Participant lookup	One identifier checked against the Peppol network (SML, SMP and Directory) with a definite answer: reachable, registered without document types, registration pending, or not registered.	$0.001 per lookup ($1.00 per 1,000)
change-detected	Change detected	In monitor mode: a new registration in a followed country, or a followed participant that became reachable or unreachable, or changed document types, name or access point.	$0.004 per change ($4.00 per 1,000)

These are list prices, which the Free plan pays. Paid Apify plans pay less for every event except the Actor start: 5% on Apify's Bronze tier, 10% on Silver and 15% on Gold and higher.

Invalid identifiers and lookups that could not be completed are never charged. A run that cannot query the Peppol network registry at all, because DNS to the SML is blocked where it runs, stops before the first identifier and costs no more than the Actor start; when the lookups fail with an error rather than an answer, it first tries again for up to 200 seconds, and never for more than half of the time the run has left. In monitor mode each followed identifier costs a lookup per run, and a change costs extra only when something actually changed. A daily watch over 500 counterparties costs 500 × $0.001 = $0.50 per run in lookups, plus $0.00005 for the Actor start and $0.004 per change: $0.50005 for a run without changes. Following a country is capped by maxNewRegistrationsPerRun: at the default 2,000 a run charges at most $8.00 for new registrations, and the first run looks up every registration in its look-back window at once, so it reaches that cap when the window holds more than 2,000 - lower maxNewRegistrationsPerRun or lookbackDays to set your own ceiling. Business cards of earlier registrations whose name or country changes, or that disappear from a followed registration day, are charged as changes too; they need no lookup, so maxNewRegistrationsPerRun does not limit them; the cap of maxLookupsPerRun + maxNewRegistrationsPerRun changes per run and your spending limit do. A change is charged when its record is written to your dataset. To cap what a run can cost, set Max cost per run in the run options in Apify Console, or pass maxTotalChargeUsd when you start a run through the API (Console accepts no limit below $0.00105, one Actor start plus one lookup); the run never charges more than that limit. When your spending limit is reached, a run stops checking: identifiers are checked in list order, so a limit below the cost of your whole list leaves the end of the list unchecked on every run. Changes a run holds back are left for later runs, which pick up a registration only while its registration day is within lookbackDays; a registration that leaves the window first is never delivered or charged. The default run timeout is 24 hours, enough for the 100,000 identifiers lookup mode accepts (about 17 hours at the Directory's 2 requests per second, with delivery); you can set another timeout in the run options. A run that gets close to its timeout stops starting lookups and delivers what it has. In lookup mode each identifier it did not reach gets a free lookup-failed record whose statusReason says so, for as long as the run still has time to deliver those records; the identifiers after that are not in the dataset, and the log and the run's status message say how many were not processed. Identifiers past maxLookupsPerRun get no record either way, as the cap leaves them out. In monitor mode the identifiers it did not reach keep their last known state, and registrations and registration days it did not reach are left for later runs, like the ones a limit holds back. A new run starts again at the top of the list, so submit only the identifiers that were not checked, split a large list, or give the run a longer timeout.

Worst case with the default limits: a lookup run charges at most 10,000 lookups (maxLookupsPerRun) at $0.001 each, which is $10.00, plus $0.00005 for the Actor start at the default 512 MB of memory, so $10.00005. A monitor run can also charge at most 10,000 + 2,000 = 12,000 changes (maxLookupsPerRun + maxNewRegistrationsPerRun) at $0.004 each, which is $48.00, so it costs at most $10.00 + $48.00 + $0.00005 = $58.00005. Without countries to follow, a monitor run charges at most one change per lookup, so at most 10,000 changes, $40.00, and $50.00005 in total. Lower either cap to lower that ceiling.

FAQ

Is "listed in the Peppol Directory" the same as "reachable"?

No. Publishing a business card in the Directory is optional, and a card can outlive a registration. This Actor decides reachability from the Peppol network registry (SML) and the participant's SMP, and uses the Directory only for the name, country and registration date.

What does registration-pending mean?

The participant has a business card in the Directory, but is not (yet) resolvable in the Peppol network (SML), so nothing can be sent to it yet. The card is published by the provider that registers the participant, and it can be there before the registration resolves in the network; how long that takes is up to that provider, so this Actor reports the state it finds instead of predicting it. Monitor mode re-checks a pending registration every run, as long as its registration day is within lookbackDays, and delivers it again the day it becomes reachable.

Can I monitor all participants of a country?

New registrations, yes. A complete daily picture of every participant is not what this Actor gives: it reads at most 1000 results per Peppol Directory query, so registrations are followed per country and per registration day. When a country has more than 1000 registrations dated on one day, the first 1000 of that day are followed and the run log says so.

Is a Peppol participant lookup GDPR-compliant?

Peppol participants are organisations, but for sole traders the registered name can be personal data under the GDPR. This Actor therefore collects only what identifies the organisation's e-invoicing capability. Never collected: contact persons, e-mail addresses and phone numbers from the Directory business cards, addresses and free-text fields, and the technical contact of access points; these fields are dropped when the data is read and cannot appear in the output or the stored state, as enforced by automated tests. Kept: participant ID, registered name, country, registration date, document types and processes, and the access point provider (an organisation).

What are the limitations?

• The Peppol Directory is queried at no more than 2 requests per second, which bounds how fast registered companies can be enriched with their name. That is about 7,000 registered participants per hour, and a run keeps time free to deliver its records before its timeout, so a run with a one-hour timeout checks at most about 5,800 in lookup mode or a first monitor run, and nearly 7,000 in a later monitor run that finds few changes. The default run timeout of 24 hours holds the longest list lookup mode accepts; a run given a shorter timeout needs a shorter list, or several runs.
• Access point names come from the access point certificate (O=), which can hold a legal entity name that differs from the provider's brand.
• SMPs are run by many providers; a slow or failing SMP, or one that answers with more than 2 MB, makes that lookup lookup-failed (not charged) rather than guessing.
• While the Peppol Directory itself is unavailable, identifiers that are registered in the network end as lookup-failed (not charged), because their name comes from there; identifiers that are not registered still get their answer. In monitor mode a registration day the Directory could not answer stays unfinished, and a later run picks it up while that day is within lookbackDays. A monitor run that follows countries and no identifiers, and could load none of its registration days, waits for the Directory once, for up to 10 minutes (less when its timeout is near), and when the Directory answers again, searches the other days once more; a run that loaded a registration day does not wait.
• Only the production network is covered; test participants are not.
• Each identifier type is looked up only under the Peppol scheme(s) in the table of supported identifiers. A Dutch company registered only under its VAT number (9944) comes back not-registered when you give its KvK number (0106), and that answer is charged. Only Belgian numbers (0208 and 9925) and SIRET numbers (0009, then the SIREN under 0002) are tried under two schemes, so when you have several numbers for a company, list each of them.
• reachable means the Peppol network registry points to an SMP that publishes an access point endpoint for the participant. The Actor sends no test message, does not verify the SMP's signature or validate the access point certificate, and does not look at the endpoint's activation or expiration date. accessPoint.certificateValidTo is in the output if you want to check the certificate date yourself.

Related Actors

• VIES VAT Validator: is the counterparty's VAT number valid? The other half of the check before an invoice goes out, with consultation numbers for reverse charge.
• EU Company ID Resolver: from any company number to the others, including the Peppol participant IDs a company is registered under.
• IBAN Validator & Bank Enricher for the bank details on the invoice: offline IBAN validation with bank name and BIC.

Support

Missing an identifier type your customers use? Open an issue on the Actor page. We usually respond within a day.

Last live run against the Peppol SML, the participants’ SMPs and the Peppol Directory: 21 September 2026, with the input the Console form opens with.