Peppol integration for your app: send e-invoices via KRONENWERK

You integrate Peppol sending into your application through KRONENWERK by creating the invoice draft with POST /invoices/drafts, having the invoice issued and transmitted in the product, and receiving invoice.issued on your webhook endpoint. KRONENWERK is not a Peppol Access Point. It sends and receives over Peppol through an accredited access point provider (Storecove) once the company is connected in Settings → Delivery, and production sending depends on that account and its configuration. The capability is SUPPORTED WITH LIMITATIONS.

What Peppol is, for an integrator

Peppol is a four-corner delivery network: your company (corner 1) hands a document to its access point (corner 2), which looks up the receiver's access point (corner 3) through the SML/SMP directory and delivers to the receiving company (corner 4). Documents are structured UBL following Peppol BIS Billing 3.0, an implementation of EN 16931. Participants are addressed by identifiers such as a VAT number under a scheme from the OpenPeppol code lists, which are mandatory in the network and updated regularly (v9.7 as of 2 July 2026). The mechanism is explained on Peppol, identifiers on Peppol identifiers, and the practical side on sending and receiving over Peppol.

For a developer the consequence is simple: you never talk to the network directly. Somebody's access point does, and the question is whose. Building your own access point means OpenPeppol membership, accreditation, an AS4 gateway and SMP publication. Using KRONENWERK means the access point is Storecove's, the connection belongs to the company, and your code only talks to the KRONENWERK API.

The flow: draft, issue, transmit, webhook

1. Your app creates the customer with POST /customers. Give the customer a country and a VAT ID: the Peppol participant identifier of a Belgian receiver is derived from its enterprise or VAT number, and a customer without one cannot be addressed on the network.
2. Your app starts the draft with POST /invoices/drafts and an Idempotency-Key. The response is a draft in state DRAFT with the seller's numbering suggestion and the customer's payment terms.
3. A person issues the draft in the product. KRONENWERK computes the tax verdict, checks the VAT ID against VIES, renders Peppol BIS Billing 3.0 UBL for a Belgian seller, validates it and spends the number. invoice.issued is queued for your endpoint at this moment.
4. The invoice is transmitted from the product. Transmission is a separate, audited action on the issued invoice, not a side effect of issuing: the country module names the route (Peppol for Belgium), the connected access point provider carries the document, and the outcome is recorded against the invoice. If the outcome is unknown — a timeout after the request left — the product refuses to send again until a reconciliation call has asked the far side whether it holds the document. Retrying an unknown outcome is how one invoice becomes two.
5. Your app receives invoice.issued, verifies KRONENWERK-Signature, deduplicates on KRONENWERK-Event-Id, and stores invoiceId and number. Later, invoice.paid or invoice.cancelled follow.

What a developer must configure

Note what is not on the list: no SMP, no AS4 certificate, no OpenPeppol membership on your side. Also note what the API cannot do: it cannot connect the company to the network, cannot transmit, and cannot read the transmission log. Those are settings and acts a person performs in the product.

Example requests

curl -X POST https://kronenwerk.org/api/extern/v1/customers \
  -H "Authorization: Bearer greif_live_…" \
  -H "Idempotency-Key: crm-account-88213" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Voorbeeld BV",
    "street": "Rue de l'"'"'Exemple 12",
    "postalCode": "1000",
    "city": "Bruxelles",
    "country": "BE",
    "vatId": "BE0123456789",
    "email": "invoices@example.be"
  }'

curl -X POST https://kronenwerk.org/api/extern/v1/invoices/drafts \
  -H "Authorization: Bearer greif_live_…" \
  -H "Idempotency-Key: crm-account-88213-2026-09" \
  -H "Content-Type: application/json" \
  -d '{ "customerId": "3f2b…" }'

The customer response carries the partner number drawn from the company's own sequence (for example K-0042) and the fields as stored: id, number, name, contact, email, phone, street, postalCode, city, country, vatId, currency, customer, supplier, archived, createdAt. Name, street, postcode and city are required because EN 16931 carries an address in parts, and a customer with no street is one no document can be addressed to. The invoice API is described in full on the invoice API page.

Receiving over Peppol

In Belgium the obligation to receive structured invoices over Peppol applies to VAT-registered businesses without a threshold, so a connection that only sends would be half the obligation. Once the company is connected, incoming Peppol documents arrive at the access point provider, are handed to KRONENWERK, are read into bills and validated. Your integration learns about them through the purchase.recorded webhook, which carries purchaseId, kind, documentNumber, supplierName, supplierId, documentDate, dueDate, currency, netMinor, taxMinor and grossMinor. The inbound document itself is not exposed on the API. The Belgian context is on the Belgium hub and the country page Belgium.

Alternatives, honestly compared

If your requirement is fully automated sending with no person issuing, KRONENWERK's API is not that today, and a direct provider contract is the honest recommendation. The Peppol guide for developers covers what you would need to build in that case; Peppol vs national networks explains where Peppol is the route and where a national system (KSeF, French plateformes agréées) is.

How KRONENWERK handles this

SUPPORTED WITH LIMITATIONS KRONENWERK generates Peppol BIS Billing 3.0 UBL for Belgian sellers at issuance and sends and receives over Peppol through an accredited access point provider (Storecove) once the company is connected in Settings → Delivery. KRONENWERK is not itself an accredited or certified Peppol Access Point. Production sending depends on the company's Storecove account and configuration, and transmission is an action a person takes in the product after issuing. The API's part is the customer, the draft, the read-back and the webhooks, on the Enterprise plan. The Peppol route is wired for Belgian sellers; for German sellers the product produces XRechnung or ZUGFeRD for email or download and names no transmission route, because German law names none. French transmission is a different mechanism and is NOT YET READY — see French platforms. Product details: e-invoicing.